Redesign /admin

Do you see this in addition to the current categories, or instead of one of them?

Hmmm. Good ideas. For bonus points, it would be nice to do this in a way that would make the section headings more parallel with one another. Unfortunately, I don't have any immediate suggestions about how to do that.

Just found this, had started very early work on a patch but better to thrash it out here. I reckon we need at least one or two more headings as well, so we have less huge lists for people to scan down. I plan to split site configuration maybe, but haven't got to that yet.

Added a new section for "EXTENSIONS" which includes "stuff you can install", and another for "LANGUAGE TOOLS". Site layout can then link direct to theme settings pages instead with roughly the same structure as now for both - just top level items for the different tasks.

CONTENT MANAGEMENT:
* Books
* Comments
* Content
* URL aliases (?) (tricky)

SITE BUILDING:
* Contact form
* Content types (renamed)
* Feed aggregator
* Fields
* Forums
* Menu
* Taxonomy
* Triggers

LANGUAGE TOOLS:
* Content translation
* Interface translation

SITE LAYOUT:
Blocks
Theme settings (direct link to themes settings pages)

EXTENSIONS
* Modules
* Themes (direct to theme overview)
* Update status (as is, don't need to change anything)
* Maybe add "administration by module" here too.

REPORTS
* the same minus update status

USER MANAGEMENT
* the same but rename or remove Access rules

SITE CONFIGURATION (rename to SITE VARIABLES?? we use "customize and configure" in a lot of places which aren't necessarily related to this)
* All existing stuff
* Post settings
* RSS Publishing

+1! I like these suggestions - and I prefer catch's suggestion with more focused sections.

URL alias is tricky, but I don't think it relates to content per se.. A URL alias can be used for any kind of path, it's not directly tied to content. Even end users will experience this, where one might set up a URL alias pointing "login" to "user/login". I would keep it as it is, under Site building.

The rest looks fine, although the sections Language tools and Site layout do seem like overdoing the granularity. But thinking about it, it feels right to separate these from Site configuration and Site building - they need to be easily spotted by users. And language tools do deserve a section of their own in a multisite setup, where you'll probably have more than these two language related modules.

BTW. I recall a discussion on g.d.o/usability about this, but was unable to find it..

With language tools I figured most sites with the two core modules switched on may well have a contrib or more as well. I agree it's a bit arbitrary, but I couldn't think where else they'd go that'd both be suitable but allow them to be grouped together. Site layout might make sense for Panels to go into (although it has it's own top level section in D5). I personally quite like the idea of maybe 6-8 top level admin sections so theres less scanning of long lists to do.

Another issue to look at is site configuration - some stuff in there you generally set up once then forget about (file system, much of the stuff in site settings etc.) I seem to remember those being in one long form, then broken out for maybe D5... either way it'd be good to rationalise some of that a little considering so many commone tasks are hidden under tabs a level or two down from /admin at the moment.

re: site configuration - some stuff in there you generally set up once then forget about:

I was looking at the 'Site configuration' list and maybe it makes sense to rename "site configuration" to "system settings" ?
I like how the term 'system' focusses on the underlying Drupal configs instead of those for 'the website'. Of course these settings influence your site as well, but especially in multi-site environments it reminds you of the fact that these are system-wide settings.

I'd also prefer a few more and shorter lists. Now, where do all the contrib settings go? Normally it's the 'Site Configuration' list that gets really long. Should those become part of 'System Settings'? Or get their own? (I guess probably not)

We should probably look into a 3-column layout, with the last column 'rowspanning' the previous two, to accomodate for that 1 big list that accumulates module settings.

Definitely move 'site information' into site building. There was some discussion about moving mission etc. into a block/region rather than the unique handling it has now, but that underlines that those things should all be found in the one place.

Not sure about three columns unless we get a new admin theme which has sufficient space but less scrolling would be good.

What do the D6 featurelist, my handbook redesign mockup and the Mac OS X system preferences have in common?

Answer: the top-level sections are layed out in rows, not columns

This article is a nice breakdown of how full-width section-rows are good for quick and scannable organisation of 'content':
http://www.andyrutledge.com/bad-layout-conventions.php. This is what inspired my approach for the featurelist and handbookpage mockup.

Now, in this context I'm not suggesting to drop the sidebars, but I think the same concept might apply here:

With some css trickery you could make each section still contain just one unordered list, display each item at 33% or 50% width to suggest the columns.

What do you think?

That's a great idea!

I like it a lot, but just to be clear, you are suggesting that we not show the (sometimes not all that meaningful) descriptions? So this would be like the /admin page when someone has hit the "Hide descriptions" link? We could perhaps do the descriptions as mouseovers then?

Ooh, good reminder. Hiding the descriptions is the first thing I do on the admin page, I just forgot about them here. But there could still be an desciptive sentence between the section header and the link list.

Edit: Though ideally we wouldn't need them and I agree they aren't that helpful, certainly after you've become more familiar with the interface, then they are mostly clutter. Maybe a tooltip is enough?

yoroy: based on the UMN testing I'd say at least some of them are needed. Mentioning tags and classification under taxonomy for example.

Ouch, I even forgot there are descriptions for each item! ( I was thinking about just the one for each section, duh)

Hmmm, adding descriptions to each items in this setup would probably only work if initially hidden/as a tooltip. Showing it by default would make this kind of "li {display: inline}" listing impossible.

Catch: do you think a tooltip would suffice or are you suggesting a mode where these descriptions are shown by default?

Any reason we couldn't have a couple of divs inside the "li {display: inline;}"? Initially I'd probably want to keep the descriptions visible yeah - although it's not statistically valid etc. etc. generally people were looking at them during testing (even if they weren't finding what they wanted).

What about modules opening their own top-level category? At the moment I know three: Panels2, Übercart and devel, which introduces one for blindtext-content.

In the new concept this would not be allowed. But could be easy: contact the maintainers and give them a nice fitting category to reside in...

Here's a mockup with 1) full descriptions, 2) only section descriptions and 3) no descriptions. I really wonder if the extra information weighs up against the visual noise it generates. I feel nr. 1 is totally unscannable. Even with the section-descriptions only (2) the flow is broken. (Also, these admin section descriptions seem te add very little info in general). And I already edited a lot of the descriptions down to fewer words in this mockup, there's a lot of redundant wording in them

If the UMN testing also showed that collapsed fieldsets don't really hide anything because people will open them all, then why not get out of the user's way here as well and focus on better naming of the links and just let people quickly choose an option?

I know that for example 'Taxonomy' has already been discussed a lot, but it's just a rotten term for 'normal' people. I suspect that word alone could make a lot of people feel stupid. We should try and find words that don't need explanation. Even if that means that the 'dumbed down' word doesn't completely cover the functionality behind it. 'Categories and tags'.

Actually you're right. With the descriptions, people still hovered over every link and click on most of them, so maybe it's not such a big deal. Also mockups 2 and 3 look really nice :)

I feel like we're talking about a couple of different things now though - the categories themselves and the presentation of them. Could we split this into two issues maybe?

Yoroy: would you mind adding some color to the mockups or use stronger separating of the rows? Scannability of mockups both with and without descriptions dont get good marks m.E.

Also found one more module being a bad boy and adding its own Top-Level category: Workflow-ng

Comments on presentation (in lack of another issue, AFAIK):
Yoroy's mockups in #18 look really good, but like others have pointed out, scannability is a problem.

In comparison, the System Preferences dialog in OS X (see attached screenshot) holds up to 8 elements per row, making it easier to scan each section. With only 3 elements per row, your eyes would go zic-zac. However it may be difficult to have more elements per row, as it is much easier to work vertically than horizontally on the web. Icons does help scannability, although that's another issue (morten.dk's).

One comment: I and my users have always been confused by "Create Content" and instead (to this day) still look for a menu that has "Add {content type}" options...

RE: URL Alias

Do others find "URL Alias" usable? I personally know very well what URL means but most users may not. Any chance to consider "Manage Paths?" Note that the URL Alias admin path (in 5.x at least) is "admin/build/path"

A lot of participants in usability testing found 'Create content' confusing as well - in some cases thinking it was a form for building content types (although they didn't know what content type was at that stage either), rather than posting content.

How about "add content"?

Changing this to "add $content_type_name" would be a much bigger change, but worth exploring.

"Manage paths" might be worth considering compared to "URL aliases".

@Catch
-I've usually gone back in forth between "Publish content", and "Compose content". While "compose" is more accurate, "Publish" seems to be more effective.
-Manage paths is a bit vague -- URL alias isn't that bad -- as long as the user knows what an alias is.... "Path" on the otherhand can mean a lot of things, and isn't exactly a word that sticks out the same was as URL. Knowing what url means is pretty low bar for someone who's supposed to administrating site settings.
@yoroy
-I like version two in your mockup best. The sections need explanatory text, but I feel the pages under them should not, or else we need to rename them or split them up.
-I'd propose adding a new section "Content Settings", containg rss, default settings, maybe even content permissions. "Post settings" seems to mean "Content defaults".
-I feel that "add content type" deserves to be shown on '/admin' -- to important to hide under a local task. "content type settings" should be renamed to "mange content fields" or something along those lines. I feel both of these want to be in "content management".
-Comment management has always struck me as being close to admin/user than admin/content -- but i may be batsh#t crazy.

+1 for separating module settings into multiple categories. I've tried to re-work the large list of module settings menu items in admin_menu in the past (see #196772: Split module settings into sub-menus), and used "System settings" to group all Drupal core module settings and the package name of all modules to group contrib module settings.

Maybe we should stick (back?) to a hook_settings(), solely used for module settings (and system_settings_form()) that appear below "Site configuration". hook_settings() would not require an entry in hook_menu() and Drupal would automatically group all module settings by package, resp. "system settings" for core settings. If a module needs an advanced configuration (not relying on system_settings_form()), we should assume that such configurations are not "settings" per se, but rather configuration pages below "site building"...?

issue #137585: New admin/media section marked as duplicate. please review the request when solving this issue..

@yoroy - I'm really liking option 2 in post #18. The section titles are much easier to scan in this configuration. The present uneven columns throw off the scanability of the administrative interface as you're always looking for the start of a new section. The design is also more space efficient while providing short section descriptions for clarification. The links could still have tool tips if someone really wanted to know what a particular item was about.

yoroy's screenshots don't take account of the fact some users have help text enabled. This would make it very problematic once you add a paragraph of text for each link.

Bumping this to get some more thoughts. Catch makes good suggestions for new/renamed sections. It'll probably be very hard to get real consensus on these so keep in mind we should probably user-test any changes we make.

BioALIEN: We should not need a paragraph of text for each link, and even with descriptions disabled (I'd still prefer that) we can show them in the links title attribute.

I've made a little experiment with collapsing the sections, showing the links on :hovering the section title:
http://www.yoroy.com/elders/drupal/adminsections.mov

Wouldn't this be a perfect use-case for a card sort? (When ideas are there, that is).

Some thoughts about top-level categories:

Top-level is top-level and fixed
At the moment some greedy modules (panels2, übercart) create their own top-level categories. In the future an UI Guideline will hopefully forbid this

Clear names
As hard as it is, those must get better. As present, there are still duplicates and unneccessary verbal noise: "Content MANAGEMENT" "User MANAGEMENT" "SITE Building" "SITE Configuration" But also good work has been done for D6 with the introduction of "Reports". How about trying with single words for every section: Content - Users - Structure - Settings (Options, Configuration) and here you go.
(I am so silly. should've watched yoroys video before writing, because he found wonderful single words. While I think System is better than Settings, I prefer Structure over Website. On the rest we have a little surprising blind consensus.)

I think "manage path's" and "URL alias" are both problematic. Path is ambious, and alias is jargon. Combining the two into "Manage URL's" might work

re #21;

Apple has long been a gold standard for usability. kudos for surfacing that example.

note the word count: the OSX System Preferences pane covers at least as broad a spectrum of functions as Drupal's /admin page; yet the Apple components are referenced in ~40 words, total. there aren't any hovers, either.

on a scratch D6 site, the equivalent screen area shows 602 words (and no icons)
that's a 1500% verbosity factor! [and on sites with a generous set of contrib modules, the count can easily exceed 1,000 words.]

Apple invests heavily to distill and simplify verbiage as much as possible (great icons don't hurt, either!).
for most people, reading is a burden.

less is more. we're just scratching the surface so far.

proposals to follow.

Adrian
Adrian Russell-Falla

I'm thinking... what we need is support for icons in menu items.... and just let the theme decide when and where where to add those icons.

Its an intresting point of view, but looking at the current web applications - don't be scared to just use words. Facebook, is essentialy all about its information architecture, I think that as we work hard on labels we would be more in our domain. Where as Apple it's domain is completely diffrent, we'r unlikely to suddenly make such an emotional design shift. The count of words is a intresting metric, but I would like to point out that the meaning of words is far more important. Improving the meaning of words on our admin is going to be far more beneficial.

Here's a screencast that assembles some of this thinking - and a bit more.

http://groups.drupal.org/node/16903

Wow! NICE!

that is what i call nice...

+1 from me!

I know that this suggestion heads towards kitten killing, if included in this patch, but this is the best place I think to ask the question, and then split a new issue off if it seems worthwhile.

In parallel to defining a limited set of categories for the admin section, is it worth duplicating these for modules at admin/build/modules? At present it is a bit of a free-for-all with how a contrib module maintainer categorises their modules, and this can make it confusing as to where a recently downloaded module will show up in the module list.

I suggest restricting the categories to be broadly similar, if not the same as proposed here. This would then mean that if an admin wanted to add Forums to their Drupal installation, they could go to the "Content" section of admin/build/modules and enable Forums, and then navigate to the "Content" section of the admin page, and configure the Forums.

This also might help with #196772: Split module settings into sub-menus reference above, as it would then make sense for the modules to enable their settings pages at eg admin/content/forums, rather than again an open slather at admin/settings.

I hope this makes some sense, and I haven't completely mis-interpreted the intention of this redesign!

I'd like to call attention to yoroy's (perhaps) overlooked comment in #8: the "Administration theme" page doesn't need to be a page at all. It could easily be added to the main "Themes" page as fieldset or a tab.

This would also have the added benefit of clarifying the meaning of "System default" the admin theme drop-down box. Instead, it could read something like "Default (selected below)."

Yes, that's another page which could happily disappear.

+1 on catch's "Add content" instead of "Create content". Simply adding content may look less frightening than creating it.

I would definitely NOT change "URL aliases" to something containing "paths". We already have conflicts between code and UI terminology ('node types' versus 'content types') and saying paths when talking about aliases doesn't make them any less.

I am wondering, are we just refactoring the menu's structure in this issue or are we also doing something about /admin?

Anything in the long run which helps makes admin menu items easier to find is a good thing. I have users who always end up emailing asking for a direct URL for some setting because they can't find it.

I think seperating out "core Drupal" functions as mentioned above from contributed modules makes sense. On a moderately complex site the Site settings list can become quite large, and unusable unless you know what you're looking for.

Implemented yoroy's mockup

Screenshot: http://img.skitch.com/20090213-c2cu2r5r2sie4hk8g6qqahsj6d.jpg

also this makes the page longer.

dmitrig01, nice patch. i was able to apply it successfully and it really helps clean up the admin screen.

However, on a semi-related issue, are the top-level descriptions really needed? i.e. Content management - Manage your site's content. It seems like we're defining the word by using the word as part of the definition. I know it's been discussed above (and probably in many other issues) but I think the top-level might benefit from the less is more approach. Something along the lines of:

• Content
• Design (presentation? layout? templates? i need help here...basically, themes and blocks)
• Plugins (modules? extensions? behavior?)
• Settings
• Users
• Reports

I know modules can define their own top-level admin items. It might be useful to provide a "Drupal best practice" for doing so in order to keep things consistent.

That's not part of this issue, so please don't try to bring this in. we can tackle that in a separate issue.

Well, it's not really clearly defined what this issue should be changing and what not. There's a couple of things:

- Move some items to different sections
- Change the layout
- Don't show the descriptions per label
- Reword the labels for both section and item titles and descriptions.

If we make the patch for this issue only about changing the layout, that would be a first step but the favoured approach so far (number 2 in http://drupal.org/files/issues/d7-adminsections-02.png) also hides the descriptions per item. (Even when hidden, they still show up on hovering a link, the descriptions are added to each item's "title" attribute.)

So, I propose to make "hide each seperate item's description, just use the title attribute" part of this patch. Re-reading catch's comment in #19, I would even be in favour of removing the show/hide descriptions toggle link completely. (we could switch to using a

instead if a


then?)

Dmitrig01: I see you are hard coding the 1/3 width columns. By removing the item descriptions I think we should take the opportunity to allow for even more items next to each other on larger monitors. I'll look up the CSS I used, but basically I defined a width in % and a max-width in em for each item, something like:

li {
  float: left;
  width: 33%;
  max-width: 12em;
}

I know Bojhan would love to test these changes, it would be great to have at least the patch that does what I describe above.
Let's make rewording and moving stuff part of follow up issues and make this one about just changing the visual appearance.

To clarify, make the layout work like this (ignore the different wording for now :-)

Here's the CSS I used for this layout

div.admin-panel .description {
  width: 80%;
  float: left;
  margin: 0.75em 0 0.5em 0;
}

div.admin-panel h3 {
  float: left;
  width: 14%;
  margin: 0.5em 0 0 1em;
}

div.admin-panel .body {
  padding: 0; /* LTR */
  /*display: none;*/
}

div.admin-panel:hover .body {
  padding: 0; /* LTR */
  display: block;
}

div.admin-panel ul.menu {
  float: left;
  margin: 0.5em 0 0 15%;
  padding: 0;
}

div.admin-panel ul.menu li {
  float: left;
  width: 33%;
  max-width: 10em;
  padding: 0.125em 0.25em;
}

div.admin {
  padding-top: 0;
}

div.admin .left {
  float: left;
  width: 100%;
  margin-left: 0;
}
div.admin .right {
  float: left;
  width: 100%;
  margin-right: 0em;
}

Note: descriptions on does not currently look good. i am investigating.

By the way, descriptions next to titles also doesn't work in garland.

I'm retitling and repurposing issue. Discussion on admin categories can continue on #374490: Bikeshed: Re-work top-level admin categories

dmitrig01: Can you try the vertical allignment as in yoroy's picture?

@bojhan not sure i understand . if yuo're talkinga bout descriptions next to titles, i tried that and i couldn't get it working.

Everyone: Read http://groups.drupal.org/node/19171

/me is suggesting to postpone until #59 is in #374490: Bikeshed: Re-work top-level admin categories

Don't postpone this on a self-confessed bikeshed discussion please. I did my best to name the multiple issues this admin rework entails in #52. Changing the layout can be done independent of the actual amount of categories and the items within.

sorry, double post, see next…

Adding this to the bottom of Garland's style.css:

/*
 * Alternative layout for /admin (in Garland) *
 */

div.admin .left,
div.admin .right {
  float: left;
  width: 100%;
}

div.admin-panel {
  overflow: hidden;
  padding: 1em;
}

div.admin-panel h3 {
  width: 11em;
  float: left;
}

div.admin p.description {
  float: left;
  clear: right;
  margin: 0.25em 0 0.5em 0.5em;
}

div.admin ul {
  clear: left;
  float: left;
  margin-left: 14em;
}

div.admin li {
  float: left;
  width: 33%;
  max-width: 12em;
}

gives me this (in FF3 at least)

The order of the sections is messed up there. we'll want to remove the hardcoded 2 columns in the html output for this page to make that work.

Yeah, I removed it in the patch. but you're failing to notice two things: one, for some reason, the gradient is cut off, and two, sometimes there are 4 columns and sometimes two.

@alexanderpas we can work on the two issues at the same time. This issue just fixes the layout. the other issue reorders the menus.

How is the gradient cut off? Don't see what you mean there.

This seems to fix the sometimes 2, sometimes 4 items in a row (removed the float:left on .admin ul):

/*
 * Alternative layout for /admin (in Garland) *
 */

div.admin .left,
div.admin .right {
  float: left;
  width: 100%;
}

div.admin-panel {
  overflow: hidden;
  padding: 1em;
}

div.admin-panel h3 {
  width: 11em;
  float: left;
}

div.admin p.description {
  float: left;
  clear: right;
  margin: 0.25em 0 0.5em 0.5em;
}

div.admin ul {
  clear: left;
  margin-left: 14em;
}

div.admin li {
  float: left;
  width: 33%;
  max-width: 12em;
}

#53 is nice and clear, #63 less so (ugly bullets, entries divided over two lines). I guess this will be improved.

Question: will this be Garland only or Drupal system default? If the latter, will this introduce a minimum width? (Imagine a fixed width theme with two sidebars.)

@yoroy: as an admin I always hide the descriptions, so personally I applaud them going away, but I can see their usefulness for inexperienced users. In that light two disadvantages of "descriptions in title attributes" may be that they will disappear after 5 seconds (Firefox 3, IE6, more...? You'd have to do a mouse-out + mouse-over for them to re-appear) and that you can only see them one at a time, making comparisons more difficult.

Gaele, read catch's #19 above here. Even with descriptions on, during last years usability test people consistently 'brute-forced' their way through the interface by clicking almost every link anyway.

I have good hope that a good reworking of how the links are grouped in their sections with some rewording of the link texts themselves will be a bigger improvement then showing these descriptions.

Great Initiative.

As I am looking forward we soon have some kind of usability.drupal.org where we can vote on issues and proposed solutions, I give this some points to make it into the top 20.

remove graphic bullet, better alignment

/*
 * Alternative layout for /admin (in Garland) *
 */

div.admin .left,
div.admin .right {
  float: left;
  width: 100%;
}

div.admin-panel {
  overflow: hidden;
  padding: 1em;
}

div.admin-panel h3 {
  width: 11em;
  float: left;
}

div.admin p.description {
  float: left;
  clear: right;
  margin: 0.25em 0 0.5em 0.5em;
}

div.admin ul {
  clear: left;
  margin-left: 14em;
}

div.admin ul li {
  float: left;
  width: 33%;
  max-width: 12em;
  list-style: none;
  background: none;
  padding-left: 1.4em;
}

status…

I have good hope that a good reworking of how the links are grouped in their sections with some rewording of the link texts themselves will be a bigger improvement then showing these descriptions.

I agree.

However, I'd prefer keeping this as is for now, and put some effort in #220263: Generalize "Hide descriptions" link

See also Jeff Noyes mockup at http://www.jeffnoyes.com/?q=node/30

Why? "I prefer" doesn't count! :-)

The issue you refer to *adds* a feature and another "button" that shifts the burden of making a decision onto the user. Here, we're basically only redesigning for quicker access, hide clutter from the initial view (many descriptions really are full of redundant non-informative generalities) without actually removing them (still in title attributes).

Why? Because consistency is king.

Descriptions are not just used for admin page entries, but also for permissions, input fields, and perhaps in other places.

All of those descriptions are in the way for experienced users. That's what #220263: Generalize "Hide descriptions" link is for. To get rid of them completely, even from the title attributes. Perhaps "hide descriptions" should be the default.

I totally agree with you that many descriptions suck (Default time zone: "select the default time zone", Configurable time zones: "Enable or disable user-configurable time zones" ;-) However, in a title attribute they will still suck.

I'm willing to dedicate time to improve both labels and descriptions in core. (And I know you're good at these things too, yoroy ;-)

Identified at UB Usabilty Testing: http://www.drupalusability.org/node/109

subscribe

Subscribing.

subscribing.

this issue is stoped?

I'd say it is merged into this: http://www.d7ux.org/d7ux-information-architecture-a-detailed-view/
It is being worked on here #510110: IA : Configuration & Module
Note the new top level Categories:
Content - Structure - People - Appearance - Modules+Config

Marked as Duplicate of #510110: IA : Configuration & Module , even if this issue "only" adresses Config + Modules