Drupal 7 User Interface Patterns Bojhan Somers & Roy Scholten
 
Reusable solutions to recurring design problems <ul><li>About design patterns </li></ul>
What is a design  pattern? About design patterns <ul><li>Common design problem </li></ul><ul><li>Solution </li></ul><ul><l...
Why? <ul><li>Consistency </li></ul><ul><li>Sanity check </li></ul><ul><li>Self-service </li></ul>
The basics <ul><li>Form element </li></ul>
Common problems Form elements Choosing the right one for the job
Radio buttons Form elements
Radio buttons Form elements Don ’ t use them for Yes/No options
Radio buttons Form elements Don ’ t use them for Yes/No options. Use a checkbox instead
Checkbox Form elements
Checkbox Form elements
Select list Form elements
Select list Form elements Beware overloading it Make it clear that a selection is needed
List box Form elements Avoid whenever possible
Fieldsetitus <ul><li>Grouping elements  </li></ul>
Common problems Grouping elements <ul><li>Overloading the grouping pattern by adding too many elements to a single groupin...
Fieldsets Grouping elements
Fieldsets Grouping elements <ul><li>Avoid Fieldsetitus </li></ul><ul><li>Keep them within one scroll </li></ul><ul><li>Avo...
Vertical tabs Grouping elements
Vertical tabs Grouping elements <ul><li>Avoid using it for the main interaction  (skip able) </li></ul><ul><li>Avoid long ...
Machine name Grouping elements
Machine name Grouping elements <ul><li>Use for all machine names  </li></ul><ul><li>Avoid using it for other occasions </l...
Summary <ul><li>Pattern index </li></ul><ul><li>Fieldsets </li></ul><ul><li>Vertical tabs </li></ul><ul><li>Machine name <...
Operations <ul><li>Listings </li></ul>
Common problems Listings <ul><li>Lack of overview </li></ul><ul><li>Too many operations </li></ul><ul><li>Too many columns...
Table Listings
Table Listings <ul><li>Standardize order of columns </li></ul><ul><li>Order operations, edit first and delete last. </li><...
Table empty Listings
Table empty Listings <ul><li>There are no [things]  available/ yet. Add [thing] </li></ul><ul><li>Action should be the sam...
Drag & Drop Listings
Summary <ul><li>Pattern index </li></ul><ul><li>Table (empty) </li></ul><ul><li>Drag  and drop </li></ul><ul><li>Filters <...
Navigation <ul><li>Information architecture </li></ul>
Common problems Information architecture <ul><li>New information architecture concept, so a lot of misplaced items </li></...
Information Architecture Information architecture
Information Architecture <ul><li>Sections </li></ul><ul><li>Content </li></ul><ul><li>Structure </li></ul><ul><li>People <...
Configuration sections <ul><li>Sections </li></ul><ul><li>People </li></ul><ul><li>System </li></ul><ul><li>Content author...
Configuration sections <ul><li>Principles </li></ul><ul><li>People </li></ul><ul><li>System </li></ul><ul><li>Content auth...
Local actions Information architecture
Local actions Information architecture <ul><li>Keep the task label short, start with a verb “Add”.  </li></ul><ul><li>Pref...
Tabs Information architecture
Tabs Information architecture <ul><li>If the main tab is a listing, call it “List” </li></ul><ul><li>Group similar tabs  <...
Contextual links Information architecture
Contextual links Information architecture <ul><li>Primarily used in the front end </li></ul><ul><li>Short labels (2/3 word...
Summary <ul><li>Pattern index </li></ul><ul><li>Information architecture </li></ul><ul><li>Configuration sections </li></u...
The fastest way to improve your interface is to improve the copy writing <ul><li>User interface text </li></ul>
Common problems User interface text Too much of it Jargon & difficult words Not instilling confidence in the user Document...
 
 
Omit needless words User interface text
Omit needless words User interface text
Omit needless words User interface text
Omit needless words User interface text
Jargon: developer docs in the UI User  interface  text
<ul><li>Node, taxonomy, truncate, enabled, disabled, modifications, execute, retain, retrieve… </li></ul>Jargon and other ...
No confidence in the user User interface text
No confidence in the user User interface text Note that… Please… Don’t… If enabled… Shouldn’t… You may now… Allow…
Explaining a broken UI User interface text
Explaining a broken UI User interface text
Summary <ul><li>Pattern index </li></ul><ul><li>Page help </li></ul><ul><li>Form element label </li></ul><ul><li>Form elem...
Index <ul><li>Grouping elements </li></ul><ul><li>Fieldsets </li></ul><ul><li>Vertical tabs </li></ul><ul><li>Machine name...
Pattern library <ul><li>How do we make it happen? </li></ul>
 
 
 
What did you think? http://chicago2011.drupal.org/sessions  (“Take the Survey” link) @bojhan ,@royscholten Thanks!
Upcoming SlideShare
Loading in …5
×

Drupal 7 Interface Pattern

4,885 views
4,754 views

Published on

Presentation @ Drupalcon Chicago on interface patterns of Drupal 7

0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
4,885
On SlideShare
0
From Embeds
0
Number of Embeds
98
Actions
Shares
0
Downloads
25
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide
  • UX – Team leads Netherlands Heavily involved in UX of Drupal, UX Maintainers of Drupal 7
  • Surgical teams that follow a basic cockpit-style checklist in the operating room, from confirming the patient&apos;s name to discussing expected blood loss, reduce the rate of deaths and complications by more than a 33%
  • So, there’s real value in having a checklist. For Drupal admin ui that checklist would consist of design patterns
  • 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&apos;s interface is hard and very time consuming.  We would like to create a consistent user experience- when you are using all these modules
  • 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.
  • 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.
  • 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.   Beware, this is already a semi-advanced pattern. There will be people who won&apos;t recognize it as something that hides more options than directly visible
  •   Recommendations: - Sensible first selection - Provide a sensible default or be clear about the action that is needed: &amp;quot;Choose one here…&amp;quot; - Beware, this is already a semi-advanced pattern. A lot of users won&apos;t recognize it as something that hides more options than directly visible   (So here it&apos;s fine…)
  • 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.
  • Fieldset is the first pattern 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.  Useage:  When there are a lot of form elements, which need to be grouped logically There are very different form elements on a page There are very similar form elements but with a distinctive difference (blocks administrator)
  • Avoid Fieldsetitus ( Don&apos;t put a fieldset around the main (first) interaction on the page if there is one.) Keep them within one scroll Avoid nested fieldsets , it disorientates the user Position default-collapsed fieldsets below expanded
  • 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 Not the main interaction skippable - node form
  • Skippable No pane that is too long. The vertical tabs are meant to be in view with the content of the page - to allow orentation Long descriptions No more then 9 Not less then 3 Don&apos;t use nested vertical tabs, it disorientates the user Don&apos;t use multiple vertical
  • Some input fields have to create a second, &apos;sanitized&apos; version of the value given by the user called a &apos;machine name&apos;. Like removing spaces or replacing them with underscores. These are needed to have safe values for a database column name  In the interface this means double the work for users for something they are very likely not interested in knowing about. Solution:  Automatically create the machine name version from the human readable input. Show this version in a smaller size to the right of the normal input field. Provide an edit link to change the generated version of the machine name. Useage:  Whenever you are asking the user to fill something in which will soley be used for system purposes and has previously already been entered in a similair way. Database name generation
  • Use this only for machine names
  • Overloading the grouping pattern by adding too many elements to a single grouping Unnecessary groupings: fieldsets with 1 checkbox
  • Tables, the most common listing in modules. There are a lot of fairly obvious things that tend to go wrong. Table: what goes where: ordering columns and operations,
  • Order of columns (convention is: name, status, operations Too many columns, with duplicate or unnecessary information (reconsider, when you are adding a column) If possible, put the available operations in one row. If that’s not possible, put them right underneath each other
  • Which means that any table which has no data in it, like in this case Secondary links menu. (MANUAL CODING)  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. There are no [things] available/ yet.  Add link .
  • Drag &amp; 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
  • Drupal 7 its information architecture is designed after a age-old model, that of the book shelf. Where every book is in a category and other books in that category, give you clues for where to find the book you are looking for. Hubs Content and people for listings related to that object, (e.g. Signup module for People) Structure is where very important functionality lives, the kind of modules and functionality you use day-in-day out when you are building or maintaining a Drupal website. Appearance (theme page – why is it here? Promote design) Configuration ( Whenever a module exposes configuration of any sort, its most likely to fit in this place. Its where functionality that you touch primarily during site-building or occasional configuration goes. ) The Reports section is all about listing of report pages such as “Recent log entries” and “Available updates” – it is common for modules that are aimed specifically at website analytics to expose their reports here.
  • Recap : 5 Actual sections where you can put stuf Structure is for frequently accessed site building functionality (front end. its usable to limited extend, designed to stay small, optimized for around 7 items): Views Panels NOT Backup &amp; Migrate Configuration Configuration is for infrequently accessed site building or configuration functionality goes (initial setup!!) Most of the modules that you build Rules (infrequently accessed site building) (don’t decide on the label, LABELS do not reflect reality…)
  • Instead of one bit bucket, we choose to split this page up on a lot of smaller buckets to make it easier to scan.
  • The functionality (modules) already placed in this category. The label assigned to the category. If new section ------------------------------------------------------------------------------------------ Could it fit a category created by a parent module (Field category by CCK)? Would the category house other modules (e.g. be the parent modules)? Are you sure your module won ’t be the only one in this category?
  • You should use this when you have an action that is a very common task to perform on that page. Distinguishable - position - color - + sign
  • You need consistent navigation for related pages, in which the navigation context is always visible. There is always a default tab. In core admin, this is often a listing (content, users, terms, aliases etc.). Name this one &apos;List&apos;.
  • Avoid long tab labels p the label short, avoid more then one word ? Don&apos;t group similar tabs together (make sure tabs are related yet also *distinct*?) Avoid creating more then 4 tabs. If you find yourself making more, look for broader groupings and
  • Problem:  When you want to change a setting of an object in your site and the way to that settings page gets so long that you forget what you came to do in the first place. You lose context because the setting is located so deep in the administration section, so far removed from the object. Solution:  Provide a small drop-down that displays on hovering an object. The options in the drop-down offer direct links to a few tasks for this object. The tasks are exposed *in context* of the object itself. Objects Objects like blocks, nodes, menu&apos;s that have a few frequently used tasks (edit, add, configure) Other objects in the front facing part of Drupal
  • When those causes add up we see an overarching problem emerge: we have too much of it.
  • When those causes add up we see an overarching problem emerge: we have too much of it.
  • You can win back a lot of user interface real estate by having a critical look at your form labels and descriptions. Don’t have descriptions because you can
  • If 2 or 3 extra words for the label make the desc. Unnecessary, then do that
  • Maybe somebody can open a core issue for this one during this session… Found this beauty in the theme settings
  • This is really all that is being offered here.
  • Don’t document edge cases in the UI
  • Obviously not fixable by rewriting the tekst…
  • Drupal 7 Interface Pattern

    1. 1. Drupal 7 User Interface Patterns Bojhan Somers & Roy Scholten
    2. 3. Reusable solutions to recurring design problems <ul><li>About design patterns </li></ul>
    3. 4. What is a design pattern? About design patterns <ul><li>Common design problem </li></ul><ul><li>Solution </li></ul><ul><li>Solution Rationale </li></ul><ul><li>Visual examples </li></ul>
    4. 5. Why? <ul><li>Consistency </li></ul><ul><li>Sanity check </li></ul><ul><li>Self-service </li></ul>
    5. 6. The basics <ul><li>Form element </li></ul>
    6. 7. Common problems Form elements Choosing the right one for the job
    7. 8. Radio buttons Form elements
    8. 9. Radio buttons Form elements Don ’ t use them for Yes/No options
    9. 10. Radio buttons Form elements Don ’ t use them for Yes/No options. Use a checkbox instead
    10. 11. Checkbox Form elements
    11. 12. Checkbox Form elements
    12. 13. Select list Form elements
    13. 14. Select list Form elements Beware overloading it Make it clear that a selection is needed
    14. 15. List box Form elements Avoid whenever possible
    15. 16. Fieldsetitus <ul><li>Grouping elements </li></ul>
    16. 17. Common problems Grouping elements <ul><li>Overloading the grouping pattern by adding too many elements to a single grouping </li></ul><ul><li>Unnecessary groupings: fieldsets with 1 checkbox </li></ul>
    17. 18. Fieldsets Grouping elements
    18. 19. Fieldsets Grouping elements <ul><li>Avoid Fieldsetitus </li></ul><ul><li>Keep them within one scroll </li></ul><ul><li>Avoid nested fieldsets , it disorientates the user </li></ul><ul><li>Position collapsed fieldsets below expanded </li></ul>
    19. 20. Vertical tabs Grouping elements
    20. 21. Vertical tabs Grouping elements <ul><li>Avoid using it for the main interaction (skip able) </li></ul><ul><li>Avoid long panes </li></ul><ul><li>Avoid long descriptions </li></ul><ul><li>No less then 3, no more than 9 </li></ul>
    21. 22. Machine name Grouping elements
    22. 23. Machine name Grouping elements <ul><li>Use for all machine names </li></ul><ul><li>Avoid using it for other occasions </li></ul>
    23. 24. Summary <ul><li>Pattern index </li></ul><ul><li>Fieldsets </li></ul><ul><li>Vertical tabs </li></ul><ul><li>Machine name </li></ul>Grouping elements Use fieldsets for chuncking functionality, vertical tabs to hide a lot of functionality. Avoid overloading patterns, or adding unnecessary groupings.
    24. 25. Operations <ul><li>Listings </li></ul>
    25. 26. Common problems Listings <ul><li>Lack of overview </li></ul><ul><li>Too many operations </li></ul><ul><li>Too many columns, with duplicate or unnecessary information </li></ul><ul><li>No empty table state </li></ul>
    26. 27. Table Listings
    27. 28. Table Listings <ul><li>Standardize order of columns </li></ul><ul><li>Order operations, edit first and delete last. </li></ul><ul><li>Avoid adding columns with similar data </li></ul>
    28. 29. Table empty Listings
    29. 30. Table empty Listings <ul><li>There are no [things] available/ yet. Add [thing] </li></ul><ul><li>Action should be the same as the local action </li></ul>
    30. 31. Drag & Drop Listings
    31. 32. Summary <ul><li>Pattern index </li></ul><ul><li>Table (empty) </li></ul><ul><li>Drag and drop </li></ul><ul><li>Filters </li></ul><ul><li>Admin listing (Structure/Config) </li></ul><ul><li>Weighted listing (Appearance) </li></ul><ul><li>Sectioned listing (Blocks, permissions) </li></ul>Listings Listing are mostly about adhering to standards (positioning columns, operations), avoiding unnecessary columns and empty table messages.
    32. 33. Navigation <ul><li>Information architecture </li></ul>
    33. 34. Common problems Information architecture <ul><li>New information architecture concept, so a lot of misplaced items </li></ul><ul><li>Not applying new patterns (contextual links, action links) </li></ul>
    34. 35. Information Architecture Information architecture
    35. 36. Information Architecture <ul><li>Sections </li></ul><ul><li>Content </li></ul><ul><li>Structure </li></ul><ul><li>People </li></ul><ul><li>Configuration </li></ul><ul><li>Reports </li></ul><ul><li>Principles </li></ul><ul><li>Content and people for listings related to the object </li></ul><ul><li>Structure is for frequently accessed site building functionality (max 7) </li></ul><ul><li>Configuration is for infrequently accessed site building or configuration functionality </li></ul><ul><li>Don’t decide purely on your interpretation of section label </li></ul>Information architecture
    36. 37. Configuration sections <ul><li>Sections </li></ul><ul><li>People </li></ul><ul><li>System </li></ul><ul><li>Content authoring </li></ul><ul><li>User interface </li></ul><ul><li>Media </li></ul><ul><li>Search and metadata </li></ul><ul><li>Development </li></ul><ul><li>Regional and languages </li></ul><ul><li>Web services </li></ul>Information architecture
    37. 38. Configuration sections <ul><li>Principles </li></ul><ul><li>People </li></ul><ul><li>System </li></ul><ul><li>Content authoring </li></ul><ul><li>User interface </li></ul><ul><li>Media </li></ul><ul><li>Search and metadata </li></ul><ul><li>Development </li></ul><ul><li>Regional and languages </li></ul><ul><li>Web services </li></ul><ul><li>How to choose </li></ul><ul><li>The functionality (modules) already placed in this category. </li></ul><ul><li>The label assigned to the category. </li></ul>Information architecture
    38. 39. Local actions Information architecture
    39. 40. Local actions Information architecture <ul><li>Keep the task label short, start with a verb “Add”. </li></ul><ul><li>Preferably only one task, avoid more then two </li></ul>
    40. 41. Tabs Information architecture
    41. 42. Tabs Information architecture <ul><li>If the main tab is a listing, call it “List” </li></ul><ul><li>Group similar tabs </li></ul><ul><li>Avoid creating more than 4 tabs, consider broader groupings </li></ul><ul><li>Avoid secondary navigation </li></ul>
    42. 43. Contextual links Information architecture
    43. 44. Contextual links Information architecture <ul><li>Primarily used in the front end </li></ul><ul><li>Short labels (2/3 words) </li></ul><ul><li>Avoid more than 6 tasks </li></ul>
    44. 45. Summary <ul><li>Pattern index </li></ul><ul><li>Information architecture </li></ul><ul><li>Configuration sections </li></ul><ul><li>Local actions </li></ul><ul><li>Tabs </li></ul><ul><li>Contextual links </li></ul>Information architecture With all the new patterns, it mostly comes down to choosing the right labeling.
    45. 46. The fastest way to improve your interface is to improve the copy writing <ul><li>User interface text </li></ul>
    46. 47. Common problems User interface text Too much of it Jargon & difficult words Not instilling confidence in the user Documentation instead of guidance Explaining a broken user interface
    47. 50. Omit needless words User interface text
    48. 51. Omit needless words User interface text
    49. 52. Omit needless words User interface text
    50. 53. Omit needless words User interface text
    51. 54. Jargon: developer docs in the UI User interface text
    52. 55. <ul><li>Node, taxonomy, truncate, enabled, disabled, modifications, execute, retain, retrieve… </li></ul>Jargon and other difficult words User interface text
    53. 56. No confidence in the user User interface text
    54. 57. No confidence in the user User interface text Note that… Please… Don’t… If enabled… Shouldn’t… You may now… Allow…
    55. 58. Explaining a broken UI User interface text
    56. 59. Explaining a broken UI User interface text
    57. 60. Summary <ul><li>Pattern index </li></ul><ul><li>Page help </li></ul><ul><li>Form element label </li></ul><ul><li>Form element description </li></ul><ul><li>Messages: error, warning, confirm </li></ul><ul><li>Button labels </li></ul><ul><li>Fieldset legend </li></ul>User interface text Focus on the task at hand. Use the simplest word possible. Omit needless words: cut 50%, then cut 50% again. Be nice.
    58. 61. Index <ul><li>Grouping elements </li></ul><ul><li>Fieldsets </li></ul><ul><li>Vertical tabs </li></ul><ul><li>Machine name </li></ul><ul><li>Listings </li></ul><ul><li>Table (empty) </li></ul><ul><li>Drag and drop </li></ul><ul><li>Filters </li></ul><ul><li>Admin listing (Structure/Config) </li></ul><ul><li>Weighted listing (Appearance) </li></ul><ul><li>Sectioned listing (Blocks, permissions) </li></ul><ul><li>Information architecture </li></ul><ul><li>Information architecture </li></ul><ul><li>Configuration sections </li></ul><ul><li>Local actions </li></ul><ul><li>Tabs </li></ul><ul><li>Contextual links </li></ul><ul><li>User interface text </li></ul><ul><li>Page help </li></ul><ul><li>Form element label </li></ul><ul><li>Form element description </li></ul><ul><li>Messages: error, warning, confirm </li></ul><ul><li>Button labels </li></ul><ul><li>Fieldset legend </li></ul>Index
    59. 62. Pattern library <ul><li>How do we make it happen? </li></ul>
    60. 66. What did you think? http://chicago2011.drupal.org/sessions (“Take the Survey” link) @bojhan ,@royscholten Thanks!

    ×