“Make easy things easy and hard things do-able.”

I believe the first principle is a ripoff from Perl’s design principle. Nothing wrong with that, other than the fact that Drupal is a multifaceted beast with many users, each with a different take on what “easy” and “do-able” mean. In fact, I was psyched to do my first Drupal project for a non-profit customer (for free, to build a portfolio). But, when it came to their expectations for ease of content maintenance, I had to switch to Joomla. In the long run, no matter how cool the functionality, if it is too hard for the end user, it will not be used.

“Design for the 80%”

I’ve always liked the 80-20 rule. That’s why I’m a ‘jack-of-all-trades’, I suppose. I learn 80% of a subject easily and move on before it gets too complicated… Unfortunately, a corresponding rule states that ‘the Devil is in the details’. You should verify that, when you decide to go for the 80%, you aren’t going down a dead-end road that makes the 20% extremely difficult!

“Privilege the End User”

As I mentioned above, I had to switch from Drupal because the end users did not understand the interface enough to use it. I believe that this is a good goal. Drupal seems like it is where Unix was at one point, where the lunatics controlled the asylum. Like ending programming statements by spelling the word backwards (if…fi), many constructs seemed to be made simply to ensure a barrier to entry. What needs to happen to Drupal is the equivalent to Apple OS X…that is, abstract a pretty and usable front end onto a robust, if unfriendly back end.

Sorry for the length. Good luck!

Who is Drupal made for? What kinds of users? Clearly it’s not made for my mother to start a blog. That’s what blogger and wordpress are for. There are thousands of easier ways to make certain kinds of webpages.

Drupal’s power is in its flexibility. So I agree with 2cents. He’s the one making sense here…

Strategy
Eliminate the site builder.

Challenges
Provide a fluid user interface and experience for core and contrib modules to properly account for Drupal’s extensibility.

Goal
Drupal allows anyone to create complex websites without developer knowledge.

*That’s a rock solid experience strategy.*

Challanges
Making modules more a part of Drupal, then treating them as an unmanageable outer user experience.

5 year experience
Drupal helps you create a complex website, without you needing to go into the code.

First let me say this. It makes me sad to hear that you are trying to generalize websites like blogs, social networks and even small business websites. They are all the same to you, it seems. I think you interpret the Pareto principle wrong. It is a fact that they all need different things to make the user experience better or great. It is also my belief that you can for each website solution with success apply the Pareto principle.

So, here is a suggestion. Why not pick one battle at the time, the Drupal way. Focus on one type of website solution. Take a single user blog for example. Nobody has provided a great solution for this yet. Why? I have an idea why and I might tell you some other time. If you would use an approach like this you would end up with a website solution that resulted in something like:

- A Drupal profile that refers or downloads all required modules and themes during the installation process. The profiles feature in Drupal might need to be extended a bit for this to work great.

- An administration theme for that specific website solution.

- A default end-user theme for that specific website solution.

- The installation may even contain a different terminology, different user roles, custom settings, default content and a lot more.

Best of luck!

Broadly speaking, I think you can happily leave the goals nebulous – that’s what goals are – but you might want to translate them into three or four SMART targets which give you better indicators of success. It might be good to produce some sample user stories we’d want to cater for, based on the user matrix (but not become a slave to that level of detail right now). Would we want to think of users in terms of experience or motivation – how a user would distinguish themselves – rather than their level of expertise – how the existing community would rate them?

More specifically, regarding the details of the experience strategy, user matrix etc. mentioned here, I think that this whole process needs more transparency and structure than these blog posts. Coming to it cold, it’s still not clear from the post above whether or not the “experience strategy” is specifically those three bullet points, or the blogpost linked to in a later paragraph. Or is it both? Or is one a summary of the other? What do we point to, when we talk about the components of d7ux? What parts of the strategy relate to the Drupal experience (referred to in the first goal above) and what parts relate to the drupal.org experience?

If we want a structured, robust procedure, then we should have dedicated canonical documents which describe it, and clear links between them. It needs to support images bigger than 450px across, like the ability/time diagram, without smashing the page layout, like that diagram does. They need to make sense without YouTube videos, which a lot of people can’t watch at work, or don’t have the time to sit through. Putting them together shouldn’t be allowed to soak up much time but, from the point of view of existing community members wanting to contribute to d7ux, it’ll ironically improve the process’ usability!

2. Get rid of the useless default themes. Drupal claims to be professionally developed. But it ships with themes that use table layouts or layouts where main content doesn’t come first. lol.

3. You can choose if backend and frontend use different themes. Stick to that, developing an underlying code structure that let’s users easily adjust their backend to their needs (see 2 different ways to configure your car). Add an easy to use default theme to that and give instructions for developing further backends, like e.g. having fieldset in tabs instead of list them beneath each other. That would best reflect drupals philosophy being a framework and let beginners and advanced users get most out of it.

Although drupal seems hard to use, CCK makes a difference to other cms. Clients are happy when I tell them, that I can create input fields adjusted to their needs, minimizing the effort for them to add data.

4. Improve workflows, e.g. when a module creates a block, then let the user set if and where that block appears right out of the module settings page without having to change to the blocks page.

One question.

At the top of the page here it says “Privilege the End User.”

At the top of the page at http://www.d7ux.org/ it says “Privilege the Content Creator.”

Which strategy are you following?