The admin toolbar already provides a way to access all management functionality, so why not skip adding the management menu to the sidebar? This was part of the original admin toolbar issue at #484820: Initial D7UX admin header, but was left out from the last patch inadvertently.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Status: Needs review » Needs work

The last submitted patch failed testing.

Bojhan’s picture

Why have the menu at all then? I thought the toolbar was using the Management menu or is it hardcoded? Either way, if we disable it - we have to come up with a better name for it. Otherwise it will only confuse users.

Gábor Hojtsy’s picture

Bojhan: Well, we need some way to have all the admin menu items accessible, editable, etc. A menu provides that functionality. If we remove it as a menu, then where would all the items live? From where we'd pull them for the toolbar?

Also, not all sites will use the admin toolbar, and they need ways to present the management menu. Also, there might be sites, where some users get the admin toolbar, while others get a menu block. I am not saying we'd propose that as best practice, I'm saying we should not rule out the option outright.

David_Rothstein’s picture

Currently, the Management menu is the home of the "add new content" link. If it is disabled by default, then by default it seems Drupal would not provide non-site-administrators with a link to add new content...

See also #408160: Normal users should not see the create content link appear by default in a menu called "Management", which is already marked critical. Can it be marked "super-critical" instead? :)

Bojhan’s picture

Oke, so its basically displaying in two places now. Lets remove the block. Regarding add new content link, that's going to be a hard one - since then we have to display it in another menu

catch’s picture

Currently the management menu isn't enabled on upgrade from 6 to 7 (I think there's an issue for this but can't find it now) - we could potentially enable the toolbar in the d6/7 upgrade instead of that block - if you have admin_menu or some other mechanism installed, you need to remove one of them either way.

Gábor Hojtsy’s picture

The issue @catch mentions is #410636: D6->D7 update does not create required menus. Added a comment there, so that the upgrade path is also properly aligned.

Gábor Hojtsy’s picture

Status: Needs work » Needs review
FileSize
2.41 KB

Updated patch with the failing tests fixed. At least they pass on my machine. The block test assumed there is a management block (although it said it looks for a navigation block). The system test looked for items showing up from the management menu in the sidebar.

Gábor Hojtsy’s picture

Had a brief detour in #408160: Normal users should not see the create content link appear by default in a menu called "Management", but then realized that all the admin menu items and the create content (Add) menu is there on the toolbar, so it already covers all those items by default in a Drupal install. So we truly only remove some duplication. Anyone thinks it is ready then?

Gábor Hojtsy’s picture

Oh, David says non-admins will have no way to add content. He is right! We do need to solve splitting the menus then in #408160: Normal users should not see the create content link appear by default in a menu called "Management".

Gábor Hojtsy’s picture

Any opinions on this?

Bojhan’s picture

Whatever solution we come up with is going to require permission trickery, isn't it?

Dries’s picture

I'd create a 'Create content' block by moving the create new content stuff to its own block. That would allow us to make progress.

Gábor Hojtsy’s picture

@Bojhan: why would it require permissions trickery? Whatever permissions people have will match the items shown under their Create content.

Bojhan’s picture

@Dries Won't we duplicate links then?

@Gábor Because - for it to be intelligent we need to check permissions on toolbar and supply the block or links to those who don't have that permission.

Gábor Hojtsy’s picture

@Bojhan: on most sites, there would be at least one content type: forum topic, user profile node, whatever, which is not created via an admin UI, so the create content block would have its use there. To fully support the notion of "this is an admin submitted content type" and "this is a user submitted content type", we'd need more logic. We discussed this on IRC and came down to two options:

- we infer from the permissions; if content of some type can be submitted by people who cannot see the toolbar, that content type is admin submitted
- we just make the admin theme setting for content types more granular and general; from a "all nodes are submitted via admin theme" to a "this node type is an admin submitted node type" which would mean it does not show up in the regular create content submenu and would use the admin theme

I don't think we should solve this bigger issue here.

David_Rothstein’s picture

I really don't think it's a good idea to pull some items out of the "Create Content" block while leaving others in... I'd say a given user should either see the block or not, and when it's there it should contain links to everything they are able to create. Otherwise won't they get very confused about what their content creation options are?

Personally I think a "Create Content" block is more useful than the current "Add" button in the toolbar - it exposes more information and requires fewer clicks to start creating the content.

(Note: Maybe this discussion should be taking place on the other issue?)

Gábor Hojtsy’s picture

David: some node types will use the admin theme for submission (and consequently the overlay). So some links in the create content menu would open in the site theme in the page while others would open an overlay and use the admin theme when clicked. Is that less confusing then having a set of content types submitted in the site theme and another one in the admin theme separated by how you submit them?

Dries’s picture

I'm with David in #17. Let's just have a block with all the content types that I can create. I'd imagine that most site administrators would only make that block visible to non-administrators but that is up to site administrators to decide. Let's start of by doing the simplest thing so we can unblock the other issue. Then, we can circle back to this issue and do more advanced stuff. Mark and Leisa were going to thinker about this some more as well so let's just focus on unblocking us.

moshe weitzman’s picture

FWIW, I have been expecting to see Create content as a single link in the Primary links along with My Account and Log Out.

Status: Needs review » Needs work

The last submitted patch failed testing.

David_Rothstein’s picture

David: some node types will use the admin theme for submission (and consequently the overlay). So some links in the create content menu would open in the site theme in the page while others would open an overlay and use the admin theme when clicked. Is that less confusing then having a set of content types submitted in the site theme and another one in the admin theme separated by how you submit them?

Although I realize the implementation details might be particularly tricky, I honestly think the ideal thing to do here is that it depends where you clicked from. If you're in the overlay and click on a create content link within that, I think you should stay in the overlay/admin theme. Whereas if you're on the "main site" and click such a link, I think you should stay in the main site theme.

I honestly don't think the content type matters much. Just because I have forums on my site that regular users can submit to doesn't necessarily mean that I, as a site administrator, automatically want to go into "regular user mode" every time I myself submit a forum post.

David_Rothstein’s picture

Anyway, back to the issue at hand... Instead of disabling the management menu itself, maybe another possible implementation would be to have toolbar_page_alter() simply remove it from the page whenever the current user has toolbar access?

I think this might have some advantages, since it means that the menu would automatically come back when the toolbar module is disabled (or for any user with admin privileges who does not have the toolbar permission turned on), rather than leaving them stranded without any links to the admin section?

Bojhan’s picture

@David It's best to avoid this kind of magic, because it tends to confuse the user.

catch’s picture

@David, one of the advantages of the toolbar (and admin_menu) is that you more or less see your site how it appears to regular users without masquerade or whatever, if we start hiding menus which are there for 'regular' users, then that all gets a bit trickier conceptually.

David_Rothstein’s picture

@catch: How many 'regular' users would typically see the management menu, though? I would think that's pretty rare.

Anyway, it would be great to solve the problem somehow... otherwise disabling the toolbar module would put you into a pretty confusing state. You'd have to somehow figure out to go to the blocks page and enable the management block by hand, all without the benefit of a menu on the screen to help you navigate around.

Here's a crazy idea: Could we use toolbar_page_alter() like I suggested, but also put the management menu in the header by default? That way it doesn't look like things are being magically moved around, just replaced with a different version. See the attached screenshots. (This wouldn't work as well in the non-default situation, but the toolbar module could easily provide a checkbox for disabling or enabling this feature, etc.) Of course, the management menu looks pretty ugly up there right now (especially in the last screenshot), but I think that's an existing bug to be fixed anyway; Drupal doesn't really do a good job supporting blocks in the header region.

deekayen’s picture

FileSize
54.28 KB
38.56 KB

When doing a minimal install, there's no default link to anything administrative. That seems like a bit too far in the other extreme - there should at least be a link somewhere to admin, even if not the entire nav block.

catch’s picture

@David - any user with 'create foo content' permissions can see the management menu, that's the opposite of rare, it's extremely common.

deekayen’s picture

@catch - I think you misunderstand. You get install_2 in #27 when you install using the Drupal (minimal) profile, then configure the site name, uid 1 user, and time zone, then proceed to the site. Totally fresh install. The management block is disabled in that case (verified by visiting admin/structure/block). Permissions aren't the issue I mean.

deekayen’s picture

This might not be the right issue to be discussing my complaint. DamZ pointed to it as related discussion and I just jumped on.

catch’s picture

Sorry deekayen, I was responding to David Rothstein's #26, are you another David?

David_Rothstein’s picture

@catch: Right now that is true, but seems extremely unlikely that will be the case when D7 is released...

catch’s picture

hmm, fair enough.

What about if toolbar_enable() disables the management block, and toolbar_disable() enables it again? That's a bit less magic than hook_page_alter() since it won't show up in the blocks UI as enabled.

Gábor Hojtsy’s picture

Ok then, why not add a new block for only the creation of content as per Dries above from #19? Then we should follow up with some intelligent link altering to allow for certain node types to open in the overlay (admin theme) and others in the site theme. A user testing with the overlay and admin theme showed that showing a node form in the admin theme but not in the overlay can confuse users a great deal (see http://vimeo.com/5994325 around 16:20).

dodorama’s picture

This is still an issue and I like what David_Rothstein proposed on #23 where the toolbar module takes care of disabling the management menu.
I don't have the authority to mark this as critical but in the current state this is really confusing

webchick’s picture

Priority: Normal » Major
Issue tags: +beta blocker
FileSize
340.18 KB

Yeah, this is pretty nuts:

aye-carumba.png

Making at least one of these go away in the default install would be a nice thing. :P

catch's idea in #33 to flip/flop toolbar + management block is interesting. As is Dries's for pulling create content into its own block, though that's similar to #408160: Normal users should not see the create content link appear by default in a menu called "Management".

Marking as a beta blocker not because this issue particularly is, but because the "we seriously need to nail down D7's default menus" is.

Bojhan’s picture

Priority: Major » Critical

Actually going to mark this critical, it's a little belated but I have been doing a little bit of usability testing for #601932: Allow dashboard to limit available blocks, David Rothstein did too and several other individuals have reported to me that instead of using the Toolbar, users have a tendency to use the "Administration" in the management menu. This links to a fairly confusing page, where top-level navigation is listed(/admin) - which would be fine for hardcore users, for first-time users this is pretty confusing. So far I have seen this happen with 2/3 participants I tested, although not statistically critical - it seems pretty serious.

I think the action plan could be :
1) Move create content link to another menu
2) Disable Management menu by default

Then we have two outstanding issues then and apart from minimal profile, which I have to little experience with to truly judge. Outstanding issues :

1) What to do if the toolbar/admin_menu is disabled
2) What to do with minimal

chx’s picture

As I have not seen the standard profile for... i dunno, a year at least now, but webchick's screenshot raises my old fears in #511218: Is this usable?: duplication of user menu links between Toolbar & Garland -- we simply have too many zones with links: you have the admin bar on the left, then "Hello admin" / logout on the right, next line shortcuts on the left then edit shortcuts on the right, then tabs and then the user menu and if the current page have breadcrumbs... I count seven hot zones in the "upper" part of the page. If you want to count the sitename linking to home, eight. And the user's page still linked twice.

EvanDonovan’s picture

@webchick: Thanks for the screenshot in #36, with labels.

I agree with chx. I had been disturbed back in March by the way that user menu links were duplicated, and now it looks like site admins can still see a good number of different menus in the default profile, and Bartik doesn't really make it less confusing.

tgeller’s picture

-1 for considering this critical or a beta blocker.

Come on, folks. It works. This is just a UI quibble.

Any of us could find a dozen items currently tagged as Major that blow this out of the water. And that's not even mentioning the alleged UI freeze of a year ago....

aspilicious’s picture

If the toolbar is disabled you can't do any admin tasks if you don't know the links without that menu. You have to consider this.

BTW: this not critical :s

Bojhan’s picture

@chx, @aspilicious, @EvanDonovan I think we identified the issue, just never properly attacked it due to its complexity understanding how to mange minimal/standard/every other possible use case with menu's (@chx I know you adressed it earlier, at that time I felt we could solve them - clearly we didn't). Either way this issue is about solving it, so please enter the creating solutions mode and put forward ideas.

@tgeller You might disagree, but it doesn't work for users - that it works technically is not an qualification we use in usability issues. If it affects the majority of our users its considered beta blocker/critical(or major) - we don't take this lightly.

So what about the solutions I put forward in #37?

Jeff Burnz’s picture

Bojhan - I concur with your findings of many users favoring a left navigation approach, I did some testing also and included sidebars in my admin theme for this very reason (many users favor something like DHTML menu as opposed a static horizontal toolbar approach). Its a worrying finding however that users are clicking the Administration link and taken to a page that duplicates the Toolbar links - i.e. not seeing the toolbar as a route to the same pages. My question would be does this behavior persist, or at some stage do they percieve the toolbar and start using it?

I wonder if you could run similar test and disable the Management menu before testing, basically to see if tasks are more difficult etc without it (force use of the toolbar). If its just not there they can't use it, not necessarily a bad thing?

Move create content link to another menu? I don't really like that idea, it seems very well positioned up there and we'll have yet another menu in a sidebar (I assume) to deal with on default standard install. I do like the idea of simply not enabling the management menu, its the first one I turn off, every time. I assume you mean a stand alone "Add Content" menu whose only links are node/add links.

webchick’s picture

Question about the users you were testing with who favoured the left-hand nav. Were they previous users of Drupal? Or new users? I'm curious if those who favour the left-hand nav are heavy Drupal 6 users? I'm pretty sure after the Toolbar patch went in I probably used the left-hand nav for a few weeks just purely out of habit, for example.

David_Rothstein’s picture

Agreed with some of the other comments above - the best thing to do would be to go back to Gábor's original patch (at the top of the issue). Just disable the Management block in the Standard profile, but enable it in Minimal.

However, we then really need to resolve #408160: Normal users should not see the create content link appear by default in a menu called "Management" first, right? Unless we are really going to hide content creation from end users completely in the default configuration of Drupal?

A potential problem with the other solution, in #33 (having the block be automatically disabled when the toolbar module is enabled) is that what happens if I (as the super-user) enable the module and only intend to (and only grant permission to) use the toolbar for myself... then other people on the site who need access to the Management menu suddenly see it disappear and lose their links? (Or even I might lose some links, since currently the Toolbar is not a direct mirror of the Management menu; the Management menu can have other things in it that will never appear in the toolbar.)

catch’s picture

Disabling the block via toolbar_install is going to create a big mess, sorry for mentioning it in the first place. If we do anything here, it should be just removing the menu from the standard profile.

This is clearly postponed on #408160: Normal users should not see the create content link appear by default in a menu called "Management" although that doesn't necessarily preclude a here ready.

webchick’s picture

#408160: Normal users should not see the create content link appear by default in a menu called "Management" has been committed.

Let's go with a patch that removes the Management menu from standard.profile (very similar if not identical to Gábor's patch above). This will move the default install to more like this:

http://img.skitch.com/20101020-dkywhen89n7kx6n9s79kakhy6c.png

...which seems like a much better place for us to be.

tstoeckler’s picture

Can we also then not enable the user menu by default. As you can see in webchick's screenshot it is duplicated 100% by the toolbar above. I don't want to start a whole other discussion, but in one of the issues related to the sea of navigation elements that the user is currently "provided" with, the reasoning was equivalent to this issue:
The reason against not having it enabled is that in case the toolbar is not there, the user has no way to see his profile. But if we make this change in standard.install, similar to what is proposed for the Management menu, then that is not a problem.

webchick’s picture

Please open a separate issue to discuss that, but IMO, no. That user menu was a deliberate addition in D7 to match expected behaviour in 99.9999% of other sites. That it's duplicated in the toolbar is a bit wonky, but that only affects admin users.

EvanDonovan’s picture

I support the proposal in #47.

Although I also think it looks a bit weird to have the user menu be duplicated in the toolbar, I think that there is no easy fix for that at this time, since the only fix would really be to special-case admin users so that they wouldn't see that menu.

I.e., something like,

"if(!user_access('use toolbar')) { print $user_menu; }"

but with the actual permission and variable name used, of course.

That in and of itself might be simple, but there would probably be more special-casing needed that I am not aware of.

yoroy’s picture

Status: Needs work » Needs review
FileSize
2.41 KB

But yes, let's focus on the *management* menu in this here issue. I'm simply reposting Gabor's last patch from #8 here. Needs review for testing bot, will probably fail soon enough.

David_Rothstein’s picture

Here is a patch that just disables the management menu in the standard install profile.

As for the discussion of the user menu, someone should write a FAQ about that because I've seen it discussed in like 5 separate issues :) The reasons we can't dynamically hide the user menu are basically the same reasons we can't dynamically hide the management menu:

  • It would give admin users a warped view of what the site looks like for "regular" users (see @catch's comment in #25 above).
  • The toolbar user and regular user menus only start off as mirrors of each other by default. As soon as you start adding more links to the user menu, it makes no sense to hide it from administrators.
David_Rothstein’s picture

Ah, crosspost.... But yeah, there is no way that older patch will apply. As for the test changes that patch contained, I guess we'll find out soon if they're still necessary or not :)

By the way, we do need to get this fixed but I don't understand how this is possibly classified as critical. The are other ways to get to the "Administration" page besides this menu (for example, in the user test I performed, I'm pretty sure she got there via the breadcrumbs, which are of course you can do from every single admin page). The top-level "Administration" page may not be the most amazing page in the world, but it's hardly a disaster if someone winds up there. It contains the same content as the toolbar after all.

David_Rothstein’s picture

Hm, rereading some of the above comments, there's a problem we still aren't solving here:

...[with this approach] disabling the toolbar module would put you into a pretty confusing state. You'd have to somehow figure out to go to the blocks page and enable the management block by hand, all without the benefit of a menu on the screen to help you navigate around.

Do we worry about that? I just tried disabling the toolbar module with this patch applied, and definitely felt pretty lost afterwards, with no way into the admin area whatsoever :)

(I guess in the worst case people who do this and get lost will use the back button to get back to the admin area, though.)

catch’s picture

IMO we don't need to account for people disabling the toolbar.

- they may also enable admin menu or some other module
- the module admin screen is in the admin section so you won't immediately lose navigation
- in d6 we never worried about people who disabled the navigation menu block. many sites do though.
- you can also get to block admin via contextual links
- at some point we have to say tough luck, browse to /admin. While my idea of magically enabling the management menu on toolbar disable would have covered this one case. It would have annoyed or confused every other case.

webchick’s picture

I marked this critical because major UI changes were supposed to be hashed out before beta1, and this one wasn't. We need to fix it before beta2.

I'm personally fine with that level of "shoot yourself in the foot" and that's even with forgetting about contextual links entirely. That makes it even less of a concern, IMO.

EvanDonovan’s picture

I think catch's argument in #55 is compelling, since I have always hated the management menu's weird mishmash of options, and disabled it on many live sites. People can hit the back button, or we can tell them they need to go to /admin directly.

catch’s picture

Status: Needs review » Reviewed & tested by the community

This is ready to go.

I have one remaining concern, which is that this currently breaks the pattern of the minimal install profile enabling less stuff than the standard profile, but that doesn't overrule the usability issue here (nor the usability issue of leaving the minimal profile with no navigation at all), and it's only configuration anyway.

David_Rothstein’s picture

@webchick, I believe the record will show you marked this major, not critical :)

In any case, it sure does seem like it's RTBC now!

webchick’s picture

Priority: Critical » Major

Well, whatever it is, it's now fixed. ;)

Committed to HEAD.

Yay! Thanks, all.

webchick’s picture

Status: Reviewed & tested by the community » Fixed

Ahem.

yoroy’s picture

Happy!

aspilicious’s picture

Ok after reading all of this again, thnx Bohjan for your response, I like the solution.
I wasn't aware of the fact that different profiles in core were allowed to show different blocks.
Learned something new again!

Yeay!

Status: Fixed » Closed (fixed)
Issue tags: -beta blocker

Automatically closed -- issue fixed for 2 weeks with no activity.