I think your suggestions solve the problems of customizers somewhat, but may not be enough. Let me reiterate the case again.
One class of user that I need to serve is someone who likes to tweak site design. This is mostly HTML tweaking, but does involve some TAL and simple Python expressions, pulling information out from an underlying application. It's a limited experience that you could consider to fit your "by the book" approach, but they do seem to need certain things that Zope 3 currently doesn't offer them.
Such people want a fast turn-around, and want a low dependency on tools (such as version control systems and editors). These people are not programmers and won't be learning how to check stuff into SVN any time soon. They *do* want the ability to tweak a bit in a site's design, or an app's UI, through a TTW environment. They currently get this with Zope 2, and they don't get it with Zope 3 or Five.
And then, what *I* want is a way to take some of what they've done under version control, under maintenance, clean it up, develop it further, without too much hassle.
Perhaps this class of users is so small they're considered unimportant, or perhaps they're not engaged in this discussion because we're programmers talking amongst ourselves. I think I heard from some of them at the last Plone conference, where I heard the question "well, but can you work with this through the web, without restarts?" a few times, in the context of Five. When they heard "No", they weren't exactly happy and said it was important for their way of working. It's not my way of working, but their way works well enough for them, so they obviously don't like hearing "change your way of working" for an answer.
meep...
Posted bychrismat
2005-12-21 07:13 AM
""" One class of user that I need to serve is someone who likes to tweak site design. This is mostly HTML tweaking, but does involve some TAL and simple Python expressions, pulling information out from an underlying application. It's a limited experience that you could consider to fit your "by the book" approach, but they do seem to need certain things that Zope 3 currently doesn't offer them."""
I've actually thought quite a bit about this. The challenge is to give these kinds of folks an appropriate but limited amount of power; enough power to make simple changes but not complete control. You want to limit their power due to security concerns and encourage them to learn more about views if they want more power.
One way to do this is to not use TAL. Instead, use something like PyMeld to give people the opportunity to change the behavior of something in very limited ways. The template could live on a filesystem, and they could change it via Dreamweaver. Or, because its power is so limited, they could always change these kinds of things through the web without requiring a restart and without any special security wrappers or anything. A section of the template might look like this:
They could change "name" to "description", "date", and so on. The designer could insert whatever happened to be anticipated by the view logic. All templates would be a complete HTML page and would work in WYSIWYG tools. They wouldn't need to know any Python. They couldn't effect the performance of the site, because the site performance is basically fixed to view speed. You could provide them documentation in the form of what kinds of names are available to them in which places.
I suspect people will say that this is too limited. But it does provide a reasonable answer to allowing tweakers to have control of what is shown during a rendering without extending arbitrary power to them. If they needed more power, they could gradually be introduced to Python and views.
""" Such people want a fast turn-around, and want a low dependency on tools (such as version control systems and editors). These people are not programmers and won't be learning how to check stuff into SVN any time soon. They *do* want the ability to tweak a bit in a site's design, or an app's UI, through a TTW environment. They currently get this with Zope 2, and they don't get it with Zope 3 or Five. """
I've noticed that a lot of my customers (which of course is a limited sample of people; I don't mean to suggest it's a comprehensive set) don't really want to do editing via a TTW interface. They only use it because it's the only way to do it. They'd much rather use a WYSIWYG HTML editor against files on a filesystem, because they've had experience doing this before. I'd actually usually (and do) rather just give them a Samba mount to the directory that contains a checked out version of a set of templates. Since Five templates are reloaded in debug mode, they'd be able to preview their work immediately. Since they'd be working in a checkout, you could later come along and see just what they did using svn or cvs or whatever and check in what's appropriate. This tends to service a good 90% of my customers' customization requirements; the other 10% they need to get me involved in or they need to learn how to write product code or complicated TAL. I've also had a bit of success here by giving them GUI frontends to CVS so they can see what they've changed (even if they can't or don't want to check it in).
Other folks may have different needs obviously; there is apparently this mystical "scripter" person hanging around who wants more control but doesn't want to pay for that control with the overhead of a version control system. I suspect that providing him this kind of power isn't always a really good thing to do. "I want it" isn't a compelling reason as far as I'm concerned, because whenever I come across such a site designed via spurious customization hacks, I almost always need to suggest we throw it away and start over. Their dependence on this kind of power ends up hurting them (and Zope) as a result.
If there is some class of people that doesn't care about what happens tomorrow and just needs to "fix it" today, then fine. Go nuts. Have at it. TTW customization out the yang. The limiting factor is really just how long will it be before someone *else* needs to look at that and make it actually work outside of a toy environment. Often this is sooner than later. I'd rather be compassionate about it and take them in a sane direction to start with. I think they can be enouraged to do the right thing using "project code generation" to a large degree.
""" I think I heard from some of them at the last Plone conference, where I heard the question "well, but can you work with this through the web, without restarts?" a few times, in the context of Five. When they heard "No", they weren't exactly happy and said it was important for their way of working. It's not my way of working, but their way works well enough for them, so they obviously don't like hearing "change your way of working" for an answer. """
Restarts are indeed a problem, even if you're a pretty experienced coder. We should think about making that better. But the kinds of folks who want to control both the look and feel and have arbitrary power to change logic without any version control overhead also tend to be the people that want this kind of coding cycle. I won't pretend that it doesn't frighten me, but I will concede that it works for some definition of works for a certain class of people. I just don't want to "sell" Zope proper based on this kind of coding cycle... if a third-party tool serviced this goal, that'd be fine. Maybe something that hooked up external editor or a textarea to allow for the direct editing of filesystem templates?
It's not just designers and tweakers. The publishing company I work for (80 b2b magazines, 12 conferences, 150 websites, umpty-leven email newsletters) has about 8 programmers who are quite productive with PHP or ASP or ASP.Net, or Zope 2 scripting. So maybe these guys are really "scripters" by the standards of Zope 3 mavens. But they are the people I am trying to win over to Z3, and it's tough, because they have a hard time getting their heads around it. Several of them have at least basic familiarity with Python, and RoR and Django and TurboGears are attractive to them. If that's the way we have to go to get away from PHP, so be it; but for maintainability and (after the learning curve) rapid development, I still think Z3 is the way to go, and I am trying to figure out how to get the company there.
So I think Chris' call for scaffolding is right on the money. Most people are intimidated by a blank sheet of paper, and an example application that can be tweaked and modified is a big boost to productivity. (At least until the developer has gained some experience with the framework, then the training wheels can come off.)
I do not think that TTW is a big issue, TTB is much more important. I also think TAL is not really a problem. Keeping ZPT's in the mix will make Z2 users feel more secure, and if the Book in TTB says to work with a simple subset of TAL, people will be cool with that.
One class of user that I need to serve is someone who likes to tweak site design. This is mostly HTML tweaking, but does involve some TAL and simple Python expressions, pulling information out from an underlying application. It's a limited experience that you could consider to fit your "by the book" approach, but they do seem to need certain things that Zope 3 currently doesn't offer them.
Such people want a fast turn-around, and want a low dependency on tools (such as version control systems and editors). These people are not programmers and won't be learning how to check stuff into SVN any time soon. They *do* want the ability to tweak a bit in a site's design, or an app's UI, through a TTW environment. They currently get this with Zope 2, and they don't get it with Zope 3 or Five.
And then, what *I* want is a way to take some of what they've done under version control, under maintenance, clean it up, develop it further, without too much hassle.
Perhaps this class of users is so small they're considered unimportant, or perhaps they're not engaged in this discussion because we're programmers talking amongst ourselves. I think I heard from some of them at the last Plone conference, where I heard the question "well, but can you work with this through the web, without restarts?" a few times, in the context of Five. When they heard "No", they weren't exactly happy and said it was important for their way of working. It's not my way of working, but their way works well enough for them, so they obviously don't like hearing "change your way of working" for an answer.
I've actually thought quite a bit about this. The challenge is to give these kinds of folks an appropriate but limited amount of power; enough power to make simple changes but not complete control. You want to limit their power due to security concerns and encourage them to learn more about views if they want more power.
One way to do this is to not use TAL. Instead, use something like PyMeld to give people the opportunity to change the behavior of something in very limited ways. The template could live on a filesystem, and they could change it via Dreamweaver. Or, because its power is so limited, they could always change these kinds of things through the web without requiring a restart and without any special security wrappers or anything. A section of the template might look like this:
<table meld:id="thetable">
<tr meld:id="thetr">
<td meld:id="name"/>
</tr>
<table>
They could change "name" to "description", "date", and so on. The designer could insert whatever happened to be anticipated by the view logic. All templates would be a complete HTML page and would work in WYSIWYG tools. They wouldn't need to know any Python. They couldn't effect the performance of the site, because the site performance is basically fixed to view speed. You could provide them documentation in the form of what kinds of names are available to them in which places.
I suspect people will say that this is too limited. But it does provide a reasonable answer to allowing tweakers to have control of what is shown during a rendering without extending arbitrary power to them. If they needed more power, they could gradually be introduced to Python and views.
""" Such people want a fast turn-around, and want a low dependency on tools (such as version control systems and editors). These people are not programmers and won't be learning how to check stuff into SVN any time soon. They *do* want the ability to tweak a bit in a site's design, or an app's UI, through a TTW environment. They currently get this with Zope 2, and they don't get it with Zope 3 or Five. """
I've noticed that a lot of my customers (which of course is a limited sample of people; I don't mean to suggest it's a comprehensive set) don't really want to do editing via a TTW interface. They only use it because it's the only way to do it. They'd much rather use a WYSIWYG HTML editor against files on a filesystem, because they've had experience doing this before. I'd actually usually (and do) rather just give them a Samba mount to the directory that contains a checked out version of a set of templates. Since Five templates are reloaded in debug mode, they'd be able to preview their work immediately. Since they'd be working in a checkout, you could later come along and see just what they did using svn or cvs or whatever and check in what's appropriate. This tends to service a good 90% of my customers' customization requirements; the other 10% they need to get me involved in or they need to learn how to write product code or complicated TAL. I've also had a bit of success here by giving them GUI frontends to CVS so they can see what they've changed (even if they can't or don't want to check it in).
Other folks may have different needs obviously; there is apparently this mystical "scripter" person hanging around who wants more control but doesn't want to pay for that control with the overhead of a version control system. I suspect that providing him this kind of power isn't always a really good thing to do. "I want it" isn't a compelling reason as far as I'm concerned, because whenever I come across such a site designed via spurious customization hacks, I almost always need to suggest we throw it away and start over. Their dependence on this kind of power ends up hurting them (and Zope) as a result.
If there is some class of people that doesn't care about what happens tomorrow and just needs to "fix it" today, then fine. Go nuts. Have at it. TTW customization out the yang. The limiting factor is really just how long will it be before someone *else* needs to look at that and make it actually work outside of a toy environment. Often this is sooner than later. I'd rather be compassionate about it and take them in a sane direction to start with. I think they can be enouraged to do the right thing using "project code generation" to a large degree.
""" I think I heard from some of them at the last Plone conference, where I heard the question "well, but can you work with this through the web, without restarts?" a few times, in the context of Five. When they heard "No", they weren't exactly happy and said it was important for their way of working. It's not my way of working, but their way works well enough for them, so they obviously don't like hearing "change your way of working" for an answer. """
Restarts are indeed a problem, even if you're a pretty experienced coder. We should think about making that better. But the kinds of folks who want to control both the look and feel and have arbitrary power to change logic without any version control overhead also tend to be the people that want this kind of coding cycle. I won't pretend that it doesn't frighten me, but I will concede that it works for some definition of works for a certain class of people. I just don't want to "sell" Zope proper based on this kind of coding cycle... if a third-party tool serviced this goal, that'd be fine. Maybe something that hooked up external editor or a textarea to allow for the direct editing of filesystem templates?
Replies to this comment
So I think Chris' call for scaffolding is right on the money. Most people are intimidated by a blank sheet of paper, and an example application that can be tweaked and modified is a big boost to productivity. (At least until the developer has gained some experience with the framework, then the training wheels can come off.)
I do not think that TTW is a big issue, TTB is much more important. I also think TAL is not really a problem. Keeping ZPT's in the mix will make Z2 users feel more secure, and if the Book in TTB says to work with a simple subset of TAL, people will be cool with that.
-- Wade Leftwich
Ithaca, NY
Replies to this comment