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:
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
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:
Note that this page has not had a ‘visual design’ applied to it yet, the image above is wireframe only.
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).
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:
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!)
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)
File System Path (currently File System)
File Upload Restrictions (currently File Uploads)
Logging & Errors
Backup & Migrate (example of contrib module placement in this IA)
Update Status (example of contrib module placement in this IA)
URL Path Settings (currently URL Aliases)
Pathauto (example of contrib module placement in this IA)
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.
We are really excited to share with you our initial concepts for a D7. Please take a look at the video above and there are LOTS of sketches and paper prototypes that you can explore over on the Flickr group as well.
In this video you’ll see the three key aspects of the D7UX interaction model we are proposing:
the ‘header’ which will be displayed to users who are logged into the site, comprising of a ‘global’ header allowing access to all functionality (permissions allowing), and a customisable/role based set of buttons allowing fast access to the most frequently used tasks (eg. add/edit) or views (eg. find content).the example shown in the video would be for a ‘content creator’ type role. We haven’t completely thought through the application of this header down to the level of ‘site member’ (eg. someone who adds discussions to the forum on the site you’ve built using Drupal), but we think as a concept it has legs.
the ‘in line editing’ which will allow you to ‘switch on’ edit mode and edit content in place (wouldn’t that be lovely!). Of course, not all content would be editable on the page so the edit view would also allow for a range of ‘editors’ to be launched into an overlay window. We’re imagining: block editors, content type editors, navigation editors, views editors as a start (some of these terms will probably only make sense to Drupallers – apologies for that, will try to translate in future versions)
In the video we also show another idea that we are quite excited about, although we have a long way to go before it is entirely thought through … we’re not entirely sure that it will work, but the problems we are facing with it seem to be getting easier not more difficult, which is a good sign… You could think of this as a Direct Manipulation Tool for Site and Page Structuring. It’s been inspired by some of the tools that we’ve used in the past to do Information Architecture work (hence the use of that word in the initial header that is currently being CrowdTested, yes, it will most likely change!).
The idea behind this tool is that we are able to make site building and page creation a much easier task for people who don’t know and don’t want to know the ins and outs of Drupal’s technical architecture. We’re really excited by the potential this has for achieving our objective of allowing users who are not developers to build complex sites using Drupal… would love to hear what you think of it, and stay tuned for much more work on this component.
We’re looking forward to pushing some of this out for more Crowd Testing very soon. I’d really encourage you, if you’re concerned about what people will make of this, to get involved in the user research – go put it in front of people and find out for real what people do and what’s usable or not. I’ll post another set of materials and scripts for CrowdSourcedUsabilityTesting very soon!
Ok. So, there you have it.
We’ll just wait here, nervously and excited, whilst you have a look…. then, please, tell us how you like it so far!