This summarises for me, many open source projects problems.

Yes its great that a community of coders can make Drupal and Linux, but at the end of the day, as a specialist group, their paradigms are quite different from every day users.

I think you are right that this is the key design concept for Drupal.

If you can then move on to GNU/Linux next I’d be VERY happy.

Simon

Re:3, This is always a hot topic. I think Jacob Redding said it best “notify the user that they are (a) logged in and (b) have certain privileges to change things.” I believe this is all you were trying to say.

What delineates an administrative or permissible task from only being able to view it is very important. Leisa wasn’t entirely clear on point 3 but she made it clear enough in her comment. This is what’s confusing about Drupal now. There’s no clear context on where you are or what you are doing. The page layout and design doesn’t have to deviate too much from the main site but what you can do and the state you are in must be made very clear. And to be honest, the usability study that steered a lot of people to focus on an administration theme did not work for me. I think that was only one part of the problem.

I’d also like to add a 7th point. Or rather, an overall goal… To be engaging and fun. I’d hate to bring up Apple since it’s so commonly done. When you have a task to do, you just do it. There is little administrative debris compared to Windows. We wouldn’t want to go too far in completely hiding some options (ever hack on a .plist file?) but it ends up being fun to work with since the task at hand can be focused on instead of the system getting in your face while acting like it’s your problem.

2. yes, yes & yes. Lots to win here!

3. I don’t see a problem in this. It doesn’t state where the exact line between front and back, create and admin etc. should be drawn, just that it’s important to always be clear which side of the system you are working on. You switch on the tv on the front side. Cabling and power cords are usually on the back side. Most of the times you just use the remote control. Whatever *you* decide you want to be on the front or back is up to you and fully customizable on both the tv and the remote.

4. I’m sure it’s possible to find sensible defaults for this if we can agree on the focus for the default install profile (http://groups.drupal.org/node/21013 ? or http://groups.drupal.org/node/21014 or something else?)

5. Very curious how the tone of voice excercise pans out!

6. Ship with dummy content? It will be interesting to think more about that phase where installation ends and actual use of Drupal begins. I’m definately in favor of letting people create their first “Hello world” post as quickly and smoothly as possible.

Drupal has intentionally never delineated between administrative functionality and normal use items precisely because different use cases dictate who can do what. we have privileges and I personally seek to remove and inline all administrative control to sensible locations within the natural flow of working with your objects on a daily basis.

Practically speaking this means things like “promoting delete to a menu local task” on nodes so it isnt hidden as an admin function but as a decorator of the object itself. It also means eliminating discrete settings pages except where necessary and no obvious object would serve as a decorator (I’m looking at you block editing!).

The lack of the dichotomy really expands our capabilities to respond well to different use cases (issue tracker, social network, etc) and i personally dont think it hurts us much in the “drupal as a blog or pulishing platfrom” either. The trick imo is to do this intuitively without cluttering the interface and in a fashion that can be extended across all of contrib as well.

But this is where Drupal’s great theming system comes in. As Leisa correctly points out, it’s a question of theming, not of architecture. If admin users are getting confused, why not enable a different admin theme out-of-the-box? It follows along with principle number 4 (sensible defaults). I’d suggest the Rootcandy theme as a great candidate.

In addition, it would be smart if Drupal provided an interstitial warning to the user if they do switch the admin theme to the same theme as website, along the lines of:

“You’re about to change the administration theme to the same theme as the website. Pages where administration functions are performed will have the same style as public-facing website pages. Please note that some users with permission to access administrative areas of the website may be confused. Are you sure you want to do this?”

The wording would likely need to be changed. But that way if admins get disoriented, at least they were warned and can always switch it back.

This is exactly what Cpanel provides.
Click “Install Drupal” and everything, including the database, is ready.
Takes less than 3 second!

Maybe you already did the big picture thinking and are past the listening phase; but, I would like to put out my vision.

You are working on the details of the interaction within Drupal. I am interested in the big picture that keeps people from even using it.

These are endpoint goals that can probably never be achieved.

1. Installation. Similar to your #6. It should be like OS X’s installation of applications. Drag them to the Applications folder and they work.

- Drag Drupal to your website and it works.

2. Updating. There should be something like Apple’s Software Update feature. – Drupal announces there is an update available.

- You say update and everything in Drupal, including modules, are updated.

3. Theming. The ideal theming would be to click a button that says, “Make It Look Good” and it does. I know this will never happen but theming is programming in Drupal and Contributed Themes all work differently and, of course, not exactly the way you need them to; so, you have to go back to do your own.

-Drupal Theming should be graphic design not programming.

4. Modules. “Does anyone know how to make Drupal do ‘X’?” This is a really common question in Twitter. The answer is that there usually is at LEAST one module that does “X”. How do people find modules? How do you know what the best one is? How do you know how it plays with other modules. I have over 1000 modules in my sites/all directory because I like testing them out. But of course my sites are constantly broken. http://drupalmodules.com/ is a start, but it would be better if Drupal had a way during site building to answer the question, -”How do I make “X” happen?”

-Drupal answers the question, “How do I make “X” happen?”

5. Modules (part 2). When you install modules blocks and fields mysteriously appear. (Or don’t appear because you have to go turn them on in blocks.) It would be great if every tab, input field, block, etc. had a tag on it which let you know which module put that there. It would help with site design.

-Drupal lets admins know where everything on the page is coming from.

I also have those experiences since our company started using Drupal to build sites for others (back in Octobre 2006)?