Media Library Microproject – Update & Feedback Please!

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!

D7UX Information Architecture – A detailed view

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
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
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
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.
Config

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:
Modules

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.

Information Architecture Strategies

Drupal IA Strategy
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.

Understanding the D7UX Information Architecture Approach

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.

Designing Accessibility Into Themes

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.

Microprojects launching!

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)

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.

Join us for Structure Summit Sunday – 7 June from 16:00 GMT

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.

Roles & The Admin Header

Roles

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?