The D7 IA has evolved to be very wide and flat because the toolbar has a flat menu structure that requires a page load to drill down. As we re-structure the interaction pattern of menus we have an opportunity to reassess the IA. Wide top level menus with a large number of children made sense when every level down required a new page load. The new menu allows for deep exploration without the need for multiple page loads so we can build narrower and deeper and employ more hierarchies and sub-categorization that will inform the user. To illustrate this point I’ve created the following example:
Wide, flat architecture
The user is looking for “Soy Milk”
Top level:
Meat, Poultry, Seafood, Dairy, Fruit, Nuts, Grains, Beverages, Desserts
Right away the user has to A) read all nine items and understand them, and B) make a guess at which of the categories Soy milk belongs in. This becomes especially difficult when the user might place the item into more than one category.
So let’s say the user picks Dairy. They now see:
gruyere cheese, cheddar cheese, skim milk, greek yogurt, strawberry yoghurt, raspberry yoghurt, vanilla ice cream, brie, stilton, cream cheese, sour cream, whipping cream, cottage cheese, whole milk, chocolate ice cream, mozzarella cheese, Half and half, 2% milk.
Obviously there are quite a few items here to read before the user realizes what they need is not here. So the user goes back up a level to beverages and they now see:
papaya, orange juice, apple juice, lemonade, coke, sprite, bottled water, soy milk, smoothies, root beer, ginger ale, pomegranate juice, Lactose free milk
Again the user needs to find the item in a large list.
Now imagine that the same user comes back later and this time they want to find skim milk. Will they go to Dairy or will they go to beverages? The large number of items in each make it highly improbable that they will remember that skim milk was in dairy and not beverages, so again they are guessing.
Narrow, deep architecture:
Again the user is looking for Soy Milk
Top level:
Foods, Beverages
No ambiguity here, Soy milk is a beverage.
Beverages:
Dairy, Juice, Soft drinks, Other
Is soy milk “dairy” or “other”. Say the user tries Dairy
Dairy:
Skim milk, 2% milk, Whole milk, Half and half
Ok that was wrong, just as it was in the wide, flat version, but the user goes back up a level to other...
Other:
Soy milk, Lactose free milk
...and now they have found what they want and, crucially, when the user comes back later looking for skim milk they are very likely to remember that they saw skim milk in dairy. In the wide, flat example the user had to read a total of 69 words to find what they were looking for whereas in the narrow, deep example the total is 22.
Example number one has a very similar number of parents and childrens as a D7 site with several modules enabled. Now let’s look at the current D7 IA.
Current D7 IA:
- Dashboard
- Content
- Structure
- Blocks
- Content types
- Menus
- Taxonomy
- Appearance
- People
- List
- Permissions
- Modules
- List
- Update
- Uninstall
- Configuration
- People (menu page)
- Account settings
- System (menu page)
- Site information
- Cron
- Content Authoring (menu page)
- Text formats
- User interface
- Shortcuts
- Development (menu page)
- Performance
- Logging and errors
- Maintenance mode
- Media (menu page)
- File system
- image styles
- image toolkit
- Search and metadata (menu page)
- Search settings
- URL aliases
- Regional and language (menu page)
- Regional settings
- Date and time
- Web services (menu page)
- RSS publishing
- Reports
- Help
Very wide and flat. Nothing goes more than three levels deep. There are seven top level items (3 to 5 is optimal), and nine children of configuration, far too many to remember. Nomenclature is confusing to an average user. Naming rules are inconsistently applied (“list” should be “list” people” or “list modules”) Categorization is confusing and inconsistently applied.
User-centric proposal for D8 information architecture.
What follows is a list of proposed changes to the IA with explanations of the Data and thinking that led to the proposals. All of the proposed changes together are presented at the bottom as they would appear if they were all implemented at once. Don’t infer from this that the proposals are intended to be implemented all at once. Each change will be opened as it’s own issue and they can, and should, be implemented one by one as (and if) they are agreed on. To aid the process of reaching consensus on these we have included the test data that led to the proposal and as each change is tested we will post the results to the issue. As a matter of practice we should all agree that user data should trump our own personal opinions in all cases.
Proposed changes:
- Locate ther new UI “pages” under “Content”
- Locate the revised UI “blocks” (with block positioning moved to “layouts”) under “Content”
- Move “Views” under “Content”
- Change the name of “Views” to “Content lists”
- Re-instate “Site building” as a top-level category
- Move “Structure” under “Site building”
- Move “Appearance” under “Site building”
- Move “Modules” under “Site building”
- Change the name of “Modules” to “Extensions”
- Create a new top level item called “Site administration”
- Move “People” under “Site Administration”
- Move “Reports” under “Site Administration”
- Add a new category called “Workflow” under “Site Administration” to accommodate contrib solutions.
- Create a new category called “Operations” under “Site administration” for actions (as opposed to settings) that are now under configuration
- Move “Maintenance mode” under “operations”
- Make a new item called “Run cron” and place it under “Operations”
- Move “RSS publishing” under “Operations”
- Move “Content authoring” under “User interface”
- Move “Media” under “User interface”
- Create a new category called “Navigation” under “User interface”
- Move “Shortcuts” under “Navigation”
- Change “System” to “Site”
- Move “Site information” under “Site”
- Move “Users” under “Site”
- Move “Search and metadata” under “Site”
- Move “Regional and language” under “Site”
- Change “Regional and language” to “Region and language”
- Move “Cron” under “development”
Some of the thinking and data behind the proposals
Content:
The user will expect that they should be able to go here to edit any content that appears on their site. Currently the content section only contains nodes but from a users perspective content might be an article, a page, a block, an image, a video or a view. Therefore all of these should appear under content.
Anti-patterns to this in the current IA are:
Blocks, which the user sees as a form of content, now appear under structure. Documented here: (Dharmesh to provide reference)
Pages have the same issue: (Dharmesh to provide reference)
Views, not currently in Core IA but soon to be, will have the same issue: (Dharmesh to provide reference)
The litmus test of whether an item belongs under content should be “Is the output of this UI a unique entity (small e) that is printed in the users front end theme”
Pages
New UI, belongs in content.
Blocks
We think that the user will expect to find a list of blocks (which contain content) under content, not structure. To be clear this is a UI that lists blocks without table drag. Placing blocks in D8 will happen in the layout UI.
Content lists (views) (see nomenclature discussion about name change)
We think that the user will expect that lists of content presented on a page are a form of content, not structure.
Site building:
Building a site consists of choosing a theme, structuring information both on each page, using content types, and across multiple pages using menus and taxonomies as well as adding modules that extend the functionality of a site. Therefore it makes sense for all of these things to fall under site building.
Structure
The users expectation here is that the information architecture of the site, as well as any building blocks of the site that are not themselves content, such as fields, content types, taxonomies, forms would be found under structure.
Anti-patterns to this in the current IA are:
Layouts (currently part of panels but soon to be in core) which the user sees as “appearance” are now found under structure. (Dharmesh to provide reference)
The litmus test for whether an item belongs under structure should be “Is the output of this UI a reusable element from which entities that appear in the front end theme are built?”
Categories (see nomenclature discussion about name change)
Tests consistently show that users cannot understand what taxonomy is or why they would need it
Appearance:
Appearance refers to things that are visual and the user will expect that if they want to change how something looks, both in terms of it’s style attributes (color, font, size, etc.) and it’s position (layout).
Anti-patterns to this in the current IA are:
Regions (coming in D8) now appears under structure when it should be an element of appearance (layout)
Breakpoints/grids (coming in D8) now appears under configuration when it should be an element of appearance (layout)
The litmus test for items under appearance should be: “Does the output of this UI make an immediate visual or spatial change to what is displayed in the users front-end theme?”
Layouts
New UI listing all layouts.
Regions
New UI
Breakpoints
New UI
Grids
New UI
Images
New UI displaying all the uploaded images in your site as a view.
Extensions (see nomenclature discussion about name change)
As a top level item this seems misplaced. It is a site building task that should not need to be accessed often. Testing this under “site building” to see if it’s still discoverable.
Administration
This category has far too many children to facilitate good wayfinding. The proposals here are a first pass at better categorization to make this section narrower and deeper. Counter proposals on how we could accomplish this would be welcome.
User interface
Seems like Content authoring, Media and Navigation all make sense together but perhaps the category name could be better.
Site
Site information, Users, Search and metadata, and Regional and language all seem to effect things that happen on the front end while things under “User interface” affect the administrative tools.
Development
Definitely requires a separate section.
Full Proposed D8 IA
Top level: Dashboard, Content, Site Building, Administration, Configuration, help
- Dashboard
- Content
- Pages
- Blocks
- Content lists
- Site building (menu page)
- Structure (menu page)
- Menus
- Content types
- Categories
- Appearance (menu page)
- Themes
- Find themes
- Layouts
- Regions
- Breakpoints
- Grids
- Images
- Extensions
- Find
- Update
- Uninstal
- Site Administration (menu page)
- People
- Workflow
- Operations
- Maintenance mode
- RSS publishing
- Run cron
- Reports
- Configuration (menu page)
- User interface
- Content authoring
- Text formats
- Media
- File system
- image styles
- image toolkit
- Navigation
- Shortcuts
- Site (menu page)
- Site information
- Users (menu page)
- Account settings
- Search and metadata (menu page)
- Search settings
- URL aliases
- Regional and language (menu page)
- Regional settings
- Date and time
- Development (menu page)
- Performance
- Logging and errors
- Help
I still need to annotate this with citations from the studies Dharmesh has done. Lisa Rex is currently conducting a study of this IA.
Comments
Usability Study Findings
Usability Study Findings
I have conducted immense rounds of usability testing around this issue. Here are some of the reports that might be useful:
Aggregated report of findings
Blog post on Drupal toolbar
Note: Although these are comparative study findings, the core of issue - the problems with the existing toolbar are completely valid.
Dharmesh Mistry
UX Researcher | Acquia,Inc.
@tkoleary This is exciting.
@tkoleary This is exciting. On first review, there a lot of this makes sense to me. I’m going to need some time to look this over again, and review @dcmistry's work (and look at this in context of the new toolbar design). Hopefully there will be an opportunity to discuss this at BADCamp…
My 2 cents, speaking as a
My 2 cents, speaking as a site builder:
Please don't take 2 steps back in favor of 1 step forward with the D8 IA by adopting the overhauled relabeling and reorganization suggested here, as thoughtful as it is.
The D7 IA makes sense.
It works quite well.
Once grocked -- and especially once admin_menu_toolbar is installed and core's toolbar is disabled -- access to items is very fast.
The D6 IA was a pain in the butt, but D7 gets it right.
Let's not add yet another piece of new learning for those migrating in the future from D7 to D8.
I will end with a question: Has there been mass negative feedback about the D7 IA?
I think not.
I understand...
Your reluctance to move from the D7 IA. A lot of people will feel the same way. But there are very strong reasons to change it.
First off let's not confuse the two issues of toolbar and IA. There is a new toolbar that is already very far along for D8 and has received a great deal of discussion.
There are a couple of thing you mention that frame the issue quite well, one is that you have been using Drupal since 6, two is that you are a site builder and three is that you admit that the IA has to be "grocked".
The user that the IA needs to work for is the brand new content author, not the experienced Drupal vetrean site builder. You had already internalized Drupal concepts as well as the D6 IA before you ever saw the D7 IA so you are essentially blind to how a brand new user apprehends it. You are right that new users have to grok the IA. That's a problem. There should be no grocking involved. It should be effortless and self evident.
Usability testing clearly shows us that new users to Drupal FAIL MISERABLY at understanding how to get around in Drupal. It is an extremely disjointed and fractured experience. We absolutely must restructure the IA, and keep restructuring it iteratively over time, until it passes usability tests on new users with flying colors.
To your last comment "Has there been mass negative feedback about the D7 IA?". There has not been a massive amount of negative feedback on Drupal.org, but the people who comment on d.o are people like you and me. We are not doing this for you and me. You and me (designers, developers, sitebuilders) make up a very small percentage of the people who use Drupal (site administrators, content editors, content authors). Those people do not comment on Drupal.org, but when we ask them they tell us. Not that "The IA of Drupal needs to be changed" because that is meaningless to them, but "I cant find what I am looking for" and "I don't know what this word means" and "There are too many options for me to sift through, it's very confusing"
Overall that is the way most people see Drupal "Very confusing". Has anyone ever told you that they find Wordpress "Very confusing"
I think not.
Usability testing clearly
I don't agree with this premise. I tend to agree with Bob's comments. If you keep overhauling the IA, you will probably never get to a solution that works for everyone.
There will always be the chance that you alienate existing users in order to "improve" the experience for new users. Why do existing users not matter?
The problem here is:
New users will always arrive with varying levels of experience in managing content and building websites. Drupal offers solutions to a complex set of problems. While it is possible to improve the experience for new users, there is always the chance that a new user will experience difficulty. The difficulty arises from learning.
Do Adobe reinvent the IA of Photoshop each release to appease new users?
The best way to ensure new users (with varying levels of experience) are able to competently use a new system is to ensure that good usable training resources are available to reduce the burden of learning.
I find that most people I talk to find Drupal confusing initially. This is generally down to their level of experience in understanding a "Content Management System" and the shift away from "website = editable pages". Once they learn, they begin to understand.
It's difficult to compare to Wordpress. In fact, I feel it is illogical to make such a direct comparison.
If it was so simple to solve this problem. Then Drupal would just copy Wordpress wouldn't they? If by your statement, you believe that Wordpress has solved the usability issue, then why doesn't Drupal just copy Wordpress?
The answer: Drupal can not be Wordpress. Wordpress and Drupal are not the same.
As an alternative
As an alternative suggestion:
Adopt admin_menu_toolbar in D8's core, as a replacement to D7 core's toolbar module.
This resolve's the opening issue:
"The D7 IA has evolved to be very wide and flat because the toolbar has a flat menu structure that requires a page load to drill down."
Could there be some research
Could there be some research data on what is difficult to use around the IA in Drupal 7? I know that in previous community research we found some issues with people navigating around, but not by far as disastrous as you make it sound. It's likely that we are just missing that though, since we did not do very specific tasks around structure vs. config.
The data that Dharmesh links to is largely a comparative study with findings on that its better and some individual design issues, it has little data on the actual IA trouble that people run into.
I am in general missing a lot, a lot of argumentation and seeing a lot of assumptions for this change. For example;
1) Users struggled with differentiating between two categories (structure and configuration) - having 7 places solves this?
2) What are the rules for modules, you can't redesign the IA without a thorough analysis of how it impacts contrib and how they should place there modules.
3) What is the advantage of narrow and deep over flat? The reason we made the IA flat, is to counter the fact that a narrow IA requires you to poke very deep to find what you want - and that in itself creates a lot of usability issues with orientation, narrow might work if the labels are very accurate in describing the contents but also more sensitive to errors as you now have 5 more places to look for functionality and sometimes with depth.
4) What is menu page, is that a page you go deeper into or is it a category like on configuration? For now I interpreted as a page you go deeper into.
5) Site administration feels very small, even taking contrib into account. Is it really necessarily to have its own top level. Will people feel "site" also covers site information?
I have loads more questions, but this should be good for now - I wanted to give at least somewhat timely feedback. It's definitely a lot requiring our userbase to relearn the IA every release, and its had quite an impact on our contrib community. However we should always do it, if we think its going to be better.
I am really looking forward to the usability testing results of this.
Some good points
1) Users struggled with differentiating between two categories (structure and configuration) - having 7 places solves this?
I don't think I understand this question. 7 places?
2) What are the rules for modules, you can't redesign the IA without a thorough analysis of how it impacts contrib and how they should place there modules.
This is a good point. We need to set up a sandbox with the new menu and throw a whole tone of modules into it to see what happens.
3) What is the advantage of narrow and deep over flat? The reason we made the IA flat, is to counter the fact that a narrow IA requires you to poke very deep to find what you want - and that in itself creates a lot of usability issues with orientation, narrow might work if the labels are very accurate in describing the contents but also more sensitive to errors as you now have 5 more places to look for functionality and sometimes with depth.
IMHO it's pretty clear that categorization simplifies search and adds clarity. Nevertheless we will test it, and in context with the design, not abstracted in treejack as we have done already. (btw Lisa's study already exposed some flaws which I will correct)
4) What is menu page, is that a page you go deeper into or is it a category like on configuration? For now I interpreted as a page you go deeper into.
An example of a menu page in D7 right now is content types. We could possibly bypass the need for menu pages entirely by having a parent item which only has children (and not it's own page) simply expand the child items in the menu. There are two problems with this though; 1) If the user has the menu in horizontal orientation they still need the menu pages, and 2) having some of the links in the vertical menu open child items and others load pages might be strange. Having said that I'm open to testing this as well.
5) Site administration feels very small, even taking contrib into account. Is it really necessarily to have its own top level. Will people feel "site" also covers site information?
My expectation is that many modules will place things here, notably workflow tools.
Nathaniel's points are right
Nathaniel's points are right on the mark.
Every single respect in which each new version of Drupal reorganizes the previous version's IA idioms requires relearning on the part of the existing Drupal community. The degree of this relearning should not be underestimated.
This dynamic of IA reorganization has been going on in parallel with significant version-to-version discontinuities in Drupal's underlying mechanisms. With Drupal, these discontinuities are especially large -- and often painful to the community -- because the project's leader does not believe in "backwards compatibility".
These discontinuities are painful to module maintainers, in particular, plus to anybody who migrates a site from version N to version N+1.
In turn, they are painful to site builders and others faced with use of modules/extensions that have not been ported to Drupal's newest version, not because the modules are unworthy, but because their maintainers are exhausted.
You may feel that I digress. Au contraire. At this point in time, and I mean as of D7, Drupal's IA actually works extremely well.
Those of us who have adopted D7 and moved on from D6 are now wondering how great these discontinuities will be with D8. We are assuming they will be large. Therefore, we are also hoping that discontinuities are not introduced where there is no underlying need to do so.
In short, why "fix" something that is in fact not broken?
Again, why "fix" something that is not broken?
As Nataniel states, Drupal is inherently complex. This is because it is a sophisticated and powerful Content Management Framework. All worthy frameworks require a major investment of time to learn. This investment varies in large part based on a person's background. Also, regardless of background, the first engagement with Drupal will be the most expensive.
So, it is no surprise that newcomers face a steep learning curve, as did I -- despite my deep background in software product development and in hands-on Java enterprise framework architecture and engineering.
With software product development, there is always a tension between continuous improvement on the one hand -- and product predictability and stability, plus retention of the existing user base, on the other.
As a case in point, witness Microsoft's disastrous introduction of Windows Vista, where an effort was made to overhaul the Windows IA significantly away from that of Windows XP. MS regained sanity with Windows 7, but largely because of the intervening Vista debacle, it is no surprise that XP lives on and remains the Windows OS/framework of choice by over 40 percent of new purchasers of Windows. (See http://en.wikipedia.org/wiki/Microsoft_windows#Usage_share.)
Terrence et al, I know your intentions are well meaning and sincere. However, they strike me as largely theoretical and academic in nature, as opposed to pragmatic. The push back you are getting from me stems from my passionate belief that with D7 the Drupal IA is very pragmatic as it stands.
Yes, I agree that evolving the IA makes sense. I do not agree that overhauling it makes sense.
Nor do I believe that it makes good "product management" sense.
This is because Drupal has acquired a very bad rap for things working one way in D5, another in D6, and yet another in D7. If the IA is overhauled with D8, that rap will only worsen.
Additionally, now that the Drupal community is truly large, the unnecessary overhaul of something as central as the IA would negatively impact a very large user base, a user base that is still coming to grips with D7.
D7's worthy IA is in fact helping that user base to "grok" D7. It is pragmatic and largely right. It is my and others' sincere hope that the D8 IA be based on D7's IA, rather than being an overhaul of it.
When I mentioned the prospect of IA overhaul to this week's local DUG meetup, the news was greeted with gasps -- the consensus sentiment being "Oh, no".
Respectfully,
Bob
Expert interface vs. Novice interface
The wide (D7) architecture is a good example of an expert interface, while the narrow architecture is a good example of a novice interface. The efficiency of the narrow architecture for a novice user is clearly demonstrated in the original post.
There is usually a tradeoff in choosing to accomodate novice over expert or vice-versa. The wide interface allows the expert admin to access any config screen within two clicks—she manages several sites and has the menu more or less memorized. This is more efficient for her. Contrast with the novice interface: options could be up to 4 steps away.
Choosing the narrow interface targets novice users. OTOH, the impact of the tradeoff is lessened by efforts to improve the toolbar.
My first though was: "this approach will make it more difficult for me to use Drupal"
After thinking it over, I had a different perspective:
- there are a greater number of novice / occasional users
- an improved toolbar will be welcome and will help lessen the impact on expert users
- some things will be more difficult for expert users, but expert users will be more likely to use alternatives to the menu (drush, etc.)
- the narrow IA could better accomodate a more crowded admin interface (the ones with 200 contrib modules)
Change is hard, but I'm more optimistic about this design after thinking it over.
http://cleaver.ca
It all depends on what you
It all depends on what you think Drupal is for. Dries at DrupalCon London used the iPhone as an example of powerful functionality combined with ease of use. That is a great objective. He did also say that Drupal is not for every use case. My own experience of real world small website owners, plus giving daily support on the forums, is that Drupal has not been a cost-effective solution for most of them, and Drupal 8 will not be, however good interface (partly because the small user with a bunch of contrib modules is not satisfied with the major version upgrade experience: but there are other issues requiring technical knowledge too). So my own view is that Drupal should be designed to shine more in the sector where it is already the best solution, for website owners who can afford some skilled site-building help and training of end-users. I wonder whether anyone who has worked for a couple of years directly with low-skilled low-budget Drupal users, as I have, will honestly be able to recommend Drupal 8 to their grandmother as the best CMS for a users who needs ease of use and of maintenance. On the other hand I am torn, because if no one aims for Dries's high aim of cracking both usability and power, then we will never get there.
It will be a fail...
...even for the target audience you describe if we do not handle usability. The biggest complaint from Acquia enterprise customers about Drupal is the pain of content authors. I'm not saying your Grandmother should be able to build a Drupal site but she better be able to easily write a blog post on one.
Thanks for the feedback
Your point about expert vs novice users is a good one. We should also keep in mind that with agressive permission control for authenticated users (content creators) there will be far fewer items in the IA. I think that for D8 we need to think carefully about the default permissions for those roles and what the IA looks like in those cases.
This is a good point. I do a
This is a good point. I do a lot of work with content editors and publishers, and generally their permission set is along the lines of:
- create content of X content types
- administer/approve content
- administer/approve users
- administer/approve comments
- add content to a menu
- administer taxonomy terms
There are quite a few instances in core Drupal where it is impossible to create a sensible content editor experience, eg
- administer and create taxonomy terms but shouldn't be able to manage fields
- edit some blocks but shouldn't be able to move them
- add/edit a block to the sidebar of a page
- edit menus but not top level menus
- add a page to a specific part of a menu without having to perform Twister
I'm not sure how this chimes with other people's experience but generally I find there are three types of privileged user on a given site.
- developer/site administrator/loathe the term but in Drupalspeak 'site builder' - someone that will generally have if not all but most permissions. Will generally know Drupal enough to work round its quirks
- content editor - will have access to content, perhaps people, tabs, in D7. Will generally know Drupal to throw things at it.
- authenticated users of different flavours - won't ever see the admin interface of the site. Never heard of Drupal
These obviously don't fit all use cases but they are user types that are repeated over and over again in my projects and therefore should be strongly considered when thinking about the information architecture and how bare it may look for content editors, who are often the ones using it day in day out.
"There are quite a few
"There are quite a few instances in core Drupal where it is impossible to create a sensible content editor experience."
This is precisely why module families like the Workbench suite (http://drupal.org/project/workbench) are being created.
Frankly I do not believe that the admin toolbar -- which has been the reference here for the Drupal "IA" under discussion -- should be configured for any constituency other than site builders (broadly defined).
IMO, the D8 "IA" proposed with the initial post here will not solve the content editor's dilemma. If anything, the admin toolbar proper should not be overloaded in order to satisfy content-editing concerns. To do so will disrupt its value to site builders.
In fact, one of the key responsibilities of site builders is to provide solid solutions for content editors -- either by adopting solutions like Workbench or be crafting their own.
Let's think out-of-the box, along the lines of Workbench and the like, and leave the admin toolbar proper "WIDE & FLAT", as it should be.
There is no need to tweak the admin toolbar to meet the real and important needs of content editors.
Content Editor Role
I wasn't sure whether anyone was calling for a "Content Editor" role in the default core install. I think if there was such a role that came with sensible default permissions, it would go a long way towards making the content editor experience much better.
It would be even better if permissions are added automatically when a new content type or fields are added. Better still if contrib modules started to make use of this role.
http://cleaver.ca
Fantastic idea!
We absolutely need to think of IA in multiple layers based on our understanding of the 80% use cases. I'm so glad you suggest this because it leads us to a better understanding of how the IA evolves by role and to the fact that we probably need to restructure the nomenclature and the default permissions for the other roles as well.
Based on discussions I have had with both small and (very) large Drupal 7 users over the past year my first pass at this would be:
Role: Anonymous user.
Permissions set: Reply to comments only (No menu access)
Role: Authenticated user
Permissions set: All of the above plus permission set usually associated with having an account on a social network ie. add content but only to pages I own.
Role: Content author
Permissions set: All of the above plus create any kind of content and save as draft for approval by a content editor.
Role: Content editor
Permissions set: All of the above plus publish content author content, edit page layouts (but not master layouts), place blocks, edit views, edit menus.
Role: Site builder
Permission set: Everything but configuration/site information
Role: Site owner
Permission set: Unlimited
Now that I've finished this I am realizing it's really a new meta issue. :)
I think this is a good
I think this is a good start.
About novice vs. expert users, we should also consider the intermediate users. A sign of a good design is to ease in the new user easily giving them the tools they need to understand what is happening whereas it is also the responsibility to cater to the power users by making them efficient in the process.
The proposed design I think is a good start to do that. IMHO for the novice users, where there is so much to grapple, a simplified IA is going to not be overwhelming to the new users to use Drupal. As they become more used to Drupal, the “jump to” and “short cuts” will help them to be efficient. The advanced users (including expert users) will be benefited from “jump to” and “short cuts”.
Also, it is a lot easier to keep the status quo and difficult to get the buy-in to make something which is disruptive but necessary.
Dharmesh Mistry
UX Researcher | Acquia,Inc.
I like the new IA
I've also been using Drupal since d6, and I think the proposed IA for d8 looks pretty good, even though I found d7 a step up from d6.
The keys for a good IA are the scent of information. It's not so much how deep in the IA has to go, it's whether or not they have the scent of information at every step of the way. Is it is easy to pick which option I should click next? Do I see a word that matches my mental model for where I would find it?
(By the way, in your soy milk example, I would have selected the label "Dairy alternatives" as a much better option than "Other" for that particular category. Miscellaneous is almost always a terrible label.)
It's also important that at any one level, there aren't too many choices, because that's just overwhelming. My experience is that seven is the upper limit for being comfortable while making a choice. But I agree, 3-5 is better.
And I also agree that the real challenge here is how this system handles a typical number of modules (or extensions, as you're proposing to call them.) Should all extensions live in their own area in the IA? Or should they be located near the kind of function they provide? The latter is probably more usable, but that makes it difficult to limit the number of choices at any given menu level.
One quibble I have with the proposed IA: Images are listed under Appearances. I actually would consider those content, and I would create a Media category under content, which Images could live under, and which videos could also live under from contrib. Appearance may also deserve a Media category, but I would put image styles there, rather than under configuration. I look at Appearance as a special category of configuration. File system and image toolkit probably still make sense under configuration.
I'm not entirely sure that site building is a category that makes a lot of sense. That's not a term that's in general use, and I don't inherently understand what lives under there.
While I know the goal is to limit the top level to five choices, I think in this case you might be better off with seven by bumping up structure, appearance and extensions to the top level. Each of those are fairly understandable terms.
And if you're really concerned about limiting the IA to five, maybe think about visually separating Dashboard and Help from the rest. Nothing really "lives" under those options.
I also think Configuration is a questionable category. All of these configurations are sitewide, so why not put them under Site Administration? And I think Settings is a much more understandable and common term than Configuration.
So then if you could visually separate Dashboard and Help, you would have the following top options:
Which, to be fair, isn't that far off from the D7 IA.
The biggest difference at that point is that People and Reports would be under Site Administration. Reports, I think, make total sense under a Site Administration category. Would People? Maybe.
And now I wonder if Site Administration is such a logical term. Isn't the entire menu site administration?
And now I think I've effectively written myself into the corner of mostly agreeing with the D7 IA advocates.
Anyhow, hope some of this feedback is useful.
:)
Yes there are a lot of things to think about here. I think I agree with your comment about images. Others have said the same. Similar thoughts on the "site building" stuff. I think by default content authors should not even see those anyway so it might make sense to keep them top level.
Lisa Rex and I rea putting together some tests showing these in the new menu structure so we should have even more data soon.
Coffee
Let's not forget about the Coffee module:
http://drupal.org/project/coffee
Re-purpose the UI categories?
Hi guys,
Nearly 3 years into Drupal development, as a designer, I would still categorise myself as a starter but it's great to see this discussion unfolding and would certainly like to share my initial 'administrative confusion' with Drupal - and throw my designer/UI centric experience to date in here.
I hope it helps.
First off I do think there's confusion here, even after 3 years and the huge improvements that came in with Drupal 7. Most of the confusion stems from configuration options not appearing where you would expect them - and this is most confusing when trying to explain/train a new client how to use the admin/configuration system.
I would also say that most of the confusion could stems from the choice of categorisation and the main group labels being used (still) but especially the content, structure and configuration groupings.
To my mind a re-definition of these what the groups should contain (followed by best name for the groups) might really help. To put it simply I would separate the group functions as follows:
Content (creation and administration)
Appearance (settings)
Configuration/Architecture (irregular set-up tasks)
Administration/Configuration (regular admin tasks)
User (user centric tasks)
Help
See below for suggested administrative items but there's a couple of stand-out items for me.
The first point is that when training a new client on using the site you do really want all the content in one place so that anyone with appropriate permissions but whose role is centred on creating, updating, censoring or otherwise handling 'content' has only one place to go; to the "Content" group.
I would also have Blocks and Views in there as most averagely complex pages (URLs) consist of your main node content and several surrounding blocks of "content" (and by "content" I mean the usual words and images that ordinary users would refer to as content).
Referring back to the earlier point about renaming 'taxonomy' as 'categories' is really an injustice to what the taxonomy module does as it very much creates content (by default) and each new term automatically has it's own node/URL (and editable fields including images, etc).
Likewise, Views is very much part of the content creation system. I.E. Most averagely complex sites will have to allow content editors access to the Views architecture to update content (if you're using Views with a global text area, for example). You could argue that the Taxonomies and Views are more to do with Structure, certainly under the present arrangements, but the Structures area currently contains a hotch-potch of items that aren't 100% connected with "structure" either.
So my central idea would be to re-purpose "Structure" under a "Configuration/Architecture" tab, for one-off, or irregular, set-up tasks allowing many of the more ambiguous items currently residing in the current "Configuration" area to be re-purposed to contain only regular administration tasks where the name "Administration" sits better on the top. I.E. The Administration area is largely reserved for regular administration tasks that you would expect to be performed by a high-level admin role (and on a regular basis).
Likewise, all the user-centric tasks (including people/user administration) might sit better under a new label "User" where we can also logically have roles, permissions, settings, people (although surely 'users' is a better term than 'people') and user interface like text formatting. The reason being that user administration for many types of sites is large part of the day to day operations and it is quite specific. Under the present D7 arrangement there are user/people centric operations in several different parts of the admin system with some updates requiring you to jump back and forth between them.
Here's the complete list. Not meant as a fait accompli but just some ideas/insights from a designer/UX/ordinary user perspective:
Content (creation and administration)
- Nodes
- Blocks
- Comments
- Forms (webforms)
- Taxonomy
- Views
Appearance (settings)
- Themes
- Deltas (layouts)
- Images (toolkits etc)
- Fonts
Configuration/Architecture (irregular set-up tasks)
- Site information (name, emails, slogan, analytics, etc)
- Regional (language, date & time, etc)
- Content types
- Modules/extensions
- File locations
- Context
- Menus
Administration/Configuration (regular admin tasks)
- Search (settings, 404s, etc)
- Metadata (URLs, redirects, page titles)
- Operations (maintenance, backup, rss, cron, etc)
- Workflow (actions, triggers, rules)
- Performance (caching)
- Reports
User (user centric tasks)
- Roles
- Permissions
- Settings
- People
- Interface (text formatting etc)
Help
A final thought is that many of the module-specific settings could and perhaps should be left with the modules (now grouped under "Configuration/Architecture" with the above model. A current real bug-bear of mine is that module-specific configuration options do sometimes appear in the current "Configuration" tab, adding to the cluttered feeling in there, and sometimes they only appear with the module, etc.
I hope that helps but I look forward to seeing how you guys progress this. I would love to help somehow if I can.
Q.
Thanks
This is excellent. We just finished reviewing the first round of testing on the IA in the summary and we have surfaced some results that map very closely to some of your ideas.
Lisa Rex and I are working on a summary and a revised IA based on the results which we will post here soon, along with links to the videos.