Open Bug 135571 Opened 23 years ago Updated 16 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.