Rethinking /admin

The plan is to solve the following problems:

• New installations provide a set of instructions on how to set up a site. But this disappears as soon as you put something on the front page.
• When users upload content, they frequently lose it
• When new things happen on the site (e.g. actions are triggered, comments get posted), users have to click all around the place to find out what has happened.
• There is very little distinction between a site builder and a site administrator.

Administrator or Site builder or Both

The admin interface has to be flexible. It is used by a wide range of users. For simplicity I want to isolate three different types of users here:

1. There are the expert Drupal developers who are involved in the construction of the site. These people see the welcome message instructions regularly and ignore them because they already know what to do.
2. There are the administrators of the final site, doing day to day activities such as creating content, moderating comments and forum posts, blocking IP addresses, etc. These people never see the welcome message because the site has already been created.
3. There are people who do both, but who are not expert developers. Drupal is not their day job, they just want to create a site for themselves. These are the people who read the welcome message instructions and use them as a guide.

The focus here is on improving the admin interface for users 2 and 3 without disrupting 1.

Flexibility

If we are to cater to the site administrators, the /admin section needs to be flexible. The site builder needs to be able to say what the final user can see, and what they can't see.

Drupal can already do this through the permission system. But there are problems with the implementation. The main issue, is that permission to view the administer menu for authenticated users is off by default. In its current implementation this is the correct behaviour, since the admin menu is not really built for a simple authenticated user (someone who can only create forum posts, as an extreme example). Instead, we give these people options on the /user section of the site. But this does not gracefully scale as new permissions are added. For example, on drupal.org I am a member of the docs team. That gives me the rights to edit most pages in the handbook. However, to keep track of new content we have to write a php script that displays a page of latest contributions (http://drupal.org/handbook/updates). In a sense this does a similar job to admin/content/node. But we can't provide access to it because permission to that page allows users to edit all content.

There is another issue too. For example, if access has been granted to see admin/content/node, but not to access the /admin pages you have to type in the url directly to see it. This is a potential security risk because it hides the fact that a user has been granted access to a page (you only know because of a checkbox) making mistakes more likely. It also forces site builders to create a link to it manually (unless they want to keep that page orphaned).

So what happens when you turn on permissions to access the administer pages? Well, it creates the top level menu items and shoves them in your menu even if those sections are empty for that user. So if you restrict all rights to items in the 'Site building' menu that menu section becomes empty, but the user still has a menu item in their navigation screen. For security reasons, it's a good idea to create a separate admin account for day to day operations which does not allow access to site construction tasks. You can't currently do this is a clean fashion.

In the reworked design, the default would be for all authenticated users to have access to /admin as default. If all you have permissions for are the forums, this still has something useful for you. In contrast, if you are user 1 you will have a whole load more options to play with. And access can be turned off completely, if the site builder decides they want to provide an alternate mechanism for their authenticated users.

Welcome screen instructions

The first screen a user sees after installing Drupal is a set of instructions explaining how to set up the site: choose a theme, choose some modules, add some content. One big problem is that it disappears as soon as content is promoted to the front page. Something you rely on shouldn't disappear.

And some users never see it at all. If you hire someone to build a site for you, only the dev shop will see these instructions. We still need to make it clear to them, how to make changes to their site.

The solution is to make the admin interface clear enough that you don't need the instructions.

Where's my content?

Our usability studies have shown that users lose content easily. If a role doesn't have permission to administer content, there are circumstances where there is actually no way of finding the content again, except for guessing the url. There are many ways for the site builder to create ways of finding content again (tracker, taxonomy pages, views, menu items), but there are still two issues. 1. There is no good default. 2. There's no central location to find this stuff.

The answer to the question, then, is always to go look at the admin dashboard. Site builders can break this answer if they wish and provide and alternative, but the aim is to make this the default.

Design vs flexibility

Currently /admin is one big menu all laid out on one page. From a usability standpoint this is actually a pretty good design. It allows users to scan for the exact content they want without doing a lot of clicking and page refreshes. In most cases this is not too overwhelming because we stick to under seven menu items per category. 'Site configuration' is the exception; it has become the big bin to put stuff in when we haven't worked out how to integrate them properly elsewhere in the UI. 'Logging and alerts' and 'Administration theme' are prime examples that don't really belong here. But there are issues elsewhere as well ('Post settings' under Content Management, for example). There is room to tidy things up here, and turn a sea of links into a lake at the very least.

One problem with a long list of links, is it very difficult to memorise the layout of the page and get fast at navigating. In a thread on dashboards, Amazon pointed out that the new Wordpress interface contains distinct navigation regions. The reason this is a good design is that it provides more context for memorising and recognising the separate admin areas. To get fast at using a screen this recognition part is really important because it gives you the opportunity to avoid re-reading stuff. For example, when I search for the Modules configuration menu item, I instantly know where 'Site building' is because it is always top right. The simple design choice of having two columns makes navigation faster because it gives us one extra dimension for memorising placement of something in space.

The advantage that Wordpress always has over us, however, is it specialises in blogs. That means the UI team can really spend time optimising the admin screens so that they fit the rather tightly defined design objectives. Drupal, on the other hand, has to fit many use cases as well as many different drupal themes. This makes our task a lot harder.

Still I think we can aid navigation by making each section more visually distinct. I'll leave specifics alone until we get down to specific designs at a later date. But that's one design goal.

Dashboard vs menu

The big problem with a simple menu is that it doesn't allow input or give feedback. It is simply a navigation system, pointing us to various places where we can do things elsewhere. I'm less concerned about input (though it is worth thinking about), but feedback is really important. In our current state, if any activity happens on the site that we need to know about we have to go looking for it. Comments are a prime example. Out of the box, there is no clear way to see when someone has posted a comment to our site. We have to look in admin/content/content and then admin/content/comment/approval. That's fine if you only need to check up on one thing, but that is rarely the case.

Another good example is update status which currently uses drupal_set_message() when it wants to inform you of out-of-date modules. These status messages are really designed to display feedback on your last operation. If we start adding persistent messages here, then this is going to muddy the status message waters.

So the aim is to allow modules to provide feedback to the admin screen, relevant to the user. This is the authenticated user's home page and when they arrive at it, it tells them what they need to know. In other words, we need to create a dashboard.

Again, flexibility is important. Nobody on drupal.org, for example, wants to be informed every time a comment is made. Also performance concerns need to be taken into account. So this should be completely configurable, probably integrate with Actions and it will require an API.

What about /user?

I've been considering where this dashboard stuff really belongs. Some menu items are user specific so in a sense they belong in the /user section. On the other hand, many admin roles are not user specific. One aim here is to give authenticated users a single place to go that they they can call home. Having /user and /admin breaks that idea.

Where a separation may make sense, is between site building and site administration. But I'm not convinced that is such a good idea either.

So I'm proposing that /user and /admin combine. Obviously we need a separate place for user profiles, but not every site even makes use of that. What I'd like to get rid of is this default almost-blank /user page when we login and provide users with a useful administration screen instead.

Going forward

The above is basically a brain dump of stuff I've been thinking about for the past six months or so. It is not, therefore, anywhere near a complete or detailed enough propal. I'm simply after feedback on the initial idea and suggestions. There are many perspectives to look at this from, if this is going to be well designed.

Let's sum up what I'm proposing so far:

• by default all authenticated users get access to some form of /admin
• modules can hook into /admin and provide feedback to the user (the dashboard)
• sections of /admin can be turned on and off through the permission system (we have this, but it needs cleaning up)
• editing your own account happens under /admin not /user

[editing to add... if anyone feels like including images in the comments of this thread, can you please link to them rather than imbed them. I've found they tend to dominate the discussion too much in other threads and also it blocks the intertubes with heavy page loads. Cheers! :)]