Recomendados
Más contenido relacionado
Similar a Drupal 7 UI Patterns Guide
Similar a Drupal 7 UI Patterns Guide (20)
Más de Bojhan
Drupal 7 UI Patterns Guide
- 1. Drupal 7 User Interface Patterns Bojhan Somers & Roy Scholten
- 7. Common problems Form elements Choosing the right one for the job
- 8. Radio buttons Form elements
- 9. Radio buttons Form elements Don ’ t use them for Yes/No options
- 10. Radio buttons Form elements Don ’ t use them for Yes/No options. Use a checkbox instead
- 13. Select list Form elements
- 14. Select list Form elements Beware overloading it Make it clear that a selection is needed
- 15. List box Form elements Avoid whenever possible
- 20. Vertical tabs Grouping elements
- 22. Machine name Grouping elements
- 27. Table Listings
- 31. Drag & Drop Listings
- 35. Information Architecture Information architecture
- 39. Local actions Information architecture
- 43. Contextual links Information architecture
- 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
- 50. Omit needless words User interface text
- 51. Omit needless words User interface text
- 52. Omit needless words User interface text
- 53. Omit needless words User interface text
- 54. Jargon: developer docs in the UI User interface text
- 56. No confidence in the user User interface text
- 57. No confidence in the user User interface text Note that… Please… Don’t… If enabled… Shouldn’t… You may now… Allow…
- 58. Explaining a broken UI User interface text
- 59. Explaining a broken UI User interface text
- 66. What did you think? http://chicago2011.drupal.org/sessions (“Take the Survey” link) @bojhan ,@royscholten Thanks!
Notas del editor
- 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'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'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'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: "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…)
- 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'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't use nested vertical tabs, it disorientates the user Don't use multiple vertical
- Some input fields have to create a second, 'sanitized' version of the value given by the user called a 'machine name'. 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 & 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 & 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 'List'.
- Avoid long tab labels p the label short, avoid more then one word ? Don'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'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…