D7UX Experience Strategy V2

A big thank you to everyone who provided feedback on the first draft of the experience strategy – your input was very thoughtful and insightful and we have made great use of it to draft this second version of the strategy.

We think this is getting very close to a strong and workable experience strategy. Please take a moment to read through it and let me know what you think!

Drupal7 Experience Strategy & Goals V2

our objective:

To make Drupal a tool that is powerful and flexible for content creation and management even for people who don’t write code or speak Drupal-speak without compromising the ability for developers to do their work. Drupal will allow anyone to create complex websites without developer knowledge.

our design principles:

  • Make the most frequent tasks easy and less frequent tasks achievable.
  • Design for the 80% of current and potential Drupal admin users – 80% of users will only use 20% of the functionality. (Hat tip to Pareto and his Principle)
  • Privilege the Content Creator
  • Allow for customisation but don’t make the end user do all the work, make informed and thoughtful decisions about the good default settings

our goals:

  • non-coding, non-Drupal experienced users should be able to add/edit and otherwise manage content without confusion, errors or extensive training.
  • people should be able set up a site and publish content without having to go into a ‘configuration/setting/options’ type section
  • the interface should not get in the way of the developers doing developing (and configuring and other administering) work.

Mark & Leisa’s Personal Goals:

  • be so in love with Drupal UX that it becomes our tool of choice for content publishing
  • be so confident about the Drupal UX that we recommend putting the ‘Download’ button back on Drupal.org (ref: D.O Redesign Strategies – Why Is It So?)

57 thoughts on “D7UX Experience Strategy V2”

  1. thank u, Swift Arrrow, good spoken.
    A wish to add for me: a possibility to save the configuration of an analyzed well running site. In case of rebuild after crash or on new database or server, it would talk with me:
    “thanks for rebuilding the site example.net.
    Things to do:
    Could not find module filefield. you have to install filefield to reach the previous saved configuration.
    you have to activate filefield to reach the previous saved configuration.”
    Or sth like that.

  2. We have been “Struggling” with Drupal 6 for months, almost ditching it. We are ASP devs converting to the PHP sect and trying to adopt Drupal. As a Project Manager (no longer technical) leading this, there are some real basic difficulties with this CMS that makes adoption a real pain and sometimes just not worth the trouble. I am not sure if this is the right forum…

    1. Wysiwyg editors should be part of the core – pre-installed. Its crazy not having one as standard these days.

    2. Wysiwyg editor means having the ability to upload images in a very easy way, when creating content. Setting this up in Drupal is just difficult. A real long way scenic route around for what should be a standard function. This is particularly annoying.

    3. Upgrading Modules. Shouldn’t we merely be clicking “Upgrade” within the Drupal interface to upgrade modules or core. We should take a page out of Ubuntu’s ease of upgrades. They make it blindingly easy. Drupal on the other hand is terribly clunky. Unnecessarily wasted time.

    4. Blocks: there is no obvious guidance within the system towards setting up blocks that relate to taxonomy. The essential power of the system seems mystic, and remains unknown. Despite digging the internet for answers. Its all still mystic and thus useless.

    I opted against Joomla because I thought Drupal was designed solid from a tech perspective up, taking into account permissions etc. I see Drupal as a great CMS if it can be made more user friendly for the less experienced techos.

    At the moment it’s just clunky…not easy.

  3. I agree with most, there has to be less loading and unzip and pick and fetch and click… but i tink, a swiss knife is not for kids.

    1. wysiwyg-Editors now are included as a wisywyg-connector plus a small external editor of your choice! I like that especially. OK, the connector (API) could be in core.

    2. didn’t check that, may be a good point, this is addressed to external editors.

    3. tried “Plugin-Manager”? there is some work to do (copy and paste md5-checksums) for security reasons, but well operating in installing and updating modules.

    4. blocks contain content related to taxonomy. please discuss in the drupal.org-forum.

    Good luck!

    frank

  4. I’d like to follow up on the points Bojhan made in #34 and try to focus the actual vision/strategy/tactics a bit further. I remember reading this post and used that as a guide to narrow things down a bit:

    1. Philosophy: what does Drupal stand for?
    “Freedom to publish for everybody”

    2. Vision: how to know we realised this philosophy?
    “Drupal will allow anyone to create complex websites without developer knowledge.”

    3. Planning/Tactics/Design principles: what to do to reach that vision?
    – Make dependent tasks discoverable
    – Provide sensible defaults for the 80%
    – Especially for the day to day site administration tasks

    That last point is my interpretation of ‘privilege the content creater’. Testing has shown that especially the UX for content and site management tasks is essentially broken. It’s the part where “we” Drupal devs and site builders leave our clients to do their day to day site maintenance that needs special attention. Which probably overlaps nicely with the 80/20 principle.

  5. Hi Frank,

    In relation to 53…

    We have been ploughing away at a Drupal install, just to get it to the stage where you have a decent wysiwyg and image uploader installed. Most of the image uploaders tried are pretty poor and not at all straightforward to install. It’s taken us an entire full day and late evening to reach this stage.

    The problem is its exceedingly difficult to determine which modules work with what. The dependencies and installation process for them is very time-consuming (at a very early stage of adoption), for 2 critical but simple tools required to make a basic website – “without developer knowledge”.

    1. There really needs to be an easy point and click way of installing or upgrading modules and the core in Drupal. (Like the way Ubuntu installs software apps – thats cool!). Functionality enhancements should be merely point and click.

    2. Module dependencies need to be clear during this possible automated module install process. So the user has a better understanding of what works with what. So he is not chasing the installation serially.

    I performed my first core upgrade from 6.2 to 6.10. My experience is it was very painful. The instructions on how to do this are good but miss a few critical points – like, you have to re-install modules again and check all your configs again. Very painful if you are building your site up step by step.

    I am newish to Drupal but eager to see it improve and lead other CMSs.

    If we could concentrate on improving adoption, so you can get a newbies up and running with the basics with minimal fuss, that would help nurture the newbie learning curve, and perhaps adoption rate.

  6. Raj, sounds like you’d benefit from backing up the sited directory and putting it back in place after the drupal core upgrade. If you put contrib modules in sites/all/modules and stuff like that, then this makes the upgrade pretty painless and consistent. I just did an upgrade like this today. (except I usually just delete the sites directory from the tarball before replacing it so sites/ doesn’t get overwritten.)

    Anyway, hope that makes your next upgrade a bit easier. Also, it tends to be easier if you don’t jump versions so dramatically. Keeping up with updates makes life easier and helps show what may have caused the problem should it occur since you don’t have as many variables.

Comments are closed.