We could start by factoring out the common HTML headers and footers
that are usually in management screens. Most of the screens would then
be coded like this:
... it would be a start.
Here are some random PaulThoughts.
- ShaneH 7/26
The management interface was effective for a while, but what I see happening is the same problem that plagues most GUI's: the lack of access to verbs. In Zope, this means that you just can't fit enough tabs at the top of the screen. There are so many things you can do to manipulate an object. I think there needs to be a way to make more actions available to the user without cluttering the screen, such as a simple drop-down box.
Another problem with the management interface is that it targets 3 different groups of people - Administrators, Programmers, Content Developers. This partly due to the fact that content management and programming are not totally separate in Zope - DTML is too powerful/complex for that. Plus, it's not flexable enough for Content Administration of custom products - E-tailer wrote their own, for example. Which means integrating different product's management interfaces is a pain.
There has to be some way to allow the management to be integrated into an existing site's design.
A more differentiated group of default Roles would make customizing the interface for different audiences easier too. I suggest Superuser (==today's Manager), Developer, Administrator (== today's Owner), Member, Anonymous in descending order of power. Superuser runs the domain. Developers develop, Adminstrator are in charge of a section of a website or an object they own (say, a Squishdot), Member's can login and customize their own settings.
- ChrisW 26/7/00
I really like this dev.zope.org stuff, all my dreams are coming true ;-)
FWIW, I'd be happy to graphic design for you... Checkout http://www.bay-c.co.uk and http://www.devaal.ccdata.com/ for some stuff I've done.
As far as comments go:
I think the browsers you're targeting are too new. Aim for the version 4's otherwise all the corporates who have fixed browser versions (NN6 isn't on the horizon any time soon anyway :( and 5.1 is a bit elitist) By all means take advantage of the new browsers, but make sure any "new browser functionality" they use degrades gracefully if you use it on an old browser.
I strongly agree with the idea of hanging preferences off the user object.
The widgets/skins thing will also be great for re-use. Getting rid of the redirect-based-on-REQUEST thing would be a good first step. I'd really like to see lots of reusability so useful ZMI functionality can be used in other projects, without having to be re-written as it is now :(
The Style Guide and all the APIsx must be very well documented.
This is quite a major point: I think you've got the target audiences wrong, as I see it, the groups are:
End users and content managers add content to sites using Zope objects. They tend to be fairly clueless WRT technology and the like. They need lots of common metaphors and plenty of help. Simplicity and ease of use are the key here.
Developers. These people build sites from stock Zope components or write their own using things like ZClassesx (maybe more likely with ZClassesNGx ;-) and Python Products. They need a rich interface and lots of API references and the like... debugging and lots of error messages are common here. They'll probably "build the site" as well with the Content Managers filling the gap. This group could be split further into those two build the site and those who build the products but I think they'd want the same interface.
Server admin, part of which will be needed by group 2 as well. This group will want to start/stop/restart servers, manage Zope versions, install/upgrade/remove products and the like. They'll probably be managing lots of users and other configuration-type information.
I'd just like to throw in a big fat "me too" on almost everything above, by everyone, but especially the note about version 4 browsers (IE and NS both) being important (for about another year, I'd say personally). I'm not real keen on "hanging preferences off the user object" if done without an intervening "preferences" object, let's say, where a preference is a relationship object that conceptually sits between a thing the preference is for, and the user whose preference it is. It might be that the user object is responsible for holding on to the preference, but it shouldn't be by a bunch of properties in the user object's base namespace.
- Chrisw 27/7
Phil, all I'd say is don't make it more complicated than it needs to be. Maybe have a preferences attribute of the User Object that is a dictionary? That dictionary then forms the
I like this proposal; in fact have been thinking
about it for a while and talked to TheOtherMartijn about it. Note that
this proposal goes beyond just user interface if you want to do it well;
it goes right into core of Zope: the standard Zope components, such
as Folder (the stuff in OFS and more).
Model needs to be separated from View/Controller. View/Controller needs
to be in the widgets. The widget sets can be varied independently from
the model, which are the actual components themselves. The components
know nothing about HTML or userinterfaces; that's up to the widgets.
- (ChrisW 27/7
I really like this :-)
This is a drastic overhaul, but I think it can't be avoided on the
longer term. It has vast advantages.
I've written two (!) proposals that discuss this. See CleanUpTheCore and