Drupal 7 usability

Maarten Verbaarschot volunteered to take on a Microproject (thanks Maarten!) and for the past few weeks he has been working on interface design for a Media Library for Drupal. There is a great discussion going on in the Drupal.org issue queue that you might want to take a look at.

Maarten is currently working on the third iteration of these wireframes but he’d really love it if you can take a look and give him some feedback - anyone who has ever added an image to a web page should be able to have a say on this interface, so don’t hold back!

In particular, Maarten is looking for some user stories where users would be uploading content using this Media Library interface rather than uploading whilst in the process of creating a ‘node’ (story, article, post etc.). I know I have a couple but if you do also perhaps you can share them in the comments below or on the issue queue thread (if you’re a member of Drupal.org or would like to be!)

He is also working on an interactive prototype for this, and would love a little help from someone with good JavaScript skills so if you’re so inclined, please comment below.

You can see the work that Maarten has done so far here:

* Iteration 1: http://www.flickr.com/photos/mverbaar/sets/72157620755726297/
* Iteration 2: http://www.flickr.com/photos/mverbaar/sets/72157620894822174/
* Iteration 3: http://www.flickr.com/photos/mverbaar/sets/72157620894824094/ (in progress)

We really look forward to your feedback (here, on the flickr photos, on the issue queue, wherever is most comfortable for you).

Thank you Maarten for all your hard work so far! You rock!

And thank you to Maarten’s employers, Merge, for sponsoring a week of his time to work on this project. You rock too!

We’ve talked through the ’strategy’ behind the proposed D7UX Information Architecture (IA), now let’s take a look at it in detail. What goes where.

Let’s go through each major section in turn:

Content

The ‘Find Content’ page, showing a searchable, sortable, filterable list of all the content on your site is the ‘landing page’ for the Content section of the site. From this page you can also choose to Add Content (although it is suggested that for Content Creators this also be shown as a Shortcut on the Toolbar).

Different types of content can be filtered into different tabs, as comments are, for example, on this page. You may also wish to provide separate tabs for content such as Products (if you have Ubercart running), or Events or Projects

Structure

This section of the IA groups together tools used to ‘build’ content for the website which both have and create a User Interface (UI), including:

• Taxonomy
• Content Types
• Blocks
• Forums
• Books
• Feed Aggregator
• CCK (Contrib)
• Panels (Contrib)
• Views (Contrib)
• Webform (Contrib)

Note that this page has not had a ‘visual design’ applied to it yet, the image above is wireframe only.

People

The People landing page uses the same content display and interaction patterns as the Find Content/Content landing page, providing a searchable, sortable and filterable list of ‘people’ on your website. As expected, this includes everyone with administrative privileges and registered users, however we also provide to extract lists of users from nodes and show them in this one location (with contextual links to/from the node of course), including even participants, group members etc.

So, for example, if your site was running a series of events you would be able to click on the ‘events’ tab and see a list of published events and an overview of participants (eg. 46/100 attendees) and communicate with attendees in this location rather than having to to the node to perform this function (as noted above, you will also be able to access this list via the node if you prefer).

Appearance

This page is still a work in progress but would show the currently active theme, other themes available for selection and theme configuration options. Any tasks associated with selecting or managing the theme live in this section. As noted in the ‘Strategies’ post, this is not a common task however it is very important in the evaluation and ‘getting started’ process and requires this primary position for wayfinding and positioning reasons.

Config & Modules

Config & Modules (renamed recently from Modules & Config) is a hard working section of the site that houses the less used (on a day to day basis) functionality of the site, but some of the most critical aspects for site administrators.

The first of the two pages in this section is the Config page. There is a ’status’ message at the top for module updates but the majority of the site is dedicated to making the site administration tasks easily findable. We have approached this primarily by regrouping and sometimes renaming the individual items or their groups for clarity.

The propose content and grouping of the contents of this page are:

People Settings:

• Roles
• Permissions
• Emails (extracted from admin/settings/user for findability)
• Registration/Deactivation (extracted from admin/settings/user for findability)
• Personalisation (extracted from admin/settings/user for findability)
• Other Settings (because there were still a few odd settings left!)

Media

• Image Toolkit
• Image-Cache (example of contrib module placement in this IA)
• Image Field (example of contrib module placement in this IA)
• Image (example of contrib module placement in this IA)

Site Administration:

• Site Information
• File System Path (currently File System)
• File Upload Restrictions (currently File Uploads)
• IP Blocking

Maintenance

• Maintenance Mode
• Logging & Errors
• Performance
• Backup & Migrate (example of contrib module placement in this IA)
• Update Status (example of contrib module placement in this IA)

Development

• Testing

Search

• Search settings

URLs

• URL Path Settings (currently URL Aliases)
• Clean URLs
• Pathauto (example of contrib module placement in this IA)

RSS

• RSS Publishing

Workflow

• Triggers
• Actions

External Publishing

• Blog API

Internationalisation

• Translate Interface
• Regional Settings
• Languages

This page will also house a ‘launch pad’ to access the interfaces for major modules that do have significant interface requirements, for example Ubercart, Organic Groups, Projects, and Storm (Project Management). For site that use these modules extensively, the toolbar and dashboard will also provide more direct access into the module interface & functionality.

Reports will become accessible from the dashboard interface.

The other page in this section is the modules page:

This page essentially provides access to add new modules to your Drupal site, and to manage/configure your currently installed modules. Grouping them in with the other configuration functionality removes any ambiguity about where to go for configuration tasks, however it is important to maintain the term ‘modules’ in the global navigation as this is a keyword that people will frequently be scanning for. This modules wireframe is fairly new - to discuss this page in detail pls head over to the Modules page in the Project Framework

In addition to all of this there is a Help section, a Profile Page for the user, a Log Out link and the customisable task bar and dashboard that we’ll talk about in more detail elsewhere. But otherwise, that’s about it.

I know from what I’ve seen of (particularly new) users interacting with Drupal this can make a significant positive difference. I hope you feel the same and, as ever, welcome your feedback.

Designing an Information Architecture (IA) for Drupal is an incredibly challenging project - essentially you are trying to design an IA that allows just about anyone to do just about anything. Flexibility is very often the enemy of good design - people make good and fast decisions with fewer options not more - but how do you choose the right options so that they work for as many people as possible? Tricky stuff.

To give you a sense of the breadth of the scope - we need to design for both:

• people who use Drupal every day (efficiency & capability is key) and people who are brand new (evaluators & learners - does this make sense to me, does it appeal to me, will I be able to use it to do what I want?)
• Verity, the content creator (ref: Who Is D7UX for, very limited set of tasks but very frequent use) through to existing power users/developers (know Drupal inside out and don’t want the UI to get in the way)

In devising the proposed information architecture we have applied the following principles/philosophies/guidelines:

• less clicks is not necessarily better: some of the early feedback we have had to the IA has been along the lines of ‘but I can get to this in one click using the Admin header now - this means I’ll have to make 3 clicks, therefore the IA is not as good’. The number of clicks to content is actually a poor metric of information architecture usability. Much better is the number of mistakes made - people don’t mind clicks if they are not lost, if they are confident that they are getting closer to the content/functionality they seek. Our information architecture is designed to support wayfinding and reduce errors in a system that can grow incredibly large.
• few options shown = more decisions made: at the moment, Drupal tends to show all of its options all of the time, this is incredibly overwhelming for many users. Generally speaking, as humans we do really well at choosing between say 3-4 options, and very badly at choosing between 24 options. We want to ‘break down’ the decision making as much as possible by grouping things together well and using good (human friendly) labels.
• group & order by frequency of use & complexity - tasks that are performed with high frequency/repetition are very different to tasks that you do only occasionally, especially in Drupal.There are many differences between ‘adding content’ and changing the file path for uploaded files.The more frequently I perform a task the more familiar I become with it, the more I become interested in efficiency (being able to do it more quickly), the more skilled I am at performing that task. So, for adding content, what we want to do is move anything out of the way that will impact on efficiency. If I make a mistake adding an article I can very quickly recover that mistake without significant systemwide impact.Tasks that I perform infrequently (like setting the filepath for uploaded documents) are very different. I am going to have to find the location of this task again (as I won’t ‘remember’ where it lives most likely), if I get it wrong it could have a significant impact systemwide. Accuracy is very important.We have placed the very frequently accessed tasks at one end of the IA (Content) and the less frequently at the other end (Config & Modules) to aid both findability and to support the different ‘postures’ that users have for these different tasks.

Walking through the top level navigation:

• Content: This is where you Add/Edit and Find content, including comments.
• Structure: This is where the ‘builder’ tools live - things that both have and create UIs, for example Blocks, Menus, and contrib modules like Panels and Views will live here.
• People: Similar to Content, this section allows you to Add/Edit and Find People on the site. People includes registered users and admins, but also lists of people extracted from content types (event participants, group members) - this is a kind of new concept so stay tuned for more details to follow.
• Appearance: Themes & Theme Config. This link is largely designed for ‘evaulators’ and new people to Drupal, as we know that Theme management is not a regularly accessed but is one of the first things that people look for and explore when ‘getting started’ with a content management system so we need to make it very findable (and also to send the right messages about Drupal and our attitude to design)
• Config & Modules: This is where you’ll find the configuration functionality that you access once in a blue moon (or possibly only the once when you set up the site) - we’re going to pull things like ‘roles’ and ‘permissions’ out of ‘people’ and put it over here (this is an example of the group & order by frequency of use & complexity principle). You’ll also get a full list of the currently installed modules, link to install new modules and ability to update/configure modules as well as a jumping off point for some of the major modules that require their own signficant interface, for example Ubercart.
  

Hack Your Own Experience:

There are so many different kinds of Drupal end users and Drupal sites that we need to provide an easy way to configure the interface to support your particular use case, and the way we are doing this is by allowing you to configure a set of ’shortcuts’ on the taskbar (the icons below the header) and to configure a set of widgets for your dashboard (the first screen you see when you log in and accessible from the dashboard). So, for example, if your site was an online store, you might have dashboard widgets showing your latest orders, and a taskbar shortcut to your catalogue.

Next: I’ll be posting a detailed section by section analysis of the information architect and what goes where.

This is the first in a series of posts discussing the proposed information architecture (IA) for D7UX.

Before we get into too much detail, be sure to check out this great video that Roy Scholten (Yoroy) posted recently that helps explain some of the key features and rationale of the IA and how it relates to the current Drupal information architecture.

Because she is amazing, Ann McMeekin has prepared for us a guide to designing accessibility into themes - it’s useful far beyond this project so we’re sharing it here and pls feel free to pass it on to other who might find it useful. You can download a PDF version of this document here.

Before You Begin

• Do some research. If you don’t understand what accessibility is, or how people with disabilities use computers, take some time to do some research. http://www.uiaccess.com/understanding.html is a good place to start, and some videos of people with disabilities using the web can be found at http://www.youtube.com/view_play_list?p=09C317E35FC6D005.
• Ask an expert. If you need help, ask an expert. If you don’t know any, you can find lots of helpful and knowledgeable people at http://www.accessifyforum.com.
• Accessibility isn’t just about sight loss. Although we usually associate accessibility issues with people who have sight loss, many other people encounter difficulties when trying to use websites. The needs of those with hearing impairments, mobility difficulties, and cognitive impairments or any combination of the above are just as important.
• Aim for a good experience regardless of ability or technology. Listening to a site is a very different experience from seeing a site but, with careful implementation, both can be a good experience. Where a drag and drop interface might be great for those who can use a mouse, the equivalent experience for keyboard only users would be something equally easy to understand and use.
• Include accessibility in the design. Accessibility is better for users, easier to implement, and less likely to have an adverse impact on the visual design if it is included in the design process rather than being implemented at the end.

Structure and Markup

• Use appropriate markup. Lists are lists, headings are headings, and quotations deserve appropriate markup, too. Paying careful attention to web standards automatically increases the accessibility of any page we create.
• Avoid using structural markup for presentation. The H1-H6 elements are for providing structure not altering text size and blockquote elements are for distinguishing quotations not indenting text.
• Avoid using unconventional markup. At best, unconventional markup can be confusing for users, at worst, it can make pages difficult or impossible to use. For example, don’t use form elements instead of lists for navigation, and don’t use links instead of buttons for form submission.
• Use the <title> element effectively. Putting the information in the form you’d use for a reverse breadcrumb trail (e.g., [page] - [section] - [site name]) places unique information first and means less repetitive reading for users.
• Specify the natural language of the document. This ensures that browsers display characters properly and screen readers use the correct pronunciation rules. For English in HTML add lang=”en” to your <html> element. For XHTML1.0, change your <html> element to <html xmlns=”http://www.w3.org/1999/xhtml” lang=”en” xml:lang=”en”>. Language codes can be found at http://www.loc.gov/standards/iso639-2/php/English_list.php.
• Specify any changes in the natural language. If you change language midway through a page and don’t markup the change correctly, the screen reader will read the second language as if it was the first. The lang attribute can be added to any element. The span element can be used within a containing element or a div can be used if the change includes multiple elements. For example <p lang=”fr”>Bonjour</p>, <p><span lang=”es”>Hasta la vista</span>, baby</p> or <div lang=”la”><p>Lorem ipsum…</p><p>Etiam in risus ipsum…</p></div>.
• Use lists for navigation. This allows screen reader users to build a mental model of the size of the site/navigation without having to listen to and count each item in the menu.
• Use the most appropriate source code order for the type of site. Designing a page structure based on user needs allows us to provide a better experience for our users. Putting navigation before content works well for sites where users browse before reading, but putting the content first may be more appropriate for blogs and other content-rich sites where readers are more likely to read first and then browse for other content.
• Use skip links to provide keyboard shortcuts to content or navigation. Ideally, skip links should be visible by default, because they are especially useful to those who have mobility difficulties or do not use specialized accessibility software. However, having them appear when the links receive focus is acceptable, if they are placed sensibly. To be most useful, they should be kept to a minimum (no more than three) and be the first links in the source code order. The link text should ideally describe the destination, for example “Skip to main content” or “Skip to main navigation,” rather than “Skip navigation.”
• Create a logical page structure. Check the page without CSS. It should still have a logical structure and be easy to navigate and understand.
• Use headings appropriately, including section headings if necessary. <h1> is used for main heading of each page (which is not always the site name). Any subheadings (including section headings) of <h1> are <h2>, and so on. Using this type of heading structure allows screen reader users to create a mental model of the page, quickly determine if it contains the information they seek, and then navigate directly to the section they want.
• Write good link text. Link text should contain all important information, be concise, be unique, and make sense when read out of context. “Terms and Conditions (PDF 30kb)” is good. “Click here” is not.
• Notify users of popups and new windows. In general, use of pop-ups and new windows should be avoided in favor of allowing users to choose the desired behavior. However, if the use of a popup or a new window is unavoidable, the user should be notified within the link text. This can be done by including the words “(new window)” or “(pop-up)” in the link text or inserting an appropriate icon and giving it appropriate alt text.
• Avoid CAPTCHAs if at all possible. If their use is unavoidable, provide an audio alternative (e.g., http://recaptcha.net/) and a mechanism for users to get timely support if they need it, for example, an email address or telephone number.

Data Tables

• Specify table headers. Row and column headings should be marked up using the <th> element and scope=”row” or scope=”col” attributes as appropriate.
• Associate headers with cells. If more than one level of heading is required, give each header cell a unique id (e.g., <th id=”id1”>) and use the headers attribute to explicitly associate the cell and its headers. Each heading id should be referenced, in order, within the headers attribute, for example <td headers=”id1 id2”>. This ensures that the headers are read out to screen reader users in the correct order.
• Describe the purpose of the table. Use the caption element to provide a visual description which concisely describes what information is being provided. For example, using “June 2009” for a calendar.Describe the structure of the data. Use the summary element to provide a concise description of the data structure of the table. Using the calendar example, the summary could be “Columns contain days of the week from left to right, starting on Sunday.”

Forms

• Place important information/instructions at the top of the form. Providing instructions first reduces user error and provides a better user experience.
• Always indicate required fields. In addition, inform users at the beginning of the form how required fields will be indicated. The convention is to use a red asterisk, but this can also be provided by a small icon accompanied by alt text that says “required”.
• Ensure all form fields have a label and explicitly associate it using the for attribute. Explicit association allows screen readers to announce the correct label, and moves the focus to the associated element when the label text is clicked. If there is absolutely no room for a visible label, the label may be moved offscreen using {position: absolute; top: -999em} in CSS, or the title attribute used instead.
• Place labels close to their associated element. Too much white space between label and element can mean that screen magnification users cannot see the label along with the field, which may lead to increased errors when completing the form.
• Include the required field indicator within the label element. If this is placed after or below the form field, it may be missed by those who use screen reader or screen magnification software.
• Place help text between the label and the form field. If guidance is needed to enable users to complete the field correctly, it should be provided before the relevant field, not after.
• Allow users to hide/show help text. This allows users to control how much information they are presented with and cuts down on visual or auditory “clutter” for frequent users.
• Group form controls and label them appropriately. Use a fieldset with an appropriate legend to provide context for groups of radio buttons or checkboxes.
• Write legend text with care. Be aware when writing legend text that screen readers read the legend and label text for each item enclosed within the fieldset. Try to ensure that each label makes sense when read together with the legend, as well as on its own. A great example of this can be found at http://uk.tv.yahoo.com/ where a fieldset legend of “Search” combines well with radio button labels of “the web”, “for images”, “for video”, and “for audio”.
• Segment lengthy forms. When working with lengthy forms, consider splitting them into multiple pages or using headings in addition to fieldsets with legends. In this case, headings can be worded slightly differently to the legend to minimise repetition and hidden offscreen using CSS.
• Summarize errors at the top of the form. This provides an overview of all action required to complete the form correctly. It is also beneficial to provide anchor links to fields which require attention.Highlight fields with errors clearly. This could be accomplished by using an icon at the beginning of the label with alt text of “error: [concise description of error]”.
• Allow users to confirm or undo important actions. This helps increase user confidence and reduce errors.

Interactivity, JavaScript and Rich Internet Applications

• Build a solid base. Design the base experience to be a great one before jumping into dynamic interactions. This ensures that the users who cannot access or use the rich experience do not feel deprived.
• Be aware that screen readers parse JavaScript. Many modern screen readers have some level of support for JavaScript and care should be taken to ensure that its use does not cause pages to become less accessible.
• Be careful when implementing functionality that changes areas of the page without refreshing the page, such as AJAX. Screen reader software works by taking a virtual copy of the page, which it then interrogates. If the page changes without a refresh (or some indication that the user should refresh their virtual copy) users may be unaware that content has changed.
• Research best practice techniques before implementing rich interactions and functionality. As this is a relatively new area, techniques are continually being developed and improved and support for rich interactions is increasing. The Paciello Group is doing great work in this area and documenting it at http://www.paciellogroup.com/blog/.
• Understand the impact of the desired functionality. It is better to exercise caution when considering the use of new techniques or functionality. If, following research, it is not possible to implement the desired functionality in an accessible manner, consider using an alternative until an accessible solution is found.

Color

• Specify background with text color. When specifying any text color, be sure to also specify a default body background color.Check color combinations for sufficient contrast. Check all background/text color combinations to ensure that they meet WCAG2.0 guidelines http://www.w3.org/TR/WCAG20/#visual-audio-contrast. A great tool for this is the The Paciello Group Color Contrast Analyzer .
• Check that readability is maintained when using patterned backgrounds. Ensure that text maintains a suitable contrast ratio against any textured or patterned background. This can be done by using a strip of solid color between the text and the background pattern to separate the text from the background and maintain readability.
• Don’t rely on color alone to provide meaning or understanding. For example, don’t refer to colored text or change the text to red to indicate an error. Provide some other method such as underlining, adding a border or outline, or adding an icon with appropriate alt text

Images

• Provide alt attributes for every image. Every image placed in HTML must have an alt attribute which contains a concise, appropriate alternative.
  • For linked images, the alt text should describe the destination of the link.
  • For decorative images, the alt text should be null (alt=””) or empty (alt=” “) which lets assistive technology know that the image can safely be ignored. Alternatively, these images can be presented as CSS background images.
  • For images of text, the alt text should duplicate the text within the image.
  • For images which contain information, or are important content, the alt text should be a concise description of the purpose of the image. A good way to identify this kind of image is to imagine reading the page to someone over the telephone. If the image is not important enough to be described, it can be considered decorative and treated appropriately.
  • If the image is a graph or diagram, the alt text should be a concise description of what the graph is (e.g., “Sales figures for June 2009”,) accompanied by a longer description or alternative displayed adjacent to the image or provided on a separate but clearly linked page.
• Avoid using CSS to display images which contain information. It is better to treat the image as content, display it using the img element and provide an appropriate alternative.
• Ensure text contrast is maintained if a background image is not displayed. Specify a background colour in addition to the background image to avoid text becoming unreadable if the background image is not displayed for any reason.Use images to enhance understanding. This can help those whose main language is not the same as the language used on the site, and also those who have difficulty understanding text. For example, a question mark icon could be added next to the word “Help”.Combine adjacent image and text links. Combining adjacent links where an image and text have the same destination reduces repetition for screen reader users. Ensure the image alt and link text make sense when read together, leaving the image alt null if the alt text would otherwise duplicate the adjacent link text. A link to a downloadable document could be written as <a href=”url”>Annual Report 2009 <img src=”pdf.jpg” alt=”PDF”> 400kb)</a> or an email link could be written as <a href=”mailto:address”><img src=”email.jpg” alt=”” />email us</a>.

Typography

• Use relative units. Base text sizes from a default of at least 100% or 1em. If absolute units must be used, provide a separate stylesheet for Internet Explorer that specifies sizes in percentages or ems to ensure those users can resize text if they need to.
• Maintain readability when text size is decreased as well as increased. In general, avoid specifying text smaller than 75% or 0.75em, but if smaller text is required, ensure it remains readable at two steps smaller than default. This helps users with tunnel vision who may reduce the text size in order to reduce eye strain when reading on screen.
• Consider making small text bold. This can improve contrast and readability.
• Increase line-height to improve readability. Using a line-height of slightly larger than normal (e.g., 1.2 to 1.6) can prevent ascending and descending characters from “crashing together” making text easier to read for everyone, but those with dyslexia or other reading impairments in particular.
• Avoid fully justified text. This can create “rivers” of whitespace and cause significant difficulty to dyslexic users.
• Use appropriate case. Screen readers use different pronunciation rules for text in ALL-CAPS. For example, “CONTACT US” would be pronounced “contact U S” rather than “contact us”, which could cause confusion. Avoid this by using the appropriate case in the source and using text-transform in CSS to change the visual display if required.
• Limit use of images of text. If images of text or image replacement techniques are required, limit their use to only the main heading of a page. This helps users who require specific colour schemes, preventing them from having to make further changes to their browser settings in order to read the page.
• Make images of text clear and easy to read. If images of text are unavoidable, ensure that the text size is reasonably large (above 18px) and has good contrast. This helps people who use screen magnification software, as small images of text will pixelate when magnified and may become impossible to read.

Orientation and Way-finding

• Provide focus states as well as hover states for links. Ensure that any changes which happen on hover also occur on focus to help keyboard only users identify the focused element.
• Identify the current location in navigation. Using a different visual style to identify the current section or page within navigation can helps users to quickly orient themselves within the site.
• Do not remove the default browser focus outline. The focus outline is vitally important to users who have mobility difficulties and navigate through the site without using a mouse. If the default focus outline seems insufficient, it can be enhanced using CSS.
• Do not move links out of the viewport using CSS. If links are moved offscreen, keyboard-only users can become disorientated as the focus indicator will disappear from view until the user has moved to a focusable element within the viewport.
• Make links easy to identify. Make links clear and easy to distinguish from emphasized or body text.Make clickable targets bigger. For example, using display: block within a navigation menu to allow users to click the area around the text or making clickable buttons or links larger. In addition to attracting more attention from all users, this particularly helps users who have impaired motor skills.

Testing

• Validate your HTML and CSS. Invalid code isn’t necessarily inaccessible, but may cause the page/site to behave unpredictably, which may in turn cause problems for assistive technology.
• Check color combinations. Use a tool which tests against the Luminosity algorithm and test for color-blindness issues using an appropriate tool or simulator.
• Ensure fallbacks are in place. Check that all important functionality works without javascript, CSS and images.
• Unplug your mouse. Before trying out a screen reader, unplug your mouse and try using the site/theme with keyboard only. If you can use the site comfortably without using your mouse, you’re doing very well.
• Use an automated testing tool. Tools like WAVE can help you identify coding errors and suggest areas which may require further manual assessment.
• Get an expert review. If you don’t feel that you have the experience or knowledge to fully test the site, get an expert to review the site.Do some user testing. If at all possible, ask some people with disabilities to test your site/theme and observe them while they’re using it.

Recently we issued a call to UX (User Experience) people who wanted to have a try at participating in a small open source project, or a Microproject (as we’re calling them). We were overwhelmed with volunteers and are now, happily, in the process of pairing them with a bunch of projects that have been suggested by a whole range of people within the Drupal community.

To kick there projects off I’m creating a home for them over in the Issue Queue on Drupal.org, but I’ll create an index of them for you here so you can dip in and out as you please

Please also feel free to leave any general feedback about the overall Microproject concept/framework as a comment to this post.

Active Microprojects: (in no particular order)

• D7UX Microproject - Dashboard Widget for Traffic Data
• D7UX Microproject - Missing Critical Blog Functionality
• D7UX Microproject - My Profile Page
• D7UX Microproject - Dashboard Widget for Watchdog Data
• D7UX Microproject - Missing Critical Forum Functionality

Note - there are still quite a few more waiting to come online, as time permits - I’ll update the comments below as more are added.

Loading…

Update - Transcript and Document Of Record

Thank you to everyone who participated in the Summit on Sunday - there were several dozen people in attendance and it was a very productive session.

A transcript of proceedings can be downloaded here PDF (note: it’s about 150 pages of Skype chat, so only do this if you’re feeling brave/bored/exceptionally curious). We also tried to keep a document of record showing our agenda, some outputs and an incomplete list of participants, which you can see here. It is not entirely comprehensive and should be considered a working document only.

The discussion around the overall outcome for Structure continues and we will post an update soon.

The essential information Our mission: to come to an agreement on whether the Site Building Tool should be included in D7 and if so, how we can best make it work for both the Drupal technical architecture and existing Drupal users AND for it’s primary target audience.

Should you choose to accept this mission:

1. Join the Skype public chatroom here
2. Download Skitch to help capture and share your ideas visually
3. Add your name to the comments below so we can add you to shared Google documents (use your proper email address in the comment form so you can receive access notifications)
4. Be online at 16:00 GMT on Sunday 7 June (what time is this where you are? and with profound apologies to our Australian and NZ friends for such an unsociable time)
5. Spread the word! We want all kinds of people involved from Drupaller to People Who Should Use Drupal But Can’t, from developers to designers to shop owners and site administrators.

Our Moderator
I’m really excited to report that Ivanka Majic, Head of Design at Canonical, will be moderating our Summit on Sunday. Ivanka has a great appreciation for the challenges of designing for open source projects and a vested interested in D7UX being a good user experience, because the Canonical site is running on Drupal! She’s also a great moderator and I’m confident she’ll help us to ensure that we get to some firm and actionable outcomes on Sunday. Thanks Ivanka!

Homework
If you have the chance beforehand it would be great if you can check out the two most recent ‘prototype’ walkthroughs that we’ve posted (video see below), as well as the Project Framework Page for Structure.

A little background. If you’ve been playing along at home you have no doubt come across the Site Building Tool that we have proposed to live in the Structure section of the D7UX interface. We believe that the design and implementation of this tool can make the most significant difference in making it possible for non-technical users to make a reasonably sophisticated site using Drupal within a matter of hours, not the weeks or months that it often requires of new players at the moment.

The more time I spend talking to people who *should* be able to use Drupal but who can’t, and people who have had brief experiences with Drupal then ran away screaming in either frustration of fear, the more convinced I am of this. As recently as yesterday I took our latest prototype out to show some people, and despite the fact that it is still very rough and confusing, it’s potential was obvious.

We’ve been talking about this tool since early April - time is passing rapidly and if we want to make this happen we need to get on board with the concept and start working out how we can make it work. We need to do this as a matter of urgency. Our current channels are not moving us forward quickly enough, so I’m going to propose that we try something a little different.

Structure Summit Sunday

The absolute best way to get to the bottom of these complex issues is to get everyone in a room to thrash it out. Of course, we can’t all get in the same physical space together, so let’s try the next best thing and all meet this Sunday with the express purpose of coming to an agreement on what this tool can be and how we can make it happen.

I want to walk away from this session on Sunday with a clear vision for the tool and a feeling that the people who participated share this vision and our enthusiasm for the challenge ahead. (Of course, the flip side is that we decide that we can’t do it… which would be unfortunate, but I guess we have to consider it as an outcome).

I considered a bunch of ways to approach this, originally thinking that we’d do it in IRC, but with some more thought I’ve decided to create a public Skype chat that we can all join. This is a less intimidating environment for non-techy, non-Drupally people (and I’d really like to have a good mix of all of us in the discussion).

You can join the public chatroom on Skype using that link but we’re not really going to get the Summit going until 16:00 GMT on Sunday 7 June.

Why should I get involved if I’m not a Drupal developer?

• chances are you’re more likely to be in the target audience for this tool - your insight will be incredibly helpful in helping us get this right. (Especially if you can identify with the Jeremy character sketched out here)
• you will be the people who will be able to keep us focused on the right user experience, so that we don’t get caught up in How Drupal Works and What Can Be Done
• you can be instrumental in making Drupal an Awesome User Experience - this means putting some pretty powerful tools in the hands of people who can do amazing things with them.
• you will win mine and Mark’s undying gratitude by helping us solve a really tricky design problem that will make a big difference.
• you’ll be working on Something That Matters.

Please, please, please come join us and help make this happen. The saddest thing of all would be if a good idea died because we didn’t act on it quickly and decisively enough.

People have asked about who will see the proposed D7UX Admin header. I wanted to take a moment to talk about that and about Drupal default ‘roles’ and get your thoughts.

For those who aren’t familiar with Drupal here’s a quick overview that I copied from a Drupal 6 installation:

Roles allow you to fine tune the security and administration of Drupal. A role defines a group of users that have certain privileges as defined in user permissions. Examples of roles include: anonymous user, authenticated user, moderator, administrator and so on. ….

By default, Drupal comes with two user roles:

* Anonymous user: this role is used for users that don’t have a user account or that are not authenticated.
* Authenticated user: this role is automatically granted to all logged in users.

Clearly, to begin with, we’d be proposing that the Admin header is shown only authenticated users - that’s obvious enough!

I’d now like to introduce another concept that seems natural to me and to many others that I’ve spoken to about this (although perhaps not so much to experienced Drupal users) and that is a default differentiation between ‘Member’ and ‘Admin’.

The idea being that the Member role or roles based on the Member default are for people who have ’signed up to’ or ‘registered with’ the website (as a member) in order to participate more fully either by creating content (submitting a session idea for a conference, a discussion post to a forum, that kind of thing). The Admin role and roles based on the Admin default are for users who have a closer association with the website - the website ‘owners’ or ‘managers’, the people to whom we’re happy to show the ‘underwear’ of the website. Admins would see the Admin Header but Members would see their tools and admin menu in the page context.

Now, of course there are many, many variations on roles that need to be created and sometimes the differentiation between whether or not a role should be a ‘member’ or an ‘admin’ is not clear. I think there is an inherent guide in the name ‘member’ that should be helpful - a member has a particular kind of relationship to a site and there are kinds of content and functionality that is less appropriate to a ‘member’ and more appropriate to an ‘admin’. There is sufficient flexibility in the system that means you can make a call whichever way you think is appropriate to your particular scenario, and to change your mind later if you like!

This is not dramatically different to the way that many Drupal sites work already and almost all of the infrastructure required already exists and just needs a little spit and polish. No architectural changes are required to achieve this - it is really a tiny and superficial, but from a user experience perspective I think this will make a significant difference in helping people understand Drupal roles and how to best implement them.

What do you think? Any questions?

Designing a big system like Drupal is no easy task, we all know that. Part of what is not easy about it is that you have to design both little chunks and also big stories. Getting these to come together in a coherent way is not easy to design but even more difficult to communicate.

We know that there are people out there who are worried about how the D7UX design will work. We’d also really appreciate it being put to the test. So, here’s a forum where we can do that.

If you have a concern about how D7UX will work, post it here. In order for us to be able to respond to it, you need to make it as specific as possible. The best way to do this is to tell it as a bit of a user story (and try to use as little Drupal speak as possible so we can all play along).

For example, your concern may be that there is no place in the Information Architecture for the people who have signed up to an event to be managed. Your user story would be something like: If I create an event and then I want to see the list of all the people who have registered, how would I do that?

Please feel free to post ANY concern you have here. We will endeavour to answer every single one of your concerns as best we can and as quickly as we can. That way we can *all* start feeling as though the design is robust, get a sense of how it will play out in a range of user scenarios, and we can identify and correct any weaknesses as required.

Who’s first!

There’s been a lot of talk about Open Source Design & User Experience lately. Here is a great opportunity to dip your toe in Open Source Design, see what it’s like and work on a small but important project for the Drupal 7 User Experience Project (D7UX).

What is this?

An opportunity for UX people to work with Drupal developers to solve specific, finite and modular user interface issues. No previous experience or knowledge of Drupal is required.

A UX volunteer will be paired with module developer(s) to work on the interface and UX aspects of a module, create wireframes that capture UX recommendations which may then be implemented by the developer(s).

A Drupal UX Mentor will provide guidance and support as required. We’re estimating that each microproject will require no more than 12 hours of a UX Volunteer’s time and those hours can be spread, flexibly, over a 3 week period.

Why are we doing this?

• to give UX professionals an opportunity to ‘try out’ designing in an Open Source Community (and hopefully love it so much they stay!)
• to give developers the opportunity and framework to engage with designers/UX professionals to maximise the usability of their module
• to get feedback and insight into how we can help designers and developers to engage in a much more holistic way on an ongoing basis
• to spread the UX workload and maximise the improvements available for inclusion in D7
• to help make Drupal 7 an amazing user experience!

How will it work?

This is a brand new and somewhat experimental initiative so your involvement will be instrumental in shaping the way the process works, but this is what we have in mind:

• 26 May - 1 June 09 - Call for participation: see ‘Get Involved’ below.
• 2 - 10 June 09 - Cross Matching: We’ll assign UX volunteers to modules and introduce the teams!
• 10 June - 1 July 09 - Engagement
  A three week period will be assigned for the participants to work together to improve the UX of their assigned module.The work involves
  o Developers briefing the UX people on how the module works and anything they need to know about how Drupal works
  o UX people creating wireframes or prototypes (your call!)
  o UX people and developers collaborate to finetune the user interface and perhaps do a little guerilla usability testing (if possible/appropriate).
• 1 - 8 July 09 - Evaluation
  Each participant will be asked to submit a brief evaluation of their experience (what was good, what was challenging, how they’d do things differently next time, how things could be better) so that we can learn more about how to foster the engagement between Designers/UX people and Module Developers throughout the open source development lifecycle.

What kind of projects?

We would love to sign up around half a dozen microprojects. Here are some examples of projects we think would be perfect as a microproject:

• design a great WYSIWIG Editor interface for Drupal 7
• design the interface for a great media library for Drupal 7
• design some great dashboard widgets for Drupal 7

There will be opportunities to get involved in more complex UI projects for D7UX and we’re working closely with the Drupal Usability team to define and collaborate on these.

Get involved!

Want to get involved? Yay! We’d love to have you aboard!

• If you’re a UX person who’s interested in participating, leave a note in the comments below (and use your real email address in the comment form so we can contact you!)
• If you’re a Drupal developer and you’d like some UX love for your module, add a link to your module project page or even the specific issue if there is one and give a quick summary of what the module does and what the main user interface challenges are.
• If you’ve got some ideas for what needs UX attention (task ideas) even if you’re not a designer or developer - feel free to post your suggestions in the comments below

We’re really looking forward to working with you all on these projects and seeing what we can achieve in the coming weeks!

ps. want to find out more about how you can get involved in the Drupal Usability Community? Come say hello here and see what we’re up to!

Quick question, for an average Drupal site that you’ve worked on, what would be the *typical* number of content types in use?

(I know there are lots and lots of different kinds of Drupal sites, just think about what would be average, common, typical for you. Not edge cases!)

thank you!

As we start to get some outputs that are getting higher and higher in fidelity (that is, more like what they’ll be when they’re done), it becomes easier and easier for more people to take a look and give their feedback. This is great, but it’s also a challenge. Why so? Well, because, D7UX isn’t for everyone - and if it’s not for you, then in order to give feedback we can work with you need to be able to put yourselves in the shoes of someone it *is* meant for, or better still - find one of these people and try it out on them.

A well designed interface doesn’t work for everyone all the time, that’s just an impossible dream. It should work for it’s defined target audience most of the time though, and that’s what we’re aiming for.

So, who is D7UX designed for?

There are two main audiences that we’ve had in mind as we’ve designed this interface for D7.

1. Our ‘Clients’, the Content Creators - the first group we’ve broadly named ‘our clients’ because for many of the community who make sites with Drupal, these sites are then turned over to another person or group of people who use Drupal to add and maintain content on the website.Often these people share the following characteristics:
   - They’re not developers. They don’t know much about code and how it works,
   - They’re not in the Drupal community, they don’t love Drupal as much as we do, they don’t speak Drupal-ese,
   - Updating the website is probably just one of many jobs they have to do,
   - They’ve probably used other Web Content Management Tools than Drupal in the past.

   These people tend to have a small number of tasks they need to do on the website, and those tasks tend to be repetitive.
   The best thing we can do for these people is to make those tasks as simple, question free, and error free as possible.

2. Non-technical Site Builders - these guys are a whole other kettle of fish. They have a more advanced understanding of what technology can do and how code works, but they’re not developers. They are, however, considered technology or web experts in their field, which may be something like academia, or ’social software’ or they may just be the person at their tennis club or church who ‘understands the web’. People expect them to be able to build fairly sophisticated websites and they’d rather like to be able to do it themselves too, except without the technical skills, it can be hard. You’ll probably find a bunch of these people currently using Ning.Often these people share the following characteristics:
   - They’re not developers but they do understand quite a bit about how code works and may be able to write and understand a little code themselves
   - They find themselves needing to create websites (often for others) that have fairly sophisticated requirements, including forms, community tools, online stores, and content publishing using a range of page templates.
   - They have experience with a range of online content publishing tools.
   - They have probably heard of Drupal but had little experience with it before and certainly don’t speak Drupal-ese

If you know anyone who fits one of these two descriptions then these people will be idea test candidates for the D7UX interfaces as they emerge. If you don’t then here are a couple of very sketchy ‘personas’ you should consider when evaluating the usability of D7UX.

Verity (our client, the content creator)

Verity is a part time administration assistant for a cancer support charity. She is working part time while she completes her Social Care Diploma. Before she left work to study, Verity was a Personal Assistant in the Finance Sector. Verity is in her late twenties. She is quite proficient with the MS Office Suite (Word, Excel etc.), and she uses Facebook and email but she doesn’t consider herself very good with technology.

One of many tasks Verity has to complete each week is to update the ‘news’ section of the website and any other small content updates that are given to her to make by more senior staff. She doesn’t mind this job but she is often interrupted by the phone and other staff while she is updating the website, which can make it tricky for her to remember where she is up to in the process. If she has any trouble with the website updating there is an IT consultant Verity can call, but she likes to avoid doing this unless something is very broken as the consultant is both very busy and expensive!

What Verity Wants: to be able to complete her website updates quickly, without getting confused, and feeling confident that she’s knows where she is and what she’s doing at all times.

Jeremy (non-technical site builder)

Jeremy is a social software consultant (no, he doesn’t like that job title either). He works with medium to large organisations to help them understand how social tools could help their businesses be more successful and he recommends tools that they should use and how they should be implemented.

Jeremy is often frustrated because it is difficult to customise existing tools to suit his clients. Also, he often has to use tools from many different places to put together the solution they require. He would love to have the ability to ‘build’ a site that would meet his client’s requirements, however his technical skills are not great - for example, he can edit some PHP code to get it to do what he wants, sometimes, but he can’t write much from scratch. He understands what CSS is and what it can do, but he’s never written much himself.

Jeremy has friends who are developers and professional designers and he can call on them for some assistance. He heard of Drupal a few years ago at a social networking event and tried downloading and installing it but didn’t get very far and his general reaction to Drupal now is ‘it’s scary’.

What Jeremy Wants: the ability to build sites with rich functionality and flexibility without have to write code.

Note: these are not formal personas, they are just quick ’sketches’ drawn from the research we’ve done to date (since August 08) that we hope will assist you to evaluate D7UX interface design.

What about the developers?

Good question. We do care very much about the Developer Experience (DX) but we also know that many developers are perfectly happy with Drupal the way that is is (as long as they have the Admin menu installed) and that they, of all people, know that essentially all Mark & I are doing is ‘theming’ the admin and that they can override this with ease. We’re not doing anything to The Way Drupal Works that will inhibit their ability to do all the amazing things they do now, and more in the future. Having said that, we hope that they are pleasantly surprised by the interface and might even consider keeping it. Or, perhaps, at least part of it. And in particular, we hope this buys them more time to do what they’re great at - development work - rather than spending that time training and supporting people who know (and need to know) Drupal less well.

Drupalers - how do you mostly use Taxonomy? How do you usually create content categories in your Drupal sites? (pls RT) #d7ux

(Tweeted 14 May 09)

FYI- Just a quick survey to see what people are doing, not a request for Taxonomy tutorials

Here’s a rough transcript of the video content, if you read this you won’t miss out on any content covered in the video:

It’s been a little while since our last ‘update’ so we wanted to check in and let you know what we’ve been up to on the project in the past couple of weeks.

We’ve been moving through a transition in the project from the high level, strategic ‘iteration zero’ (in Agile terms) phase of the project to a much more detailed, tactical, concrete phase. Until now there’s been lots of thinking and communicating ideas, now we’re moving into a phase where we need to get our heads down and plough through a lot of detailed work, and we’re finding it harder to get the time to give updates. Part of the way to address this was the creation of the Project Framework and there have been lots of little discussions going on in those threads, but we do need to find a better way to communicate regularly these more granular pieces of work - stay tuned as we figure out the best way to do that (and we welcome suggestions of course!)

Mark describes this phase with a diagram (of course), that show the communication decreasing as the fidelity increases (and us at the cross roads) - it’s not something we’re happy with, so we’re working on it.

There has been work a-plenty though, starting with a great workshop we had over two days in London in late April - Jeff Noyes and Jason Reed (the Acquia designers), Roy Scholten (yoroy) and Dries gather round a table with Mark & I to work on the D7UX design work and see if we could break it. Jeff has a great write up of the workshop here and I managed to grab a tiny bit of video for you (of course!)

Since then, I’ve been working on defining the interfaces and interactions in some wireframes and Mark has been working up the visual language, and we’ve started working with the engineering team at Acquia to start getting this built. We hope to have something that you can touch and feel in the not too distant future (how exciting!) This is just the beginning of the journey and we still have a lot of refinement to do, and the whole system will continue to evolve as we work through more challenges and learn more and more.

In the wireframes we’re identifying a whole stack of ‘needs attention’ issues - these are things like ‘the WYSIWIG menu needs special UX attention’, ‘the idea of a media library needs special UX attention’ - they are kind of smallish chucks and fairly modular and we’re hoping that we might be able to throw these out into the community and ask for your help to take the lead in working through the details of these kinds of challenges. We’re not sure of the best way to engage/manage this - your thoughts and guidance would be appreciated (issue list seems the logical place, but is it?)

In the next couple of weeks we’re going to get back to focusing on usability testing and user research in a much more regular way. We’ve kind of dropped the ball on Crowd Sourced Usability Testing in the past few weeks (and in retrospect our schedule was pretty aggressive)  but once we have a working prototype it will be much, much easier for us (and you) to be much more active in continuing to test and gain insight into what is working and what needs refinement in the interface and overall User Experience (UX). (by the way, did you see that Wordpress have just opened up usability testing to their community as well? interesting huh?)

Finally, we’ve started working with an awesome authoring tools accessibility expert  Ann McMeekin, to help ensure that we’re making Drupal7 an amazing user experience for *everyone* - especially given some of the more ‘fancy’ interactions that we’ve been proposing - there’s a new section of the Framework for Accessibility and I’m pleased to report that Ann is pretty happy with the approach we’ve taken so far and working with us to help take advantage of some of the newer interface options available to us thanks to ajax and JavaScript without negatively impacting the UX for those of us with special needs.

So, that’s about it for now. Expect plenty more from us in the coming weeks. And, as ever, let us know what you’re thinking and don’t forget to keep track of what you’re most interested in through the comments and content in the Project Framework.

We’ve said lots of times that we’re really interested in accessibility and that we’ll be keeping accessibility issues and guidelines in mind as a part of our user experience design process for D7UX, well, I’m happy to report that we are really kicking that into gear, and we’re starting by having a big pow-wow with a really expert in the field. We’re going to be spending We spent the day on Wednesday (13 May) with Ann McMeekin, an Accessibility Expert who is also an invited expert on the Authoring Tools Accessibility Guideline Working Group (AUWG). Ann is going to give us some advice on how we can contribute to making Drupal7 compliant with the impending Authoring Tool Accessibility Guidelines (ATAG) 2.0

We’re going to open up this thread to discussions around Accessibility, but first up I’d like to ‘open the floor’ to you all and give you the chance to your thoughts/issues/ideas/questions through to Ann for her consideration.

So, if there’s anything you think that you’d like us to ask Ann, or to draw her attention to, the please let us know in the comments below and we’ll include it in our discussions on Wednesday and be back here with some feedback! Ann can take a look and give you her feedback or make sure it’s being taken into account where appropriate.

Rough transcript of the video (so that you don’t have watch it if you’re not so inclined):

• introducing Ann, a freelance accessibility consultant with about 5yrs experience, previously at RNIB . She helps people make websites better for people with disabilities and in turn for everyone
• Why get Ann involved so early? Accessibility like Usability quite often comes to the table far too late. Ann thinks it is a great opportunity to get involved so early so that she can direct the design and production effort rather than having to ‘audit’ and require ‘rework’. Ann is able to pick out things that look like they might be problem areas so that we can design things in the best way to support good accessibility.
• Ann has reviewed a lot of the work done to date - her initial feedback is that so far there is nothing she’s seen that has made her throw her hands up in horror. She thinks there are some really interesting things going on in what we’re doing to try to create a rich experience, but this can be challenging, but the work she’s seen so far has scope for the implementation to work for everyone - she’s confident we’ll be able to create a good UX for everyone.
• Some of the challenges that these rich experiences pose for accessibility, esp. ajax and screenreaders. There are lots of technical challenges that don’t yet have solutions but this also poses a great opportunity to find ways to make these implementation successful. Thinking about how to implement that into the work now means that as the browser and screenreader technology improves the ‘hacks’ that are required now can simply be removed later on. The important thing is to ensure that the base level experience is a good one and that the richness is just an added extra. Basic things like form interaction, when it’s done well the ‘accessible’ experience is great, you don’t feel like you’ve got a less good experience even though you don’t have all the fancy JavaScript.
• Authoring Tools Accessibility isn’t just about having a system that is accessible, it’s also about designing a system that helps people make good decisions about accessibility as they are building sites using Drupal. (Which is v familar to our design principle of helping people make good design/UX decisions when making sites with Drupal).

no wireframe currently available

Description: Includes the design of the installation process as well as install profiles

Current thinking/roadmap:

• continuing the work done to date to streamline and improve the usability of the install process
• add creation of dummy content as part of install process
• development of install profiles for most common/likely site requirements
• consider optional user of wizard

* Aggregated Feed (Pipe) of Related Discussions

Please feel free to add your thoughts as comments below or if you’d rather publish them elsewhere you can have them the pipe by using this tag #d7ux_12_0

go back to Project Framework to view all project components

Also in this section:

• installation profiles (d7ux_13_1)
  

Description: A design element we’re considering for use in D7 that users will be able to move around the screen and drag off elements (that we’re currently calling ‘templates’ and ‘bits’)

Current thinking/roadmap:

• we were thinking of something pretty similar to what was shown in the Buzzr prototype recently

* Aggregated Feed (Pipe) of Related Discussions

Please feel free to add your thoughts as comments below or if you’d rather publish them elsewhere you can have them the pipe by using this tag #d7ux_12_0

go back to Project Framework to view all project components

No wireframe for this yet!

Description: where you go if you need help to build/manage your site

Current thinking/roadmap:

• haven’t really given this section a whole lot of thought yet but thinking about crossover with d.o documentation
• also thinking about contextual help

Aggregated Feed (Pipe) of Related Discussions

Please feel free to add your thoughts as comments below or if you’d rather publish them elsewhere you can have them the pipe by using this tag #d7ux_11_0

<a href=”http://www.d7ux.org/project-framework/”>go back to Project Framework to view all project components</a>

Also in this section:

• Contextual Help

No wireframe available yet

Description: A more ‘technical’ section of the admin, predominantly for site administration purposes. Content creators should not need to go into this section in order to add/edit/delete content. You should be able to get a simple site up and running without going into this section.

Current thinking/roadmap:

• probably not significantly different to the current

Aggregated Feed (Pipe) of Related Discussions

Please feel free to add your thoughts as comments below or if you’d rather publish them elsewhere you can have them the pipe by using this tag #d7ux_2_0

go back to Project Framework to view all project components