Our UX Principles: 1. Make the most frequent tasks easy and less frequent tasks achievable. 2. Design for the 80% 3. Privilege the Content Creator 4. Make the default settings smart

D7UX Experience Strategy V2

Posted: March 31st, 2009 | Author: | Filed under: Strategy | Tags: | 57 Comments »

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 Comments on “D7UX Experience Strategy V2”

  1. 1 Drupal 7 User Experience Project » Blog Archive » Current Activities - What you can do NOW! said at 3:10 pm on March 31st, 2009:

    [...] Experience Strategy: we’re up to our second draft (here’s the first draft with comments). What do you think? [...]

  2. 2 Eric said at 4:53 pm on March 31st, 2009:

    Good stuff. Everyone wants Drupal to be flexible, but that doesn’t mean its complexity can’t be hidden behind sensible defaults and a better hierarchy of tasks and settings.

  3. 3 Lynda Chiotti said at 5:15 pm on March 31st, 2009:

    Do we need to differentiate between installing Drupal and setting up a site? Is it realistic to propose that installing can be done by a non-programmer? I suspect not, so maybe we should say that explicitly.
    Just a comment on the first principle: setup and configure tasks or selections are infrequent, but they tend to happen first, thus affecting the perceived usability of all else. Even with smart defaults, I would look for clarity wherever selections are offered, especially for an infrequent task.
    Maybe add a goal to cover this and for error correction and system messages: Communication from the system about selections, status or errors should use language most people understand and offer actions most people can take.

  4. 4 Brad Wade said at 5:19 pm on March 31st, 2009:

    Principles 1 and 4 seem good and clear.

    3) I still have no idea what “Privilege the Content Creator” means. Is this obvious to everyone else? Can you please explain.

    2) Even in the short from please include Design for the 80% *of admin users*. “Design for the 80%” is meaningless unless you are assuming that you mean *of admin users*.

    Now that I think about it more. I don’t understand your use of the Pareto Principle/80-20 rule in this context. I understand the priniciple to state that 20% of your work will get you 80% of the way there. So the trick is determining which 20% is the right 20% to focus on so that you will achieve 80% of your goals.

    Are you stating that you will design with the needs of 80% of the admins in mind? If so, I would say that is not the Pareto Principle. In my understanding, an example of the 80-20 rule would be that once having determined the problems that need to be fixed, you plan to fix the 20% that will achieve 80% of the overall progress.

    So, I’m still unsure what you are saying with this principle. What is it that you are trying to communicate? (And how does that relate to the 80-20 rule?)

    -Brad

  5. 5 Boris Mann said at 5:20 pm on March 31st, 2009:

    Re: good defaults.

    I will once again bang this drum and ask “What will a default Drupal install do out of the box?”. Because depending on what type of site you are building, good defaults will vary wildly.

    My vote is still for an OOB community site: http://groups.drupal.org/node/19812

  6. 6 Christopher Calicott said at 5:36 pm on March 31st, 2009:

    @boris It seems to me that if a hardcore developer is about to use Drupal for a major project – versus someone that’s going to be using it for the more common types of sites – those people should be choosing the option of doing an installation profile that does a very bare bones, streamlined installation… rather than make that “80%” group figure out how to make Drupal bend to their very common needs. I think this is probably what Leisa’s “privilege the content creator” concept means, as opposed to privileging the expert level developer with a fresh install. Makes perfect sense to me. After all, the more highly capable a user is, the more likely they are to know what something like an “installation profile” even is and how to get up and running.. right?

    -=- christopher

  7. 7 Boris Mann said at 6:17 pm on March 31st, 2009:

    I have no worries about developers – core Drupal 7 (already, today) has a “bare bones” profile labelled “expert”.

    The install profile in question is default, which will be recommended / highlighted for “regular” users.

    So, who is that regular user and what kind of site are we going to show them out of the box? We even have the ability to do an “install wizard” in core that guides users to the type of site / setup they want.

    It would be great to have Mark / Leisa help guide us in this.

    We have time to make this shine, and catch (amongst others) has been doing good work on this.

  8. 8 Mark Boulton said at 6:26 pm on March 31st, 2009:

    @Boris

    Thanks for your thoughts, Boris. In response, and I know this may sound like a bit of a cop out, but we don’t know yet. We know that we should provide good defaults, but we also know the wide variety of sites that can be produced. As you rightly indicate, there might not be a middle ground.

    Is the community site really the middle? I don’t know, I’m just playing devil’s advocate. But, this *is* something we’re considering.

  9. 9 Josiah said at 6:33 pm on March 31st, 2009:

    I’d like to see designers and themers mentioned in the goals somewhere. I’m beginning to become concerned that a more strict UX will become restrictive in nature for themers and designers unless it is clearly and intentionally avoided. Every Drupal site gets a theme applied and ideally they’d all be very different so we need to keep that flexibility and the current community drive to improve theme-ability in mind.

    To answer Brad’s question “What does ‘privilege the content creator’ mean?”, I think the point is that if you have a UX that could be either easier for the content creator or the site builder, the content creator’s ease of use wins. Ideally both could be improved, but the content creator is the user we most want to simplify life for.

  10. 10 Boris Mann said at 6:38 pm on March 31st, 2009:

    The community site that I linked to is a straw man (that page is a wiki, please edit!).

    I know you don’t know yet, I just want to make sure that the possibilities are highlighted … and stress that there are people that can work on this install profile, and that it IS the place where all the “sane defaults” will most likely live, and I’ve taken a first crack at that with the wiki page.

  11. 11 Josiah said at 6:40 pm on March 31st, 2009:

    On Boris’ thoughts, I think the Community Site is an opportunity the Drupal is good at and wouldn’t put it as much in conflict with WordPress and Joomla. From a marketing stand-point that seems to make sense. It is, however a smaller portion of overall sites I see created. Perhaps it’s trending in that direction though.

    The newspaper world and non-profit world and music world all use Drupal more and more. They all have potential for community, but currently the sites are more about content with some community tools around them.

    Might this also be better resolved in the install by giving option. D7 now has 2 options (blank slate and basic setup or something like that). Why couldn’t we have a content driven site, a community driven site, and a brochure-ware site instead of a generic starting point?

  12. 12 Thomas said at 12:16 am on April 1st, 2009:

    It’d be nice if Drupal 7 would ask what type of site you’d like to run, a smart installation profile, and based on that answer, appropriately activate and configure modules that will probably be needed.

    And maybe a list suggestions for popular modules you may want for your type of site…

  13. 13 larowlan said at 12:22 am on April 1st, 2009:

    In terms of keeping it simple. I find that adding a menu item to the top of the navigation menu titled ‘content’ and linking to admin/content/node gives a usability boost for content creators/maintainers.
    Similarly expanding the create content menu by default.
    This makes the two most common tasks – maintaining and creating content – only 1 click away.
    Just my 2 cents.

  14. 14 Parasolx said at 12:53 am on April 1st, 2009:

    @Thomas,

    I’m totally agreed with you. I hope that in D7 it will coming up the list of module that can be used based on the type of website being make.

    Such as, if the user wanna to make a blog, it will list out the recommended module can be install such as Blog, Blog API and rest.

    For forum, came out the recommended list of module that is retrieve from the D7 official website based on the taxonomy tagging towards module list.

  15. 15 Boris Mann said at 1:07 am on April 1st, 2009:

    @Josaih @Thomas – we definitely can run a sort of “wizard” as part of install.

    However, we need people that are knowledgeable and passionate about a particular site use case to design the defaults. So get cracking! –> http://groups.drupal.org/node/19812

  16. 16 Brandon Sussman said at 2:55 am on April 1st, 2009:

    I claim the newcomer’s right of making heretical statements :)

    (Not heretical – just sanity checking my own understanding of the discussion) U in UX means “Site Implementing User” not “Site Visiting User”. drupal makes wonderful sites for visitors if they have the skill to “do a drupal site”.

    I think translating principle 3 from cute opaque language to standard english grammar and usage would serve you better in this very important discussion.

    I think the concept of profile is a brilliant one. It leads to the development of a profile/config module that can be used to preconfigure drupal installs for quilters or farms that raise sheep or web designers (I am all three). I would love to have that preconfigurability. Then the actual profile of the target audience would matter less because it would be easy to build and modify preconfigutations.

    The rest of this is a long rant on the profile under discussion in this thread :)

    The tagline about doing this site in drupal is very significant.

    I do not love Joomla but if you wanted this site in Joomla, it would do all you need in about an hour. Whilst this does not in any way exhibit the power and development capabilities, it does speak volumes to the 80% audience I think you are trying to hard to define and serve. If I were me, I would do a plain vanilla install of Joomla (1.5, not 1), install one of the available contributed themes and your own logo. Then sit back and think seriously about the minimum skillset necessary to do that, what it gives you and whether or not that is an 80% example of our drupal goal.

    If you don’t like the thought of touching Joomla, substitute Gallery2 and try it. This is a narrower CMS, sort of like WordPress for images, but the point is that there is a fairly attractive, ready to populate with content, with a total labor component of under an hour and no more skill than using phpmysql and the gui ftp client available in every shared host system I have ever seen.

    Isn’t that the skillset and outcome you are after?

    Even better – find a person that wants a site that you think Joomla or drupal or WordPress or Gallery2 or phpBB would be good for and spend a few hours sitting with them doing a site from scratch. I have done this. Since I have over 30 years in user-facing system design, it was a very eye-opening experience. BTW – those are the folks we need to participate in this discussion if they are the target audience for d7UX.

  17. 17 David said at 4:14 am on April 1st, 2009:

    I definitely like where this outline is going. I see a strong thrust to making managing a site easier for the person new to Drupal and inexperienced with site development. This is a natural and needed shift in largely developer-centered system. However, as I look over the bullet points, it seems to me that if that is used as a guide for shaping the next version of drupal, the balance is off. I would like to avoid a drastically swinging pendulum, swinging from catering to the developers, then the novices, then the designers, etc. etc.

    I think what I would personally like to see in this outline, since the whole project is focused mainly around the interface, is more attention given to the administration screens. Making it easy to navigate around they myriad of options available in an installation. No matter how easy it is to get started, there will always be some work to do to make my site Just Right(tm). A HUGE part of developing in Drupal is working with all of the admin screens.

    Establishing revamped admin areas of core should then become a best-practices example of how module admin screens should be developed.

  18. 18 Laura said at 1:13 pm on April 1st, 2009:

    I think David’s comment just above is right on: The admin area is the root of the UX problem. It’s not a dashboard, and it’s defined by features instead of benefits — what the tool can do instead of what you want to do.

    The easy install may be one barrier for folks, but there are increasingly available hosted solutions that can help get past the challenge of creating a MySQL database, etc.

    A wizard might be nice, but wizards take a lot of work for little upside. Run it once and then what?

    Making sense of the admin area, separating out content management from content architecture, and putting content creation into the content management area (as well as in findable places for end-users with permissions) would be the big big win.

  19. 19 Brandon Sussman said at 1:50 pm on April 1st, 2009:

    The ‘make a blank database’ step is interesting.

    I used to think that ability to create a blank database using standard webhost tools was a pre-requisite for having one’s own site.

    On the one hand, I find phpmyadmin easy to understand and it seems to be well embedded in many web host provider solutions.

    But

    I have experience with intelligent (non-computer-technical) folks who were unable to happily accomplish the step.

    So is it very challenging to build an installer step that takes input of servername, username and password and creates its database? If so, maybe drupal install should just do it.

  20. 20 Laura said at 2:08 pm on April 1st, 2009:

    There are two issues with that, Brandon. One is that having Drupal create a database is something most webhosts will not allow. It’s a security issue.

    As for the installer that asks for servername, etc., Drupal already has that in Drupal 6. Are you talking about something different, because it currently does just what you describe.

  21. 21 Farrell said at 2:12 pm on April 1st, 2009:

    I think this is a great start. I love working with Drupal — but it is HARD.

    I’ve had clients give up on Drupal because of this.

    In terms of the admin, I think the permissions language is very confusing under access controls. What these fine-grained permissions actually do can seem a mystery.

    Also, and I’m not sure you’re addressing this here, but the upgrade process is a real nightmare for non-programmers. What happens when someone implements a newly easy-to-use Drupal 7 site, and then breaks it during an upgrade?

    Just a few thoughts. Keep up the great work!

  22. 22 Brandon said at 2:46 pm on April 1st, 2009:

    @Laura –

    Ooh – I forgot I knew that :)

    So discussing database creation changes is really moot.

    In my heart, I really believe that a person seeking to install drupal needs a minimal skills set that includes understanding how to create an empty DB. I do not think making drupal easier to drop in and run depends on eliminating that step. Sorry to distract :)

  23. 23 Liam McDermott said at 6:37 pm on April 1st, 2009:

    This looks good, a simple brief, but with strong principles you can refer to in all your design decisions.

    There were only two things I took issue with:

    Design for the 80% (of current and potential Drupal admin users, ref Pareto Principle. Note that most of the 80% are not developers.)

    As Brad Wade said, this isn’t the Pareto Principle. Frankly though, I’ve been going around for years thinking it was; as have 37 Signals, who were possibly the ones who usurped the idea in the first place!

    Privilege the Content Creator

    This sounds rather like marketing-speak. I can see what you’re getting at, but it sounds like something a middle-manager would say. :D

  24. 24 Boris Mann said at 7:17 pm on April 1st, 2009:

    @Brand Sussman: they exist today, and have been in core since Drupal 5. See http://drupal.org/project/installation+profiles

    Now…”what should Drupal do out of the box?”

  25. 25 Leisa Reichelt said at 9:50 pm on April 1st, 2009:

    a few notes that are relevant to this post that I’ve also posted elsewhere… apologies for duplicates.

    //

    I’ve been offline in a workshop all day, and have only a few minutes to respond, so here are some initial thoughts on the feedback so far. I’ll get back with some more specific responses soon.

    who are the 80%

    who are the 80% of people we refer to? yes, some of them are people who want to make blogs, but the vast majority are your clients, or your coworkers – they’re the content team at MTV who have to publish the latest news on Michael Jackson, they’re the marketing team at Sony BMG who have to make a website for the next big rock star, they’re Obama’s team at the Whitehouse keeping us all up to date on Recovery.gov… it’s a whole bunch of smart people for whom interacting with Drupal is a part of their every day work.

    at the moment, a lot of people are doing a lot of work customising interfaces to make them usable, running hour after hour of training so that people can ‘learn’ Drupal to just publish some content online, fielding support calls throughout the day… spending hours that could be spent making Drupal even more powerful.

    these 80% are not dumb, but they’re not Drupal developers and neither should be. Chances are they’ve seen a bunch of different content management systems. they should be able to use Drupal without being made to feel dumb.

    simple != dumbing down

    there is absolutely no relationship between making Drupal easier for these people to use and making Drupal less powerful or less sophisticated. we respect the importance of the Developer Experience (DX) – but you guys are here to talk about your experience and what needs fixing. We’re here to represent those who aren’t here in the community but who are a big part of the reason we, the Drupal community, *are* here.

    wordpress, schmwordpress

    yes, we are using WordPress as a tool to communicate in this project. As @webchick pointed out, we’re using a bunch of different tools. I don’t know what the fixation on WordPress is and why there is an assumption that we would use it as a model for Drupal. Yes, WordPress has pretty nice UX. But is is just one of many content management systems that Mark & I have been exposed to as users and designers of dozens of different content management systems, both open source and commercial and custom built, over the past decade or so. We’ll be drawing on ALL of that, as well as our developing Drupal knowledge and, with your assistance, the vast resource that is the Drupal community as we move forward on this project.

    we’re listening

    we’ve had some tough things to listen to today, but we’re listening. we’re working hard to make sure that as many people know about this project as possible so that you can shape it. this *is* a big opportunity – please continue to engage with us and lets work productively to get to the best possible outcome – a Drupal that continues to be incredibly powerful, but that also gives good UX to the people who take what we make and continue to grow it through creating and managing content and communities.

    more soon!

    x-posted at drupal.org and elsewhere on this site

  26. 26 Jay said at 1:43 am on April 2nd, 2009:

    Hi everyone!

    I’m a little late in the game and there’s a lot to read so sorry if I’m stepping ahead or jumping too fast.

    It sounds like this thread is focusing on a lot of issues, installation, administration, etc. I think we need to organize the feedback into proper buckets so we can better focus our efforts.

    Also in “our goals”
    * non-coding, non-Drupal experienced users should be able to add/edit and otherwise manage content without confusion, errors or extensive training.
    -but advanced users should still be able to have control. Maybe a basic and advanced page that can be interrelated. I’ll try to wireframe what I mean by this.

    * people should be able set up a site and publish content without having to go into a ‘configuration/setting/options’ type section
    -Setting up a site and publishing content should be two separate bullet items.

    * the interface should not get in the way of the developers doing developing (and configuring and other administering) work.
    -not sure if “get in the way” is correct, I would think, powerful or intuitive for developers would be a better approach.

    Also a quick question, is the feedback only in the form of comments? I think it’ll get harder and harder to filter out the information as time goes on.

    This is exciting stuff guys! Cant wait to get into the nitty gritty. =)

    Best,
    Jay

  27. 27 Mike Goodwin said at 4:41 am on April 2nd, 2009:

    I don’t know if CCK and Views will be considered in this UX work, but to me the usability of these modules could greatly enhance Drupal’s uptake. If users could grasp the utility of these modules and have a simple UI to configure them, then the possibilities for their site could be virtually endless. Core by itself can do quite a bit, but Drupal’s power is realized much more with Views and CCK. So, I hope that the UX of these modules is at least considered.

  28. 28 lowlevel said at 8:27 am on April 2nd, 2009:

    To have edit over the node is just fine.
    You don’t have to go to special admin section just to edit what you or somebody else was posted.
    I think that good thinks that we already have must be kept and only make it simple.
    I hate this huge navigation menu it become so big. Putting something into right place is painful.
    What I’m thinking.We have hooks to change many things but you must know some PHP and how drupal works.
    But this hooks are well know. What about to be able to click on submitted link and say what you want to see and system generate hook in template.php for you ?
    Also if we take a look at contrubuted modules there is a big mess.
    Every module place some link somewhere.
    Yes we are talking about drupal core. But after core comes contributed modules.
    Without clear concept where things must be it become mess. For me UX is from core to every module.
    Also links on bottom of every node. This links are known because modules register this links.
    It’s good to have ability to simple re-arrange them like menus items.
    Breadcrumb this is main source for navigation.
    Controlling breadcrumb is painful.
    I mean more and simple control over page element that is visible on the site. And in most case you want to change it.
    Submitting a node if you have many modules is pain. Page become so long. So many options that most of people doesn’t care.
    I see in one of your videos using horizontal space is nice. But place for body text is small.
    You have to be able to make big preview in some modal windows if you have bit table or wide text.

    There is really a lot of things that can be improved.

  29. 29 k said at 9:47 am on April 2nd, 2009:

    Just one thing: replace “easy” with “intuitive” (you might add also transparent and efficient – it’s too easy just to say easy).

  30. 30 Eric said at 4:44 pm on April 2nd, 2009:

    I totally agree with Mike Goodwin, CCK and Views really make Drupal stand apart in terms of flexibility. This brings up another usability issue, though, and that is that terminology in Drupal is completely obtuse. When my clients see “views” they first think “yes, I want to change the way my site is viewed” and then I have to explain that views are a “view of the data, what you *really* want themes.”

    This sort of thing is a big barrier to entry IMO. I think something along the lines of “Lists” would be a better name for Views module. “Content Creation Kit” isn’t a bad name, but new users will need to be brought to the understanding of what it means to “construct” new content vs. “create” new content. (Maybe it is a bad name)

    To me, a big part of this project means I don’t have to stand over a client’s shoulder and redefine terms that rest of the world understands to mean something different. It means that I could turn WordPress users into Drupal users without them going back after a year. (It’s happened, and it was because of usability)

  31. 31 John Kipling Lewis said at 5:58 pm on April 2nd, 2009:

    You know how you can install software by clicking {next}{next}{next}{next}{next}??

    The standard installation of Drupal should “just work” by doing just that. You shouldn’t need to read anything, or know anything, or think to get it up and running to start. Just click {next}{next}{next}…

    BUT, when you know more and you’re in the 20% club you wont be just clicking {next}{next}{next}… because the screen you are on here would be for customizing where you database is and you want it in a special place… so you can configure it before you continue to click {next}{next}{next}.

    Get it?

  32. 32 Robert Castelo said at 8:17 pm on April 2nd, 2009:

    I’d like to add one more to the wish list…

    * Allow for intuition
    - incorporate a mental model into Drupal that’s coherent enough that the user can guess where to go and what to do to achieve their goal.

    Best example I have experience of for this is the Mac UI, where a lot of the time you can just guess how to do things both in the Finder and applications.

  33. 33 Spencer Wyatt said at 10:28 pm on April 2nd, 2009:

    Just want to chime in and offer my thanks and encouragement to Mark and Leisa. I really appreciate what you guys are doing – please don’t get discouraged.

    I started using Drupal a year and half ago and (after the steep learning curve) really loved that I could make Drupal do anything I wanted it to – the power and flexibility it offered was amazing. But, I’ve always felt embarrassed when it came time to pass a site off to a client.

    For me, it’s ok that building a site in Drupal can be a cumbersome process – it’s not ideal but it’s worth it. But, once the site is built and just needs to be maintained, then it HAS to be dead simple. Because at that point, I (as the designer/developer) am no longer involved and my non-techie client has to be able to add/edit content, pictures, and even videos without help.

    It takes a lot of tweaking – custom admin views, hook_form_alter() on node add forms, stripping out most of the navigation menu and rewording the rest, etc. – to get close to an intuitive interface for my clients.

    A few months ago, I gave up and started using ExpressionEngine. There was definitely a new learning curve and there were a LOT of things about EE that I found lacking. I’m NOT suggesting that Drupal emulate EE. But, my clients were able to “get” the admin panel out of the box.

    But, once I heard that Mark Boulton had been brought on to work on Drupal, I came back.

    I’ll continue to fight with Drupal to make it more usable for my clients until Drupal 7 comes out. And I bought the Pro Drupal Development book so that I can start contributing back to the community. The promise of an improved Drupal 7 has made me fully committed to the project and the community. Before now, I was too skeptical about Drupal’s future to really commit.

    I think Mark and Leisa’s work and methodology on the drupal.org redesign attests to the enormous value they bring to Drupal and their commitment to working with every member of the community. They both really get design and user experience. I trust that they will help make Drupal easier (and more enjoyable) to use without taking anything away from its power and flexibility.

    As a side note, any designers out there should read Mark’s new book “A Practical Guide to Designing for the Web” available as an ebook now and hard copy in two weeks at http://www.fivesimplesteps.co.uk/

  34. 34 Bojhan Somers said at 11:23 pm on April 2nd, 2009:

    So these are really starting to get in shape, I am still a bit overwhelmed by the amount of principles and goals. I feel community wise, one strong vision or principle could survive better then a couple of fairly normal ones.

    I can comment on each individual one, but I feel strongly that it might be better to reconsider the whole list and see which one is really essential to communicate to the community, for example the

    - Make the most frequent tasks easy and less frequent tasks achievable.

    It is a very important goal – but in the list of other goals it doesn’t stand out as much, while the 80/20% does.

    So which one really has to stand out? I still feel the “Drupal will allow anyone to create complex websites without developer knowledge.” should – since that is an experience I wish share – and Drupal seems to be moving towards.

    Currently there are objectives, principles and goals and personal goals. I know its fairly normal to do this – however I can never really make the distinction between them, especially in this context.

  35. 35 Jeff Burnz said at 2:31 am on April 3rd, 2009:

    Points:

    * 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

    Imply installation profiles, effectively site-in-a-box afaikt. Drupal is so flexible we would have to make many assumptions about what sort of website 80% want to build or give multiple choices of install profiles (which are then automatically downloaded and installed during the install process).

    Your list looks solid to me, Id say this is RTBC.

  36. 36 How about the learning experience? « drupalsliu.wordpress.com said at 5:41 pm on April 3rd, 2009:

    [...] about the learning experience? By drupalsliu This post is a comment on D7UX Experience Strategy V2, reformatted as HTML list: ( I am not a fan of slogans and I think their mouse-over-red font looks [...]

  37. 37 Chacha said at 8:36 pm on April 3rd, 2009:

    Thanks for this post. I’m new to this discussion and kind of overwhelmed.

    What matters to me as someone with a site that has a number of features for many users (a collaborative website?) is having different kinds of experience paths for all the different users, especially when these evolve and grow.

    I wrote a post about how Drupal has let me down
    (and why)
    (and what I can do about it) http://www.artmess.org/content/why-drupal-breaking-my-heart

    Here are some ways I could contribute to drupal ux:

    1. Re-learn design. Find books on modern user experience design. Or at least blogs? I have totally outgrown my old resources. I don’t need help with web design basics, or even interface design basics. I need content publishing advice.
    2. Build a library of good examples of publishing interfaces. I know word press is easy. But I haven’t gone through the interface with an eye for what Drupal needs to learn from these other interfaces.
    3. Search for a vocabulary for these design conventions. Designing Interfaces was really awesome a few years ago because it does just this. It made it really easy to talk about. But I need this for today’s dashboards. I either need to make my own notes, or find someone else’s.
    4. Draw more wireframes and think about user tools.
    5. Share my problems with other UX designers and actually participate in this conversation even though at the moment I am completely overwhelmed.
    6. Experiments:
    * think of ways to integrate thinking/blogging about design with a continuously evolving drupal site design.
    * I can make a comments space & block that will solicit user feedback on some websites. Basically, do my part to hear all the complaints about the particular Drupal experience I have created. I can pull out simple common issues and share back with Drupal.
    7. Send my thoughts to the people I work with. We will perhaps spend the next few months studying this issue and hopefully come to a better place.
    8. Complain more about Drupal.

  38. 38 Matt Young said at 6:16 am on April 4th, 2009:

    I’m happy with this strategy apart from ‘Privilege the Content Creator’. What the heck does that mean?

  39. 39 Iamme said at 9:10 pm on April 4th, 2009:

    “I’m happy with this strategy apart from ‘Privilege the Content Creator’. What the heck does that mean?”

    Why is this so hard to understand? Drupal is designed by the developer for the developer. The wording, and organization of tasks is obfuscated by the idiosyncratic and often counter-intuitive logics of developers. Even some the most fundemental tasks depend on a knowledge of what’s going on behind the scenes in order to find and utilize. Things are not self explanatory.

    Easy example:

    Views and the arguments option. It’s a critical module, but it makes little intuitive sense. The title ‘views’ is not self explanatory to a user that doesn’t have a psychic connection to merlin of chaos’ mind and ‘arguements’ is just absoultely bizarre and meaningless to somebody without a programmers background. An arguement is something you have with your neighbor over why his dog shits on your lawn, not an option within your website.

    The needs, expectations, and knowledge of the -=*END USER*=- in the creation and management of drupal sites need more consideration, that’s what it means.

  40. 40 Boris Mann said at 11:10 pm on April 4th, 2009:

    In my anecdotal experience, “end user as content creator” actually have an easier time than “end user as basic site admin/builder”.

    What you are describing is “end user as basic site admin/builder”. And that, I think, is where we keep getting tripped up.

    So, your example of Views and arguments is perfect: that is advanced functionality. You are *literally* programming, albeit with a visual, web based interface.

    I’m sure that the UI of Views can be improved, but I’m also relatively certain that end user as basic content creator is going to be a likelier focus rather than this advanced functionality.

    I’d love to see statements of easiness. “It should be easy for a site admin to X” and aim for improvements. *I* find Views arguments hard, so I don’t expect a magic make it easy wand to be waved.

  41. 41 Elijah Lynn said at 10:58 am on April 5th, 2009:

    Chris Pirillo talking heavily about Drupal, the user experience and install profiles.

    http://chris.pirillo.com/were-taking-an-open-direction-with-web-communities-are-you-in/

    Relevant info, recommended listening.

  42. 42 Robert Castelo said at 10:03 pm on April 5th, 2009:

    Identifying the “80% of users” might be tricky with Drupal….

    There are two ways users could be categorised:

    1) What they want to build

    Drupal sites are so diverse that I suspect it would be impossible to specify an 80% usage pattern.

    2) Experience with Drupal

    Drupal is designed to be used by a team (content creator, editor, site administrator,…) rather than an individual doing everything as they would on Blogger or WordPress – although of course one person can wear all these hats, Drupal’s strength is that it is possible to separate out all these roles.

    Many users, specially in organisations, have had it installed, configured and managed by someone else.

    Another point is that users will only be newbies for a limited time, after that they will have some experience, and the majority of their time using Drupal will be at that skill level. So making it easier for users to make initial steps is a good thing, but they will mainly be using it at an ‘experienced’ level.

    Also motivation is a factor, and something that tends to get lost in user testing, when someone is assigned a task they have no personal interest in. Most users will have a goal, and will therefore put in a certain amount of effort to achieving it, which means they are open to learning some new concepts in exchange for gaining the ability to achieve their goal.

  43. 43 ShadowSkill said at 1:16 pm on April 6th, 2009:

    Hi guys, is there any D7 demo site for us to play with? Good for guys who don’t want to do the initial setup :)

  44. 44 Shawn said at 9:26 pm on April 6th, 2009:

    You might also consider: “providing examples” as an additional principal. That might turn into demos, installation profiles, user contributions, etc. I find that showing a novice an example is a powerful way to move them up the learning curve.

  45. 45 Bevan said at 7:44 am on April 7th, 2009:

    This looks great! I don’t understand though why this is a draft. Shouldn’t this be a living document that will be out of date before it’s goals are met?

    It also reminds me of some work we did on UX goals just after the UMN Usability testing; http://groups.drupal.org/node/9252

    See also the related discussion; http://groups.drupal.org/node/11385

  46. 46 Bevan said at 7:44 am on April 7th, 2009:

    I forgot to subscribe

  47. 47 frank said at 9:57 pm on April 8th, 2009:

    so, drupal is nearly perfect for me. i am only missing some help with features. let’s see hwat happened, when gates and windows wanted to be more user-friendly and not handling with pure settings. now they have so many handles, it is not easy to find the right one to open, in a second you feel the urge for fresh air. in my opinion it is useful to provide as much help as possible, to CLEAN UP the bursting modules-room, keep the eye on “logic” everywhere, and everything will come as easy as flower-picking.

  48. 48 pkbrooks said at 10:00 pm on April 8th, 2009:

    Iamme said at 9:10 pm on April 4th, 2009:

    “I’m happy with this strategy apart from ‘Privilege the Content Creator’. What the heck does that mean?”

    Love your thoughts. I am a ?two? year user of Drupal now and am not really interested in coding or development. I have a design background and enjoy enjoyable websites that are intuitive and thoughtfully designed. I have enjoyed Drupal for the one selling point it flaunts and that is its versatility. However, like you said an argument is what I have with my neighbor (too funny) and a view to my thinking meant I was going to simply push some buttons or check some boxes and shazam I would be able to go to a page and see what I had intended. Alas, that is not is not true and I have had to do much more reading up and writing on forums to get my brain around the more development-focused mentalities that drive Drupal. No complaints in one respect, because it has forced me to learn. But, I cringe at the thought of someone with less focus or simple intelligence trying to use one of the better CMS systems out there. I will be reading the objectives soon and doing my part to help out.

  49. 49 joan said at 1:48 pm on April 9th, 2009:

    We have been participating for a long time in usabilty. Not just us but also many non-Drupal users. From many different parts of the web. There is an ocean of information but it was dried up, reasons unknown. For best results it will be good to revive this forum and NOT RE-INVENT WHEEL! Its here – http://drupal.org/forum/6

  50. 50 Swift Arrow said at 4:55 pm on April 9th, 2009:

    Some Ideas that have been festering in me for a while:

    I recently gave an introductory talk on Drupal, and found myself explaining again and again that “Views” meant “List of Nodes”, that “Node” meant any unit of content, that “Theme” meant the display (colors, shapes, etc) and that “Taxonomy” was just groups of categories with sub categories.

    Would I like to see these things renamed to be more instantly understandable? No! I would, however, like there to be some sort of walk-through for newbies on their new site, explaining what things were. Perhaps some meaningfully written “sample content” or something, installable on request (think Joomla!)

    I think the word “Node” fits the Drupal philosophy much better than any alternative.

    Taxonomy smacks of geekiness, but once someone has used Taxonomy to organize their site, they realize that no other word would do.

    Views is understandably a little ambiguous, but if used once, it is easy to get along with.

    Content Construction Kit had me hung up for a long time; until I actually used it (and I resisted it as much as possible, mostly because I could see no relationship between it’s name and what people were suggesting it for) but still, I think just a few more reminders of it’s real definition are all that is needed.

    Theme is mercifully well understood (but perhaps we should rename it to “Wrapping” just to keep the learning curve ;)

    So all that down, my suggestions:

    1) My number one gripe is that I install a module, then go to access permissions to configure how it’s used, then go to Blocks to enable it (typically), then go to menus to adjust it’s menu link…. all this for just one module (or view). I know the administrative tasks by module view exists, but doesn’t change this. Better would be one page for the module (like the view creation page in D6) with _areas_ on the page for access control, for blocks that it enables, for it’s configuration, etc. Keep the existing blocks and access control pages too, but add a centralized page for each module.

    2) After a site has finally been pulled together with various modules, all configured as needed, all blocks put in place, these things need very little changing – just the occasional addition of a block, etc. The maintenance of a site is just in controlling the content. Content management should be more separated from the admin side of things (or vice versa).

    3) I dont know if this is possible with the current workflow (I haven’t been able to figure that one out yet) but creating a “Content Creation Flow” i.e. a sort of wizard interface for adding content would be great – one that could be applied to all sorts of content (eg page 1: write content, attach media, page 2: select categories, page 3: select dates and publishing options). Perhaps this could be implemented as tabs for each step on the content creation page. That would help ease up clutter. Which fields go on which page of the creation process could be controlled in CCK.

    Creating a website is very different from creating a Blog, for which I wholeheartedly recommend (and use) wordpress. But even WordPress has it’s UX drawbacks. I particularly dislike having to learn my way around a newly re-designed interface every time I update to a new version.

    Everyone knows what a blog is going to need, but no-one can define what a website is. I think some install profiles should be shipped default with drupal, such as Blog site, Brochure site, etc. and have a set of instructive sample data installable too (articles that tell the user how to do common first-step tasks.)

    But there is no way around the learning period for Drupal, or for that matter, any other website creation system. The best we can do is make it easier.

  51. 51 frank said at 11:50 am on April 10th, 2009:

    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.

  52. 52 Raj said at 12:15 am on April 11th, 2009:

    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.

  53. 53 frank said at 6:51 am on April 11th, 2009:

    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

  54. 54 yoroy said at 10:50 pm on April 11th, 2009:

    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.

  55. 55 Raj said at 11:56 pm on April 11th, 2009:

    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.

  56. 56 Josiah said at 12:35 am on April 12th, 2009:

    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.

  57. 57 drupalpoint said at 6:53 pm on September 26th, 2009:

    Hi,

    Please make sure that it is easier than wordpress to use drupal.

    Amy

cialis avec ou sans ordonnance | Custom wriitng help probably the best custom. | Ask for the best assignment help by calling our toll free number.