Total Drupal administration revamp

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
sun's picture

This is actually very very closely related to Redesign /admin as well as Re-work top-level admin categories. I don't want to pollute both issues with the following findings. If you are interested in reworking Drupal's administrative structure and top-level categories, you want to read on.

[01:22] * tha_sun gathered awesome usability insights from a newbie Drupal user after lengthy discussions.
[01:22] * tha_sun will incorporate that knowledge in admin menu 3.x.
[01:24] <dmitrig01> tha_sun: that being?
[02:48] <tha_sun> dmitrig01: I made a fundamental mistake in admin menu
[02:48] <dmitrig01> tha_sun: yeah?
[02:49] <dmitrig01> tha_sun: what mistake
[02:49] <tha_sun> Technical people know what CRUD means
[02:49] <tha_sun> and how CRUD relates to Drupal modules and all the functionality Drupal provides
[02:50] <tha_sun> Regular users, however, focus on C and RUD
[02:50] <chx> tha_sun: meaning?
[02:50] <tha_sun> Drupal had "Create content" in a separate location in the Navigation menu
[02:51] <tha_sun> Admin menu moved that below "Content management"
[02:51] <dmitrig01> that's not fundamental, that can be easily fixed, no?
[02:51] <tha_sun> After discussing the administrative items with that newbie user who doesn't understand Drupal at all...
[02:53] <tha_sun> ...he came to the conclusion that most of the stuff below "Content management" and "Site building" could be summarized as "Manage content", resp. "Manage site"
[02:53] <tha_sun> So he either wants to create something new. Or manage something existing.
[02:53] <Michelle> tha_sun - I usually move create content to the top level of admin_menu. Awesome shortcut
[02:54] <tha_sun> He was confused that "Create content" lives below "Content management" in the administration menu
[02:55] <tha_sun> And he also did not see a difference between all the items below Content management and Site building. Both deal with managing your site's content or data.
[02:56] <tha_sun> While there are a few items below Site building, like "URL aliases", that are rather related to "Maintenance" of the site.
[02:58] <tha_sun> So, a trivial view on Drupal's administration is C + RUD + Maintenance (including logs and stuff) + Settings (mostly one-time)
[03:00] <tha_sun> That said, the C category would contain all content/data creation items, i.e. content, users, a new URL alias, categories, Panels page, View, etc.
[03:01] <tha_sun> While the RUD category would contain all items to manage that content/data
[03:03] <chx> you mean the UD
[03:03] <chx> R is read.
[03:03] <tha_sun> No, including all the "View all xyz"
[03:03] <tha_sun> Which is the basis for UD
[03:05] <tha_sun> So, our "node/add" path basically makes sense - but to make it really trivial, it would not be limited to nodes, i.e.: add/*
[03:06] <chx> tha_sun: you need to talk to yoroy ASAP
[03:06] <chx> tha_sun: there is a formal usability testing and soon
[03:06] <tha_sun> I think so, yes...
[03:07] * tha_sun marginally followed those "rework anything" issues
[03:08] <chx> webchick: ping. tha_sun had his relevation, found his calling and now preaches usability. you must hear this.

Lastly, on a side note, we (both) recognized that Content management » "Post settings" as well as "RSS publishing" are settings (one of both even having this term in the title), so they're 100% misplaced there.

Comments

Card-sort

sun's picture

And this is the resulting triviality in a picture.

"Create ..." and "Manage ..." actually refer to 2 separated top-level items. The first one for creating all available/possible stuff, the second for listing (and updating/deleting) existing stuff.

Daniel F. Kudwien
unleashed mind

Daniel F. Kudwien
netzstrategen

That's grokable!

Cliff's picture

As both a newbie and a usability evaluator, I follow this arrangement much better than the current one for a number of reasons:

  • Before I can manage content, I've got to create it.
  • You've used strong, succinct action words for the things I can do:
    • Create
    • Manage
    • Maintain
  • “Settings” is prominent, but not intrusive. So I know where to find it when I need it, but it doesn't compete with the more frequent tasks for attention.

What's the rationale behind the order of items in each column? Frequency of use? Order of use? Something else?

(In case anyone is wondering, to “grok” something means to quickly perceive its overall organization and the purpose of each element. Or something like that. One day, I should look it up.)

Best Categories I've Seen/Heard

quicksketch's picture

I agree, this is the most rational reorganization of top level categories I've seen yet. I'd be happy with "Manage" for the first item, since it's not really creating much. I'd like if the items for "Create content" were also listed on the admin page, then you'd have a page that would actually work to manage the entire site without the Navigation menu.

Ditto on create content section in admin

Brandonian's picture

While I'm sure there was a logical reason at some point for the placement of the 'node/add' pages outside the admin section, I've always had a problem with them being separated out.

sun, this looks great.

Basically, this proposal

sun's picture

Basically, this proposal outlines the logical reason (which might have been there) for separating them. However, I'd also be +1 for moving the entire "Create (content)" item below "admin" (which would equal to just dropping that entire item in the Navigation menu when following this proposal). Even on countless community sites, I never allowed users to access node/add directly anyway. That page is ugly by default, requires advanced developer knowledge to alter, and on top of that, it is one of the most challenging pages to style.

Daniel F. Kudwien
unleashed mind

Daniel F. Kudwien
netzstrategen

Create Manage Maintain ?????

alexanderpas's picture
  1. Create
  2. Manage
  3. Maintain
  4. ?????
  5. PROFIT!

sun, great work, it even works nice in URL's (except for maintain...)
create/story
manage/comments
settings/site

I would say...

webchick's picture

??? = "Configure" so that it matches the rest as a verb. Also, the items under the "Maintain" section look a lot more like "Monitor" to me, since it's basically just "keep an eye on how things are" rather than "perform actual actions based on that information."

A couple of things:
a) One thing we saw in testing at UMN is that despite how overwhelming the admin panel is, people "got" that they were to go to "Site building" first to set up some basic things. We lose that "hierarchy of importance" in this approach -- "Modules" which is tweaked dozens of times through the building of a site, is in the same area as "Time zone" which you touch exactly once.
b) There will be places (permissions for example) where there will be entries under one Create / Manage menu that are not in the other. I don't think this is particularly horrible, but just something to point out that could possibly be confusing.

I'm not opposed to this direction, but let's wait to hear what the UX team has to say (would like to hear input from merlinofchaos as well, who designed the current system). But regardless of what they say, I'd love for this to be backed up by some more hard data than one user's experience. Would be great if we could somehow test a variety of navigation approaches at the UB testing next week, but I'm not sure how feasible this is.

Thoughts and feelings

EclipseGc's picture

ok, so sun and I discussed this some in IRC and I want to reiterate what was said there, here.

I REALLY loathe the idea of having a "create" menu foisted upon me for things I'm already managing. If we take the example of views, or menus, or really anything I might have a "create" for as well as a "manage" being forced back into the create menu just to create a new view would drive me absolutely nuts.

The proposed solution to this was that local tasks still be allowed, however now we start having multiple-menu items going to essentially the same thing. Let's consider views for the moment.

I might have:

$item['create/view'] = array('stuff');

And this is a MENU_NORMAL_ITEM, but I also need this exact same screen now as a MENU_LOCAL_TASK, so my current option might be to do thus:

$item['manage/views/add'] = $item['create/view'];
$item['manage/views/add']['type'] = MENU_LOCAL_TASK;

Which is fine and dandy, but sort of weird. We discussed perhaps extending menus to have aliases pre-defined in the item. Perhaps like so?

$item['create/view'] = array(
  'page callback' => 'views_page_create',
  'type' => MENU_NORMAL_ITEM,
  'alias' => array(
    'path' => 'manage/views/add',
    'type' => MENU_LOCAL_TASK,
  ),
);

I'm sure there are all sorts of reasons from the menu people NOT to do this, of which I am completely unaware. This is not meant as a proposal so much as it is to draw attention to the idea that we might need some sort of mechanism for easily defining multiple menu items to the same page callback that's supported as the "right way" to do create links for any module needing to support that feature.

Personally I'd prefer to see such things completely self contained within "manage" but if we're bound to go this route, then we need a good alternative.

Eclipse

A more trivial option would

sun's picture

A more trivial option would probably be to just do

<?php
$item
['create/view'] = array(
 
'stuff'...,
);
$item['manage/views/add'] = array(
 
'redirect' => 'create/view',
);
?>

Not sure whether we're forgetting something trivial here though... (does the menu system already provide similar functionality?)

Daniel F. Kudwien
unleashed mind

Daniel F. Kudwien
netzstrategen

Congrats on seeing the light

yoroy's picture

Congrats on seeing the light folks! :-)
BTW, defining CRUD would help non-techies follow the discussion…

EclipseGc, please beware of "I like/hate" reasoning. Sun is reporting observed behaviour from a newbie. We are trying to improve Drupal for those beginners/intermediate users. Throwing in your own "over-experienced" perspective is not really helpful towards that specific objective.

Also, beware of talking solutions before we even clearly defined the problem! Card sorting is a good idea but it's absolutely necessary to have not only experieced drupalist do that sort.

Anyway, I'm really glad to see this discussion happening and I definately think this is heading towards improvements!

Yeah, I definitely agree in

EclipseGc's picture

Yeah, I definitely agree in general with both your statement here and the details of the card sort thus far, however just because we'd like to make drupal friendlier to the newbie/intermediate user doesn't mean we should sacrifice usability for the more proficient user. Furthermore, I'd be surprised if I was the only person who had a problem with separating out the create links from the manage links in such a manner that I was forced to use them when I was already in the middle of managing something. That's my only real issue here. Solve that and I'm very happy with the solution, and you've lost nothing in regards to what the card sort is telling you.

Can I be the only person who feels this way?

Eclipse

Core patch for usability testing

sun's picture

I will try to provide a patch for Drupal core this week, which just changes the top-level items as proposed here. I'm not sure whether I will be able to alter the entire functionality though, because that would probably result in a 400 KB patch or so... Would that be useful for the usability testing next week?

I probably should roll this against a certain unstable release, so it will definitely apply. Gotta have to ask webchick whether she can tag a new one (dunno when the last one was).

Also, there is one important note I missed to point out: My newbie Drupal user only knows Drupal's administration interface with Administration menu module enabled. Without administration menu, I think he would not have understood Drupal's administrative functionality at all. So the next best question would be whether there is a chance that you could also perform usability tests with Administration menu module enabled...?

Daniel F. Kudwien
unleashed mind

Daniel F. Kudwien
netzstrategen

Great post!

elv's picture

And very interesting food for though. It has made me think hard about the current state of the admin. But I'm not sold on this new idea yet.

I've always thought the 'Create content' menu item was misplaced too, but I had a different reasoning.
It seems to me there are two kinds of content types: 'timely', like stories, and 'timeless', pages, book pages.
Timely contents are created then seldom modified, so the faster you can create one the better. In this case the Create content link at the top level is adequate.
The problem arises when you 'manage' the timeless content. Typical case, the marketing section with your services and products description needs an overhaul. Your existing timeless contents will probably be edited multiple times, while new ones will probably be added. Then you have to constantly switch between two totally different sections on two different levels of the navigation menu: 'Create content' and 'Administer/content'. And this seems to me like a really counter-intuitive workflow because in this case C and UD are tied.

So I've always thought it would be good to group all the CRUD functions. The basic idea would be the Administer/Content page with added links or button at the top to create new contents, which would become the one and only place to 'manage' content. C + RUD on a single page.
I may be wrong, but I believe a 'master' page like this would be a good substitute for the classical hierarchy/tree people are used to and confused not to find in Drupal. Add an 'is in menu: ' filter and you have an easy way to display only the few nodes you need to work on.

I'm also not sold on grouping all he creation pages in the same menu. To me menus, blocks, users, are not 'content' the way content editors (non admin, not webmaster) would think. I think 'content' is something they can write by themselves (like nodes), it's usually what visitors are looking for. A content is a piece of text/image/video they can display somewhere in a site/structure.
Menus are not really contents, they are actually used to create the site's structure. Besides, editors should use the menu settings in node/add/... as it's probably more friendly than the menus admin.
Blocks are yet another breed. They can contain content by the above definition, but even then you still need to enable and place them, and unlike with the menu settings this can't be done on the creation page.
Grouping all these items would lead to a lot of confusion, me thinks.

Screenshots of it in action

webchick's picture

Drupal head:
Only local images are allowed.

  • Flush all caches
  • Run cron
  • Run updates
  • Disable developer modules
  • Drupal.org

Create:
Only local images are allowed.

  • Add URL alias
  • Add block
  • Add category
  • Add content type
  • Add feed
  • Add forum
  • Add forum container
  • Add menu
  • Add user
  • Add vocabulary
  • Create content
  • Import OPML

Manage:
Only local images are allowed.

  • Blocks
  • Books
  • Comments
  • Contact Form
  • Content
  • Content types
  • Feed aggregator
  • Forums
  • Menus
  • Profiles
  • Taxonomy
  • Translate interface
  • Triggers
  • Users

Maintain:
Only local images are allowed.

  • Recent log entries
  • Recent hits
  • Testing
  • Top 'access denied' errors
  • Top 'page not found' errors
  • Top referrers
  • Top search phrases
  • URL aliases
  • Updates
  • Top pages
  • Top visitors
  • Status report

Configure:
Only local images are allowed.

  • By module
  • Actions
  • Aggregator
  • Blog API
  • Book
  • Clean URLs
  • Contact
  • Date and time
  • File system
  • File uploads
  • Forum
  • IP address blocking
  • Image toolkit
  • Languages
  • Logging, errors, and alerts
  • Menu
  • Modules
  • Performance
  • Post settings
  • RSS publishing
  • Search settings
  • Site information
  • Site maintenance
  • Statistics
  • Text formats
  • Themes
  • User settings

Help (nothing below)

Observations...

webchick's picture

The "Create" menu is a huge mess.
a) It seems almost ordered in reverse order of how often I normally create each of those things.
b) The things most people actually want to create such as "Blog entry" and "Forum topic" and "Article" are buried in a sub-menu rather than on top.
c) Wtf @ Import OPML? :)

I'm not a fan. I actually think this is more confusing because it puts obscure things like URL Aliases at the same level (or actually, higher than) things such as the actual content on the site. But even if this order were reversed it still presents a usability issue. There's no separation between my 'day-to-day' creation tasks and my "once in awhile" tasks. -1 (more like -10).

The "Manage" menu, however, I like quite a bit. You see right in front of you all the "thingies" you have to deal with. IMO, We should simply make sure each of these things has a consistent way to "Add a $thingy" that's contextually relevant from its management panel. That would solve a lot right there, I think.

Maintain looks like a hodge-podge.
a) Why is URL Aliases under here and not Manage?
b) I think it would clean things up a lot if all of the log-related stuff was under "Reports" or similar.
c) IMO Modules and Themes belong under here. Or somewhere other than where they are currently, at least, because....

Configure:
a) Similar problem to Create, the stuff I am going to interact with on every site I ever build (Modules and probably also themes) are buried under here at the same level as "Post settings" which I don't think I've ever touched in my life. -100 to that.
b) Get rid of "By module" probably.
c) Why are things like "Book" and "Forum" here? Their settings pages should be accessible under "Manage"

Help:
How come help doesn't expand to anything? Will it eventually in the future?

Agreed. We need to separate

Xano's picture

Agreed. We need to separate the creation (addition) of content and the creation of system... thingies, especially since creating content hasn't got anything to do with administration.

I think the ultimate question is... do we want to sort menu items by task or by subject? If we sort by task, creating vocabularies and terms is done in a completely different place than configuring general Taxonomy settings. If we sort by subject, those three things are grouped together. If we don't figure this out, it's useless to start looking at the i's, let alone dot them.

...

sun's picture

Create:
a) Hrm. No, only "Add URL alias" is at the top. Don't know why. The rest is alphabetical. No difference to current menu ordering. No customizations here.
b) That's still admin_menu's functionality ;) I could move those node/add/* items for demonstration purposes though.
c) ...is what I thought, too. Not invented here.

Manage:
Agreed. This is basically, what EclipseGc meant above.

Maintain:
a) Could be moved back below Manage, but was identified as "only needed it something goes wrong" (having Pathauto installed). On that note, "Comments" serves probably the same purpose: maintaining your site.
b) ...is what I thought, too. Search + Statistics modules are guilty here. Has always been that way and is totally weird.
c) Disagree here. You are a developer. You change your modules and themes weekly, sure. Regular users do not. Modules and Themes are a fundamental part of your Drupal site. They are like settings: one-time operations. If you grant your fresh Drupal user the 'administer site configuration' permission, he suddenly gets "Modules" and "Themes" in between of "Blocks" and "Menus". This is scary - which of those pages are safe for him to play around without completely breaking the site? Moving them somewhere else (something new) would be an option though.

Configure:
a) See Maintain's c) above. "Post settings" is a one-time configuration setting. It's completely misplaced below admin/content where it lives today.
b) Possible... (please note that this is probably rather an admin_menu issue)
c) Disagree here. Those provide settings. The entire idea is to separate Createable/Manageable content from one-time settings. If those belong back to Manage, why not Actions (to Triggers), Clean URLs (to URL aliases), Languages (to Translation interface), etc.? Where do you search for module settings when you want to configure a setting?

d) One thing I'd really like (and which I had working for admin_menu in D5) is to move all system settings below a admin/settings/system (grouping) menu item. That would reduce the clutter here.

Help:
Did not expand since D5. Maybe/hopefully the new help system patch will allow to expand something there (but not too much).

Daniel F. Kudwien
unleashed mind

Daniel F. Kudwien
netzstrategen

Couple clarifications...

webchick's picture

I think it came across that I think Post settings should be moved to somewhere more obvious. This is definitely NOT the case. Let me attempt to illustrate what I'm after this with a "click heat map" of sorts:

Only local images are allowed.

This would be my ideal use of this menu:

  1. Users click "Create" dozens of times per day to fill the site with content.
  2. Users click "Manage" maybe once or twice per day to moderate content or similar.
  3. Users click "Maintain" maybe once a week to keep an eye on things.
  4. Users hardly ever click "Configure" except for the first time they install a new module.
  5. Users almost never click "Help" because our screens are so user-friendly they don't need it. ;)

Therefore, what I'm trying to say is that menu items should thus be arranged appropriate to this use. You click on "Modules" and "Themes" way more often than you click on "Post settings." Yet, you certainly don't mess with them once a day (at least once the site is built). So therefore, they're best placed under "Maintain" which is where I go for my "once a week or so" thing (I probably want to check my modules to see if they're up to date, etc.) Please, by all means, bury "Post settings." But maintain the "click priority" for the other items.

Create what?

elv's picture

They probably create lots of content (nodes) but need new blocks or menus far less often.
IMHO node creation should not be buried under a "Create content" submenu.
I like the way SimpleMenu works (sorry for the mix of english and french):
Only local images are allowed.

But managing the nodes is still too buried for my taste:
Only local images are allowed.

Yeah it's the other admin menu module, I know... and Admin_menu is for admins.

This proposal follows the

sun's picture

This proposal follows the paradigm that it is not important how often you create things, but instead it is important that you want to create something. This is the very first decision you take for your task at hand: Create something new or edit something existing.

Daniel F. Kudwien
unleashed mind

Daniel F. Kudwien
netzstrategen

I understand

elv's picture

And I mostly agree. But I'm still wondering if the C + RUD paradigm is a legacy of computer use, and if makes sense in a CMS.

On a computer in almost any app you can create a document (File->New...) but it offers no way to manage the files you created, because it's a job for the Finder or Windows. Apps are C, the OS is RUD.
Even outside of the OS/apps world, I can see this separation. Like in Google Docs, where the whole interface is essentially a management interface, with a "Create" menu at the top left.

In both cases it's more like a RUD + C interface, you browse/manage first, then can create. So I guess like Quicksketch I'd put Manage before Create, but it's not the important point.

What really puzzles me is why in Drupal has the management/browsing part always been buried deeper in submenus than the create part? It certainly makes sense to have a shortcut to create content from anywhere! But I think people would be more comfortable if they could easily view their contents, I mean not browse them page by page in the frontend theme, I mean viewing lists of contents ala administer/content. With a bit more love, it could be the landing page for users/editors. This page is like the Finder/Windows, the Create content menu is like the apps, and everything else is like the control panels/system preferences.

Only local images are allowed.

It may be legacy, true.

Senpai's picture

On a computer in almost any app you can create a document (File->New...) but it offers no way to manage the files you created, because it's a job for the Finder or Windows. Apps are C, the OS is RUD.

It may be true that this is simply a holdover from the early days, and needs to be gotten rid of, yes. However, if that's true, what's is an application's File > Open menu used for? :)


______
Senpai


Joel Farris | my 'certified to rock' score
Transparatech
http://transparatech.com
619.717.2805

Would it be an idea to place

skilip's picture

Would it be an idea to place post setting under the per-content-type configuration form? I never got it in the first place why these settings are global instead of per content-type.

AFAIK this has already been

Xano's picture

AFAIK this has already been done :) Sometimes, wishes do come true :P

Good but…

David Latapie's picture

Hi,

  • I like the decreasing use. Very pleasant! Achievable? Dunno
  • I find “Manage”, “Maintain” and “Configure” too close in their meaning. After a while, I i understood, but I am a Drupal user, so I'm biased. I have nothing better to propose, though.

A word of caution

Senpai's picture

Webchick sez:

There's no separation between my 'day-to-day' creation tasks and my "once in awhile" tasks. -1 (more like -10).

This line of thinking is dangerous, because it presumes that you know the intimate bits of the software, and as a power user, you know how much of what type of activity you will be doing. It's also this line of reasoning that might have caused Microsoft Word to end up with 'crippled' menus that hide those bits "users shouldn't have to see". Just a word of caution. :)

Why is URL Aliases under here and not Manage?

I think that most people would view an alias at the same level as the actual peice of content that it represents. On a Mac computer's desktop, there' really no distinction between a file and an alias of that file, save for the slightly different looking icon. Why can't we view URL aliases as being at the same level as their content counterparts?
______
Senpai


Joel Farris | my 'certified to rock' score
Transparatech
http://transparatech.com
619.717.2805

admin

sun's picture

This is the regular view on this stuff and why it also affects the "Redesign /admin" issue:

Daniel F. Kudwien
unleashed mind

Daniel F. Kudwien
netzstrategen

I feel like this screen is

Nick Lewis's picture

I feel like this screen is nothing more than a sitemap of admin functions. To think that "/admin" should be a coherent entry point to all things administrivia is like thinking that a sitemap should be a coherent entry point to a content rich site. How big will this page get? Depends on the site...

Overall, I think this page wants to be an entry point to commonly needed pages, or the starting point for a drill down, but even before the proposed changes it IS information overload.

And god bless yall, these proposed improvements kick ass.

"We are all worms. But I believe that I am a glow-worm." - Winston Churchill
work: http://www.entermedianow.com
blog: http://www.nicklewis.org


"We are all worms. But I believe that I am a glow-worm." - Winston Churchill
work: http://www.chapterthree.com
blog: http://www.nicklewis.org

Some cardsorting results

beeradb's picture

I had two friends with no previous Drupal experience complete the optimalsort set up by dmitri in http://drupal.org/node/374490#comment-1258436. Just to add to the discussion here I thought I'd post the results.

This guy is a developer:
http://skitch.com/beeradb/br6nw/drupal-admin-cardsort

And this is a small business owner who is not a developer, but administers her web site:
http://skitch.com/beeradb/br6dy/cardsorting

It's quite interesting how different the two are. Anyway, just thought I'd add the perspective of a couple more newbies to the discussion

Wow

elv's picture

Interesting! Especially the second card sorting. What does Content do in Content settings? I think it's name is misleading, renaming it to "Manage content" or "Edit content" or pretty much anything else would be an improvement.

I think you can take the

beeradb's picture

I think you can take the labels with a grain of salt :)

Honestly I'm not a big fan of the second cardsorting. I think the first one is pretty close though.

Card sorting

dwees's picture

What if we produced a default card sort for users, but then made it much, much, much easier to move items between the different menus? The ability to edit menus got better in D6 but the ability to move items between menus still sucks.

See http://jqueryui.com/demos/sortable/#connect-lists for a rough example of what I mean.

That's exactly what I am

skilip's picture

That's exactly what I am dreaming of since the first time I've laid my hands on a CMS. I've However you do not want that on each page load. Perhaps only on admin/menu?
[offtopic]Blocks should also be draggable ;)[/offtopic]

Yeah, I would only load this

dwees's picture

Yeah, I would only load this on the admin page, and it's meant for administering the Admin menu. We create a default structure that our usability teams decide is appropriate, and then let people customize the menu, where the menu items should go in the blocks using a drag and drop structure.

Dave

I would definately keep all

skilip's picture

I would definately keep all user related stuff under an user section. This is such specific stuf. It would be confusing to put 'create user' and 'permissions' under top level 'create' and another section 'users' under 'maitain''.

Yeah, ok... A lot of this

EclipseGc's picture

Yeah, ok... A lot of this stuff is exactly what I had such a big problem with when I got involved in the conversation to begin with. Create block, or alias is entirely unrelated in EVERY way to "create blog" with the principle exception that they both have the word "create" in them. They require different permission levels, and overall they dilute the user interface and experience. These are clearly managerial "creates" and as such should be placed under the manage tab. It doesn't sound like I have to harp on that at this point so, I'll keep moving.

The next major problem here is that I think we have two schools of thought. One is "Lets organize the actions by type." the other is "Let's organize these actions by how often they're used.". Both are valid... and probably incompatible. We should probably organize another cardsort in the manner that Webchick suggested i.e. how often things are clicked on. Though, if we already have heat mapping results from previous usability tests, this might give us at least some first level insight into how we might better sort things. I tend to think we'd need results that included whether the users did anything on the page they went to (i.e. did it serve the purpose the user was looking for). A few iterations of this might be VERY interesting... and of course probably costly as well. So at the end of they day I say we organize another card sort. It may inform us in areas we simply can't make easy assumptions about when we're trying to pin a text label on something "Are we managing this? or are we maintaining it?..."

I'm also a little concerned about sub-sections. Things like users, permissions, roles, user settings... I could see these ending up in a number of places, and I think they're already well organized under the Manage Users section, which I think is probably a very successfully organized section already. I'm not saying there couldn't be improvement, I'm just saying I'm not sure what it would be. I like some of the ideas of placing components of it into security, but again we break up what I would think is a fairly successful section. I only bring this up to point out that we have some organization that is already good, and perhaps we should evaluate what we think is good before we decimate it for something new.

I had intended on doing my own version of this shortly after szeged, but time constraints have been difficult this year. I had intended on trying to build essentially 3 levels of navigation.

1.) Create Content
2.) Stuff I use all the freaking time (content, blocks, modules, menus, frankly most of site building)
3.) Everything else with logical sub sections, maybe organized by module (there are obviously some issues here with certain core menu items)

I'm not sure it needs to be broken down further as the "by module" approach eliminates a lot of confusion very quickly. (again, with the exception of certain core items) And in fact the by module approach (currently) almost always reveals menu items I can't find elsewhere, making it often more usable and useful.

That's my $0.02 I could probably talk on this topic all day, but I won't. :-D

Eclipse

I like it a lot

elv's picture

Heh, let's be bold and crazy!
Editors don't administer (and the admin menu scares them). Admins don't edit. Why not two menus then?
That way actions are organized by type and how often they're used :)

Only local images are allowed.

Oh by the way, shouldn't Help be outside of Administer?

Edit: yoroy pointed me to this issue http://drupal.org/node/273137 "Split Navigation to User and Administration menu"

Similar system, only its

Nick Lewis's picture

Similar system, only its role specific, not drupal specific. This pub is run by a bunch of non-techies (think middle aged moms). I confess I didn't put a lot of thought into it, but it didn't require a help manual. It doesn't *do* nested menus, instead headings are used to divide the links. This is absolutely all the top dog at the publication needs: content manager, user manager, and then regular "new" content links.

---------------
"We are all worms. But I believe that I am a glow-worm." - Winston Churchill
work: http://www.entermedianow.com
blog: http://www.nicklewis.org


"We are all worms. But I believe that I am a glow-worm." - Winston Churchill
work: http://www.chapterthree.com
blog: http://www.nicklewis.org

Short-form

sun's picture

This would equal moving the (currently proposed) top-level admin categories just one level up:

  • My account
  • Create
  • Manage (if user has access to maintain anything)
  • Maintain (ditto)
  • Configure (ditto)

I'll look whether I can hack the demo site so we could get a look & feel of this.

Daniel F. Kudwien
unleashed mind

Daniel F. Kudwien
netzstrategen

I think the top level

Nick Lewis's picture

I think the top level "/admin" is just a site map of admin pages anyways. Removing it from the flow = one less click to get somewhere useful, and prevents people from getting overwhelmed the first time they click "administer". We should keep the page but, but consider moving it somewhere else, and naming it "Administration Index", or something... [ not sure it has a good name ].


"We are all worms. But I believe that I am a glow-worm." - Winston Churchill
work: http://www.entermedianow.com
blog: http://www.nicklewis.org


"We are all worms. But I believe that I am a glow-worm." - Winston Churchill
work: http://www.chapterthree.com
blog: http://www.nicklewis.org

Yes!

gaele's picture

Editors don't administer (and the admin menu scares them). Admins don't edit.

Right. Two different roles, two different sets of tasks. An editor is not interested in setting up the site or monitoring whether modules are up-to-date.

Perhaps most people are okay with the current reports and user management sections because they correspond to two separate roles as well? (sysadmin and user manager)

Admins edit.

sun's picture

Editors don't administer (and the admin menu scares them). Admins don't edit.

I strongly disagree. As an admin, I probably edit much more than any other user. There might only be exceptions the other way around. However, that does not mean an admin could not just "see more". Also, see my other reply below.

Daniel F. Kudwien
unleashed mind

Daniel F. Kudwien
netzstrategen

As an admin, I probably edit

gaele's picture

As an admin, I probably edit much more than any other user.

I would rephrase this:

As a person with admin rights, I probably edit much more than any other user.

Think in terms of roles, not persons.

Heh, let's be bold and

matthew.lutze's picture

Heh, let's be bold and crazy!
Editors don't administer (and the admin menu scares them). Admins don't edit. Why not two menus then?
That way actions are organized by type and how often they're used :)

This is why /admin/user/permissions and /admin/build/menu exist. The problem we're going to run into trying to create editor profiles and admin profiles is that many users, just like now, will want different levels of access for their editors and their admins. What it sounds like you're really asking for is two more pre-configured roles to stack with "Anonymous User" and "Authenticated User": "Editor" and "Administrator".

At which point, we should also discuss the need for "Contributor" or "Blogger" for site owners who want to allow authenticated commenting but have a blogger less privileged than editors, as well as "Power Contrib" for media contributions or bloggers with more permissions than blogger but less than editor.

In the end, it takes under five minutes to create a menu for editors, with links to creating contents they need and maybe one to the /admin/content/node page. Then it takes 30 seconds to enable it for the editor role only in the blocks menu.

Plus, with permissions (which would need to be customized anyways) a custom admin theme would only show the proper stuff to an "Editor" or which ever role.

Is this really a wheel we need to reinvent?

No, Contributor or Blogger

elv's picture

No, Contributor or Blogger are roles in the Drupal sense. What I'd like is to split the admin into two main tasks.
Bloggers and contributors still just edit, meaning they enter contents/create nodes/publish articles.
They fill the box, while admins tweak the box itself. Think driver vs mechanic, when you drive you don't need the tools in sight and can keep them hidden in the trunk.
As website builders we can have both hats, but not simultaneously.

It's not about use-cases, but Usability. ;)

sun's picture

See gaele's post above - whether you assign this or that permission to your administrative users or not, does not count.

What counts is that all possible use-case and role combinations get an initial idea of what they can do in Drupal.

Given all those use-cases and distinction examples of users and administrators, here is the type of user that breaks your layout: "Moderator."

Drupal's administration interface is not about roles, but rather about permissions. Likewise, it's not about use-cases, but about allowing all kind of users to do certain stuff. Limiting Drupal's interface to a certain "default" use-case does not account for its capability to build any kind of site.

Daniel F. Kudwien
unleashed mind

Daniel F. Kudwien
netzstrategen

elv said it better than me.

gaele's picture

elv said it better than me. A moderator, just like an editor, has a "driver" hat.

Permissions

Boris Mann's picture

Think about it with permissions. Can the "admin" screen be a constant dashboard, that even people with only create content have access to?

For (2) -- I use those things when I'm building a site. Then I only manage and create.

Can the "admin" screen be a

Nick Lewis's picture

Can the "admin" screen be a constant dashboard, that even people with only create content have access to?

Absolutely, so long as we renamed it dashboard


"We are all worms. But I believe that I am a glow-worm." - Winston Churchill
work: http://www.entermedianow.com
blog: http://www.nicklewis.org


"We are all worms. But I believe that I am a glow-worm." - Winston Churchill
work: http://www.chapterthree.com
blog: http://www.nicklewis.org

Also...

Boris Mann's picture

...it should be red. And store bikes :P

Context

RobLoach's picture

I think what we're missing with this system is context. If we're looking at a list of Photos, we don't care about adding a Blog Post. All we care about is adding another photo. Drupal isn't made for newbies, it's made for people who know and understand this context and can tell the website how the context lies (ie put the "Add Photos" link in the "Photos" listing page).

Good call

sun's picture

...but scope creep for the issue at hand ;)

See EclipseGc's proposal for redirecting/cross-linking local tasks (tabs) above. That might be a starting ground for providing context on other pages as well.

Let's focus on the task at hand first, ok? :P

Daniel F. Kudwien
unleashed mind

Daniel F. Kudwien
netzstrategen

Focus

skilip's picture

If we want this to be a success we need to focus on what we want to achieve. AFAIK we want to make administration and building D sites more intuitive, especially for new D users. So we need to ask ourselves this: 'What do you want if you just installed Drupal'. People install D because they want to build a website. So the first thing users do after installation, is looking for where to create content, create menu-items, add some blocks and maybe enable some extra modules. Other stuff, like site configuration, user permissions and so one, are too overwhelming for the first time. Users will only delve into that when they need it. (this is my personal experience, as well as what I've learned from costumers, but I guess the results of the usability tests back me up).

How about this:
Admin

  • Account
  • Content
    • Create
    • Administer
  • Menus
  • Blocks
  • Modules
  • Settings
  • Users
  • Logs
  • Help

Removing the top level 'Administration' menu item is definitely a good idea!

Having a menu-item for each content type is not a good idea. You'd get too much menu-items. This would result in lack of scannability. We need to keep the top-level menu as short as possible!

Most important: we need to keep it simple and intuitive!

Wrong direction.

sun's picture

Sorry, but there's no difference in your proposal to what we have now. Instead, it adds confusion, because users have to understand the meaning of the additional items (like Menus/Blocks), which are not top-level categories, but point to certain functionality already. Additionally, contrib modules will likely add more items to the top-level.

Also, a big -1000 to "Modules". That's the opposite of the entire idea here. Modules can be anything. They can provide functionality for creating/managing content or provide something else. They also provide settings, so you have to search in Modules and Settings to find where a module placed its settings. Where do you search for creating or managing "xyz" ? Will it be in Content > Create, or Menus > Add, or Blocks > Add, or Modules > Foo > Add, or Users > User > Add ? Now, rephrase the question for the case where you want to edit/delete something existing.

Daniel F. Kudwien
unleashed mind

Daniel F. Kudwien
netzstrategen

First time for disagreeing

skilip's picture

First time for disagreeing with you sun ;).

I admit it could cause confusion, but confusion is not something we need to avoid when discussing hot stuff like this. We'd better think about all possible aspects and possibilities. My approach, though wild, isn't out of the wild. It's because my customers ask me for this all the time. Let me rephrase:

If a user installs D he/she wants to build a website, so 'Content', 'Modules', 'Block' and 'Menu' will be terms which the user searches for first. These terms are really straightforward and speak for themselves. How can that be confusing? I really don't care if putting those menu items top-level doesn't fit into CRUD philosophy, we're talking usability here.

For module related configuration pages, that's merely a lack of the current module system. These module specific configuration-, permission- and help pages should be accessible from the module page, in context. Adding this feature to the module page would reduce the number of current administration menu-items largely.

Another argument for putting 'Modules' top-level: We're talking about how D looks like after you just installed it. At that point you're admin and you will most likely want to install additional modules. After the site is built, and user roles are created, non-privileged users won't have access to 'Modules' , so it won't be present at all. (the same for blocks and menus).

Putting 'Create content' and 'Manage content' under top-level item 'Content' would simultaneously solve the issue Where did my content go.

Oh, not to forget; themes should reside under 'configuration'. You're not building something, you're configuring your website.

A few thoughts. If we were

matthew.lutze's picture

A few thoughts.

If we were to go forward with this, we'd need a better way to identify configuration pages for modules as separate from standard site pages. As it sits, making '.../modules' easier to get to/use moves the confusion back to how to find and manipulate the settings for the modules a user enables.

Also, as theming is a site configuration, so too really is module installation. Most site builders, I would wager, change their modules (once they're happy with configuration) maybe only a little more than they change how the site works. Just as a site header or title is set once it's configured, or your theme example. Especially for the "I want a blog" site builders, theming may arguably be more manipulated than modules. So modules should reside under 'configuration' too.

We may need working definitions of 'build' and 'configure' to have a meaningful discourse alone this thread... there's a lot of functional overlap in the two concepts.

Keep on trying

eigentor's picture

After a not-so-short discussion with Sun yesterday, a bit of fiddling with his demo (Sun: could you post the link here) and an attempt to completely resort the entire thing myself, I got to a different point of view.

I generally like Suns concept of rethinking it completely. Though a fundamental flaw comes in: if you group it into create manage maintain and configure: Well you introduced some good terms that everyone understands. But you have a mass of n subitems. And reducing the top levels to 4 means you got more in each group, and need to introduce subgrouping in order not cause even more confusion inside the new top-level items. So basically you throw the mess into your cupboard and close the door. But oh when you open the cupboard...

This has take into account that an average drupal site employs at least 20+ contributed modules that make for bloating this a lot more, and in sites with 50+ Modules - you get the point.

But our new structure must be good enough to handle this.

Up till now, I thought, one could put "Module settings" somewhere. But this is fundamentally wrong. Modules hook into all kinds of semantic areas in Drupal: some affect users, some affect create content, some affect Reports or help. (from a perspective of the old top level items).

Here I'd like to divide the thing into two use cases:
1. You installed a module and want to find the settings for it. Without the "by module" page you are often lost. There could be a solution for that.
2. The modules are already installed and you look for it from a different angle (having forgotten where it was the first time) and you look for a semantic structure to guess where the module should be according to common sense.

Our present structure with Module settings mainly under the Configure Category tries to satisfy both and fails, resulting in a - having more than 20+ modules - incredibly long "Site Configuration" Tab.

So how about adressing these two use cases in two steps.

1. Use case: I installed a module and am looking for its settings

Here Skilips module table proposal comes in. It is nothing less then something that is indended for core (though I know it is quite some way to get there) http://drupal.org/project/module_table
Only local images are allowed.
It introduces a central place you can do anything from when installing modules. It might be debatable how to integrate permissions page and if it is good at all to keep everything in one place. But even Plugin manager is being thought of being integrated into it.

This Page introduces a common place for modules the user visits often and gets to know quickly. He knows he can always find module settings from there, and, very importantly, always when he first installs the module, which may have caused many people to quit drupal because they the hell could not find the modules settings or could not use it because permissions had to be set.

2. Use case: I want to configure the module and am trying to find the right top level item for it

That being taken care of, opens up the space for a semantic structuring of the top-level Administration items that puts every module setting where it - intuitively - belongs. This is not an easy task and I found myself wondering where a module belongs - example Panels - because often they are ambigous.

Finding this structure needs user testing, and especially testing with users that do not know Drupal, and especially do not know our old Structure. Cause we all are biased because we want to find the things where they used to be.

And an aspect that has not been mentioned here - Learning theory says a human brain can quickly scan averagely 7 items in one glance and keep it in the short term memory. Thus none of the levels or listings should be longer than 7 items (in an ideal world) and introduce subgroupings to archieve that. Even if this introduces one more Menu level and may cause many people to shudder :)))

Some companys pay tens of thousands of dollars to get the information architecture on their site right and a main part of Mark Boultons Work in the redesign was dedicated to exactly this as I understand it. So we should not expect this to be easy.

But, if we find a solution that is intutive to say 80% of the people, this will improve Drupals Usability tremendously.

For the moment I'd say there needs to be more brainstorming. More semantic concepts like Sun's need to be proposed, and more of them have to be worked into a working prototype (Kudos to sun the demo really is a great thing).

As Mark Boulton is approaching I guess this issue could be quite far up on the list he (in collaboration with us) could be trying to find a solution for (or pushing it ahead).

Life is a process

Life is a journey, not a destination

False distinction

sun's picture

Your first use-case is a bit off-topic. One that would (rather) match the issue at hand and would (rather) go hand in hand with your second use-case is:

1. I want to install a module and am trying to find the package name/category the module lives in

Even with module_table, you do not know, in which package name and/or category a module lives. Also, you do not know, which module is guilty or responsible for a certain thing - i.e. does a module provide some kind of content, or is it a low-level/integration/whatever module? Which module do I have to find on admin/build/modules to configure access to my images, or settings for image handling?

So, do we want (or have to) teach users first, which Drupal module provides which functionality? I know that a (my) Drupal newbie does not want to know and even would not be able remember that (since we discussed this direction as well).

I often find myself searching all fieldsets on admin/build/modules to find a certain module to enable/disable. However, in the end, admin/build/modules is a completely different can of worms that is not really tied to the top-level categories of our administrative menu and pages. I would appreciate if we could focus on the top-level categories of the administrative menu instead -- if that results in a concept that may be adapted to other areas/pages in Drupal, fine, those can be improved afterwards.

Daniel F. Kudwien
unleashed mind

Daniel F. Kudwien
netzstrategen

ok

eigentor's picture

Newly installed modules will be temporarily sorted to the top of the table on the modules page, which makes sure you don't have to search for it. Alphabetical sorting and searching is also possible, though default is by package - (and the packages have to be reworked).

But all right, sorting of /admin is our issue here. Though not only the top level catagories but the entire tree.

Packaging I think belongs here and has been used a bit too freely until now - everybody defines the package he thinks is right, or introduces fancy new ones.

Life is a process

Life is a journey, not a destination

http://www.disambiguity.com/d

yoroy's picture

http://www.disambiguity.com/drupalcon_dc_activities/ read point 2. They will definately work on this.

splash/landing screen

cpelham's picture

If I am not mistaken, the Drupal re-design research found that drupal.org users don't use the menus all that much; they use search or they type in memorized URLs (there are reasons for this, I know...) Can we at least consider that instead of debating endlessly what would be the uber menu, we simple present the user with a form that asks/ascertains what the user wants to do next? And then take the user there? This would be more human and elegant if it could be designed to work fast enough. Or is mouse/menu based navigation definitely superior?'

Maybe there could be a combination thereof? A menu and also a "Can't find what you're looking for? What do you want to do?" form, perhaps with autocomplete of a bunch of words/phrases collected from usability studies?

And if the user wants to go to a "site map" of all possible admin type functions (permissable to him/her), then can we give the user the option to re-order them and make his/her own sub-sets as he/she wishes?


Christopher Pelham
Director
CRS (Center for Remembering & Sharing)
http://www.crsny.org

CRS (Center for Remembering & Sharing) is an arts & healing center located just south of Union Square in Manhattan.

good idea

Dublin Drupaller's picture

perhaps an option of a "smart menu" might also be worth looking at. Not as an alternative, but, as an extra top level menu option...

In other words, the most visited admin page nudges the menu link for that admin page to the top of the "smart menu". When setting up a Drupal site, that's handy because you are constantly visiting the same pages to tweak settings or other.

Dub

Yes! I'm one of those

Nick Lewis's picture

Yes! I'm one of those weirdos that navigates entirely through URLs, leaving 20 tabs open to speed up tasks.... Your point about the site performance is VERY important.*
- - - -
Emphasizing search has the potential of being a big game changer, imho... Think of how quickly you could get to those pesky deep pages if you just had to type.

"page fields display"
"add content type"
"tinymce full html"
"page comments default settings"

A lot more people know how to "google" than use drupal's menus after all.

Imagine: we could stuff those pages with phrases and weird ways that we know people use -- perhaps incorporate a help system into it....

Maybe also relate certain pages somewhere -- in a message like block in the content (with the option of turning it off of course) -- e.g.
1. relate user roles page with the input format settings page which references roles.
2. relate image settings, or imagecache settings with a particular imagefield's cck setup page.
- - - -
The idea of "favorites" being incorporated into the "admin thing" is huge -- much like MAC OSX's finder, it lets people set up their own workspace in a way that is most conducive to the task they are currently doing, or regularly do....

Also, perhaps a short "history" log would be useful... of pages you've been to recently -- so people can find their way back to page quickly when the realized the f#cked up their input format settings.

- - - -
What's great this line of thinking is that it is an improvement that doesn't require 3rd party modules to necessarily reorganize themselves.

- - - -
I also think a better user page, that focuses more on activity relating to comments and posts, and their accounts particular privileges (e.g. create a new blog entry) is worth thinking about. But don't want to derail the discussion any more than I already have.

- - - -
If yall missed this module, PLEASE check it out. It has bugs, and isn't a silver bullet, imho, but its the strongest functional concept of rebooting drupal admin I've seen to date. It incorporates, a lot of what you're suggesting -- though not perfectly, and assembly is required. Useful to take a spin through it both for inspiration, and perhaps to see where certain pitfalls may lie...

The most interesting parts, i think, is
1. the "favorites" system,
2. the fact that it can disappear, or appear at your whim (since you don't always want the giant admin menu interfering with what you are doing on the site, and often, designs have no room for an admin block!)
3. How it uses content searching, and menu searching to get you to where you want to go faster...

http://drupal.org/project/navigate

ASIDES:
*You also reminded me of how weird I thought the whole drupal admin thing was the first time I used it. It seems so alien, and bizarre, to be honest (this was drupal 4.5 I think -- the fundamental mechanics have not changed a lot). "Hmmmm... create content... what an odd way to do this...." , was my first thought about drupal I think...

---------------
"We are all worms. But I believe that I am a glow-worm." - Winston Churchill
work: http://www.entermedianow.com
blog: http://www.nicklewis.org


"We are all worms. But I believe that I am a glow-worm." - Winston Churchill
work: http://www.chapterthree.com
blog: http://www.nicklewis.org

admin revamp

cpelham's picture

Yes, if we have an efficient search with pre-programmed taxonomy, I think it will fly, and some contextual awareness would make it awesome. Options to access an admin history log and perhaps a most visited, customizable favorites, would also be helpful.

And I agree that part of the initial (and continuing for me, really, even though I know Drupal very well now) alienating effect, a big part, is that the terms presented in the admin menu are sometimes unintuitive and too often do not match the module name which generated them. But that, I suspect, is mostly the result of contrib modules? I'd have to take a closer look.

I understand the rationale for what Sun has listed above under Content (node types, blocks, users, taxonomy, etc.), but I personally think this organization is somewhat confusing and blurs the mostly clear semantic structure that Drupal has striven to create. I don't think of a block as content but rather as a container for content. Taxonomy is not content but rather an organizational/labeling system. A user is...a user. Etc. Perhaps instead of "Create" we could say "Add..." (and include Views and Panels under this list) and drop the "Create Content" description?


Christopher Pelham
Director
CRS (Center for Remembering & Sharing)
http://www.crsny.org

CRS (Center for Remembering & Sharing) is an arts & healing center located just south of Union Square in Manhattan.

"Manage", not "Content"

sun's picture

I understand the rationale for what Sun has listed above under Content (node types, blocks, users, taxonomy, etc.), but I personally think this organization is somewhat confusing and blurs the mostly clear semantic structure that Drupal has striven to create. I don't think of a block as content but rather as a container for content. Taxonomy is not content but rather an organizational/labeling system. A user is...a user. Etc. Perhaps instead of "Create" we could say "Add..." (and include Views and Panels under this list) and drop the "Create Content" description?

Exactly because of that, the top-level term is not "Content", but "Manage". Also, "Create" contains contents (nodes), content-type, block, taxonomy vocabulary, and of course, it would also contain panel and view.

Daniel F. Kudwien
unleashed mind

Daniel F. Kudwien
netzstrategen

Must say I'm a bit

yoroy's picture

Must say I'm a bit disappointed by the direction this thread has taken. Sun observed 1 (one) newbie and saw that user get confused on location of creating/managing links in admin interface.

(warning: blunt generalizations ahead)
From then on, no one looked back anymore. And now you are all trying to map stuff to some CRUD (??) analogy, arguing about if a block is something you Create or Manage, if it's a "Content" or a "Container". That's still a very developer-centric perspective and I don't think it has much to do with how all this works in the mental model of new users, content creators and editors.

From the admin sections we have now, the "User management" one makes the most sense to new users. It's not grouped (or split) along certain verbs (create, update etc) but it's a collection of items that groups a certain conceptual 'domain' within Drupal; all the stuff that has to do with user accounts, permissions, roles, signup etc.

Another example: the latest usability testing showed that users lump stuff like menu items, links, paths and clean urls together, not even really seeing them as seperate things. They are all just parts of "making a link".

So my point is: I don't think it's useful to limit the groupig of items along a few abstract verbs. We need to do more user research to come up with groupings that support users mental models in ways that let's them accomplish their tasks more efficiently.

In that respect, issues like
http://drupal.org/node/273137 - Split Navigation to User and Administration menu
http://drupal.org/node/382890 - Move 'My account, Help & Logout' links to separate menu and place it top right
http://drupal.org/node/368064 - Provide a top level 'internationalisation' menu item
seem like a more constructive way (based on actual user testing) to improve the user experience of our admin then coming up with a total revamp like this thread proposes.

Thank you Yoroy! That's

skilip's picture

Thank you Yoroy! That's exactly what I was trying to bring forward. We need to focus on user experience, not on developer trends.

It seems like it might be

chrisshattuck's picture

It seems like it might be effective to split this discussion into two major threads:

  1. How to optimize the underlying STRUCTURE of the menus and their containers
  2. Providing useful INTERFACES for navigating through this structure.

It seems like our efforts might be better focused by keeping this thread on the STRUCTURE problem, and in another explore the options for an alternative INTERFACE that would be suitable for core.

I'm going to go ahead and start the thread here: http://groups.drupal.org/node/20138. Please feel free to put the kibosh on it if I'm genuinely duplicating efforts.

Chris Shattuck
Learn Drupal with over 1700 Drupal video tutorials

Yes, derail over there, please.

sun's picture

Exactly, some follow-ups on this discussion are completely off-topic. Discussion about alternative utilities for finding certain (already known) pages in a Drupal site should be moved over there.

Daniel F. Kudwien
unleashed mind

Daniel F. Kudwien
netzstrategen

Usability

Group organizers

Group categories

UX topics

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: