UB Usability : Labeling primary link label.

how about "main menu" and "secondary menu" for these?

I also think we need to move the admin menu out of 'navigation' by default.

Catch, I was thinking the same thing. Main and secondary for my vocabulary sounds way more logical, even if its technically not the best term. So a big Yes, from me on this one.

We should have a more admin interface like navigation I know, however how we will approach this is yet questionable. Not sure if that's appropriate for this issue though (I think the explode of admin navigation modules already says enough :).

Just a note that changing this will require changing the variables in the theme system to match as well.

Main/secondary menu sounds fine to me.

Patch?

Patch. (untested)

Missed a bit.

It's a good idea to revisit these confusing terms. While I'm vaguely convinced that "main menu" and "secondary menu" could make for better usability, it's hard to tell. It would be great to be able to test the usability of several options, but that's asking a lot.

I can see why we might use the non-parallel "main" and "secondary" for presentation to end users, but at the code level it seems confusing to have a function menu_main_menu() and a function menu_secondary_menu().

We could consider:

* For now, change just the terminology presented to end users, leaving variable and function names untouched.
* Or use primary_menu and secondary_menu at code level and "Main menu" and "Secondary menu" for presentation to end users.

I don't like the idea of leaving primary/secondary links in the code if we change it to menu in the UI - it'll lead to people talking at cross purposes.

Which leaves us with:

* Or use primary_menu and secondary_menu at code level and "Main menu" and "Secondary menu" for presentation to end users.

Primary menu/Main menu map to each other pretty well, so I don't see much harm being done, and it'll definitely be clearer at the code level.

I'm happy to do a find and replace re-roll for that - but would be good to get a little more feedback in case anyone's got better ideas.

Nedjo, it is indeed in any case better to run a usability test to see if the improvement is better. We hope to be able to run such a test before we get D7 out. But this depends on the resources at the students in the University's.

Generally, one would assume that implantation terminology could be completely different from user terminology, in Drupal's case I see there is quite some hesitance to this as the developer also tends to be the main user (in this case more 50/50?). I am not sure if I understand programmers terminology logic, but would it be a big confusion for them - since they do first encounter them in the UI?

Especially considering, we are not yet 95% sure. For now, should be a good choice, but I am not sure if catch agrees on this inconsistency applied to code.

I vote for :
For now, change just the terminology presented to end users, leaving variable and function names untouched.

Since we have hook_link and taxonomy_link etc. which have nothing to do with menus, I think it'd also be an improvement to the terminology in the code to use primary_menu/secondary_menu - not only for consistency (although that's nice too).

Unless there's objections I'll re-roll with nedjo's option 2.

With usability testing - we know there's major issues with 'primary links' - and I think it's unlikely that this change will make that any worse. Ideally we'll have 2-3 rounds of tests, along with informal evaluation at early beta stage or before, so changes can be tweaked (or even rolled back) based on that.

Marking to needs work pending the re-roll.

Personally, I think it is better if end-user terminology matches the terminology used in the code. I'm actually happy with catch's patch "as is" and don't share Khalid's concerns. I find the code to be very readable.

OK then, back to needs review :)

I've thought about this some more, reviewed the patch, ran all tests (no regressions) and decided to commit this patch. It's a small but important usability improvement. Marking this fixed.

We probably want to document this in the theme upgrade manual for Drupal 7.

Documented, thanks!

http://drupal.org/node/254940#menus

This patch missed some needed changes - follow-up issue: http://drupal.org/node/277196

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