Maintaining a traditional GUI is a bad idea IMO. It's too much work and too hard to maintain in such a fluid environment. Seems like most of these types of efforts turn into vaporware.
TTW is already a GUI. For some things TTW just works, since we're really just talking about some html forms, it really should be easy to create and easy to use. I work with a diverse user base ranging from interns and designers to sales reps and editors. For entering data it works great. I use two different bastardized versions of Plone for two different newspapers and they report that content entry is easy to train and maintain.
Skinning the site is more of challenge. There is no way I'm training designers the complexities of a Zope Page Template much less the complexity of a Plone template. For both sites I use Cheetah instead of ZPT and use a TTP (through the plone) skinning system. Not everyone knows how to svn, but everyone knows how to undo. This works okay. It obviously has all the problems mentioned with TTW development and is a mess to look at, but it's not as hard to understand as ZPT or as hard to follow as PHP.
IMO site maintainers need
* TTW skinning with unlimited undo and access via webdav
* Simple templating - sorry, pymeld is nice but can't be used without a programmer, I like django templates but use <!-- for loops and conditionals
* TTW installable products (like a combination QuickInstaller/egg downloader)
* TTW configuration (exportable via webdav) - shouldn't need to dive into file system to change the date format
* Seperate admin, public and preview skins - not one template fits all like Plone
* User, group and role administration
In the flesh!
Posted bychrismat
2005-12-24 07:51 AM
Looks like you're a "scripter" (or a person that helps manage scripters). Woo hoo! Excellent! I have a bunch of questions for you. ;-)
""" TTW is already a GUI. For some things TTW just works, since we're really just talking about some html forms, it really should be easy to create and easy to use. I work with a diverse user base ranging from interns and designers to sales reps and editors. For entering data it works great. I use two different bastardized versions of Plone for two different newspapers and they report that content entry is easy to train and maintain. """
You say "content entry" above so I assume this means that you want your applications to continue to be web apps. No disagreement from me. I don't want to make fat client GUI apps with Zope. I might consider creating a fat client GUI app to manage Zope configuration (e.g. a ZCML inspector) but content entry people would never see that.
""" Skinning the site is more of challenge. There is no way I'm training designers the complexities of a Zope Page Template much less the complexity of a Plone template. For both sites I use Cheetah instead of ZPT and use a TTP (through the plone) skinning system. Not everyone knows how to svn, but everyone knows how to undo. This works okay. It obviously has all the problems mentioned with TTW development and is a mess to look at, but it's not as hard to understand as ZPT or as hard to follow as PHP. """
A litany of questions: How many designers are there? Designers don't mind seeing Cheetah in templates? Do their WYSIWYG tools support it? Do they change it or just work around it? If they do change Cheetah logic, to what extent do they make change? Does it concern you at all that Cheetah puts an unlimited amount of power in the hands of people who might misunderstand it (I make the assumption given that you say these designers can't use Subversion)? How much traffic do the sites that you have this on get? Is performance adequate? Who gets the phone call when performance becomes inadequate? Do you have a process for isolating performance problems?
"""
IMO site maintainers need
* TTW skinning with unlimited undo and access via webdav
"""
Do they make changes directly to the live site or is there a staging process? If there is a staging process, how do the changes make it to the live site? Would the designers be just as comfortable accessing files that actually live on a filesystem over, say, Samba, instead of over WebDAV. If they had an alternate way to perform an undo against files on the filesystem (as opposed to the current ZMI/CMF undo interface), would that service the goal?
"""
* Simple templating - sorry, pymeld is nice but can't be used without a programmer, I like django templates but use <!-- for loops and conditionals
"""
"Templating" is a bit of an overloaded word (at least to me). I'd call that "programming", but then again I suspect I'm a bit of a fundamentalist when it comes to this. ;-)
For production sites? Who's the actor here? Under what circumstances would product-installation-via-a-shell-prompt be less than adequate? Do you use ZEO? Currently, how do you make sure all of your common-purpose ZEO clients are running the same set of software?
"""
* TTW configuration (exportable via webdav) - shouldn't need to dive into file system to change the date format
"""
What classes of configuration should be performed via the web? Are there any classes of configuration that should be performed via files on a filesystem? Have you used any Zope 3 or Five stuff yet?
"""
* Seperate admin, public and preview skins - not one template fits all like Plone
"""
In the TTB model there's only one skin for very simple database-driven content delivery apps: the public skin. For more complicated apps that require content entry, workflow and so forth, there is the admin skin as well. In the perfect world, I'd suggest separating content entry from delivery entirely (use separate physical systems for entry and delivery). This prevents a certain class of performance issues. Anyway, if the "admin" skin and logic was optional, would that bother you?
"""
* User, group and role administration
"""
Yup, although I suspect a certain class of folks would be just as happy with an LDAP browser or the ability to use MS' built in ActiveDirectory tools or Netware's NDS tools, and so on. Do you think this is a losing proposition?
TTW is already a GUI. For some things TTW just works, since we're really just talking about some html forms, it really should be easy to create and easy to use. I work with a diverse user base ranging from interns and designers to sales reps and editors. For entering data it works great. I use two different bastardized versions of Plone for two different newspapers and they report that content entry is easy to train and maintain.
Skinning the site is more of challenge. There is no way I'm training designers the complexities of a Zope Page Template much less the complexity of a Plone template. For both sites I use Cheetah instead of ZPT and use a TTP (through the plone) skinning system. Not everyone knows how to svn, but everyone knows how to undo. This works okay. It obviously has all the problems mentioned with TTW development and is a mess to look at, but it's not as hard to understand as ZPT or as hard to follow as PHP.
IMO site maintainers need
* TTW skinning with unlimited undo and access via webdav
* Simple templating - sorry, pymeld is nice but can't be used without a programmer, I like django templates but use <!-- for loops and conditionals
* TTW installable products (like a combination QuickInstaller/egg downloader)
* TTW configuration (exportable via webdav) - shouldn't need to dive into file system to change the date format
* Seperate admin, public and preview skins - not one template fits all like Plone
* User, group and role administration
""" TTW is already a GUI. For some things TTW just works, since we're really just talking about some html forms, it really should be easy to create and easy to use. I work with a diverse user base ranging from interns and designers to sales reps and editors. For entering data it works great. I use two different bastardized versions of Plone for two different newspapers and they report that content entry is easy to train and maintain. """
You say "content entry" above so I assume this means that you want your applications to continue to be web apps. No disagreement from me. I don't want to make fat client GUI apps with Zope. I might consider creating a fat client GUI app to manage Zope configuration (e.g. a ZCML inspector) but content entry people would never see that.
""" Skinning the site is more of challenge. There is no way I'm training designers the complexities of a Zope Page Template much less the complexity of a Plone template. For both sites I use Cheetah instead of ZPT and use a TTP (through the plone) skinning system. Not everyone knows how to svn, but everyone knows how to undo. This works okay. It obviously has all the problems mentioned with TTW development and is a mess to look at, but it's not as hard to understand as ZPT or as hard to follow as PHP. """
A litany of questions: How many designers are there? Designers don't mind seeing Cheetah in templates? Do their WYSIWYG tools support it? Do they change it or just work around it? If they do change Cheetah logic, to what extent do they make change? Does it concern you at all that Cheetah puts an unlimited amount of power in the hands of people who might misunderstand it (I make the assumption given that you say these designers can't use Subversion)? How much traffic do the sites that you have this on get? Is performance adequate? Who gets the phone call when performance becomes inadequate? Do you have a process for isolating performance problems?
"""
IMO site maintainers need
* TTW skinning with unlimited undo and access via webdav
"""
Do they make changes directly to the live site or is there a staging process? If there is a staging process, how do the changes make it to the live site? Would the designers be just as comfortable accessing files that actually live on a filesystem over, say, Samba, instead of over WebDAV. If they had an alternate way to perform an undo against files on the filesystem (as opposed to the current ZMI/CMF undo interface), would that service the goal?
"""
* Simple templating - sorry, pymeld is nice but can't be used without a programmer, I like django templates but use <!-- for loops and conditionals
"""
"Templating" is a bit of an overloaded word (at least to me). I'd call that "programming", but then again I suspect I'm a bit of a fundamentalist when it comes to this. ;-)
"""
* TTW installable products (like a combination QuickInstaller/egg downloader)
"""
For production sites? Who's the actor here? Under what circumstances would product-installation-via-a-shell-prompt be less than adequate? Do you use ZEO? Currently, how do you make sure all of your common-purpose ZEO clients are running the same set of software?
"""
* TTW configuration (exportable via webdav) - shouldn't need to dive into file system to change the date format
"""
What classes of configuration should be performed via the web? Are there any classes of configuration that should be performed via files on a filesystem? Have you used any Zope 3 or Five stuff yet?
"""
* Seperate admin, public and preview skins - not one template fits all like Plone
"""
In the TTB model there's only one skin for very simple database-driven content delivery apps: the public skin. For more complicated apps that require content entry, workflow and so forth, there is the admin skin as well. In the perfect world, I'd suggest separating content entry from delivery entirely (use separate physical systems for entry and delivery). This prevents a certain class of performance issues. Anyway, if the "admin" skin and logic was optional, would that bother you?
"""
* User, group and role administration
"""
Yup, although I suspect a certain class of folks would be just as happy with an LDAP browser or the ability to use MS' built in ActiveDirectory tools or Netware's NDS tools, and so on. Do you think this is a losing proposition?
Replies to this comment