Kristjan Jansen Interaction designer and social activist. Contact: kika at trip.ee

Samm-sammult, järk-järgult hiilib sisuhaldus-raamistik Drupal ka Eestisse. Esialgu näeb teda küll üsna madalaprofiililistel veebilehtedel, kuid vaadates teiste maade kogemusi, on vaid aja küsimus, millal mõni suurem ja tuntum sait Drupali kasutusele võtab.

Tasub ennast ette valmistada ja Drupaliga kurssi viia ning uusi nippe omandada kuid kes viitsib seda kuskil kontorikuumuses teha? Suvi on käes ja miks mitte ühendada meeldiv kasulikuga: ajada tehnojuttu otse looduses?

Reedel, 12. juuni õhtupoolikul saavad Eesti Drupali-huvilised kokku Peterburi maantee lähedal Loobul (veidi enne Viitnat) Lahemaa puhkekeskuses.

Vaatame esitlusi ja peame diskussioone, õhtu edasine käik on vaba, isegi saun ja tünnisaun on olemas!.

Üür ja ööbimine on sponsorite poolt makstud, kuludeks ainult oma transport kohale. Kaasa võtta söök-jook, hea tuju ja vajadusel laptop – wifi ja esitlustehnika leiab kohapealt.

Lisainfo, kaart ja registreerimine http://groups.drupal.org/node/22186

Kohtumiseni!

When I was asked to talk about user experience in DrupalCamp Finland in Helsinki University, I first came up with the long-winded presentation title ever: “Drupal UI challenges: Creating better user experience for Drupal 7 and beyond” – to cover my back obviously – since I did not had much of an idea what to talk about.

I tried to narrow it down to two things: introducing D7UX to Finnish Drupal community and talking about my recent pet peeve: re-usable interaction patterns and user interface components.

You can download the presentation here (2 MB)

Some credits: The font is free Rabiohead. Dude and angel pictures are from Flickr and picture of Chucky is well…from the hell of course!

So did my trusty MacBookPro. In evening rush hour in Budapest airport somehow my laptop was pushed off the conveyor belt of the security screener – and the poor thing landed right down to the marble floor. The LCD is clearly broken, there is some hope that hard disk survived, let see what Apple service has to say.

The most bummer part is that I can not afford to repair the thing or get a replacement to it, so my online presence and Drupal contribution level is pushed back to minimum what is truly a shame – at least for a while.

There is some irony in it: we talked in Szeged UX sprint quite a lot about low-tech usability and paper prototyping. I was not expecting that day will come so soon. I am off to stationary store to grab a “PaperBookPro” now. ;)

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:

Tumblr

Edicy (screenshots and the blog post where from it all started)

Squarespace

Typepad design assistant

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!