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

I am breathless: considering Estonian astonishingly slow Drupal pickup rate, a first big-name site has launched: Estonian Ministry of Foreign Affairs.

Was it the Drupalgate affair making diplomats finally move faster?

Edit: the conversion was made in-house, with Canadian company Liefa Communications doing design as Photoshop comps.

The title may suggest a bit medieval setting, but do not get wrong about it: in true e-Estonia fashion, every decent wooden shack around Estonia has a WiFi access and a projector to run meetings.

In one rainy Friday, 12 July, first ever Estonian Drupal convention gathered in a forest hideout near capital Tallinn. In addition in lengthy debates on Drupal latest developments and sharing best practices (Artisteer was mentioned, the usual Views and CCK gospel shared), we also talked about infrastructure of Drupal Estonia: g.d.o. group vs regional domain drupal.org (usual debate in every country's community?), releasing a proper Estonian translation (we are almost there) and founding a nonprofit organization to support Drupal Estonia activities. There was even a talk about EU funds to support regional translations of Drupal.

Meet the mighty pioneers of Drupal in Estonia – the detailed links with names and links can be found here.

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!

Recently I was called to help a very special initiative in Estonia: a grassroot non-commerical project My Estonia, a 1-day country-wide brainstorming session designed to provide all citizens to gather around issues that matter to them – from local neighborhood to larger-scale concerns.

I volunteered to help them in data visualization: to take geodata about “My Estonia” brainstorming locations (all 500 of them), split them by county and deliver freely printable maps to usein event headquarters and also distribute them in local newspapers. Since the whole thing had to be without restrictive license, I couldn't use usual “Google Map + KML on top of it” route. So, what to do then? I only had half day to come up with solution.

I turned to Mapping Kit, Drupal's plug-in suite what I noticed in DrupalCon DC presentation – and I was blown away. Although a bit complex at start (especially because of cryptic terminology of geoinformation systems) I was quickly up and running, creating maps, embedding marker layers and querying mapping servers. All I needed was there, and more.

I addition to great backend I was also blessed by very helpful individuals: Andres Kütt and his team to provide a KML with source data (view in Google Maps) and allowing to split it up by county using URL parameters.

Next step was to embed the data to the open source map: OpenStreetMap source map and OpenLayers map rendering – both supported out of the box by Mapping Kit – were both natural fit. I attached each county to separate marker layer so the client could hand-pick the any data combination he needs.

There was still more to tweak: the markers. KML source had a minimal markup and no styling whatsoever. I tried several Google's default markers but they tend all to be too complex and unsuitable for print. I finally decided to create my own simple marker (available here: marker_ball_white_32×32.png).

Now, my map was looking something like this (county layers were accessible under “+” sign):

But something was still missing: the county borders to give a clearer overview what locations belong to what region. I checked out Estonian Land Board, as they are running some geoweb public services. I tried to query their Web Map Server for county borders using Drupal's Mapping Kit and use it as WMS layer in my map. Querying part worked like a charm, but unfortunately the border data was not in the presentable format: filled polygons instead of lines, data scattered across several layers etc.

At that time I was almost running out of time so I gave a call to Land Board where Raivo Alla provided me a helful tips to fix the problem and rendered me a decent KML file with the county borders. The 5MB KML file was unfortunately too big for Google Maps and OpenLayers to crunch (Google Earth made it) so I had to cancel the effort to add county borders to my map. But nevertheless big thanks to Land Board (I am working with them to make the border file simpler and publicly available in their website).

The bottom line is this: if something makes you from zero to “homegrown geoweb expert” in half a day, it must be one hell of a tool. Also, I am glad I live in Estonia where organization structures are not too hierarchic, it's easy to avoid bureaucracy and get the public data you need fast. Thanks to all!

Second video take on content type editing is embedded below: this time focusing more on workflow-oriented fields such as status and author.

Slides can be found in Flickr.

These are exiting days for Drupal. Behind D7UX, a cryptic name meaning “Drupal 7 User Experience” hide bunch of talented professionals who really want to take the notoriously complex piece of code to a next level. Their headquarters: http://d7ux.org

So, it's time to join in. Here's my first contribution, a 10-min video embedded below what tries to explain how content type editing should work in new UI framework.

The slides I am using in the presentation can be checked out in Flickr.

Some background reading: my Drupal UI challenges article, especially “Views + Panels + CCK UI” section and also wireframe by Lullabot what explains the complexities around mapping content editing and viewing UIs.

Now as Drupal is under redesign turbulence, let's remember the summer of 2002 when Druplicon's fate was under similar heat ;) Here is my kludgy take from those times, heyday of Dax typeface. Do you note some similarities with Mark's latest wordmark proposal ? ;)

Also, here is some related Michael Angeles work from 2004.

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!

Here is the quicklist of proposed changes for recently launched GoPHP5.org. Hopefully drupal.org or its sister sites or any Drupal project can catch some ideas from this proposal (click on links to see full resolution mockups).

Current look:

1. Logo: Sorry to say that but the current GoPHP5 logo might be the biggest roadblock to the initiative to succeed, especially for design-cautious crowd. I understand the hassle to find proper volunteering professional designer, so I propose to get away with simple logo placeholder for now (see below)
2. Counter widget: Two problems with it: 1) the design of the the “end date” and “countdown time” are so different that I did not even connected them – figured that the 5.2.2008… is the mis-placed date of the press release below, meaning current date. 2) the whole purpose of the counter. I am on the fence on it…it is a cool dynamic widget and has right context as countdown is the central idea of the whole initiative. Then again, the (static) “214 DAYS”, + and (dynamic) “11:50:58” feel a complex combo. And of course the obvious question: 214 days to WHAT? (see next item)
3. The introduction: This is the next blow to the initiative: such a massive text block with almost no structure or highlights fees awfully cryptic to digest. Scrap it!
4. Headers: 1) need style tinkering: in visual hierarchy they are weaker that the projects below, this has to be reversed.
5. Logos and descriptions: ugly wrapping because of different heights of the logos.
6. “United States of America” – why not “USA”? Also, country placement and styling needs work.
7. Logos and descriptions: more padding needed.
8. Buttons: same problems as with the main logo.
9. Credits and Press: placement seems flawed.

Proposed look:

1. As long there is no proper logo, go for newspaper style that has been picked for rest of the page. Go for massive “Times New Roman” (or Georgia if you want to be fancier), combine black and gray letters to be less plain.
2. Counter widget: I do not have good ideas for styling it atm, but do try to fix the problems I mentioned above.
3. Try to compress the whole point of the initiative for 1–2–3 sentences, with less technical jargon. Add yellow highlights if needed.
4. This links takes you to full press release/reasoning. Make it appear using Drupal expand/collapse JS container if you want to be fancier.
5. Fixed header styling. Note that the labeling of headers needs work: there has to be a space for a word “Recent” as prefix. Perhaps “Recently joined software” and “Recently joined webhosts”?
6. links to all items should be in the header for easier access.
7. Nicer padding and more rigid grid layout for avoiding ugly wrapping.
8. Appending country after the host name. And go for “USA”.
9. Fixed headers. Buttons are still ugly, but it is not THAT critical at this point, they can be updated.
10. Fixed credits and press placement.

And last but not least: Drupal favicon seems out of place on this site ;)