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.

39 thoughts on “D7UX Information Architecture – A detailed view”

  1. I don’t have sufficent thumbs I’d like to point upwards.

    Let’s hope that not lots of battling will soak up all the energy. And let’s also hope that this does not have to be cut down on because of implementation details that are more far-reaching than we might think of now.

    I totally love the module page. Hey, skilip, all of your work can be found in that, you can tap yourself on the shoulder! Was not in vain!

    And then with some extra IA Goodness and integration skills from our IA Dreamteam it looks really well integrated. I love all those filtering and reordering possibilities. For me they don’t even clutter the interface. Maybe because Drupal has discovered a new dimension: Yes, we can also arrange elements horizontally! Chaka!

  2. This looks great, especially Config and Modules. I *love* the application launchpad. I also really like the idea of a “settings required” modules notice at the top of the config page. Looking forward to getting some of this stuff implemented!

  3. If this is really the future of Drupal (I’m still struck by and somewhat leery of the magnitude of these changes), please at least give us the option to move those “close” widgets to the left side of the panes. That is where they belong for us Mac users, and we really wish people would stop looking at Windows for user interface design inspiration.

    1. Garrett, you might be interested to know that virtually everyone associated with the redesign effort is mac based, certainly Mark & myself are, so placing the ‘close’ buttons in their current position is a decision well beyond simply overlooking where Apple have chosen to put their buttons.

      Fact is, for the vast majority of users, the Mac placement is highly unconventional – most people (in excess of 80% last time I checked) will be much more familiar with the ‘windows’ RHS placement and that’s a key part of our strategy – to support the 80% use case.

      Having said that, I’m sure that if someone were to make a ‘mac’ version of this theme there would be quite a few takers… ๐Ÿ™‚

    2. I’ll also say for us Linux users it’s on the right side. Mac is the odd duck out. And this is why it’s hard to do interface design that fits everyone. You need to really look at the big picture and if you do make a change that is outside what people are currently used to you better have a darn good reason for it.

    3. The right side is “correct” for Linux users because Gnome and KDE seem so content on just being Windows clones as far as user interface design goes. (Which makes no sense to me; if you’re going to design a new car, why base it off the Edsel?) It’s one of the reasons why the Mac ports of cross-platform programs like Firefox never feel *quite* right – there’s always some level of Windows-ish behavior about them, no matter how much they may paint their facade to look like a Mac program. For example, the close widgets for Firefox’s tabs are also on the right instead of on the left, and clicking in the address bar infuriatingly selects the entire address instead of merely putting the cursor where you clicked. And don’t get me started on the screaming mess that is OpenOfficeโ€ฆ

      I understand that there’s a practical side to doing what “most people” are doing, even if it’s wrong for the rest. That’s why I’m hoping there’s at least an option to put the close widget on the left side. A user interface which is almost, but not quite, totally congruous with the rest of the system is worse than one that’s just totally brazenly incongruous.

  4. Stuffs like “Forums” and “Books” can not be and should not be ever brought under Structure. They are basically Sections of a site. If “Forums” is there, why is “Blogs” missing ? And have you kept the path clear so that when one adds “Gallery” it also shows up under Structure ?

    The interface is eye candy but confusing as well seems to take a lot of space with spacious non-used spaces in between.

    1. Blogs don’t have any administrative options in Drupal core, hence why they aren’t shown. Structure is precisely about ‘sections of a site’, whereas content is what goes in those sections, so moving books and forums there makes perfect sense.

      1. Blogs have two administrative options :
        – Configure permissions
        – Get help

        “whereas content is what goes in those sections”

        What goes into the Blogs ? Content is what goes into the blog.

    2. Along with the other items mentioned above, it really concerns me that ‘taxonomy’ has been brought under ‘structure’ in this design. This is contrary not only to the current admin structure in Drupal, but also to the WordPress admin structure, which has ‘Tags’ and ‘Categories’ under ‘Posts’.

      IMHO, vocabularies are structure things, but terms definitely aren’t. Structure things are added mainly when setting up a site, and are seldom changed after that. Content is added and updated regularly. Taxonomy terms generally fall into the latter group (particularly free-tagging terms).

      1. from what we’ve discovered it seems that taxonomy is being used very much as a structural tool for Drupal. I agree that adding tags is a part of the content creation process and it will remain so under our proposed designs – assigning and creating terms will remain as part of the content creation process/templates but ‘managing’ vocabs and their associated terms would be done in the Structure section.

      2. I think its a valid argument that taxonomy terms are content, esp if we get taxonomy fields into core D7, then terms really do become first class content items. Perhaps they are being used as structure by many, but that is just one use and certainly not the whole story.

  5. What about grouping RSS, BlogAPI, RDF and such together into a section called something like Input/Output or External Interfaces.

    They’re all alternate ways to get data into or out of your database.

    1. Sean, I think only one pretty specific user group would think of these as ‘ways to get data into or out of your database’… ๐Ÿ™‚

      we’ve tried to keep the labeling as friendly to web-savvy non-developers as possible, which accounts for their current grouping and labeling.

  6. Is this themeable?

    Do I need to ship the same admin interface to all client?

    With Drupal 6 I can assign any theme for the admin interface. Locking the admin interface to a single visual is not a good idea!

    As a matter of fact, everything must be themable and overridable. If not, this is a huge step back, no matter how many eye candies we see here.

  7. @Jacques – As far as I know Administrative theme can be chosen from a dropdown of enabled themes. So, any theme can be Administrative theme.

  8. By the way, what does the big Add button does in Structures page?
    Does it add additional Structure ?
    If it add Structures from available but not enabled structures this button servers a great purpose.
    If it is for adding content it should mention “Add content” otherwise people not from Joomla-Wordpress background will be hell of alot confused.

    1. the big Add button does the same thing everywhere on the site – allows you to add content. This is a taskbar and is not contextual to the section you are in.

      1. “allows you to add content”

        So label it as “Add Content”
        This can avoid confusion.

        Is Edit contextual to Add ? What does it Edit when clicked on Structures page? What does it edit elsewhere, which content?

  9. Being a person who likes to get things done with as few clicks as possible (hardcore fan of admin_menu), I figured this overlay thing would bug the hell out of me. But it didn’t…
    It’s actually kinda fun to play with and try to get it to break or bug out.
    The overlay (especially the one using the iframe) is still riddled with tiny sneaky js bugs that are not only hard to notice but also hard to fix (especially on IE)

    but I’m getting the feeling there’s still no real consensus about iframe vs div

    imo, iframe defeats half the purpose and makes it harder to extend

  10. With 20+ years of accumulated user-experience behind it, there’s a lot to be said for using a file/folder tree for navigating content rather than a list view. Are there any plans to submit the interface to independent usability testing?

    1. Chris, we are all about independent usability testing. I’d love to test this to death as soon as we have a working prototype.

      We’ve done a bunch of paperbased /static testing to inform the design so far but would love to do lots more and to continue to invite the community to help us do more and more! (Not sure if you’ve seen the crowdsource usability testing idea we’ve been trying to get off the ground)http://www.d7ux.org/crowd-source-usability-testing/

  11. Great direction for the admin pages – I know that the administrators of our sites would love to be working with such a good admin interface, they find the default Drupal admin screens daunting.

    Have you seen Concrete5 admin screens (http://www.concrete5.org)? If not, it’s worth taking the time to review. I’ve spent about an hour now exploring it’s interface and from a site administrator perspective the software does a remarkable job in revealing it’s capabilities with very little documentation and provides a streamlined workflow – definitely worth reviewing.

  12. Why aren’t you using Drupal for your site ?

    It’s kind of hard to take anything Drupal seriously when your using wordpress.

  13. @MJ, this site is a blog site. WordPress is the best blogging platform out there today. Why not use the best tool for the job, huh? ๐Ÿ™‚

  14. Would like to see testing of administrators with partial access. I might delegate administration of content to an editor role and administration of users to another role. How does the administration interface work for the editors?

    Are you testing with other languages? I have a site that will use multiple languages in D6 and by the time D7 arrives, will require Mandarin, Japanese and middle eastern languages.

    RTL? Does the actual layout change for RTL languages?

    And those Mac comments. The correct order, based on tracking eye movements of users, is open-read-close, placing the close indicator at the end of the title, not the start, just like Firefox. The close for content should be at the end of the content but when you have a long list of teasers the read-more link can be lost by jumping back and forth across the column. A variable width read-more bar filling the last line is the best approach.

    Apple has chopped and changed among so many computers, operating systems, mice, applications, and other things that defining an Apple interface is useless. The Apple Lisa was the last wholistic project conducted by Apple. When you define an Apple subtheme, it should be an iphone subtheme because Apple will probable make the next Mac look like an iphone.

  15. Most of the above, is already working. But this would be cool, if people can do the above, without having to hit a “edit” button. But can do it right on the “normal” site output.

    See this module:
    Thats how a navigation block should look like.
    Or the Menu settings in node edit.

    That would be a tremendous step forward intuitive usability and easy to understand for low-computer-skills site admins.

    For some inspiration, have a look at this cms called Magnolia. It has some great usability features. And an other interesting approach is, that thy work with two “instances”. One which is live, one solely for administration. Thy mirror the complete site, so there is no need to put the website in maintenance mode. After modifying content or code it will be copied/pushed to the “live instance”.

    (Templates are also easy to customize, as drupal. But I am not using it because its outrageously expansive, server requirements are too high, and the core is complex (to me) to edit)

    Thank you for your efforts. Your doing really great stuff!
    And drupal will be even more cooler and easy to handle as it already is!


    1. … erm, sorry, first half of my post is missing:

      Bravo! Looks really promising!
      Love your approach.

      While I was using Drupal 6, I had some ideas, I would love to see:

      – Drag and drop navigation items (to manually reorder page hirarchy)
      – “Add Content” Buttons right on the bottom of Navigation Blocks (inserts new content right into the current navigation hirarchy)
      – Drag and drop Views outputs (could can be used to: to manually reorder reorder articles in a list )
      – Drag and Drop CCK outputs (to manually reorder images in a slide show etc.)

      Most of the above, is already working. But this would be cool, if people can do the above, without having to hit a โ€œeditโ€ button. But can do it right on the โ€œnormalโ€ site output.

  16. I notice that some of the bits on config and modules are suggestions for contrib – I hope that there will be issues created in each appropriate queue – as otherwise a lot of maintainers may only find out about the suggestions ‘by chance’!

Comments are closed.