The key to improving Drupal 8 UX is get actionable issues into the queue as soon as possible.
During a community ux/usability BoF at Drupalcon Portland, we identified some areas of Drupal 8 that need usability testing. The testing will uncover issues to be fixed. Volunteers are needed to run usability studies at Drupalcamps or with others locally this summer. Coaching on running usability studies and assistance with the usability study script will be provided.
Areas to test
Access to each of the scripts is limited to those conducting the studies (to avoid spoilers!) but access can be requested if you're interested in conducting studies.
- Content creation / management | Status: Testing in progress
- Content creation / management on mobile | Status: on hold for bug fixing
- Views (after more bug fixes) | Status: Team effort?
- Multilingual | Status: Needs volunteer
- Installing Drupal | Status: Ready for testing
- Scotch / blocks and layouts initiative | Status: sccherry / Steve Cherry to work on script
- CMI | Status: useradvocate to do heuristic evaluation
- Tour module | Status: (Charlie to do heuristic evaluation?)
- Toolbar IA | Status: sccherry / Steve Cherry to work on script with lisarex
How to test
- Read and review documentation on How to test usability. (We will try to update these docs as we go along).
- Attend one of the Monday UX meetings in IRC to coordinate / learn more. Or reach out to lisarex, Bojhan or dcmistry via contact form or email.
- Conduct your study, and post findings to the issue queue (more details on that coming soon).
Comments
What about the sitebuilder UX?
I think it is a good list of examples that needs usability studies to help improve the UX.
However, what I don't see here is the very important sitebuilder role and how we as a community can improve its UX.
When looking at the list then there are two groups of bullets that both has everything to do with the sitebuilder role:
Site using bullets:
All these bullets needs to be tailored by the sitebuilder to be able to provide as good UX for the user roles as possible. Unfortunately this is something I see large parts of the community having difficult to fully understand. Particularly when it comes to see where it needs to be fixed.
Building site features:
These are all tools the sitebuilder uses to build site features. In practically every case the sitebuilder will have to combine functionality from several of them when creating an individual feature.
Still they are treated as individual and isolated components. Very little collaboration is done to create a consistent UX and UI.
Thus, before going ahead with these usability tests we need to start by identifying:
I, and others, have talked about the importance of the sitebuilder role for years now, but still it is being conveniently ignored by large parts of the community. Our UX, usability and UI included, problems will never be possible to really improve unless we start to take this role and its need seriously, certainly not by refusing to admit they are there.
Before DrupalCon Munich I wrote a series of post about the sitebuilder role. Here particularly the http://www.tsvenson.com/blog/2012/08/the-drupal-site-building-experience post is very relevant. Look at the role map diagram in it and you can clearly see just how central the sitebuilder role really is.
To make it simple, the sitebuilder role is the central hub where practically everything is routed through.
Unless we start taking this seriously the criteria's and also the outcome of these test will be of little use.
--
/thomas
T: @tsvenson | S: tsvenson.com
It's a wiki; edit the list
Thomas, this is a community project written in a wiki. Feel free to add to the list and dive in.
Go ahead and divide the list into roles if you feel it would be useful. As for your questions 1-3, those ought to be answered in each individual usability study script.
==================================
http://about.me/lisarex
A more holistic approach would be best
...but it remains to be seen what can be done given we are short on volunteers and time in the D8 release cycle. Let's discussion at the next UX IRC meeting on 6 June.
==================================
http://about.me/lisarex
Good to hear some more perspectives. Mine:
For Drupal 8:
Next monday UX meeting in IRC, #drupal-usability. Be there :)
Link to related discussion
groups.drupal.org/node/301153
Pasted from gmail thread of wider ranging post-portland UX discussion
One-click module and core updates
@tsvenson
You present a very valid point regarding the sitebuilder perspective. That perspective cannot be overlooked from a UX perspective, the sitebuilder and the end user are both equal.
The one glaring issue I've encountered with Drupal has been module and core updates. It's clear the current process isn't as streamlined as possible as it required multiple community contributors to write up their own DIY instructions. If the upgrade process was simpler, there'd have been no need for these instructions.
What would it take to make one-click module and core updates possible? A complete rewrite? I sure hope not. Has this capability ever been discussed?
Please share your thoughts.
As drupal stands it is more a
As drupal stands it is more a tool for professional sitebuilders that build Websites for their clients.
Using Wordpress one is constantly amazed by the ease of updates (I think core updates are even automatic now).
But this does not account for the scenarios in which Drupal is used. There are and will be core updates that break APIs willingly because of security issues. This can cause problems on sites. So if you make updates automatic you break sites, which cannot be.
With Drupal 8 the process changes a bit, as I understand it, as the term API is defined more clearly, what parts can be broken and what parts can't.
But even then, I think Drupal will remain a beast vastly different from Wordpress. I guess people who build more ambitious sites with Wordpress will turn off automatic updates and exert the same scrutiny to any plugin update that any responsible Drupal sitebuilder applies when updating any module.
This means: test on a copy, check if everything works and only then deploy to live. So: personally I do not see one-click-updates coming, maybe if someone puts a lot of time into update manager.
For the time being I think they are even possible with the update manager now through the UI. Only problem is functionality might break.
Life is a journey, not a destination
Drupal-lite
Very valid points indeed. I still feel that the power of Drupal shouldn't be justification for less than ideal UX. Yes, Wordpress is more designed for the general user/developer, but they still hold a prominent position over Drupal interms of UX.
UX does affect user adoption immensely. I'm sure for the majority of Drupal developers, any perceived UX shortcomings with Drupal, do not bother them, but nonetheless, efforts should be made to address them.
You mention the risk of breaking APIs with a one-click update, and I agree wholeheartedly. Drupal's flexibility with APIs is what makes it so powerful but makes updating a significant chore.
Will there ever be a time where Drupal core and APIs will be more strictly defined that would allow one-click updates to work? Or does that fundamentally go against what Drupal stands for, ultimate flexibility?
Perhaps a Drupal distribution can be developed that restricts APIs just enough that one-click updates could happen without breaking sites. Maybe a middle ground, Wordpress UX, with Drupal's power - a Drupal-lite perhaps?