Open Bug 69555 Opened 24 years ago Updated 3 years ago

Go menu should be a submenu of View

Categories

(SeaMonkey :: UI Design, enhancement)

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

Tracking

(Not tracked)

People

(Reporter: mike_jk, Assigned: jag+mozilla)

References

Details

At the top, the Go menu should be taken out. It has Back, Forward, Home, and a 
history of previous visited sites. There really shouldn't be a menu for Back, 
Forward, and Home if that's what the Navigation buttons do. Plus you can also 
right click for the same menu. And whenever you right click on the Back or 
Forward buttons, you get a previous sites menu. If this menu can't be taken 
out, just put it somewhere else like under View like IE or have a sidebar for 
it.
--> xpapps
Assignee: pinkerton → pchen
Component: XP Toolkit/Widgets: Menus → XP Apps: GUI Features
Remember to keep accessibility in mind.  Forward and back have keys already, but
I don't know how to view the visited sites list using the keyboard, except
through the Go menu.
In general, any action that is accessible should also be accessible from a menu 
item.  Toolbars are there as shortcuts to menu functions, not the other way 
around.
ccing mpt because he wants to be cced on UI bugs.
mpt, here's the same old bug again.  I think it's time we do this already.
Assignee: pchen → blakeross
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: jrgm → sairuh
Summary: Go menu should be taken out or moved → Go menu should be a submenu of View
I agree entirely -- but not until people can make the toolbar containing the 
Back and Forward buttons much smaller. I.e., this bug depends (in a usability 
sense) on bug 22056.
Keywords: access
Huh?  I missed something.  How are the two bugs related?
oh great. in some other bug we have  people complaining that you can't 
consistently get back to appear as the first item of the context menu. so now i 
need to use view>go>back?  [assume i've never met a context menu, and refuse to 
acquaint myself w/ it now]
I don't think this is a good idea. The go menu has been in Navigator for a long
time and a lot of users rely on it to see most recent history. I agree with the
keyboard-only accessibility concerns also. Let's not do this!
i agree with german --the View menu already has quite a few items and i'd rather
not add to it; having Go as a submenu would appear cluttered, imho. recommend
wontfix. but feel free to persuade me otherwise. :)
I think the View menu is cluttered because it is full of useless items that 
users aren't going to use on a regular basis (Languages and Web Content, 
Character Coding, Apply Theme, anyone?).  And there are currently too many top-
level menus.

> lot of users rely on it to see most recent history.

Do you have usability data to back this up?  Because I sure haven't seen any 
evidence of it.  It took about four days ~2 months ago for anyone to realize 
that the Go menu was completely broken, and even then there were hardly any 
duplicates.  I realize this isn't representative of millions of average users, 
but just something to think about.
IE has Go To under the View menu. Maybe some submenus should be taken out and 
put somewhere else.
Useless items in the View menu should be taken out, Go should be the first 
submenu under View.
Dean: If people can have a narrow Toolbar, they won't need to turn it off 
completely in order to get enough real estate, so they'll still have access to 
session history (via the Back and Forward menubuttons) without having to go to 
the `Go' submenu. That's why I say this shouldn't be done until bug 22056 is 
fixed.

German: The `Go' menu was at the top level in Internet Explorer `forever', too. 
Then Microsoft pushed it into a submenu of `View', in recognition of the facts 
that (a) the job of a Web browser is to provide a minimalist interface 
surrounding complex content (rather than the other way around), and (b) it is 
extremely easy to access session history without `Go' being a top-level menu. As 
Blake says, there are too many top-level menus in Mozilla currently (not even 
counting `Debug' and `QA'), and too much stuff in the `View' menu which should be 
in the preferences or the profile manager instead.

And as for keyboard accessibility, on a QWERTY keyboard you couldn't get the 
mnemonics for `View' and `Go' (V and G) to be any closer to each other if you 
tried. Accessing it is very easy, in those uncommon cases where browsing and 
selecting from the session history titles would be quicker for a keyboard-only 
user than sticky-keying Alt then repeatedly pressing the Left key.

I suggest that the `View' menu look approximately like this:

_View
-----
  Show                              >
------------------------------------- _________________________________
::_Go:::::::::::::::::::::::::::::::>|  Back                  Alt+Left |
  _Stop                           Esc|  Forward               Alt+Right|
  _Reload                    Ctrl+R  |  Home                  Alt+Home |
  {Rel|L}oad Image{s}  Shift+Ctrl+R  |---------------------------------|
-------------------------------------|* Bugzilla bug 69555             |
  Text Si_ze                        >|  mozilla.org Bugzi...           |
  _Use Style                        >|  The Mozilla Project            |
  En_coding                         > """""""""""""""""""""""""""""""""
-------------------------------------
  _Full-Screen Mode
-------------------------------------
  Page Source/_Info          Ctrl+I

This places `Go' as the easiest item to get to in the menu (the second item, not 
the first, has been shown in usability studies to be the easiest to see and 
acquire in any pulldown menu), and also puts it right next to `Stop' where it 
logically belongs.

mpt: I agree it looks good and streamlined, but:
From my experience in usability tests over the last years too many beginning
users are relying on the items in the Go menu being in a top level menu. Some of
them actually never use the back/fwd buttons at all. I am afraid that the setup
you proposed will not be discoverable enough for the class of users that never
use secondary menus.
(BTW Debug and QA are never found in any of the commercial end-user builds...)
It's currently not easy to get the history list from the back/forward buttons, 
because the parts of those buttons that drop down the menu are small 
(especially in the Modern theme).  Bug 65726 might help, but the user would 
then have to wait for the menu to appear while holding the mouse button down.  
Making the buttons smaller using options from bug 22056 or bug 62444 would make 
it even harder to get the session history lists from the buttons, making the Go 
menu more important.

Btw, how would making Go a submenu of View make the interface more simple?
(Note that you can instantly get the lists by right clicking on the 
back/forward buttons, but then, not many people know that I'd assume).
not only to many people not know what the little triangles mean, but they are
also not accessible via keyboard.
Then the little triangles should be fixed, no?

In any case, Mozilla's default theme is Classic (which has much bigger, more 
sensible targets just like IE's) and I think we need to be designing around 
that.  It's ridiculous to try to come up with a usability compromise that works 
for all Mozilla themes when we can come up with a great one that works for the 
theme that most users will be using.
Maybe under View it should have: Back, Forward, Home, Stop, then a history of 
the 5 previous sites(if you want more then there will be a submenu that will 
list more), then have some submenus like: Toolbars, which will include 
Navigation Toolbar, Personal Toolbar, Taskbar, and My Sidebar(because in a way 
it is a toolbar). I don't think many people change these settings often, so it 
should go in a submenu. Some of the other items could go under a submenu called 
Page setup, which will include Text size, Translate, etc. At the end Apply 
Theme should be there because, I'm sure a lot of people will like to change the 
look. And because a lot of beginning users are relying on the Go menu, the menu 
should be called View/Go or Go View, so they know where it is. The View menu 
should be used for viewing previous sites(Go menu), and changing the look of 
the browser.
View/Go
--------------
Back
Forward
Reload
Stop
Home
--------------
Site 1
Site 2
Site 3
Site 4
Site 5
More>
--------------
Toolbars>
Page Setup>
Apply Theme>

This is just a thought.
The menu should be called "View/Go". Alt+V will open up the View menu. Go will 
be the first submenu under View. Alt+G will automatically open up the View menu 
and Go submenu, then you can select it just like you would in the Go menu now. 
Maybe the submenu should just appear. That submenu will act like a top level 
menu. The reason /Go should be after View is so that people will know that the 
Go menu is there and that Alt+G will work. 
I don't think this is a good idea:
a) a main menu never has two terms
b) View and Go as mentioned before are separate menus that do separate things:
- view mostly is intended setting/changing the presentation of content
- go is an extension of navigation control and history

both are so important in their own right that they should stay separate.

Then why does IE have Go(Go To)under View?
Firstly, we shouldn't use IE as a template for Navigator. Microsoft is horrible 
with keeping menu items similar across programs -- it seems to be totally 
arbitrary what they do, to me at least. Try finding preferences in IE. It's 
under Tools-->Internet Options, which is possibly the stupidist possible place 
to put it. Mozilla.org, I think, should take IE into account only if they do 
something we don't (fullscreen mode), or do something we do better (load up on 
Windows in less than ten minutes, which is an overstatement, granted).

Secondly, Go doesn't seem to have much to do with View to me. The real reason 
to clean to clean up the top menu items would be if there are A) too many top-
level menus or B) if you need to fit more menus up there. Looking at this bug 
from this direction, Go is actually pretty harmless (it's only two letters 
wide). 

Anyway, I think Go is a menu that's made specifically for newer users, and I 
doubt you'd convince Netscape to take it out given that. Communicator was 
targeted at higher-end business users, but Netscape 6 is being marketed at a 
broader audience (hence all the cute AOL-ized stuff, like the Splash screen). 
You don't want to alienate new users who may really like that menu. It's kind 
of like the "Go" button you see everywhere. "Go" is a buzzword, and Netscape 
helped make it popular, I think. 

I just don't see this happening without a real compelling reason to do so, and 
the only real reasons I've seen are from high-end user perspectives. I'd say 
it'd be worth a usability test, though, or inclusion in one, for future 
consideration. Though, as someone else said above, feel free to convince me 
otherwise. :)

James
As german said, 
  "view mostly is intended setting/changing the presentation of content"

(Re)Load Images belongs in the View menu. Of that I'm certain; the user doesn't
necessarily know that the images are separate packets. If loading images belongs 
in the View menu, then reloading should also be there--along with Stop; the two 
work as a pair.

Thus we arrive at the current state of affairs.

Now we would extend that logic to put Back and Forward in the View menu along 
with Reload and Stop--for all of these control the loading of a web page--and 
throw in the rest of the Go menu for the same reason. Besides, Stop and Go are 
opposites--shouldn't they be together?

But now we have relegated one of the ~most integral functions~ of a web browser 
to a submenu of a main menu. Even the viewer has back and forward buttons, 
though it lacks nearly everything else, including Stop and Reload menu items. 
The Go menu may be small and little-used, but it is by no means insignificant.

A line must be drawn between the View menu and the navigation menu. Where that 
is is arbitrary; it varies from browser to browser, even versions of the same. 
But I question that it should be drawn to include all the Go menu within View.

(In the current setup, that line separates navigation from all else. Stop and 
Reload don't take you anywhere; they just control loading while you're there.)
"Now we would extend that logic to put Back and Forward in the View menu along
with Reload and Stop--for all of these control the loading of a web page--and
throw in the rest of the Go menu for the same reason. Besides, Stop and Go are
opposites--shouldn't they be together?"

I think that the fact that Stop and Reload are already there on the View menu
is a compelling argument. But I bet AOL would argue that menu items, especially
those on the Go menu (which is useful for getting beginners up to speed) are
like action verb phrases:

"Go Back"
"Go Home"
"Go Forward"
Even the recent pages menu under Go makes sense if you assume a "to" before
every URL, as in "Go To http://www.blahblahblah.com"

These make sense, and these would be perfect for voice-activated
features later on. Just say "Go Home" and the menus click themselves.
You wouldn't say "View Go Home" or even "View Home", though "View Stop (or Stop
View)" and "View Reload" (or "Reload View" do make sense (more sense, anyway),
and that's why they're under View. That's my guess, anyway. It does explain the
abscence of "Stop" and "Reload" under the Go menu ("Go Stop" and "Go Reload"
don't make any sense).

-> UI:DF, send back to me when we have a settlement/compromise/decision-that-
everyone-won't-like-but-will-have-to-deal-with.
Assignee: blakeross → mpt
Component: XP Apps: GUI Features → User Interface: Design Feedback
QA Contact: sairuh → zach
Fixed by Ben in bug 85386. (Don't look at me ...)
Status: NEW → RESOLVED
Closed: 23 years ago
Component: User Interface Design → XP Apps: GUI Features
Depends on: 85386
Resolution: --- → FIXED
No longer depends on: 85386
"All these changes look excellent."  ;)
Regressed.
Status: RESOLVED → REOPENED
Keywords: access
Resolution: FIXED → ---
- make [go] a submenu of [view], is IE.


I guess a logic and coherent menu is one called "navigation".
Which is in directly relation with the Navigation toolbar and the tabs bar.
Then, is going to has the same options, but search and print:




[Navigation]
·----------------------.
| Back                 |
| Forward              |
| Reload               |
| Stop                 |
|\Go\\\\\\\\\\\\\\\\\\\|\-------------------------·
|----------------------|| * latinmoz.org          |
| Open Web Location... || * MozillaOnTheMoon.Sun  |
|----------------------|| * ...etc.               |
| New Tab              |·-------------------------·
| Close Tab            |
|\Go\To\Tab\\\\\\\\\\\\|\--------------· 
·----------------------·| * Tabs       | 
                        | * Actually   |
                        | * Opened     | 
                        ·--------------·




						...Is so funny draw with letters.


¿Why this [Navigation] menu?
i guess is not only me, sometimes i like to surf with only the menu bar, and if
i could hide the tabs bar too i would do it. I would surf with only the Menu and
the sidebar in Full Screen Mode.

¿What about 'Reload Tab', 'Reload All Tabs' and 'Close All Other Tabs'?
'Reload Tab': the 'Reload'(at the first group) will reload the tab which is
actually on the screen.
'Reload All Tabs' and 'Close All Other Tabs': they are not basic options.
If we have tabs, the inmediatly options needed is 'New' and 'Close'. Others are
enhancements. 'Go To Tab' is for if someday the Tabs Bar is allow to be hide
without close the opened pages.

'Open Web Location...': has in its own menu the options for open the address
into a new window, tab, or whatever.

All this eliminates the actuall [Go] menu; and the option 'Open Web Location...'
has this new place.


Please, read this Bug: http://bugzilla.mozilla.org/show_bug.cgi?id=129922

/.lancer





 ·¡hey! Dont forget to visit latinmoz: http://latinmoz.f2g.net/ ·
I think "Navigate" would be better than "Navigation" for a menu name.

JR
Reopened, man this must be a complete joke! Is this the way mozilla/netscape is
going to be? Hide and seek? Well say goodbye to your end users, they just
learned to use the damn thing and now someone is going to change all that yet
again! Pfff.
*** Bug 167932 has been marked as a duplicate of this bug. ***
Product: Core → Mozilla Application Suite
No comments in 5½ years.

IMHO, the Go menu, with all that it contains, sits better on the main menubar than it would as a submenu of the View menu, with which it is unrelated.

Maybe unite it with Bookmarks (as Bookmarks&History) but I'm against it: all top-level user bookmarks are in the Bm menu, and Go holds recent history, which make them (with Windows, but you won't get that many windows I suppose) the only menus which the user can easily extend indefinitely without even the need for an extension.

I move this bug be WONTFIXed. Anyone against?
It's been years since I even used Seamonkey, so this doesn't belong to me. I will note for the record, however, that while I think the Go menu *of the time* was useless enough to be relegated to a submenu, today's Web browsers have Go/History menus that are much longer and more useful (because they contain global history rather than window history), so they deserve top-level status. Not to mention that most of these newer Go/History menus have submenus of their own -- so making Go/History itself a submenu would produce subsubmenus, which would be a sin.
Assignee: mpt → nobody
Status: REOPENED → NEW
QA Contact: zach → guifeatures
Component: XP Apps: GUI Features → UI Design
Assignee: nobody → jag
QA Contact: guifeatures
You need to log in before you can comment on or make changes to this bug.