There are more interface patterns available to Drupal module developers then ever before. Drupal has standars for writing code. But what about the interface?
Tabs, accordions, fieldsets, overlays, hover links etc. When to use which?
Join Bojhan Somers and Roy Scholten from the UX-Team for a tour of the available options and some advice on when to use each one. Consider this talk the kick-off for getting our ui-pattern library in shape. It's been asked for a lot.
We will cover the following topics :
* UI-Pattrens
* Best practices (designing for context)
* Users mental model vs. Drupal's implementation model
* Experiences from the field
With the Drupal 7 release on the horizon and the excellent D7CX initiative, *now* is the time to take advantage of these new patterns.
Who are we? We are both Drupal 7 User experience maintainers… and we started the UX Team I work as Information architect on applications and websites And Roy has his own design studio. We tried to make sure to have enough time for questions...
So design pattrens have existed in software engineering for a long time. In this talk we will cover design pattrens that you can use to make your UI better and more conistent with Drupal core. We will cover forms, listing pages and copywrting. And hopefully lay the ground for a pattern libary. (show of hands) Makes modules or just their UI?
What is a pattren? A design pattren is a general reusable solution for commonly accuring problem. such as moving a block around or creating a menu. A design pattren provides a definition of the user problem, the solution we designed and explanations of why the solution was chosen.
Why would we need pattrens? We have over 2500+ modules, who all creatively create thier own UI. So... when you have about 30 to 40 modules enabled, learning every single module it's interface is hard and very time consuming. We would like to create a consistent user experience- when you are using all these modules
So somewhere back in the 90’s there was a large international study done on how checklists influences surgical death rate . As it turned out, it cut down the surgical death rate by half. So, even really simple things like – are all clamps accounted for? Helped So I think this applies to interfaces as well, some patterns we will cover are really obvious, but you kow sometimes as we are building an interface we just don’t pay attention.
A lot of interfaces share the same kind challenges, and with a pattern library they can find the same solution – without having to reinvent the wheel. I think this is important, because it allows you to troubleshoot - because you might not make the right choice the first time. Also – it battles misue of pattrens, avoiding things like a site ending up with 16 tabs.
Notice… We are only going to be talking about proven interactions, those that have been tested with real users. So we are not really talking too much about “Seven” - since a lot of that still has to be user tested. Roy is going to get us started!
So lets get started…. with forms! Most if not all interaction on the web happens through forms, So it's useful to know about the why and how of using the different form elements
Radio buttons allow users to select one option from among a set of mutually exclusive options. Recommendations: - use 3 or more (2 radios can be reworked as a single checkbox most of the times) - provide a default, make that one the first in the list.
Checkboxes allow users to select options independently of one another. Can be a single one (yes/no)
Or multiples (checklist) Recommendations: - Unchecked is the default (opt in, not opt out) - Meaning: make it safe to ignore the option - Use only the label, if you need a description, rethink the feature.
Select lists provide the same functionality as radio buttons - mutually exclusive options - but in a more compact way. Recommendations: - Sensible first selection - Provide a sensible default or be clear about the action that is needed: "Choose one here…" - Beware, this is already a semi-advanced pattern. A lot of users won't recognize it as something that hides more options than directly visible (So here it's fine…)
Beware not to overload it Scrolling through lists of this length becomes unusable
List boxes provide similar approach as check boxes, but again in a more compact way. Main difference with select list of course is that his lets you choose multiple items recommendations: - try to avoid it. Use sparingly. multiple select is not obvious at all, see if you can do it with checkboxes.
So far for the individual, single elements (skipping buttons, text fields, text areas etc.) These all allow you to present a single option or functionality But what about…
So we all know about long forms… in Drupal we have several ways to tackle these. Its all about grouping the form elements - so that they make sense.
Fieldset is the first pattren we apply in the case of longer forms. As of Drupal 7, they have changed visually. Why? Because we felt that fieldsets were often part of of the workflow. So we made them more important visually. Generally fieldsets should be used to hide certain functionality, when a user only requires a small subset of the functionality on that page at any given moment. The most important aspect of fieldsets is the top label, which should sum up its contents. Recommendations - Fieldset should stay within 1 scroll - Avoid nested fieldsets (disorientation)
So the problem that Vertical Tab tries to solve is the space and attention that fieldsets tend to take. The solution that was found is all about grouping functionally and putting those into a tab. Progressive disclosure ( short description) give an information scent. Look if the introduction of vertical tabs is actually solving a problem not just creating less vertical space. Recommendations 1 line description Not the main interaction skippable - node form No more then 9 Not less then 3 Don't use nested vertical tabs, it disorientates the user No pane that is too long. The vertical tabs are meant to be in view with the content of the page - to allow orentation Don't use multiple vertical
The machine name is the title in the Database. When we did testing on this, we found out that a lot of people where confused by this – why did they need to define this ? So the solution that was found, was automatically filling it in with the name that the user provided. Because we don’t have to tire people with this stuff…. And those who find it important to change, still can. Initially the community assumed this would confuse the user. An [edit] link - mental model [User testing] The actual [edit] word triggers the users assumption, that it takes him into an edit mode of that specific thing, not taking him away from the screen perseé Recommendation - Use this for all machine names
So when it comes to listing pages such as content administration, menu's and users We have able to introduced a lot of standards in Drupal 7 that have grown from the usability testing.
So let me explain the several components of a table. We have the title, description, ect ofcourse. But more importantly, the operations table. Recommendations - Operations always on the right - Always edit AND delete - Object name on the left - Descriptions less prominent - Always use two lines if action is to long.
Drag & Drop which was introduced in Drupal 6. Basicly alows you to drag things within a table. Recommendations - Handle should always be on the left - Provide enough feedback about the saving-state - Empty area's, should have an empty message
So in Drupal 7 we introduced the empty state of a table. Which means that any table which has no data in it, like in this case Secondary links menu. Will have an message which says nothing has been added yet - and an action to add it. Recommendations Its important to show the table headers, as this gives the user a scent what he is entering here.
Filters are often used to decrease the amount of information, to just what you where looking for. In Drupal's case they are only part of listing pages such as content administration, user administration. Flooded state, loads of data - need filtering to make sense of it.
Don't USE them! Right now, as they are in Drupal core a lot of users get confused by them. This has a fundamental reason, boolean algebra with operations like or, and. Are very logical from a mathematical and especially implementation standpoint. But users rarely ever understand, the relationship between those operations and what he will filter on. So I would like us to improve this pattren
Ahhh, our beloved local tasks…
It's true. This is what made both Bojhan and me learn how to write patches. In many ways the text == the interface. Can't really overestimate the value of good copy writing.
A drastic example of help text gone wrong. - it's way too long, pushing the actionable items on the page almost below the fold During the last usability test, all participants that skipped the help text and started to just play with the functionality quickly grasped the concept of taxonomy. Everybody who started to read the help text got confused about what they could do here. In some cases even navigating away from the page even though this was the one they needed to accomplish the given task. … So here's a couple of guidelines…
Don't write descriptions for the sake of it
Nobody reads anyway People scan and look for trigger words They scan in the 'F' pattern, so put the trigger word first whenever possible.
passive is less inviting, active is much more engaging and usually requires fewer words
So to sum up… we addressed a large number of pattrens, talked about how they came to be, and how to apply them. And how they can help you create a better UI. We now have a library of pattrens we can work with. So lets take a quick look at Drupal 7!
Feel free to break the pattrens, to try variations or to create completely new ones. Context should always be more important than consistency. Even Apple breaks their own Interface Guidelines. So lets take a quick look at Drupal 7!
Whats happening? We created a new Information Architecture, what does this mean? Instead of a long Admin page, with all your modules. - We now have about 6 to 7 categories in which modules can be placed. A couple new pattrens Actions / tabs Toolbar We still have to do quitea bit of user testing on this, to make sure users don’t get confused
Drupal 8? We are growing more complex.. now with CCK in core. Nodes almost completely become fields – and as we are abstracting further to make Drupal to be flexible we will need even cleaner and better interfaces. There are definitely many challenges ahead of us,
I’d like to thank you! We are working on an online pattren ilbarry. Contact me or Roy if you want to know more. Or just ping us in IRC. Are there any questions?
![Who are we? ,[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)