Yep, I am coming to Drupalcon: its great to have a convention so close to home (at least it's the same East Europe). But before I'd like to have a little pre-conf rant, sort of an introduction of my thinking. I'd like to collect together some fundamental problems in Drupal user interface. Being out of active contribution phase but closely following the development from the shadows here are my observations.
But before getting to issues, first some meta-level talk.
We all know Drupal has changed from humble “nicely designed CMS” to hyper-powerful CMF and pains and complexities of UI decisions have grown exponentially. Being so open-ended, so plug-and-play, so drupal-is-whatever-you-want-it-to-be is in direct contrast of process of creating simple, user-friendly UI what removes say unnecessary config screens and makes some decisions for the user. Thing is: The key for Drupal end-user experience is often not what we do in core UI but the administrator what uses his super-Drupal-toolbox to shape the UX. He can either make it really nice, removing UI baggage, picking best possible UI components and themes (just look what Michael Angeles is doing over http://konigi.com/) or completely overload the site with ridiculous add-ons and non-functioning themes.
So what we should do?
As we giving the site builders the best possible code components and APIs we also need to give them the best possible UI components and enforce and share the best practices. We need “Drupal UI Police” what provides law and order in this rebel countryside. We need a good Drupal Human Interface Guide so developers and site admins can follow this and Drupal shops can base their own HIGs on Drupal HIG.
Now, on to the problems.
UI design process
The nature of Drupal development is shaped by several factors, such as being a OSS project and being heavily driven by talented coders. This is reflected both in human relations (decision processes) and available project managing tools. User experience-centered design has yet to find its place to this process. We do not have many things:
- No lead UI designer or “core design team”
- No “UI core committer”
- No roadmap or vision for UI
- No “visual sandbox” where UI designers can play around with UI prototypes (either views + panels – based, html mocks or static images) what we could crowd-source the usability testing
- No visual issue queue. See http://kika.trip.ee/node/302, #2 and #3
- No proper UI / usability metadata for issue filtering. See http://drupal.org/node/282138
- No proper usability testing process (different big academic initiatives on this have been great but what we often need are lot of quick crowd-sourced cheap tests in small scale).
- How we could get some eye tracking coolness in? :)
People
We have lost (or semi-lost) several very talented Drupal UI contributors / consultants: Chris Messina, Michael Angeles, Steven Wittens, Peter Van Dijck (am I correct?). How to engage them, how to bribe them to come back?
UI challenges
Ok, now the UI challenges in no particular order nor grouped around common topics. I just had to let it all out, quick. I do not touch the issues what are listed on http://groups.drupal.org/szeged-uxsprint – these gonna be interesting sessions and hopefully filled with great solutions.
Lists UI
We need proper:
- Selecting: standardized UI for selecting “all in page”, “all in page + subpages”, “none”, "
" (think Gmail) - Actions on selected list elements: the current dropdown in inefficient: it does not give enough hints what are the outcomes of certain action, is there a confirm screen before real action, is the action reversible / undoable. Also, several actions need additional settings / tinkering / confirming what ideally would happen next to the action dropdown (example: associate with term → add new term).
- Filter: current filter is hard to understand mess: replace with standard “smart folder / e-mail rules”-style filter
There already some word done with views plugin though.
Inconsistent “add new item” entrypoints and forms
In core we use a link on top of listings (“add new blog entry”, …), “add” tab, embedded add form in top of the listing or below the listing and in some contrib modules even popups.
This needs standardization and consistency.
Admin Space vs User Space
Ah, the lovely discussion, going back how-many-years. So far the alternative models for user/admin space have been “Joomla/Wordpress/MT” style clearly separated admin pages vs Drupal all-meshed-together approach.
Perhaps we should look it with a fresher perspective, there are already several developments what use smarter UI to both distinctively separate user / admin space _but_ still provide preview of live site for instant feedback of changes:
Edicy (screenshots and the blog post where from it all started)
Similar ideas can be also seen in Drupal client localization UI and theme helper palette.
WYSIWYG
There are clear steer in community to get it right, Gabor battle plan and some healthy discussion going on. My ideas on this are:
- think in larger context: palettes, inline elements draggable inside content – this all needs not just pluggable wysiwyg API but more flexible / interwingled APIs (in the lines of sun's inline api)
- provide best possible user experience for all “classic” editor options:
-- plaintext editor in core – markup editor in core or in contrib – wysiwym editor in core if drupal-specific and superlight: (think bloated SimpleTest → lean DrupalTest). Hide all unnecessary tools (or even better: work inside-out, start adding tools conservatively)
Using horizontal space
Drupal is very vertical e.g. we are not using much horizontal space what widescreen monitors and improved resolutions give us (compare the situation of early days Drupal).
There has been some UIs though what have been exploring using vertical space more effectively:
- vertical tabs http://drupal.org/…ect/nodeform,
- views 2.0 UI
- panels 2.0 UI
- fieldsets in node edit forms (dropped because on theming complexity and introduction collapsible fieldsets) http://drupal.org/….preview.png
- 2-column layout of /admin
Views + Panels + CCK UI
These “developer eliminator” modules really provide a huge advantage for Drupal to break to the mainstream and differentiate from any other cms/cmf because the flexibility of these tools is just unmatched. And all can be done without coding!
In the same time the intuitiveness of UI of these modules really crumbles under the weight of flexibility (read: complexity). Views 2.0 has made some good progress, providing a glimpse of nextgen interfaces but there is still a long way to go. CCK builds on core content type UI and does not contain _that_ much of complex interactions but there are still loads of UI problems (some of them are noted below). Panels seems to be in worst shape: many elements and configurations screen are just way too cryptic and require a lot of background knowledge and endless screencast-watching.
Also note that these mission-critical modules are using non-core UI widgets and concept, everybody having their own visual language. It is good in terms of development and exploration (somebody had to do the advanced help, vertical tabs, live previews, drag-and-drop blocks etc) but in a final product this diversity kills consistency, lessons learned in one module do not help in other and user experience is hurt.
Cascading settings UI
We have a problem handling UI cascading, global-vs-local settings. It's a super-powerful concept in theory It's hard to understand for the user how toggling the setting in global space affects the local setting etc. Also, every such a case handles the UI a little bit different:
- Views: global vs local overrides between subviews
- CCK (global and field instance settings)
- Theme settings: global vs theme-specific
Notifications
Notifications API and UI are very inflexible and are riddled with problems
- no icons (see the “No icon API”)
- no notification aggregation, grouping
- not scalable for big number of notifications or notifications with long content
- placement is static: no way to do “Yellow Fade Technique”-type inline indications or inline, spacial context related notifications
- perhaps not always optimal placement (see Googles “yellow bar”, it “jumps” dependent on the context)
- permanent messages (“you are in offline mode”, admin/reports/status") vs temporary messages
Aging look of UI widgets and no icon API
Time flies fast and once-cool progress bar and ok/notification/error look aged and buggy There are some cool work done such as icon API and icon API guidelines – have not looked into it with that much detail but gut reactions say theme(‘icon’,‘error’); and icon filename standardization (and possibly name cascading in spirit of tpl.php cascading) is good and necessary – but the term “icon packs” give me shivers. Possibly there has been just too many horrible icons packs out there? Anyhow, some icons work well with some themes and some not and sometimes it is not really up for admin skills to specify it. Perhaps we need a ‘icon pack compatibility’ field on theme .info file? ;)
Broken Flows
Installer: not really broken but can really smoothened out: kill unnecessary steps (merge 1st and second screen of installer, merge 1st and 2nd screen of update, merge last screen of the installer and first welcome screen); simplify site settings form; clean up password strength UI etc
Adding new module: discussed to death but not much done in terms of indicating next steps after enabling the module. Literally we need to convert INSTALL.txt to the task-centric UI. Possibly has a strong dependency on nextgen notifications UI.
There are other critical flows and some of them – Where did my content go and 1st screen – will be discussed in Szeged BoF, that's cool.
No standardized UI and behavior for js popups
We use browser-frame popups, inline elements (password strength), expanding panels (form field groups) or we just taking user to another page, ruthlessly breaking the flow (extended filter hints)
We need standard UI pattern for these elements. This can be used for nextgen help, filter tips, inline term adding, all kind of palettes (panels).
No nextgen help
Discussed and projects underway, GHOP and Views 2.0-wise. My quick thoughts: help should allow inline, spatially contextual hints (see notifications UI and popups above), standardized “read more” behavior and look; clear distinction between local and drupal.org help pages.
Tabs
Ah, poor tabs.
AFAIR tabs were introduced when more rigid page structure $title . $tabs . $content was needed and we did not wanted to mash everything to the $content blob.
Originally tabs were meant for “local tasks”: actions you do in local page context, under the same header. This is echoed in Menu API (MENU_LOCAL_TASK) and in many core pages where original guideline "tab titles have to be active verbs such as "view, edit, configure"" still exists. During tab introduction there was lot of talk that we need introduce tab UI guidelines and tout them to module developers as best practice. But pretty soon such a constraint proves inflexible and module devs AND core devs started to mangle and misuse tabs / local tasks in every possible way.
Tab's Problems:
- people do not see tabs
- some tasks are are more important than others: it's ok to hide complex, never-touched configuration form under a tab but poor “add” needs way more spotlight.
- very OO-mapped, “object_id/action” (echoed in URL) based on system architecture (system mental model), not user mental model. Especially bad is search results approach to tabs: instead showing all results (grouped by type) in one screen as user expects coming from any web search around, search module “sticks to Drupal standards” and pushing the results to different tabs, completely ignoring the original tabs-as-verbs concept.
- hard to use outside the originally designed context, such as
$tabs . $title . $content - no support for js-enabled tabs such as jQuery tabs.
- horizontal tabs have known scalability problems
- LOCAL_TASK and it's rendering are too tightly coupled. We need to decouple them. Tabs rendering component should allow re-usage for different contexts (primary / secondary links, other global tabs, tabs in blocks – there are some initiatives around Views plugins on this)
- LOCAL_TASKs could be rendered in a different way when needed, such as Basecamp or UI where tasks are on right column? Or should some tasks brought over to initial screen as inline/expandable element instead invisible tabs?
Pushing the limits of HTML form elements
Known issue, discussion is bubbling and hierarchical select module has been around for some time We need action!
Some broken, never-usability-tested UI widgets made it to interface
- “Split summary at cursor”. No comments.
- Password strength meter. Not totally broken, after redesign can even prove to be usable
Drag-and-drop
It's great addition to Drupal UI but has several problems still:
- Saving: the asterisk * next to a moved item and invisible footer message (again a non-standard one) just do not communicate the need to save page in order to store changes.
- It works well only when dragging list items vertical dimension: in block configuration page users just do not get the limitation why they cannot move items around to to real block containers, especially when dragging affordance (4-way arrow) tells them so.
Now what?
While this all seems all-talk-and-no-constructive action, I am really trying to get time to get back to Drupal this autumn and help out in every way I can. See you in Drupalcon!
A very thoughtful and in
A very thoughtful and in depth post; thanks for this. I agree that the flexibility of Drupal makes usability difficult as a lot of control is given to the thousands of modules who do things differently. A UI best practise document may help to reduce this.
What do you see as the best way to identify and prioritize usability problems? Everyone has ideas on how to improve the interface but it's hard to know which direction to go and what items to work on first.
Your article is thoughtful
Your article is thoughtful and well-detailed. Very good.
I want to add two points:
I also reply in my blog:
I also reply in my blog: http://www.isriya.com/…al-needs-hig
It seems like, blog comments
It seems like, blog comments is an awful format to comment on lengthy posts but I will give it a try. To give a little background on where I am coming with this I am co-mentor of the GSoC project Usability Test Suite and I work part time as usability expert(which everyone seems to be these days).
Your list of workable usability issues seems like something we probably have known for a long while now. As many good solutions has come by, they simply don't get past that state since everything turns into a opinion war.
Therefore I think the individual issues are not really the problem, its the culture. What you describe as the UI design process.
Building a good user experience is a multidisciplinary thing, having one lead designer or core design team will inevitably exclude experts on certain UI specific fields fall of the boat. As many programmers build solutions for themselves, the authority of any UI team in discussions will always fall on experience seeing other using the UI (even when the UI team is right).
I can probably talk about this in lenght but http://www.bigcontrarian.com/…reat-divide/ said most of it.
We have to get any UI process, earlier and with more importance into any project – it shouldn't be just the programmer fiddling with the interface from begin to end.
Dries made a vision, but I don't think anyone picked up on it yet. If you have a vision of maybe 5 years, you can put metrics to it, only then it becomes a roadmap. I don't think this could be so hard, but we'd have to say no-go unless a metric is met kind of idea – more.
This is definitely an issue, its rare that a designer comes up with the perfect solution the first time (apart from some genius designers). Its a process of 20 bad designs and trying to get the good parts every design and turn it into 1/3 good designs. For the UTS project, we started with mock-ups and we are constantly trying to refine them – but the initial ones where pretty flawed and now we have the luxury of able to tackle them over and over until we get them right, because the maintainer considers getting it right more important then releasing it early.
I am not sure about this, not about if its good or not. But because the current process of improving d.o is so flawed its unlikely that it will be fixed anyway.
We have been working quite hard on the UTS, its far from there yet. But we can track quite a lot already. Though there seems to be little to no interest in this module, which compared to the simple test buzz to me seems a bit weird. It will allow for quick usability testing in small scale, but it requires people's interest and hard work for it to succeed.
I don't think throwing money at cheap tests, will get you the results you are looking for. I still have to find that cheap usability company, because mostly being cheap means they are simply just not that good.
Eye tracking is probably the least important usability technique we should be focusing upon. It's great to confine programmers, because they just love moving balls but eye tracking should only be used with other techniques and most of the time those other techniques get you the valuable information.
Jared Spools rant on it : http://www.uie.com/…the-expense/
People
The impact of Steven Wittens leaving on the interface is immense. Not sure how we can survive with him, we can probably get him back by seriously rethinking Drupal's process – UI wise its flawed.. I cant comment on the programmers.
Now what? I am happy that your going to spend more time on these issues. But don't get burned out, as all the others working on these issues – and kill +1 and –1 without research driven comments for me please :)
I am almost out of options when it comes to usability in Drupal, ranting doest seem to get far, nor does constructive comments. Maybe a UI team can, but for now I will just focusing on getting the tool UTS working so that who ever is honestly interested in Usability can do user testing in Drupal and his/her work environment.
P.S I am surprised you didn't talk about task-centric information architecture's.
Mmmm… we have rabid code
Mmmm… we have rabid code police (which is a good thing) that enforce coding rules and don't accept contributions that aren't up to standard.
We have no UI rules, no standards and no basis to mark UI as “needs work.”
The outcome is inevitable. At the same time, unless people step up to do the work to generate all those standards, it isn't going to happen.
Which brings me to very simple solutions like adopting Yahoo's design patterns if not their actual UI code. http://developer.yahoo.com/ypatterns/
Its probably not realistic to expect the Drupal community will on its own develop equivalent design patterns.
I am surprised you didn't
I planned to talk about many more things but this already-too-long rant had to stop somewhere.
I am too not too convinced on eyetracking either, it can only work in combination with other testing techniques. My point was to introduce more usability techniques to drupal community – somehow we need to convince others that usability testing is cool. Even when we need eye-candy to beat webchick-candy ;)
Dugg! http://digg.com/…n_ch
Dugg!
http://digg.com/…n_challenges
„Even when we need
That sounds like something I probably need to take offense to. :P Anyway…
But I'm a developer, with no formal usability training. I need help. Where do I start?
Go, webchick! I really do
Go, webchick!
I really do think we could use your help in UI field too (but somehow you need to clone yourself to really deliver it in all these fronts you are active on).
Formal usability training: I presume most of Drupal “usability experts” are not that formally trained. They just read some books, keep track on some blogs etc.
Some eye-openers for me over the times (you are probably know all these):
Good one :) I'm not sure
Good one :) I'm not sure getting outside usability people in will fix things (I speak as one), outside people often don't have the deep understanding of the history of decisions that you guys have. But then I don't have solutions either.
1 way to get outside people contributing would be the usability competition. Identify 5 screens or interactions that are clearly broken usability-wise, have a competition where people can submit their solutions, and declare a winner (with an ipod as prize or something). That would at least get the ideas flowing.
Lets do something cool. Pick
Lets do something cool.
Pick a project, make a mockup, and I'll help code it up. Then we'll have a battle in the issue queue :)
In the same time the
In the same time the intuitiveness of UI of these modules really crumbles under the weight of flexibility (read: complexity). Views 2.0 has made some good progress, providing a glimpse of nextgen interfaces but there is still a long way to go. CCK builds on core content type UI and does not contain _that_ much of complex interactions but there are still loads of UI problems (some of them are noted below). Panels seems to be in worst shape: many elements and configurations screen are just way too cryptic and require a lot of background knowledge and endless screencast-watching.