Problem/Motivation

The current admin interface divides admin pages mainly by Configuration, Structure and Content, but there is no clear definition of what is what.

For several modules, admin pages were placed in an earlier Drupal version, but since then their functionality has been increased (for example contact forms). Others contain user generated content (for example taxonomy terms). As a result, some pages are in places where they are not expected, and a number of issues try to fix the placing of few pages at a time in the current structure. (See list of related issues).

The lack of consistency also has a secondary effect of failing to properly guide appropriate placement of menu items by contrib modules.

During DevDaysMilan, we did an exercise to see whether we could define what's Configuration, Structure and Content. What we came up with instead is a different way of classifying admin pages as Content, Site administration and Site building; as well as Users, Modules, and Translations.

The idea is to organize the admin area into sections by tasks and whether those tasks represent the building of the new site (typically exported to code) or the ongoing maintenance of content and administration (ephemeral database entities). It also allows us to use the structure of the admin interface to show new users how Drupal works.

Further thoughts:

  • This classification is based on sites (or other projects) that are build by sitebuilders and themers - for other users who will then administrate the existing site (site administrators). They might need to change the recipient of an existing contact form, but not change the fields on the form. Or change the wording of the welcome email for new users, but not manage the fields and display of the user accounts in general.
  • Of course there will always be projects, where site administrators also need to access more structural tasks, but if their role has permission to do so these admin pages are still available.
  • All (lists of) content should go in the content section, including for example list of taxonomy terms, but we can use the operation links to guide users across site building, administration and and content.
  • The issue that some menu items and taxonomy terms are structural – provided as part of the site building – instead of user generated content remains unsolved by this, but there is also no regression since they are currently technically content.
  • Most reports can be placed under Administration as they help maintaining the site.

Proposed resolution

Decide whether this is a good direction to proceed.

Then formulate a set of rules to check where each admin page should be placed (instead of individual pick the places). This would (a) show whether what we are doing works, and (b) provide a standard that contrib modules can follow.

During discussion at DevDays Milan, it was proposed to do this as a community initiative.

The work in progress at DrupalDevDays

a mockup of what the Content menu would then look like - more options!

Remaining tasks

User interface changes

Yes.

API changes

Might be if paths are changing.

Data model changes

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

ifrik created an issue. See original summary.

ifrik’s picture

Issue summary: View changes
FileSize
35.32 KB
rachel_norfolk’s picture

Issue summary: View changes
FileSize
1.17 MB
260.78 KB

Just adding images...

rachel_norfolk’s picture

Issue summary: View changes
rachel_norfolk’s picture

Issue summary: View changes
ifrik’s picture

ifrik’s picture

Issue summary: View changes
rachel_norfolk’s picture

ifrik’s picture

webchick’s picture

This looks like a very interesting initiative! But I can't quite parse from the image what exactly is being proposed here. Is the idea to change from a handful of top-level admin links to 7-8 of them? (Users, Content, Administration, etc.?) Or were you re-parenting the existing links under the existing headings, using those criteria as a guide?

A couple of random thoughts:

1) The card-sorting exercise is great, but bear in mind that the audience at dev days is extremely specific (nearly all developers, typically with lots of pre-existing Drupal knowledge, usually located in Europe), and not really reflective of Drupal's wider user base. It would be really interesting to try a similar exercise "at scale" with some kind of online tool which was promoted over more general channels like the Drupal survey was in advance of New Orleans. If the results were similar, we'd know we were on the right track.
2) Even though in theory we're not supposed to be linking to links via URL anymore and instead using the link machine name system, I'm not sure we can actually do a wholesale re-engineering of the IA in 8.x. Because even if it didn't break links everywhere, it would certainly invalidate all documentation, videos, etc. so far for Drupal 8. :\ (If this is what's being proposed, sorry it's not very clear atm.)
3) But, I wonder if we could work on this in a contrib/sandbox module in the meantime, so it's easier to test and iterate on rapidly.

Could use some guidance on what specifically needs review here.

ifrik’s picture

Thanks Webchick,

the idea is first of all to come up with guidance where to place which admin pages: something like an algorithm of about 5 questions that can be used for core and contrib modules, thereby giving us more consistency and creating a better feeling to users of where to start looking for something when they install a new module.
We started on a set of such questions at the end of DevDays and Rachel_Norfolk is planning to post them here.

The scope of this would go beyond rearranging some pages, but it would mean separating out admin pages by tasks, and sometimes splitting existing pages into two. It would also mean using the Operation links to link to related pages in other sections.

Two examples:
Taxonomy terms (especially in the case of free-tagging) are user-generated content, but the list of taxonomy terms of a vocabulary, are placed as a tab of that vocabulary under Structure - together with other pages that are site building: adding fields, managing the display, configuring language settings for the vocabulary as a whole.
In our concept, the list of taxonomy terms would be a page under Content, while the other pages would be under Site building with an Operations link "List terms".

Since contact forms are now fieldable entities, the pages to add fields, manage the form display etc. would be under Site building, but the page where the recipients of the contact form can be changed would be under Site administration because this is something that's likely to get changed during the lifetime of a site, something that's not a structural change that would require a site builder, but something that somebody in the office of a company should be able to do themselves.

If we split up admin pages along those lines, then we could in lots of cases simply turn off the whole Site building section on a production site, or not display it to users of an existing site who aren't site builders. It would leave general users of an existing site with lists of existing content, and site administrators with the content as well as a section of administrative tasks and reports which they need to administer an existing site, content and users.
That would greatly improve the usability for those users who work with a site that has been build for them, and it would make it easier to configure permission so that they really only see what they need.

For site builders it would mean that all they need is in one section of the site. This could possibly include appearance configuration thereby solving the question why image styles are where they are.

So yes - this would be quite a big task, and therefore the proposal of the core contributors at DevDays was that we first should check with you as product manager on whether it's worth pursuing this train of thought before putting more work into it.

------------------------------

But - as it is the strange energy of DevDays - the discussions led to something else we could do with this.
Currently, when a user installs a Drupal site, they become User1 by default and are presented with a range of options that are too broad for first time users. In order to reduce their confusion we currently hide pages away from the admin menu. But if we could generate a User2 with a different role (like "site builder" or "First time user"), depending on the install profile, then we could set the permission so that a new user initially only sees a some of the available site building tasks - until they change their role and get the full list.

That way we wouldn't need to change the admin menu to favour one persona over the other, but simply display more or less. Users would be able go move forward as they gain more experience.

(An example would be the menu item for Display modes, which is not something we expect first time users or builders of small sites to use, but which is a vital tool for site builders of complex sites. There currently is a proposal to remove that link from the menu and only make the page accessible via the display management of a fieldable entity. Either proposals has its merits for one persona but creates a usability issue for the other. Hiding or displaying the menu item based on the role set during the installation would mean we have both.)

And if we want to think along the lines of persona's and their roles in core we could even provide them with the site UI texts in English, Simple English or Developers' English....
-------------------------------

But that's the even bigger picture, the main question for now is whether it is worth the effort to think along the lines of splitting admin pages more by tasks and persona's, and link related pages across theses sections by Operation links. A contrib module is certainly an option because it could it could then be tested properly.

rachel_norfolk’s picture

Well reminded Ifrik - subtle! ;-)

As a very first draft, these rules still need work and our plan is, now where have a structure we “feel” is right, to re-run all menu items through the rules and use that to fine tune them and the final structure. Consistency and predicability of where things exist is our aim.

  1. Does it list/add/edit a user entity?
    —goes in Users
  2. Does it list/add/edit a content entity?
    —goes in Content
  3. Does it list/add/edit configuration entities related to the look & feel?
    —goes to Theming
  4. Does it list/add/edit configuration entities related to the build and functionality?
    —goes to Site Building
  5. Does it list/enable/disable modules or themes or other extensions?
    —goes to Modules
  6. Does it list/add/edit configuration entities related to ongoing maintenance or administration?
    —goes to Site Administration

Rules should be interpreted in order - for example, see The Rules...

mirom’s picture

I welcome every activity to make admin interface more user friendly. I'm not big fun of solution proposed in #13 because in my use case it would distribute 5 items to 3 different menu parents and that would make module harder to use. We've tested it on people without any Drupal skills and it was more comfortable for them to find everything related to one functionality in one place. New people I used to train were often confused, why e.g. account configuration isn't coupled under Users menu item.

rachel_norfolk’s picture

Well, that's why we need to refine the rules!

The thing with testing is we need to be realistic; if we test only the use of one module, we end up with results that are skewed for that one module. It's important to consider "the whole" aspect of site building, dev, theming, administration...

ifrik’s picture

This issue was discussed at today's UI meeting https://www.youtube.com/watch?v=vK8dvuJx1Rk starting at about 26:09
I will post an issue for moving the content pages as a first step.

Bojhan’s picture

Angie has provided her feedback. We discussed this at the UX meeting this looks like quite an interesting challenge and happy to see that people are thinking about this.

A few considerations from this discussion:

  • The scope of this issue is immense as it intents to overhaul the entire information architecture. From our experience (doing this in Drupal 7), the effort required for a sensible new Information Architecture requires significant research with all of our audience (not just developers).
  • A approach would be to experiment this with a smaller scope, e.g. having the clear split between content and structure - by creating a contrib/experimental module which changes the routes. While its tempting to think in the bigger-picture, the new experimental approach enables us to think in trying ideas first - before fully committing big efforts to them.
  • Take some time to review the previous user research, design principles and developer documentation - a lot of opinions voiced here could be better informed if you leverage the wealth of work already done on this front. It should also allow you to better understand what does and doesn't work.

Having been involved in the previous restructure, I would say from a user point of view its definitely worth it. From a release point of view, you have to consider the scope that can be implemented without too much issues around BC as webchick clearly noted. From a product point of view, you have to clearly outline what the user challenges are, how the solution could aid/not aid in that - and what needs to be validated with user testing of an experiment to ensure this is the right direction.

Keep in mind that clear separation as suggested) also creates the drawbacks of disconnected navigation, you need to bridge both challenges. Webchick clearly notes the bias in this card sort, the information architecture provided at Dev Days was getting close to Drupal 6 and is focused around developers understanding of the 80%. There are many tools and avenues to uncover the needs and wishes of other audiences.

ifrik’s picture

Thanks Bojhan,
disconnected navigation was in fact a starting point, so we certainly don't want to fix that by disconnecting navigation somewhere else.
Instead we aim for something where users can develop a reasonable expectation where to find what - even when they install a new module - instead of needing to find and remember the location of functionality per module.

The first step therefore is work on the set of guiding questions to determine where an admin page should ideally live.
Once we got that, then we can break down the implementation into an experimental module with smaller scope, and test that.

And yes, this should be based with the knowledge and understanding of previous work and decisions taken. One of the problems in this respect however might be that the issues and documents in which these got discussed mainly got turned into code - but not into guiding principles or UI standards that can be referenced. (In contrast to existing coding standards.) Therefore, providing some rules or an algorithm as well as the reasoning behind it, instead of a card sorting exercise, is important to us.

webchick’s picture

So rather than basing the questions around concepts (which presumes some knowledge of the underpinnings of Drupal), it might be interesting to explore it around flow for particular personas, for example:

- Content: Ongoing maintenance of content, comments, etc.; anything that gets accessed frequently by a content author persona.
- Site building: Stuff a site builder persona does "first" on every site you build, and repeatedly go back and tweak: strictly limited to "80%" tasks: content types, taxonomy, views, etc.
- Appearance: Anything to do with the "look and feel" of the page/site, including blocks, layouts, themes, site name/slogan, etc., developer resources for creating new themes, etc.
- Extend: Turn on/off functionality of your site, developer resources for creating new modules, etc.
- Configuration: All the other stuff that is not 80%, and/or that you "set once and forget it." Basically the "advanced options" of Drupal.

Not saying those are any good. Just trying to think "outside the box" a bit. :) But I actually don't remember D7's IA testing poorly, whereas I do remember that D6's and D8's did, so we need to undo some damage.

webchick’s picture

Version: 8.2.x-dev » 9.x-dev

Also bumping version to 9.x to indicate that I don't believe a wholesale IA restructuring is something we'd be actively pursuing in core for D8 (a few individual items moved around maybe on a case-by-case), but we can of course explore it in contrib/distros in D8.

ifrik’s picture

Thanks webchick,

those five concepts in #19 are pretty close to what we had discussed so far, including placing anything that is or can be theme-specific (such as placing blocks) under Appearance.

There are two other concepts:
- Translations: anything to to do with translating the words in a site. Translator personas don't necessarily need to know whether what they translate is interface, configuration or content.
- Users: anything to do with the administration of existing users

ifrik’s picture

A summary of further discussions on this, in preparation and following my DrupalCon session:
https://events.drupal.org/dublin2016/sessions/one-size-fits-all-usabilit...

The "80%" criteria in general is rather vague because we have no data on what that is - or even what 100% is in this respect. So it leads to a "I think other people will use this or not" that is rather subjective.
Also there seem to be at least two contradictory ideas of what configuration is: either "only set once and then forgotten", or "those kind of settings that are different on dev and production sites and tend to be getting changed later".

We also came up with a number of questions that could guide developers, and will get different people to test them to see whether they would place pages in a similar way.

(Configuration is used it the question below in the widest sense, as in Configuration manangement.)

1. Will this page contain user-generated items?
.. No --> continue at 3
.. Yes --> 2. Will it contain users or items connected to users?
...... Yes --> Users
...... No --> Content

3. Does this page relates to installing something (module, library, theme)?
.. Yes --> Extend

4. Does it have to do with languages or translations?
.. Yes --> Language

5. Does the page contains configuration that's different between instances of the site (dev, production)?
Does it contain contain configuration that's not exported to yaml-files?
Does it contain configuration that site administrators might need to change on the production site?
.. Yes --> Administration

6. Does it only contain configuration that is not needed on a production site?
.. No --> Administration

7. Does the page have to do with the look & feel of the site, or has theme-specific configuration?
.. Yes --> Appearance
.. No --> Site building

catch’s picture

Project: Drupal core » Drupal core ideas
Version: 9.x-dev »
Component: other » Idea

Moving this to the ideas queue.

ifrik’s picture

Thanks for adding this to the ideas queue.

During the sprint in Dublin, I made a simple online form to test out whether the question make sense: http://form.ifrik.org

philsward’s picture

I'd like to join in on this conversation a bit and help out where I can. I'll be honest and say that I don't have extensive working experience with D8 yet, mainly due to the lack of necessary contribs needed for my normal site workflow and a major slowdown of site creations compared to my D6 / D7 days...

That said, I played around a bit more with D8 today while working on a new site I decided to move forward with. I must say I felt far more frustrated trying to figure out the D8 menu structure, than I felt accomplished. This prompted me to post some frustrations on a g+ post and ultimately do some digging to see what is being discussed on this front. In case you're interested in the g+ conversation.

I think my biggest hangup, was the fact that D8 has a lot more added to it over D7. I've been using Drupal since the 5 days and never had much of a problem figuring out where things were, even when D7 showed up with entities. On D8 however, it's a totally different mental ballgame and I can't exactly figure out why. More menu stuff crammed into the old Drupal menu workflow is my only guess. The old way just doesn't work for D8 anymore.

I've read through the comments on this post and there's a lot of good discussion. Some ideas were presented that I hadn't thought about and some workflows I don't normally deal with. However, in my mind, the structure needs to be split up and re-worded in such a way that the workflow deals with the intent of the user. Look at the way Google is structuring their voice search: "What do you want to do?" "What do you want to know?" "Where are you wanting to go?" "Ok, here are some results". I think a similar principle could be used when dealing with the menu structure. Group by intention of what the final outcome needs to be.

I had a novel of a comment written but decided I need to think this problem out a bit more before I come back and suggest anything concrete. I will leave on this one thought though: Create a VERY robust admin search that will present all permutations of the query for the admin menu pages. If the admin bar had an ajax search that would show me a comprehensive list of possibilities for the query, I'd probably use it more than a restructured menu ux.

philsward’s picture

FileSize
746.66 KB

Playing around with the menu structure tonight, I came up with a possible idea for the UX. I'm not 100% sold on it, mainly because I don't have the coding ability to pull it together as a real-world test, but it's a possible direction to shoot for. I'll try to do some additions to it by adding more modules like commerce, eck or paragraph bundles to see how far it will go.

Bug note: menu item (null) contains the tools found in admin_toolbar. Ideally it should be moved to the very front of the primary admin bar. Personally, I wish that module were part of core... it's such a beautiful addition...

Menu Idea 1.0

ifrik’s picture

Thanks, philsward, for your interest in this.

The issue is currently tagged with "Idea" instead of core. This means that core maintainers are interested in discussing this first before anybody puts any more work into it.

Secondly: The idea not about simply coming up with another order for the menu items - it's explicitely about coming up with a set of rules that developers can use.
If you want to try that: you can add some pages at http://form.ifrik.org/ . Once there are enough example pages in there, I start publishing the results to see whether different people come up with the same mapping.

philsward’s picture

Thanks @ifrik

Glad to know this is being looked at from a deeper level than just re-organization.

jmuzz’s picture

+1 for renaming people to users. The first button on that page is "Add user" and the rest of it is a list of users, it makes a lot of sense.

I think "extend" could be looked at too. It's the only item that's a verb instead of a noun and it doesn't correspond to all the actions it leads to. For example, uninstalling a module is hardly extending the site. Why not call it "Extensions" ? Then rule #3 could include uninstalling things too.

Rules #5-6 only talk about "configuration" but as I understand the reports are supposed to go in the same section, so maybe add a question for those too.

I like that the configuration and structure top level items would be replaced by more specific sounding, audience centered items. Configuration and structure are very general terms and it isn't always obvious which one we can expect to find certain items in. For example, wouldn't the list of text formats or web services make just as much sense in "structure" as it does in "configuration"?

Is "appearance" just going to end up being the list of themes to choose from and links to their configuration like it is now? If so, maybe it doesn't really need its own top level menu item and it could go under site building. It seems strange to give a top level menu entry to a screen that only covers one thing and which is often only used once or twice in the whole development process.

rachel_norfolk’s picture

jmuzz - I highly recommend using ifrik's little form at #24 to see whether the rules we are trying to develop answer your queries.

If we do this right; core & contrib developers should find it easy to decide where menu items should be located and then the experience of all users, developers and administrators will be improved as everything will be consistent.

It's the rules that matter at this stage, not what the individual menu items are called. (but yes, we should work on that too - eventually!)

jmuzz’s picture

Oh I see, I was looking at the rules listed in #22 I didn't realize the form had a new version.

Whatever it ends up being called I still don't think the appearance item needs a top level menu entry unless you expect it to get some sub-items.

About that form... Once you answer the question that places the entry it says "Thanks, that's all" but it seems like you actually need to hit Submit one more time for the data to go through. If I'm right about that some users may not end up submitting the data thinking that it's already done when they are at the last step.

rkoller’s picture

Hi @yoroy send me over. Voiced a suggestion already a few month back, got a "little" hold back, but came up with it again along todays UX day. I think it might be a good complementary exercise helping to hone the structure and minimize the number of clicks for the user. I've suggested to create a top task survey for the admin menu ( if you don't know a good intro is over here: http://alistapart.com/article/what-really-matters-focusing-on-top-tasks ). To get an idea about what the top tasks are people try to accomplish in Drupals admin menu - which might add up well with the current results and efforts in this issue.
Basically a list of 80-100 tasks would have to be created, then a preferably as high as possible number of users from the beginner to the savvy, from content editor to site builder to developer has to choose their top 5 tasks. In the end you get a statistic about their most important tasks (the long neck), the important tasks in the body and the neglect able ones in the long tail (task not necessarily equals menu point) . So you can reorder and reemphasis so the most important tasks are reached with the lowest number of clicks. Might give valuable insights and feedback.
At a later point you can validate your final menu structure easily by performing a tree test with those top task on it. Just an idea. :)

yoroy’s picture

I think @ifrik has already been working on this, see comment #27. Would be interesting to hear if she received enough submissions there.

ifrik’s picture

Yes, I've started on this.
This issue has been moved to the Idea's queue so I'm waiting for that. At least's that how I understood the idea of the Ideas list.

jmuzz’s picture

They are 2 very different kinds of surveys. Finding out the top tasks for people could tell you which menu items may be worth making more prominent but to me it seems like overkill. Cisco makes those surveys to help them decide which features to spend the most time developing on which goes way beyond how their menus are organized.

ifrik’s picture

What we would like to do during DevDays in Seville:

ifrik’s picture

Looking at moving the Custom Block content, we realized that the current top-level "Content" page is actually not Content as such, but only "Content type" content while all other content (either in core, contrib or created as custom entity types) doesn't really have a good space to go there.
We therefore added an issue to create #2862859: Create a top level, extendable, "Content" admin menu route that behaves like "Structure"

ifrik’s picture

Update from DevDaysSeville,
rachel_norfolk and me discussed this with webchick further to see what needs to be done to take a decision on this.

ifrik’s picture

Issue tags: +DevDaysMilan, +DevDaysSeville
rachel_norfolk’s picture

BoF to be held at the #DrupalDevDays UX table Thursday 3pm.

ifrik’s picture

Possible first step: Changing the Content page into a regular menu item.

Detailed reasoning at #2862859: Create a top level, extendable, "Content" admin menu route that behaves like "Structure"

yoroy’s picture

A late recap of the sticky notes we created during one of the bofs at Drupalcon Vienna:

## Create and manage content

- View content
- Review content
- Inline editing
- Schedule content
- Create revisions
- Link to external media
- Publish
- Search content
- Content relations
- Layout content
- Update site content
- Translate content
- Optimise SEO
- Revert a revision
- Delete content
- View content in context
- Import/export content
- Manage revisoins
- Moderate content
- Edit media
- Choose layout template
- Upload media
- Manage menu
- Manage content structure

## Build structure and configure functionality

- Create entity types for information architecture
- Structure each entity type
- Define display options, globally
- Define display options, individually
- Create content curation(?) - views, lists, blocks
- Configure language options for translations
- Prepare site for themer/frontender
- Provide/improve user interface for other users
- Create roles
- Create permissions
- Access & read help/documentation
- Access reports
- Debugging

## Building functionality

- Build the business logic
- Build integrations
- Create layouts
- Build data structures
- Provide APIs
- Write documentation
- Define permissions
- Provide configuration options
- Create forms
- Define lists of components
- Migrate content
- Fix bugs
- Update code/features
- Deploy
- Define cache rules
- Extend functionalities

ifrik’s picture

As I already said in Vienna: I think these three catergories are falling short of the reality of dealing with content, dealing with users, sitebuilding, configuration for front end development, (configuration for) translation, and maintaining a production site.

I also don't see what the difference would be between "building functionality" and "building structure and configure functionality".

We have tried to develop a process for assigning admin pages to certain sections in the admin menu to make it predictable where they are placed by developers and found by users. An initial set of questions for that are proposed in #22.

As a next step, it would be good to have different people trying and placing a large number of core pages based on such a set of questions. If many different users place the pages in the same way then the questions work, if the same page shows up in different places then we need to tweak the questions further.

ifrik’s picture

I've set up a site to test whether having such questions work: http://form.ifrik.org

This is meant to test the current set of questions and admin sections, and can be changed if the results appear to be too widely spread.

nod_’s picture

Pehaps a subset of this topic is in the related issue?

AaronMcHale’s picture

ckrina’s picture

We're working on this again trying to find the best way to represent the mental model of site builders and give a holistic answer to the several admin menu related issues, and keep #3203618: New “content creation” menu proposal for content users as a goal.
This is happening as part of the #3364258: Improve administration navigation efforts, and we're conducting a Card Sorting test. We'll post the results here once ready.

ckrina’s picture

Title: Restructure the Admin interface » Restructure the admin interface Information Architecture
Issue tags: +Needs issue summary update

Renaming this issue to append "Information Architecture" in the title so it's more clear the goal of the issue, and adding the "Needs issue summary update" to reflect the last efforts happening around this like #3366986: Card Sorting survey.