Our UX Principles: 1. Make the most frequent tasks easy and less frequent tasks achievable. 2. Design for the 80% 3. Privilege the Content Creator 4. Make the default settings smart

Information Architecture Strategies

Posted: July 1st, 2009 | Author: | Filed under: 1.0 Header, Concepts, Strategy | Tags: | 11 Comments »

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.


11 Comments on “Information Architecture Strategies”

  1. 1 DJ said at 1:06 pm on July 1st, 2009:

    Hi guys

    Have been watching with interest – it is an almost impossible task that you are doing – so keep persevering :).

    Just wanted to be pedantic I wanted to pick up on the comment:
    “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”

    You rightly point out that fewer clicks = not necessarily good.

    This is all about context though.

    Fewer clicks + more complex interface = bad

    Fewer clicks + simpler interface = very good

    What you’re aiming for is some sense of priority around frequently accessed functions and ensure these have some degree of efficiency. There is an interesting balance around usability goals (in the traditional sense) for efficiency vs effectiveness here.

    By hiding functions you are effectively displacing that complexity elsewhere, and potentially making them invisible for people who need them. Avoiding this means you need to understand tasks extremely well. Unlikely to get this right first go I would anticipate. (Perhaps I’m underestimating!) A risky strategy?

    I have always thought that perhaps CMS tools need to build in “levels” (like video games) to allow people to start with the beginners product (hiding away much of the hard admin stuff) and move up as they feel more confident.

    My own experience with Movable Type and WordPress in this area is not good. MT in particular has become an extremely complex system model over the years, the interface has become slow due to lots of CSS/JS work and despite using it a lot I haven’t configured dashboards etc as it’s all just *too much*.

    Nevertheless fwiw I think the broad headings you have chosen at the top of the IA are sound. Getting those across in the interface to show their relative importance (rather than just being a list of links with the same visual treatment) will be interesting to see!

    Cheers
    DJ

  2. 2 Lawrence Meckan said at 2:13 pm on July 1st, 2009:

    I second what DJ spoke about levels.

    I’ve dealt with enterprise CMS builds for a while now and in most corporates, the content creator is not the one with the final publishing authority, let alone technical authority.

    Make the content creation area as simple and click-free as possible.

    Leave the technical gruntwork for those who are responsible for it.

    I say this as I’ve had junior staff get lost in some commercial CMS products due to the amount of complexity involved at content creation.

    This may end up with multiple canvas / UI/ UX paths built into the site adminstration, but at the end of the day, start with the simplest area: the content creation and their content creator and build layers around that.

    As the level of technical or content management responsibilty increases, so should the canvas adapt to meet their needs.

    This generally means more options, but as the options increase, you can then model those more complex options in simpler ways.

    You could, of course, have a wizard which configures each user interface on login to the admin area to the particular user’s needs and wants.

  3. 3 webchick said at 3:18 pm on July 1st, 2009:

    I think this is a sound strategy. Thanks for writing it up.

    I really like the clean distinction between the sections as written, but something that’s come up as we’ve been firing away patches to re-position some of these menu items is that there are some “weird” things that don’t quite fit into the definition of Structure, and also don’t fit into the definition of Config.

    One recent example is URL aliases (the feature that turns something like ‘http://www.example.com/node/1′ into ‘http://www.example.com/about’).

    The most common way to add one of these is in the ‘Create content’ form. And that works fine for content-related URLs, but there are also times you want to change a system path such as ‘contact’ to ‘contact-us’ or ‘forum’ to ‘forums’, etc. In this case, you’re going to head to an admin interface that looks much the same as the “Find content” interface, where you can add, search, edit, and delete all paths in the system.

    URL aliases do not have anything to do with creating UI, so by that definition, they clearly don’t belong grouped with items like Blocks, Menus, Panels, and Views. On the other hand, they are also not “set once and forget it” like else everything that’s under our current “Site configuration” menu. And there are other places in core that are in this murky spot, like taxonomy terms, aggregator feed items, books (well. books can probably be seen as site structure, actually..), and so on.

    Something that’s really nice about the current IA (assuming all contrib modules are playing along nicely) is that I can remove the “access site configuration” permission from my editor roles, and be relatively rest-assured that:

    a) they are never going to be able to go in and accidentally screw up the file upload path.
    b) they will not be blocked from manage things they actually need to manage as part of their “day job,” such as URL aliases.

    This new IA will mean that “Site config & modules” is a mix of these “set it once and forget it” and “go back here once a month or so to twiddle something” items, and makes the job of the site builder somewhat more difficult. She can no longer just ignore everything under “Site configuration” – she now needs to carefully inspect each of the choices there and decide whether she needs to do something with it, and moreover whether her clients need to do something with it.

    If it’s possible to have a further distinction under “Site config & modules” for “Content-related config” and “Settings-related config” I think that would help a lot.

  4. 4 Claudio Luís Vera (@modulist) said at 4:19 pm on July 1st, 2009:

    The easiest way to simplify information architecture with Drupal is to NOT make it do everything for all people.

    There’s a part of the sitebuilding experience that should ask you “what kind of site are you trying to build?” This would take you into working with an installation profile that’s best suited for your purposes. Some examples would be a blog, a company marketing site, an event site, a community. Each of these has different needs and would likely have a different default interface.

    I keep comparing Drupal to Legos. At a certain level of sophistication — like trying to build the Millennium Falcon kit — having 1×2 corner pieces or 2×4 bricks in green is not very helpful. You need patterns for a larger master plan. These patterns are completely absent from the Drupal installation experience.

    We’ve run into this issue when wanting to contribute themes. We’ve gone far beyond the point of merely decorating HTML. instead, we’re designing interface that’s fairly specific in purpose.

    Drupal today has been architected to work with the least common denominator, a mishmash of defaults and settings that are more frustrating than helpful.

    Once we can get a mental model that works with site types (or “installation profiles” in Drupalspeak), I think working with Drupal will become far simpler. It’ll allow us to work with defaults and settings that make sense for once, fancy that.

  5. 5 Leisa Reichelt said at 4:52 pm on July 1st, 2009:

    hi DJ

    thanks for your feedback – I think we are broadly in agreement. What I haven’t talked about at all here is the associated ‘landing pages’ for each of the sections (I’ll talk about those in the next post!). These landing pages really take up the slack re: simplifying the interface beyond a more compact IA.

  6. 6 Rick Vugteveen said at 8:22 pm on July 1st, 2009:

    Generally speaking, I think this is an major improvement. After watching Yoroy’s overview, the choice to add another level of depth makes a lot of sense. The hardest part of the admin interface now is how common interfaces are mixed in with “set it and forget it” configuration.

    What I look forward to is seeing an overview of how Drupal’s existing /admin options map to this new IA. In particular, I’m wondering how many items will be under Content, Structure, People and Appearance. If there is only 3-4 items under each on a typical install, I think you would settle the contextual vs. selected quick links debate by default. Everything would be important so there would be no need to cherry pick common options.

    I do hear Webchick’s concern about “murky” items that would fall under modules & config. I think that this would be best solved in a follow up issue to create a new hierarchy under modules & config. One potential fix would be a new category for the more common options. This category could also map to a specific permission so you aren’t opening up the ability to rename the site or change file paths for users who just need to edit url aliases from time to time.

  7. 7 dalin said at 12:43 pm on July 2nd, 2009:

    IMHO path aliases and taxonomy are clearly “structure” related and not “config” since they control how the outside world perceives your site structure.

    Leisa, Yoroy, et. all this is great work! Your principals seem sound to me and I agree with the structure that you’ve created from them.

  8. 8 fschaap said at 12:55 pm on July 2nd, 2009:

    I can second the importance distinguishing between the content editors (“grunt workers”: permissions to add or change content but not to publish it) and those higher up in the content pipeline, like “publishers” (permissions to accept/deny/edit/publish content).

    And next to those roles there are functional and technical administrators.

    Roles, permissions and modules like TAC allow for fine grained control and this should be reflected in the user interface.

    Seeing Leisa’s breakdown of the stuff going under the top-level menu items, the, ahem, common garden variety content editors in our organisation will only see the “content” menu item. We even try to prune the node add/edit form down to the bare essentials.

  9. 9 sun said at 5:00 am on July 3rd, 2009:

    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.

    True for really novice users. But horribly wrong for users that visited one page at least once. Once you know that Foo > Bar allows you to do Baz, you know that it allows you to do Baz, and if you ever want to do Baz, you want to visit that page that allows you to do Baz directly.

    Like everything else in this world, Drupal is a labyrinth at first. But as with every other labyrinth of this world, you get to know it. Designing for that minority is wrong. Why? It’s the wrong measure for the task at hand. You can invent “agents” (like Microsoft calls it), a “guide” system, a better help, and other things to increase the pace users learn how to orientate themselves in a labyrinth. However, once they know, they want to disable the guide, because the guide clutters the interface only.

    I guess we are not talking about usability, but about e-learning. ;)

    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.

    True for content. But pretty hard to distinguish for the 4,000+ contributed modules for Drupal. Some of them can be categorized like content. Many others can’t. Users may only work with them occassionally, but they still may be as “useful” as posting content. Given this stereotype, we would have to add a new top-level category of “Sometimes Useful Tools” containing arbitrary, uncategorized items that do not really belong into any other category.

    Because module developers do not want to end up in such as category with their modules, we would see many new top-level categories in addition to Drupal core’s defaults.

    People includes registered users and admins, but also lists of people extracted from content types (event participants, group members)

    Users that are not really users should nevertheless be created as ordinary users. You will soon identify that you can do something with those people. And those people suddenly need to log in on your site.

    Drupal originally started as a simple community platform and this is where it comes straight back to its roots.

    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)

    Like any other bubble in the world, new users will be disappointed with the available options there. The marketing effect turns into the opposite. They will wonder why it was made a top-level category. And, I wonder, too.

    Config & Modules … 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.

    This is where I think this new categorization fails: It optimizes Drupal for one specific default use-case without defining a default. It reminds me of WordPress, Joomla!, phpBB, or vBulletin – systems, people install to get a very specific functionality – without the paradigm and flexibility of building blocks (aka. modules). Following this path and paradigm, building customized Drupal sites (that make a “difference”) will become harder, because one has to remove many defaults that were intended to serve as defaults for a mixture of a few possible use-cases.

    Yes, Ubercart was just provided as example here. However, Ubercart still is poorly written and does not re-use all of Drupal’s features. If it was, you would end up with arbitrary contents (content-types) tagged as “Product”, containing some forced content fields for such tagged contents (that make up a “product”), providing a few default views to browse products, and leveraging Drupal’s built-in trigger/actions system to initiate and process orders. That means: the future of use-cases for Drupal is that most business-logic can be achieved with built-in functionality only or with a small set of contributed modules installed. Drupal’s configuration and customizability makes the difference.

    Yes, it is probably very good to hide the ugly parts deep below a Config & Modules link. I.e. modules that re-invent what Drupal already provides. But disregarding those historical solutions, the difference is that “content” is not always “content” (with regard to blog posts, news articles, or forum posts); in fact, more and more “content” is becoming less “content” (like products?) or becoming a mixture of “content” and other “content” (such as an e-paper you can buy), and the underlying issue is: How do we improve Drupal’s usability to allow the user to work with everything at the same time, but understand the difference of everything at the same time. IMHO, the solution is certainly NOT to classify each and everything as “content”.

    Simplifying all content into content is too simple and inflexible for a system like Drupal. That is possible with other systems, which are primarily intended for forum posts, blog posts, manual pages, or other posts. In the same way, putting 50-100 possible configuration items below “Config & Modules” (on full-featured Drupal sites using a flattened structure as proposed) leads to a similar, hard-to-grasp user experience that does not solve the underlying issues of classification, categorization, and context.

    I also realize that you are talking about the frequency of accessing functionality in Drupal. For that sake, you intend to put all infrequently used features below “Config & Modules”. However, you apply double standards by putting the theme configuration into an own top-level item. Like “Config & Modules”, the theme configuration is usually accessed and set up once only. After doing so, users will keep on having that item directly accessible and visible without needing it at all – in fact, most users won’t need it never ever again.

    Sorry for this (too?) late feedback. This post is one of the first where one can actually read up and think about reasonings behind a proposal, because there is actually a concrete proposal and write-up to review.

  10. 10 Leisa Reichelt said at 1:52 pm on July 3rd, 2009:

    sun, thanks for your feedback, which is always welcome!

    a few things in response:

    1. to suggest that once a user has visited a page they will then be able to remember where it is and revisit it without error is unfortunately not true. I’ve seen this many, many times in my years of observing users and in the course of this project could not tell you how many times I have asked someone where a piece of core functionality lives, or asked them to re-open a page we were just looking at, only to have them draw a complete blank, or at best guess where it is. The vastness of Drupal makes this even more likely. You may very well get to know *your* part of the labyrinth very well, but I think that people who are familiar with the entire Drupal labyrinth are few and far between (and we’re most likely to see and hear them on Drupal.org, in IRC, and perhaps even commenting here!)

    2. i didn’t mean to suggest that modules, once installed, did not add to the UI in places other than the Configuration & Modules section of the site – of course if you add a module that allows you to upload images, then that will be displayed in the appropriate content creation forms. Same with Taxonomy, as another example. We will definitely need to produce some guidelines for contrib module developers to better describe the impact for this interface on how their module UI that will help ensure scalability – I’m hoping to work with Roy, Bojhan and Catch on this post in the coming week.

    3. the fact that people will be disappointed with the content that is currently in appearance is a separate issue but, as you say, related and we’ve definitely accounted for that in this design. There is a lot of energy around Drupal theming at the moment and a lot of potential to make the content of the Appearance section acceptable, if not exciting. Placing it at the top level of navigation is a challenge to Drupal to come good on this potential – hiding it away is just going to reprioritise what is really a v important issue for Drupal’s ongoing success.

    As I said in the post itself – I acknowledge that having Appearance in the top level nav is a little in contradiction to the ‘frequency’ principle, however I also know that a *lot* of people will be looking for themes/appearance content, and that it is *very* often the first thing that people want to find and explore as a part of the evaluation phase. It needs to be very findable and it needs good content in it. I think this positioning will help to achieve both of those goals.

    4. I would have thought that ‘optimising for one specific use case’ is exactly ‘defining a default’ but perhaps I am missing the point. We have optimised for what we believe is far and away the most common usage of and expectation for Drupal which is community publishing. However, we have also built in a lot of flexibility to our interface to allow easy customisation using the taskbar and dashboard widgets that will make access to functionality other than content/people incredibly easy and efficient – yes, it is a bit of a hack, but it works. And beyond that, for those who are developing sites/apps probably have sufficient nouse to refactor the menu structure themselves to better suit the content/functionality of their site.

    I would have thought that the simplicity of making all content just content and providing a range of filters/searches to allow for findability & display (eg. via tabs) is actually *more* flexible than trying to anticipate all the possible future needs and design for them.

    Similarly, putting all of the modules and configuration elements into one location enhances their findability (they’re all in the one place) and then better information architecture (on the config page) and sorting tools (on the modules list page) help people to quickly access what they are seeking. I’m not sure if you’re envisaging each of the individual modules showing their config link on the configuration page, which is not what we’re suggesting – module config will be accessed from the module list. Again, we need a specific post dealing with this in more details, and there is more discussion on the modules page over here: http://www.d7ux.org/modules

  11. 11 Anonymous for now said at 9:25 am on August 12th, 2009:

    I think a Product Experience Strategy and an Interaction Strategy should be created before an IA Strategy.

    The IA outlined is fine but it seems that the Product Experience and Interaction are bundled along with IA rather than given separate posts in their own right.

kredittkort | Streaming | download a youtube video mac