Open Bug 135571 Opened 23 years ago Updated 17 years ago

Return "New Navigator Window" to the top of File menu.

Categories

(SeaMonkey :: UI Design, defect)

Product:
SeaMonkey
Component:
UI Design
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

People

(Reporter: mattdm, Assigned: jag+mozilla)

References

Details

In today's build (2002040403), "New Navigator Window" is suddenly missing from the top of the file menu. One must dig through the File|New submenu to find it. This isn't just a trivial problem -- opening a new window is one of the most common operations, and there needs to be a quick UI element that makes it easy to get to. Ctrl-N is fine and all, but that requires shifting to the keyboard. Submenu items require much more of the brain than top-level ones -- you have to find the submenu, and then keep I seem to remember that this happened once earlier in the Moz. development process and then it got fixed, but I can't find that bug.
The "bug" you've described is bug 75338. I agree that it's inconvenient to hide those frequently used menu items behind sub-menus. I guess it's a RFE rather than a bug... Any comments from the UI team?
Actually, I think it's bug #108099 -- 75338 is about context menus. Joshua Prowse's comments in that bug add another aspect to this that I hadn't even considered -- it's bad in general to have a submenu as the first choice in a menu. It's partly an RFE, except it's more of a request-for-put-it-back-please. :)
Confirming. This is needed.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: mozilla1.0, nsbeta1
The new "Tools" menu pulled from the "Task -> Tools" submenu is indeed a very good example of pulling useful commands off the sub-menu. The hiding of "New Navigator Window" command back into sub-menu is a poor act...
Yes, I complained about this as well. For some reason, users need fast and easy access to Send Page and Send Link, but we bury New Window in a submenu. Makes no sense to me.
Assignee: mpt → jglick
The problem with bringing it back will be that if you bring back "New Window" there will be a big bruhaha over bringing back "New Tab" also - since a good deal of people use tab browsing just as much as window browsing. (I, for one, would rather see "New Tab" if I have to see anything at all at the 1st menu level.) Then, if New Tab gets brought back too, there may even be an argument over bringing back "Blank Page to Edit" (it would certainly be silly to have only ONE menu item in a sub-menu). This is a slippery slope argument. I'm not saying that "New Window" should or shouldn't remain where it's been moved (speaking personally, I have no issue with it being in a sub-menu - in fact I like the reduction in menu clutter), but if it is brought back it could open up a Pandora's box of regressing the menus / context menus back to what they were...
Jason -- "New Tab" never was directly on the File menu, was it? Now, I see the argument that it might have just as much right to be, but since that'd be a whole new thing, that's a separate issue.
To amplify Blake's point, both "Open New Window" and "Open New Tab" are more valuable than "open web location" and "Open File" combined. Why should the more valuable ones be harder to access than the less valuable ones? Additionally, "Open a new blank page to edit" is a much less valuable than "Open New Tab." Proposed compromise: Under File menu: Open New Navigator Window , Open New Tab, Open New Window (Message, Address Book Card, blank page to edit), then the rest as is.
Matthew: Actually, I can't recall if New Tab used to be on the 1st menu level or not. By "bring back" I mainly meant "bringing it back a menu level". The recent reorganization of the context menus was an attempt to group items into sub-menus so that there wouldn't be such a horribly long selection at the top level. I see the move of New Window into the same location as New Tab and New Blank Page as part of that reorganization effort. (It makes logical sense.) Even if New Tab never was at the 1st menu level before, New Window is no longer either. You might say that the cat's out of the bag at this point. If one is moved from its current 2nd level menu position, that opens the door for the rest to be similarly moved. I think that, before this bug can be "fixed", the overall picture needs to be looked at. Otherwise the UI becomes inconsistent. Andrew: There's already debate about the order in which "Open Link in New Tab" and "Open Link in New Window" should appear in the new context menus. I can see the same debate about which should come first in File menu - should this bug get "fixed" and both are moved under it. Would the resolution to bug 135250 also affect this bug's resolution? (Thus making this bug dependent on that one.)
If the 'search' item at the top of the tasks menu is context-dependant, with a separate flyout, why can't 'new <foo>' behave in the same way?
Let's fix the regression first and leave improvements for other bugs: bug 116987 More convenient placement of "new navigator tab" in the menu bug 124973 Pref to enable tabbed browsing bug 121767 File->new->message should not appear in browser component
It looks to me as if all 3 bugs mentioned in comment 11 have been, more or less, "obsoleted" by the new menu structure. At least one of them is trying to fix something that's already been fixed by the new menus. It's not clear to me what bearing those bugs have on this one. They are somewhat related, but they are not duplicates - nor would fixes for them include a fix for this one.
Jason, the problem is not that the new menu arrangement is illogical. The problem is that it is impractical.
Surely there must be some way of getting a menu structure that's both logical (for people new to the interface) AND practical?
The proposed compromise is not as thoroughly logical as the current arrangement. New people will understand the proposed arrangement, though. Overall, it would be much more practical. The pros outweigh the cons. Jason, you mentioned that one possibility would be to create a pref for putting new tab on top of new window in both the file menu and the context menu. That's a good idea, and should be implemented. At this point, I'll stop commenting.
FWIW, the current arrangement isn't logical at all, let alone "thoroughly". :)
Although the current Menus have a logical arrangement (with the possible exception of the placement of "Work Offline"), it is not as convienent or user friendly as before. I understand the concern about menus getting too long, but that concern is superceded by the issue of convienent access to frequently used commands. I think that everyone agrees that Open New <foo> is a very frequently used command. <foo> varying based on context: ie foo=Window/Tab in Navigator, foo=Message in Mail, foo=Card in Addressbook, foo=Blank in Composer (which BTW is currently totally missing from even the New submenu). Therefore it stands to reason that it should be very easily accessed. The top of the File Menu seems to be the perfect place and is consistant with user expectations from previous versions, competing products, and other totally unrelated software application experiences. The question of Window vs Tab can be easily addressed as well. Typically users favor one or the other; if you like Tabs then you probably do not as frequently open new windows and vice versa. Since right now there is already an option in Preferences->Navigator->Tabbed Browsing for choosing to default to using tabs for "Windows opened by the Web page"(case inconsistancy is from the pref), then I suggest that a sort of global preference for Tabs be made available. By default the preference is for Windows, "New Navigator Window" is at the top of the "File Menu", and the "Open New Tab" is pushed to the "New" submenu, but if a user chooses a global preference for Tabs then these two exchange places. This same pref could also address bug 135250 as to which was on top in the context menu (both should ALWAYS be present in the context menu). Before anyone submits an argument of "muscle memory" and the idea that the "New <foo>" for Windows and Tabs should not vary, I would like you to consider a couple things : 1) that "muscle memory" is determined on a user by user basis and what I am suggesting is a user pref, and 2) the "New" submenu already varies greatly based on the context of which component you are using. Based on the assumption that whatever is done here for "New Navigator Window" will also be done for "New Message"in Mail, etc, I recommend modifying the summary to reflect "New <foo>" to the top of File Menu for all Mozilla components.
I believe that 'New Navigator Window' was removed because it was thought that having two 'New' commands at the top of a menu may confuse users. That said, I found it useful.
A) note that bug 37537 was marked wontfix B) this wouldn't be such a problem if bug 104125 were fixed (need one-click button for new browser window) C) bug 104125 wouldn't be an issue if they'd just fix bug 20306 (can't open more than two windows with navigator button) Having file>new navigator window as a menuitem was something that struck me as particularly nice and handy in the mozilla UI. It meant that the designers really knew what was important in web browsing. Oh well...
I just noticed that "New Tab" is the first item on context menus for the tabs themselves. This means that having "New Tab" on the file menu isn't nearly as important as "New Window", as there's a closer and quicker way to get to that option.
I was annoyed by this deletion as well, but wasn't sure if it was just habit or the wrong thing, so I did a little research. Here's a little excerpt from _Designing the User Interface_: "...A sensible compromise is to extract three or four of the most frequently selected items and to put them on the top, while preserving the order for the remaining items. In controlled experiments and field studies with a lengthy font menu, the three popular fonts (Courier, Helvetical, Times) were put on top, and the remaining list was left in alphabetical order. This split-menu strategy proved appealing and statistically significantly improved performance (Sears and Schneiderman, 'Split Menus: Effectively using selection frequency to organize menus', ACM Transactions on Computer-Human Interaction, 1,1 (1994) 27-51)" Apple's HIG says, "submenus add complexity to the interface and are physically more difficult to use" and 'New Navigator Window' is my most frequently used menu item, so my annoyance is probably well-founded.
*** Bug 141308 has been marked as a duplicate of this bug. ***
*** Bug 143790 has been marked as a duplicate of this bug. ***
*** Bug 143808 has been marked as a duplicate of this bug. ***
Jean-Francois Ducarroz in http://bugzilla.mozilla.org/show_bug.cgi?id=147502#c4 who ever wants to work on those UI issues must consult with Jennifer Glick (jglick@netscape.com) before waisting his/her time on a solution that could be rejected. So be it. -> CC pi
Keywords: mozilla1.1
Opened bug 149297.
Just a bit of anecdotal evidence: Last night my wife was trying to check the weather, and she's not entirely used to the trackpad on her iBook. First I hear some sighs, then some exasperated grunts, then, "god damn this thing." She was trying to mouse over into the New submenu, which happens to be very far away because the File menu is very wide due to "Open Web Location...". Even on my 21" monitor here at work, New Navigator Window is 1/5 of the screen width away from File. You quickly run out of trackpad space, and have to start jumping, a non-obvious bit of finger acrobatics for novice users. So, let's remember that not everyone is using a mouse or, god bless it, a trackball, when deciding about this bug. Different input devices are common and each type contributes its own factors.
One way to fix this is to fix bug 135804, "Remove the New submenu from the File menu".
I too was dissapointed when New Window went into a submenu, it's was a nice little improvement over IE. That said, I since started using tabs. * Suggestion: what about a top-level New menu? There is lots of stuff under New and it's commonly accessed. Another suggestion: new window could go under Window menu. There is now a "new tab" button so that could cover that. In this case, leave File - New as is. Just throwing ideas in there.
Since reading stuff elsewhere, I believe the solution is simpler. No need for submenu or a new New menu :D Browser windows should only have File - New Window and New Tab. Lose the new message, address card and composer page. In other words... split the apps up further. The browser only has things relevant to browsing. I believe this is where a lot of Moz people want to go... witness the new Phoenix project.
Aaron, that's bug 135804 (which I didn't know about 'till I read your comment and searched). Personally, I prefer this solution, having gotten used to it in Chimera, so I'll be moving my vote over there.
Yes. Does anyone not agree? This bug could be closed as obsolete/wontfix or something.
Reducing the menu to New Window and New Tab is not acceptable for Mozilla. Chimera is just a browser and thus it does not have any use for the other menu items, but Mozilla is more than just a browser.
Yes, you can go into the mail client and then it's a mail client. Then you can get File - New Message, Address Book Card. But why do you want these options when you're using the browser part?
Because I should not have to launch the mail window in order to send an email. If I am browsing the web and decide to send a quick email, I want to be able to do so quickly. I do not want to have to wait for it to load up all my mailboxes and index my old mail before I can choose to send a new message. Personally I am in favor of moving all the items from the New submenu back to the File menu; it would only increase the size of the menu by 3 over what you are suggesting. Is having a menu of 15 items really be that big of an issue to anyone? The File menu would still be smaller than the Go or Bookmarks menus and it would just barely be longer than the other menus.
Component: User Interface Design → XP Apps: GUI Features
adt:nsbeta1-
Keywords: nsbeta1 → nsbeta1-
i really agree with comment number 35.
I notice there are 3 close items in File now... which is inconsistent... I never use the File - Close items but I often use the File - New items. I agree, just stick em all in the top menu and be done. (BTW there should be separators around the 3 blocks: - New - Open - Close
Product: Core → Mozilla Application Suite
Well much water under the bridge now, clearly this applies to Seamonkey now. Anyone running the latest build (nightly) - maybe this has already been done?
Component: XP Apps: GUI Features → UI Design
Assignee: jglick → jag
QA Contact: zach
You need to log in before you can comment on or make changes to this bug.