The document discusses design patterns for Drupal 7 user interfaces. It covers patterns for grouping elements, listings, navigation/information architecture, and user interface text. The main recommendations are to use patterns consistently, avoid unnecessary elements, and write clear and concise user-facing text without jargon.
In this talk, Caroline Jarrett will use eye-tracking data, and her many years experience of forms, to give you ideas for the next time that happens to you . She’ll also get us thinking about some other details of forms, like required field indicators and colons on labels.
Caroline Jarrett started to work with forms when delivering Optical Character Recognition systems to the then Inland Revenue. The systems didn't work very well, and it turned out that the problems arose because people made mistakes when filling in forms. She developed a fascination with the challenge of making forms easy to fill in, a fascination that shows no signs of wearing off over 15 years later.
Caroline is co-author of 'Forms that work: Designing web forms for usability', the companion volume to Ginny Redish's hugely popular book 'Letting go of the words: Writing web content that works'.
Creating accessible modals and autocompletesRuss Weakley
In this two-part presentation, Russ will guide us on a deep dive into how to create accessible modals and accessible autocomplete search functions. Along the way, we will look at the problem for different types of users as well as explore how ARIA can be used to improve these experiences. There will be blood, sweat and tears (Russ' words!) but hopefully a happy outcome for all.
Presentation for the Sydney Web Accessibility & Inclusive Design - 30 August 2019
This presentation was fro the AllyBtyes event on 21 May 2020. The presentations looks at a pattern for building or reviewing any new UI component – semantics, focusable, keyboard interaction, visible states, accessible name and relationships.
This ID24 2019 talk will look at a the importance of states (visited, focus, active, checked/selected, open and more) when building design systems. We will explore their relevance, how to maintain consistency and how to systemise when designing at scale.
In this talk, Caroline Jarrett will use eye-tracking data, and her many years experience of forms, to give you ideas for the next time that happens to you . She’ll also get us thinking about some other details of forms, like required field indicators and colons on labels.
Caroline Jarrett started to work with forms when delivering Optical Character Recognition systems to the then Inland Revenue. The systems didn't work very well, and it turned out that the problems arose because people made mistakes when filling in forms. She developed a fascination with the challenge of making forms easy to fill in, a fascination that shows no signs of wearing off over 15 years later.
Caroline is co-author of 'Forms that work: Designing web forms for usability', the companion volume to Ginny Redish's hugely popular book 'Letting go of the words: Writing web content that works'.
Creating accessible modals and autocompletesRuss Weakley
In this two-part presentation, Russ will guide us on a deep dive into how to create accessible modals and accessible autocomplete search functions. Along the way, we will look at the problem for different types of users as well as explore how ARIA can be used to improve these experiences. There will be blood, sweat and tears (Russ' words!) but hopefully a happy outcome for all.
Presentation for the Sydney Web Accessibility & Inclusive Design - 30 August 2019
This presentation was fro the AllyBtyes event on 21 May 2020. The presentations looks at a pattern for building or reviewing any new UI component – semantics, focusable, keyboard interaction, visible states, accessible name and relationships.
This ID24 2019 talk will look at a the importance of states (visited, focus, active, checked/selected, open and more) when building design systems. We will explore their relevance, how to maintain consistency and how to systemise when designing at scale.
Techniques for Reviewing a User InterfaceRhonda Bracey
Rhonda Bracey's presentation from the WritersUA 2008 Conference (Portland, OR)
****************
"Can you just look over these new screens for us? Oh, and can you check the error messages too? It won't take long!" If you've been asked to review a web or standalone application's user interface but don't know what to look for other than checking the text, then this session is for you. As technical communicators, we are often in a position to identify usability problems related to the logical flow, layout, and structure of the interface; inconsistencies in the design; non-compliance with standards and guidelines; ambiguous wording on labels, error messages, dialogs, and onscreen user assistance; performance issues; functional errors; and the like. Rhonda shares practical checklists of things to look for when reviewing an interface, as well as various tools that can assist you.
— YOU WILL LEARN —
* What to look for when checking an application's user interface, including overall design, textual and visual elements, user actions and interactions, navigational links, and the '-ilities': accessibility, readability, usability.
* About some tools that can help automate parts of the review process.
**************
Other supporting material available from here: http://www.cybertext.com.au/10353.htm
Designing well known websites with ADF Rich Facesmaikorocha
In this presentation we show some of the basics of ADF Rich Faces in terms of page layout, components, and skinning and how can you rebuild two well-known website layouts with those components.
Interface design is not something that belongs solely in the world of Apple. Your website and applications can all benefit greatly from an understanding of how your users might navigate your product.
Presented At the Sydney NETUG on August 18th by Adam Cogan
The whole point of a good GUI (Graphical User Interface) is being able to understand what is going on without reading every single detail. That is why we prefer big red crosses to say "Don't do that you oaf!" instead of a line of text that says "I think you may want to reconsider your options."
Sweeping out the cobwebs: Content auditing for large websitesNexer Digital
Large websites tend, over time, to develop gluts of out of date content and dark unvisited corners. Thanks to devolved publishing, whole sections of a site can spring up without proper planning or coordination, only to be left in place long after they have served their purpose. Using spidering technology, Justin will demonstrate techniques to get a grasp of the size and shape of your site and to begin the process of decluttering.
Techniques for Reviewing a User InterfaceRhonda Bracey
Rhonda Bracey's presentation from the WritersUA 2008 Conference (Portland, OR)
****************
"Can you just look over these new screens for us? Oh, and can you check the error messages too? It won't take long!" If you've been asked to review a web or standalone application's user interface but don't know what to look for other than checking the text, then this session is for you. As technical communicators, we are often in a position to identify usability problems related to the logical flow, layout, and structure of the interface; inconsistencies in the design; non-compliance with standards and guidelines; ambiguous wording on labels, error messages, dialogs, and onscreen user assistance; performance issues; functional errors; and the like. Rhonda shares practical checklists of things to look for when reviewing an interface, as well as various tools that can assist you.
— YOU WILL LEARN —
* What to look for when checking an application's user interface, including overall design, textual and visual elements, user actions and interactions, navigational links, and the '-ilities': accessibility, readability, usability.
* About some tools that can help automate parts of the review process.
**************
Other supporting material available from here: http://www.cybertext.com.au/10353.htm
Designing well known websites with ADF Rich Facesmaikorocha
In this presentation we show some of the basics of ADF Rich Faces in terms of page layout, components, and skinning and how can you rebuild two well-known website layouts with those components.
Interface design is not something that belongs solely in the world of Apple. Your website and applications can all benefit greatly from an understanding of how your users might navigate your product.
Presented At the Sydney NETUG on August 18th by Adam Cogan
The whole point of a good GUI (Graphical User Interface) is being able to understand what is going on without reading every single detail. That is why we prefer big red crosses to say "Don't do that you oaf!" instead of a line of text that says "I think you may want to reconsider your options."
Sweeping out the cobwebs: Content auditing for large websitesNexer Digital
Large websites tend, over time, to develop gluts of out of date content and dark unvisited corners. Thanks to devolved publishing, whole sections of a site can spring up without proper planning or coordination, only to be left in place long after they have served their purpose. Using spidering technology, Justin will demonstrate techniques to get a grasp of the size and shape of your site and to begin the process of decluttering.
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
66. What did you think? http://chicago2011.drupal.org/sessions (“Take the Survey” link) @bojhan ,@royscholten Thanks!
Editor's Notes
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