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:


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:

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


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:

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!)


  • 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 Mode
  • Logging & Errors
  • Performance
  • Backup & Migrate (example of contrib module placement in this IA)
  • Update Status (example of contrib module placement in this IA)


  • Testing


  • Search settings


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


  • RSS Publishing


  • Triggers
  • Actions

External Publishing

  • Blog API


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

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.

Roles & The Admin Header


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?

1.0 Header

Admin Header
Admin Header
wireframe updated 27 May 09

Description: A global header which would be shown when logged in to the site (for admin roles (site owners) but not site members (people who ‘sign up’ or ‘register’ to a site).

Global navigation is: Content, Structure, People, Appearance, Modules & Config, <Your Name – Profile>, Log out, Help

Current thinking/roadmap:

  • The top line of navigation is the global Information Architecture and navigation for the adminstration interface. The second line are a short selection of iconographical shortcuts that are customisable per role for fast access to most common tasks
  • Users are able to toggle the header to show only the top line navigation if preferred.
  • No use of javascript flyout menus, although admin menu module could be installed to override this if preferred.
  • The header will remain at top of screen all the time (even when scrolling)

Outstanding issues:

  • creation of library of icons. Need to define a short list of required icons and perhaps commission a designer to create custom icons for use in this theme (recommended re: GPL)

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_1_0

go back to Project Framework to view all project components