Closed Bug 135804 Opened 22 years ago Closed 21 years ago

Remove the New submenu from the File menu

Categories

(SeaMonkey :: UI Design, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: jruderman, Assigned: samir_bugzilla)

References

Details

Attachments

(1 file)

The browser's "File" menu contains a "New" submenu.  Most of the commands in the
submenu are for mail (hidden in navigator-only installs) and for composer.  "New
Navigator Window" and "New Navigator Tab" may be outside of the submenu, inside
the submenu, or in both places.  Each case looks silly in some way (for example,
if everything is only in the submenu, the first item in the File menu is a
submenu and a common operation is buried in a submenu).  Each case confuses
users' muscle memory because the "New" commands are always present, but are in
different places or in a different order depending on the component.

I suggest that we remove the New submenu, like we're doing for the Search
submenu (bug 135204).  "New Navigator Window" and "New Navigator Tab" would
appear in the file menu in navigator.  "New Message" and "New Folder" would
appear in the file menu in mail, with "New Folder" grouped with the other folder
commands.

I don't think "New Blank Page to Edit" (redundant with Window->Composer) or "New
Address Book card" will be missed.  If "New Message" needs to be available from
the browser (why?), I suggest moving it to the Window menu and calling it
"Compose E-mail".

Suggested by Michael Wardle in bug 121767 and by mpt in bug 135204 comment 7. 
For history, see bug 37537, bug 63133, bug 63134, and bug 135571.
I agree with moving New Window/Tab back to the main level and removing the New
sub-menu, but only so long as the other components each have their own specific
"New" commands at the top level, and not those of any other component.  (The
only New menu items seen under File should be those relating to the current
component.)
OS: Windows 98 → All
Hardware: PC → All
Mailnews needs:
New Message
New Folder
New Account
New Address Book card (I expect users to often want to do that)
That's enough to warrant a submenu IMO.
I don't know about this. new mail message is a reasonable action to want to
take, if you have mailnews installed. Maybe we could not show the submenu if
there is only the one option in it?
I use New Message a lot, but I suppose Send Link would be a workaround...
Wouldn't you just launch mail and click compose? That's two clicks, compared to
3 to access new message now! I don't understand those last two comments. 

This bug is in the spirit of splitting Mozilla up more cleanly, so that browser
only shows browser options/actions, etc. KISS, right?
For new message there is CTRL-M...
Hi. I'm using version 0.5 (Build ID: 2002090913). In the File menu there is a "New
Window" option (Command-N) and "New Tab" option (Command T). There is no "New"
submenu... i.e. WorksForMe! :-) Thanks.

Err... I would have marked it as such, but when I logged in it gave me an error,
and now the WORKSFORME option is gone. Oh well, I guess I'll just leave a comment.
Irk. Ignore previous comment. I linked into this bug from a chimera bug (in
which this is not an issue) :-[
uid is being phased out.
Assignee: mpt → blaker
Component: User Interface Design → XP Apps: GUI Features
QA Contact: zach → paw
I think it is valid to remove the submenus in both Navigator and Composer, but
as comment 2 says, Mail/News probably still needs the submenu as does Address
Book. As Neil says in comment 4, you can still create a new message via File ->
Send Page.

Comments anyone?

i.e. if a patch is made will it just get turned down?
->samir and jglick, i don't think we'd want this for buffy, right?
Assignee: blaker → sgehani
sairuh, and how about mozilla?
Huh? I know Buffy, but what the *heck* is Mozilla? Something like Godzilla in
form of Homer's barkeeper?
before you do things like this, how about making sure everything is reachable?

i can't find a way to add or remove tabs from the sidebar using the keyboard.

suppose I wanted to solve this using an extension, the easy way would be to add
file>new>tab. All my extension has to do today is overlay the new submenu.

If you decide to flatten navigator and not mailnews (because say you decide 2
new-s are ok flattened and 3 new-s are bad flattened), then i'd have to create
magic (lots of it) to *unflatten* the menu and create a new submenu. supposing
someone else comes along and decides to extend mozilla navigator in some
otherway. Perhaps they want "new (split) view" which would allow independent
scrolling of a single document. My extension doesn't predict the possibility of
that extension, and that extension doesn't predict the possibility of mine. So
you end up with both of us doing the same magic and you can have any of the
following:

File
 New Window
 Open Location...

[Someone browsing with tabbrowser removed]

File
 New Window
 New Tab
 Open Location...
["Normal"]

File
 New
  Window
  Tab
  Sidebar
 Open Location...
[My extension installed]

File
 New
  Window
  Tab
  View
 Open Location...
[other extension installed]

File
 New
  Window
  Tab
  Sidebar
 New
  Window
  Tab
  View
 Open Location...
[One way both extensions could be installed]


File
 New
  Window
  Tab
  View
 New
  Sidebar
 Open Location...
[Another way both extensions could be installed]

File
 New
  Window
  Tab
  View
 New
  Window
  Sidebar
 Open Location...
[Another way with both extensions installed and tabbrowsing removed, yes notice
that View wasn't written well and presumed tabbrowser existed]

Or you could have:

File 
 New Window
 New Tab
 New Sidebar
 New View
 Open Location...

which would really look bad when someone opens mailnews and gets

File
 New>
  Message
  Folder...
  Account...
  Contact
 Open Message <-- does anyone even know what that does?? (I know now that i used
it...)

Without an architecture (and simply saying you're going to flatten the current
system which happens to have a scalable specification removes any architecture)
you invite problems.
Forcing an additional click on users for a *very* frequent action (I personally
do that probably dozens (if not hundreds) of times daily) is too severe an
effect for more theoretical arguments like extensions. If you want, make an
additional New menu which only shows, if it contains something - extensions
could hook up there, if you really want that.

FYI, exactly this problem was one of the major reasons for me to decide for a
browser (I don't remember which) in the 4.x days - IIRC, MSIE 4.0 had
File|New|Window, and it annoyed the heck out of me.

Beonex Navigator has the menu flattened in 0.8.x.
keep in mind, even if mailnews isn't installed we want to have "File | New |
Message".  It, like File | Send Page and File | Send Link and mailto: urls would
just launch the default mail application.

I don't think File | New | Message shows up for browser only installs.

but that's a bug.  see bug #144828 and
http://www.mozilla.org/mailnews/altmail/index.html

the reason is the overlay for that lives in the mailnews package, but that will
change when #144828 is fixed.

since File | New | Message is going to be there, and we have New Window and New
Tab, I don't think we should be flatten the File | New menu.
Why do you want File -> New -> Message?

If i want to create a blank message, i'll open my mail client and create a new
message. if i want to do something relevent to the browser (click a mailto link,
send a link to this page via email, etc) then i can do that from the browser.
btw, what do you expect to happen if i have no email client installed at all?

You may say that New Message is "useful", but then maybe i want to write a
letter - should we then also include File -> New -> Word Processer Document (and
so on).

Anyhow, that's just my opinion. You are the Mail/News owner so you have final
say (rightfully) over what goes in to that component, therefore (unless you
change your mind:) the New menu will stay in Mail/News. As for the other
components, i presume this isn't wanted there either? (in which case i'll mark
this wontfix)

Um, Piers, you're not thinking of Chimera or some other browser-only product,
are you?

I actually have a vote on this bug, so you know what my opinion is, but "File ->
New -> Word Processer Document" isn't a fair argument because Mozilla doesn't
include a Word Processor.
I think that composing emails and reading emails are 2 equal tasks. Personally,
I think that File|New|Message in the browser makes no sense, just as "File|Show
New Emails for me" make no sense in a browser. (File|Send Link is different,
because there's a relation to the browser.)
Erh, so ... I think it'd be okay to have "New Navigator Window" and "New
Navigator Tab" in the File menu, and the other items in the "New" submenu. For
Mail/News, "New Message" would be in the File menu, with the other items in the
"New" submenu, etc. (i.e. put the most frequently accessed "new" actions in the
File menu itself). I seem to recall however that this was how things were in
pre-Moz1.0 versions of Mozilla, and then we did the big menu reorg. and moved
all "new" things into the New submenu.

jglick, do you recall what our reasoning for this was?
Never mind, just found the e-mail you sent on this issue.

We talked about this issue (as part of the menu reorg) at various pixeljockeys
meetings and found that it was less confusing if all the "new" items were
grouped together, either in the top level menu, or in a "new" sub menu. Since
the former would make the "File" menu too large, the latter was chosen.

We're not going to revisit this issue, marking this bug wontfix.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → WONTFIX
>Never mind, just found the e-mail you sent on this issue.

It was the topic of a pixel jockies meeting way back. Consistency of all apps vs
each component implementing this differently.

If we flatten the File: New menu, Browser has just two items, Window and Tab,
but Mail has 3 and Address Book has 4 app specific new items, which makes the
File menu sorta long.

Originally (before we made this change, menu reorg), if i remember correctly, we
had "New App Specific Window" in the File menu, but any additional app specific
new menu items were in the New flyout with the other cross app New items. (For
example, New Message was in the File menu but New Folder was in the New flyout).
But, we saw this was a problem in usability studies. Some of the New items
specific to the app were in the File menu while others were in in the New
flyout. Users had trouble finding what they were looking for. Hence, the
decision to keep all app specific New menu items grouped together. 

This lead to two options, keep them all together in the File menu itself, or
keep them all together in the New flyout. Since Mail and AB have 3 and 4 app
specific menu items, the New flyout seemed more logical for Mail and AB. If we
wanted to keep all apps the consistent, Browser would need to follow as well. 
2 arguments to consider:
- UI studies don't cover routinated users who repeat actions hundreds of times
per day. Also, I think the UI study didn't cover the case where the apps are
inconsistent (flat for browser, submenu for mailnews), as proposed in this bug.
- Some users don't care and don't want Mailnews, only the browser, and bugs like
this make them suffer for Mailnews. This makes the argument of the "bloated"
Communicator package valid :-(.
*** Bug 200053 has been marked as a duplicate of this bug. ***
For those that use File/New/stupid stuff, can't you use ctrl+m or type
mailto:someone@nowhere.com into the url bar?

Think the wontfix was dumb.
Did any one read the new roadmap http://www.mozilla.org/roadmap.html

Here's a quote

Another example of the high cost of app-suite integration is the inherently
overloaded and complicated user interface (just one example out of too many: the
File / New sub-menu). The target audience of the suite was never clear, and
seemed to shift back and forth with prevailing business- and
voluntary-contributor-driven winds. Hyatt's blog is an effective summary of the
case against this approach. Simply put: great applications cannot be managed as
common land, with whoever is most motivated in a particular area, or just the
last to check in, determining the piecewise look and feel of the application.

Doesn't anybody agree?
Sure, lots of people agree, the problem is some (lots?) people disagree as well.

Also in the roadmap, they mention that they aim to keep a high-level of
integration for those who want it - they want to please both schools.

Personally, I think the managability is pretty important. If you can separate
things out, it makes it easier to keep responsibilities clear and manage
projects separately - especially as open source.
I don't really understand the new roadmap, but I think it says that Mozilla
won't be a suite anymore. So if it's not a suite, should the submenu be removed
now that the roadmap wants change? Am I interpreting the roadmap wrongly?
Product: Core → Mozilla Application Suite
Component: XP Apps: GUI Features → UI Design
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: