Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Problem
Participants didn’t understand the primary link label.
Solution
Rethink the term itself. How do other CMS's call this?
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | primary.patch | 32.5 KB | catch |
| #6 | primary.patch | 32.51 KB | catch |
Comments
Comment #1
catchhow about "main menu" and "secondary menu" for these?
I also think we need to move the admin menu out of 'navigation' by default.
Comment #2
Bojhan CreditAttribution: Bojhan commentedCatch, 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 :).
Comment #3
webchickJust 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.
Comment #4
Bojhan CreditAttribution: Bojhan commentedPatch?
Comment #5
catchPatch. (untested)
Comment #6
catchComment #7
catchMissed a bit.
Comment #8
nedjoIt'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 afunction 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.
Comment #9
catchI 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.
Comment #10
Bojhan CreditAttribution: Bojhan commentedNedjo, 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.
Comment #11
catchSince 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.
Comment #12
Dries CreditAttribution: Dries commentedPersonally, 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.
Comment #13
catchOK then, back to needs review :)
Comment #14
Dries CreditAttribution: Dries commentedI'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.
Comment #15
Dries CreditAttribution: Dries commentedWe probably want to document this in the theme upgrade manual for Drupal 7.
Comment #16
catchDocumented, thanks!
http://drupal.org/node/254940#menus
Comment #17
pwolanin CreditAttribution: pwolanin commentedThis patch missed some needed changes - follow-up issue: http://drupal.org/node/277196
Comment #18
Anonymous (not verified) CreditAttribution: Anonymous commentedAutomatically closed -- issue fixed for two weeks with no activity.
Comment #19
David_Rothstein CreditAttribution: David_Rothstein commentedWe are at that stage now, but as far as I know this kind of usability testing didn't really happen :( However, I think we are seeing a lot of informal evidence that the new terminology is still confusing.
I think the fundamental problem is that we are overloading the word "menu" and using it to refer to two different things that aren't necessarily forced to be linked together (and aren't even linked together any more in the default D7 configuration, where the User Menu is displayed as the secondary "menu").
Discussing this further at #698014: Theme settings for main/secondary variables mismatch with menu settings to see what can still be done for Drupal 7.