The usual scenario that I see in website maintenance is that the main content creation tasks are done by a junior person, who in principle needs to get approval for content but not for admin.

For example, Site Editor (as I call the role in our sites) can do just about anything you’d need to do to run the site. (Some dangerous functions are reserved for an Admin.) But by default, all their content changes go into moderation.

Site Reviewer is another person, perhaps a superior, who reviews content. This person does more or less nothing administratively; they have the minimum set of permissions they need to see Revisions in Moderation and publish them.

This breakout was created to reflect the facts of life in, say, a small business, where a secretary or admin asst will typically be responsible for maintaining the site, and a CFO, marketing director or office manager will be responsible for approving content.

In other words, website management ioften looks something like an inverse meritocracy, to the geeks: The lower you are on the food chain, the more responsibility you have.

* I would, I guess, be site builder. It’s not only important that the back-end provides me with as many options as possible, but also that it allows me to tweak the admin interface for the actual users; the admins, site editors and content creators. I can of course start with your predefined admin interfaces for these roles (which is a lot more than we have now, so great stuff already), but I’ll also know a lot about my client’s specific needs and abilities, so it would be great if I could start with the roles you’ve laid out here, and tweak them to fit my client perfectly. That versatility is, after all, one of the greatest assets of Drupal.

* The only reason I build brochureware websites in Drupal is that I expect websites to want to grow. It would be a lot less work to build it in a simpler CMS, but I want the client to come back to me with ideas for adding a blog to the website. Or maybe a wiki, or an event calendar. Drupal allows them to explore that possibility by themselves (they have access to the full admin interface, and maybe a private testing website to experiment with), and when they need to polish the modules they’ve installed by themselves, they come to me.

So what I’m saying is, that besides looking at these classes of websites, you really need to look at the transitions between them. What if brochureware website wants to add a blog? What if the director wants some interns to start writing content? Maybe they want to start letting users register and slowly grow into a social site. All these transitions should be as seamless as possible

I think that if you really nail these two issues, then Drupal will be the perfect CMS for web developers, since it allows websites to grow smoothly, all the way from a simple brochureware website to a full-blown social networking site, or a company portal with a complicated editorial workflow.

I can’t think of any CMS that lets you grow that far and still keeps it as simple as it possibly can be for the smallest websites.

On the back end, an open source team looks at how well the AI is functioning by answering questions from projects that have been completed well with good user role differentiation, seeing what gets generated, and tweaking it.

And alongside that is a wiki where people discuss what’s not in the system yet, and how to make fewer better questions.

-Bram

administrator (Drupal default) sitewide admin. This is the only one who has to see all Drupal admin. Also responsible for installing and updating Drupal itself. (I agree with your breaking this out into two similar but distinct audience members. The site admin may not always be the Drupal admin aka site builder; someone with massive sitewide privileges over content and structure of the site may not be the one who should be seeing those red UPDATE ME NOW messages on every Administer page.)

sitewide editor - has many permissions but not burdened with seeing all admin options. Can adjust permissions for other users. Can approve content as well as perhaps make theme adjustments (?)

section editor – has a similar level of power as the sitewide editor but limited to a single area of the site. (How, I’m not sure yet! That’s my big usability issue with Drupal right now — figuring out how to make role permissions apply at levels of granularity other than “own” content and sitewide content. This is probably perfectly doable, just haven’t learned how yet. I don’t know if my experience indicates a need for Drupal out-of-the-box to support more of this granularity of permissions. Putting this in core could be a terrible idea! But I would argue that in practice a section editor role is just as separate from site editor as the site admin is from the site builder.)

contributor – like your Content Creator role. Will hardly see any options — super simple UI.

Roles; Site visitor & Site member, the lower end of Drupal’s users. We primarily need to make it easy for the site Builders to make it easy for these roles, however the default should be generic and easy anyway.

Sites; Ecommerce sites are not covered by the ones you have, and are an important part. Project management sites are also not covered well by the ones you have listed, and I think these are common too (though perhaps just because of the niche I work in?).

These are different to social sites in that they are tailored to focus users energy on managing several aspects of multiple different projects that are core to the website owner’s mission. So while they have a lot of user:user interaction and collaboration, they are not primarily there to enable social interactions or sharing of content (like social sites).

Ten icons to related tasks, different for each section or subsection of Drupal is much more legible then large menu with hundreds of options.
Additional advantage could be option of personalize this menus by adding or removing icons according to our needs.

Simple way to realize this. Each section or even subsection of Drupal interface have icon and tags described this section. When you do something in menu you get 5-10 icons related to current site by tags. If you mind some icons to important you can add one and save menu configuration for this view.

Add icon could be made by simple text-input field where we write word (for example “user”) and get icons of sections related with this word, then could add one or more icons to current menu.

IMHO then Drupal User Interface DUI :] will be the best I ever seen.

Greetings from Poland.

I was on CeBIT this year, and showed Drupal to a person who was not so techy and not so knowledgable about CMSes. When I showed him our forms, he showed me a nice little Ajax tool you can use on any html site.

It gives you a Adobe-like Toolbox on the right and makes all content elements editable inline. A pain I cannot find it anymore. Concrete5 uses pretty much the same approach for content editing you sketch.

This is very intuitive for the user and it is clearly the future.

Been wanting to make a demo video of it. Now that you already showed the concept, I won’t be able to surprise anyone anymore , but I think I still will. Got some ideas how to make this play with CCK content types with a lot of fields.

Thing is – we don’t need to change the technical basis in drupal, because it’s brilliant. No – it is ‘just’ the way we present it to the user. Witch Ajax you can implement most anything, and you don’t even have to invent much, because there are enough systems out there that do exactly this and we can draw from.

Brilliant, kudos, rock on!