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.

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

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.

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.

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.

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.

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.

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.

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.

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.