Reorganizing/renaming the Tasks menu
Henri Sivonen
http://bugzilla.mozilla.org/buglist.cgi?bug_id=48748,32502,17767,75546
Background:
The Tasks menu is a mess. Bugs have been filed on various aspects of the
Tasks menu, but little has been implemented. Bug 48748 (reported by me)
was at first WONTFIXed based on Netscape's disinterest. It was then
reopened and WONTFIXed by mpt. Now Netscape's interests have changed and
a fix was checked into the Mozilla tree against the opinion of mpt
(UI:Design Feedback owner). The fix has since been backed out.
Approval process issues:
I think the way this bug has been handled by Netscape is a bad sign.
(WONTFIXing because of Netscape's schedule. Then checking in against the
opinion of the component owner and before further discussion.) This sort
of thing shouldn't happen. (I think the name of the menu should be
changed, but the change shouldn't happen in this way.)
To get back to the changes to the UI...
Issues:
* Based on experience from other apps (on Mac and Windows at least), the
user expects to find a list of the open windows in a menu calledM
"Window". The is no menu called "Window" in Mozilla. This makes the
list of open windows harder to find.
* The Aqua HIG says that apps should provide a menu called "Window".
* It has been argued that the Tasks menu shouldn't be renamed "Window",
because
- The Privacy and Security & Tools submenus don't belong in a menu
called "Window"
- The component switching menu items don't belong in a menu called
"Window"
* However,
- Several popular apps including Adobe Photoshop, Adobe ImageReady,
Macromedia FreeHand, IE 5 Macintosh Editition, Anarchie and
MT-Newswather include items that open auxiliary windows or palettes
in their "Window(s)" menus.
- Other apps don't have component switching in the window menu,
because normally, a Web browser, an email client, a newsreader, a
Web page editor and a chat client would all appear as separate apps.
(On Mac OS X the most natural menu for these would be the Mozilla
menu that only exists on Mac OS X.)
* mpt has argued that a "Window" menu is only needed on Mac, because
users of other platforms aren't used to having such a menu and because
other platforms have better window swithing mechanisms. I disagree.
- I don't think the lack of precedence on other (or actually Unix)
platforms is a reason enough to maintain different menu structures
for different platforms. If other platforms had an established
different name for such a menu, then an overlay would make sense.
- The window switching mechanisms on other platforms aren't really
that good. X11 window managers and the Windows taskbar don't group
windows by app. This makes it harder to use the window manager
facilities for switching between Mozilla's windows only, if there
are a lot of other windows open. Also, the names might be truncated.
If the first few letters of the page title are indentical on all
pages of a given site, a window swither that only displays truncated
names is mostly useless. For example, in CDE on Solaris and IRIX,
you have to turn on a pref to see the list of open windows in the
first place. The window switcher that appears is badly designed and
takes a lot of screen real estate. At least on Solaris, the names
are truncated so much that they are next to useless.
- To my knowledge, only Mac OS X, BeOS and (reportedly) Windows XP
provide window manager level window switching with windows grouped
by app.
- Despite the fact that Mac OS X provides window switching through the
Dock, the UI folks at Apple have chosen to make the practice of
including a "Window" menu explicit in the Aqua HIG.
* The name "Tools" has been suggested, but that doesn't make the open
window list more discoverable, since the menu name is expected to be
"Window"
Questions:
* Could the Tasks menu be renamed "Window" first and the extra submenus
be relocated later?
* Could the Tools and Privacy and Security submenus be moved to a
separate top-level menu called "Tools" to enhance the discoverability
of those items?
--
Henri Sivonen
hen...@clinet.fi
http://www.clinet.fi/~henris/
Rolan...@seb.se
[lots of reasoning]
> Questions:
> * Could the Tasks menu be renamed "Window" first and the
> extra submenus be relocated later?
>
> * Could the Tools and Privacy and Security submenus be moved to a
> separate top-level menu called "Tools" to enhance the
> discoverability of those items?
Personaly I have never had a problem with "Tasks" menu, but if you must
change menu name to "Window" (for all the obvious reasons), You should most
ceartainly create another top level menu called "Tools" with Security prefs
and current Tasks->Tools stationed there. It would possibly serve also as a
default space for any 3rd party tool's menu items (That's the first place
I'd look for them).
The positioning of Mail, Navigator, Composer, etc. menuitems (wether Tools
or Window) is arguable though...
german
This was my response to what Blake on said Bugzilla bug, I thought it
might be of general interest to the newsgroup to better highlight the
motivation behind the proposed menu name change for the next version of
Netscape from "Tasks" to "Window" (the paragraphs marked with asterik
are the questions asked by Blake to which I responded).
* What changed in the past few years such that millions of Netscape 4.x
users understood that version's name for this menu -- "Communicator" --
but now they expect "Window".
- Communicator is a Netscape tradmarked name no longer being used by
this product. As an aside, market research (yes this is based on
confidential data) showed us that Communcicator had a much worse
recognition rate then either Netscape (best) or Navigator (second best).
Communicator literally had no meaning to the majority of folks surveyed
despite marketings best effort in the late 90's to establish it as a
household name of the suchnamed suite of net applications. There is no
legacy here worthy continuing for Netscape 6 and beyond.
* Or, if the millions of 4.x users didn't understand "Communicator",
what kind of data led you to believe (incorrectly) that "Tasks" was the
name they wanted.
* Why you're confident that "Window" will be -- after two other attempts
-- the correct name.
I do not think there is much of an established base of Netscape 6 just
yet. We'll continue to learn from actual usage and refine the product as
needed. "Tasks' was the best educated guess at the time of the initial
design based on a relatively small sample of observations.
* Why changing this menu's name from version to version until you get it
right will *reduce* confusion among users.
- It's a process called design iteration. Design gets actually gets
iteratedbeyond the launch of the product and into subsequent versions
based on more and more usage data is coming in. For example for the
Netscape 6 browser there is a certain of usage data after the product
has been launched that we can track to better understand usage patterns
of the RTM version.
* In general, I think people are tired of this confidential usability
info that seems to change from version to version.
I understand your frustration but there is a lot of usage data that is
strictly AOL/Netscape confidential that I will not be able share with
the public at all. However as far as I know most Netscape client
usability studies that involve generic/public product parts can be
attended folks outside Netscape.
Gervase Markham
> default space for any 3rd party tool's menu items (That's the first place
> I'd look for them).
Indeed. Just what I was about to say. Things like, er, View | Translate,
for example ;-)
http://bugzilla.mozilla.org/show_bug.cgi?id=77207
Gerv
Jennifer Glick
I think it is difficult to find an accurate name for this menu item because
it is sort of a mixed bag of stuff. Some ideas:
ONE
What about breaking it into 2 separate menus? Yes, that means more menus but
they would be more shallow and make it easier for people to find what they
are looking for.
"Windows" could contain the window management type stuffs:
Navigator
Mail
IM (Netscape)
Composer
AB
-----
Open Windows
"Tools" could contain the more feature oriented stuff:
- Privacy and Security (or list out the items in its submenu)
- Tools submenu itemsSince this menu is a mix of Window and Tools/Tasks
related items, its tough to find a word that accurately describes its
contents.
TWO
What about using the name of the application for this menu item? Similar to
4.x which used "Communicator". "Netscape" for the NS version and "Mozilla"
(or whatever is appropriate) for the Mozilla version?
Blake Ross
No, Windows XP offers this capability. Microsoft realized that this is the
job of the OS, not the app...
--Blake
"Henri Sivonen" <hen...@clinet.fi> wrote in message
news:henris-DFFB06....@uutiset.saunalahti.fi...
Henri Sivonen
<jgl...@netscape.com> wrote:
> I think it is difficult to find an accurate name for this menu item
> because it is sort of a mixed bag of stuff.
I agree. The Tasks menu will continue to be a mess whatever the name, if
it is a menu for items that didn't fit anywhere else.
> ONE
> What about breaking it into 2 separate menus?
I think splitting the menu into "Tools" and "Window" would be a good
thing. Then there would be one more menu, unless one other menu is
absorbed to the other menus.
If one more menu is a problem, I think the Search menu is a good
candidate to go.
* The usual (and HIG-compliant) placement of "Find [on Page]" and "Find
Again" is in the Edit menu.
* "Seach the Web" is basically a product placement bookmark. Is an item
outside the "Bookmarks" menu needed *in Mozilla*? There is already a
more conspicuous "Seach" button in the toolbar.
* The "Seach Bookmarks/History" item could be handled in various ways
- Making the "Find on Page" menu item change when the Bookmarks window
or the History window is the frontmost Window
- Putting the item in the Bookmarks menu
- Putting the item in the Edit menu
* "My Sidebar Seach Tab" shouldn't be a menu item at all. It should be a
pref.
> TWO
> What about using the name of the application for this menu item? Similar
> to 4.x which used "Communicator". "Netscape" for the NS version and
> "Mozilla" (or whatever is appropriate) for the Mozilla version?
I don't like that alternative. The menu would still be a mixed leftover
menu and the name is already used on Mac OS X. Having to different
"Mozilla" menus would look like a serious design flaw.
Henri Sivonen
<blak...@telocity.com> wrote:
> > the Windows taskbar don't group windows by app.
>
> No, Windows XP offers this capability. Microsoft realized that this is
> the job of the OS, not the app...
> > - To my knowledge, only Mac OS X, BeOS and (reportedly) Windows XP
> > provide window manager level window switching with windows grouped
> > by app.
However, Windows XP wont fix existing versions of Windows and Mozilla
also runs on those. Mac OS X offers per app grouped window switching,
too, but having a "Window" menu was made a HI guideline, nonetheless.
Peter Trudelle
>What about breaking it into 2 separate menus? Yes, that means more menus but they would be more shallow and make it easier for people to find what they are looking for.
>
>"Windows" could contain the window management type stuffs:
>
><snip
>
>"Tools" could contain the more feature oriented stuff:
>
I think this could be a good solution, and would help avoid getting the
bends diving into the cookie/password manager menus. ;-) Do we have
enough space in all the menubars?
>What about using the name of the application for this menu item? Similar to 4.x which used "Communicator". "Netscape" for the NS version and "Mozilla" (or whatever is appropriate) for the Mozilla version?
>
I never thought that made much sense, it doesn't really tell you
anything about what is in the menu.
Peter
JTK
says...
[snip]
>Approval process issues:
>I think the way this bug has been handled by Netscape is a bad sign.
>(WONTFIXing because of Netscape's schedule. Then checking in against the
>opinion of the component owner and before further discussion.) This sort
>of thing shouldn't happen. (I think the name of the menu should be
>changed, but the change shouldn't happen in this way.)
>
Welcome to the world of "Open Source".
JTK
"Whatsoever thy hand findeth to do, do it with thy might; for there is no work, nor device, nor knowledge, nor wisdom, in the grave, whither thou goest." - Ecclesiastes 9:10
Ian Davey
>>Approval process issues:
>>I think the way this bug has been handled by Netscape is a bad sign.
>>(WONTFIXing because of Netscape's schedule. Then checking in against the
>>opinion of the component owner and before further discussion.) This sort
>>of thing shouldn't happen. (I think the name of the menu should be
>>changed, but the change shouldn't happen in this way.)
>>
>
>Welcome to the world of "Open Source".
Welcome to the world of "programming". All projects need management, whether
open or closed source. In fact, in open source these decisions are far more
likely to be in the open, so you can apply pressure to get a different
outcome.
ian.
\ /
(@_@) http://www.eclipse.co.uk/sweetdespise/ (dark literature)
/(&)\ http://www.eclipse.co.uk/sweetdespise/libertycaptions/ (art)
| |
Blake Ross
9x/NT series will be extinct any time soon, but we should be thinking ahead
as well, and XP is the future of both product lines...
--Blake
"Henri Sivonen" <hen...@clinet.fi> wrote in message
news:henris-B3923C....@uutiset.saunalahti.fi...
Henri Sivonen
<blak...@telocity.com> wrote:
> I'm not saying the 9x/NT series will be extinct any time soon,
> but we should be thinking ahead as well, and XP is the future
> of both product lines...
A menu called "Window" wouldn't be bad for Windows XP users.
Andy
>
> * mpt has argued that a "Window" menu is only needed on Mac, because
> users of other platforms aren't used to having such a menu and because
> other platforms have better window swithing mechanisms. I disagree.
This I find very surprising. I great many Windows apps that I use have a
window switching menu called "Window". I would have characterised it as
a Windows-ism. I've seen it on Linux also.
Given I believe the practice originates on Windows and the new Apple
Guidelines recommend it, and its not unknown on Linux I'd say changing
the name is perilously close to a no-brainer.
Of course, the tasks menu does more than switch windows, but that's a
seperate discussion?
--
AndyT (lordpixel)
Matthew Thomas
>...
> * Based on experience from other apps (on Mac and Windows at least),
> the user expects to find a list of the open windows in a menu
> calledM "Window".
I don't think this is very accurate.
On Windows, applications only have a `Window' menu if they have (or
recently had) an MDI windowing model. Non-MDI applications, such as
Internet Explorer, Windows Paint, Microsoft Publisher 2000, Notepad,
etc, have no such menu. Mozilla has (thankfully) never had an MDI
windowing model.
Many, but not all, Mac OS applications have a `Window' menu. BBEdit, for
example, has not a `Window' menu, but a `Windows' menu. The Mac OS
Finder itself did not get a `Window' menu until Mac OS 9.x. I agree that
Mac users expect a `Window' or similar menu listing the windows in the
current app, but I don't think the same can be said for users of other OSes.
> The is no menu called "Window" in Mozilla. This
> makes the list of open windows harder to find.
True, but only if you're expecting to find such a list.
> * The Aqua HIG says that apps should provide a menu called "Window".
Yes, and for that reason we should include such a menu on Mac OS X --
and on Mac OS Classic, because it's semi-standard there. But we
shouldn't force that on other OSes which don't need it.
Similarly, we should have `About', `Preferences ...' and `Quit' in their
own menu on Mac OS X. It doesn't make much sense, but it's the OS
standard, and we won't gain lots of usability by not doing it. But we
shouldn't force that on other OSes for which that is not the standard.
> * It has been argued that the Tasks menu shouldn't be renamed
> "Window", because
> - The Privacy and Security & Tools submenus don't belong in a menu
> called "Window"
> - The component switching menu items don't belong in a menu called
> "Window"
As I commented in bug 48748, in an average situation where you have two
Mozilla windows open, less than 10 percent of the items in the `Tasks'
menu are to do with windowing functions. To call the menu `Window' in
such a situation would be, in my opinion, daft.
> * However,
> - Several popular apps including Adobe Photoshop, Adobe ImageReady,
> Macromedia FreeHand, IE 5 Macintosh Editition, Anarchie and
> MT-Newswather include items that open auxiliary windows or
> palettes in their "Window(s)" menus.
Such applications normally limit these non-windowing commands to about
three or four at most. Even then, I find it very poor UI. No matter how
often I use IE 5 Macintosh Edition, I still regularly open the `Tools'
menu looking for the History window. It's not there, it's in the
`Window' menu, which makes no sense because it's not one of the windows
I currently have open. (Similarly when using IE 5.0 for Windows, I
regularly open the `Tools' menu looking for the History window. Again,
it's not there, but this time it's under `View' > `Explorer Bar'. Gee, obvious.)
>...
> * mpt has argued that a "Window" menu is only needed on Mac, because
> users of other platforms aren't used to having such a menu and
> because other platforms have better window swithing mechanisms. I
> disagree.
> - I don't think the lack of precedence
I don't think it's fair to use `precedence' to imply that other OSes are
at fault, and will eventually see the error of their ways by introducing
a list of open windows in an application's menu structure. I doubt very
much that that's going to happen.
> on other (or actually Unix)
and Windows
> platforms is a reason enough to maintain different menu structures
> for different platforms. If other platforms had an established
> different name for such a menu, then an overlay would make sense.
As I described above, non-MDI apps on other platforms typically don't
have such a menu at all. So yes, I think an overlay makes sense.
> - The window switching mechanisms on other platforms aren't really
> that good.
The UI for window switching on Windows is reasonable, if you put aside
Microsoft's flagrant disregard for Fitt's Law (placing the taskbar
buttons a couple of pixels away from the bottom of the screen, thereby
narrowly preventing quick use of the taskbar). In fact, it's probably
the best window-switching UI I've seen (though there are probably better
UIs, which I haven't seen, for various Unix window managers).
The UI for window switching on Linux and other Unices depends entirely
on what window manager you are using, and what other window-switching
utilities you are running. If you find window switching too difficult,
you are quite able (and, I would suggest, expected) to install the
relevant software to make it easier.
The UI for window switching on Mac OS Classic is awful. (And I say that
as a dyed-in-the-wool Mac OS Classic user.) The OS provides a method of
switching between applications (using the application menu, or
(Shift+)Command+Tab), but it provides no way of accessing an arbitrary
window within a non-frontmost application, short of moving the other
windows out of the way and clicking the one you want.
As a result, each Mac OS application is expected to implement its own UI
for switching between its own windows. This usually takes the form of a
`Window' or `Windows' menu, which jumps about in the menu bar depending
on how many other menus that application happens to have. In addition,
therre is sometimes a keyboard shortcut (which is delightfully
inconsistent between apps) for cycling through the windows of that app.
This means that switching to a particular window is usually a two-step
process: choose the application you want from the application menu, then
choose the window you want from the Window menu. And given that the
current version of Mac OS Classic -- OS 9.1 -- is almost certainly going
to be the last, this unfortunate situation is not going to change.
The UI for window switching on Mac OS X is awful, but in a whole
different way. Open windows are represented in the Dock (which you might
have hidden completely, since it takes up so much space) along with open
applications, frequently-used applications, and the Trash, and the
distinction between these different types of items is pretty poor. To
make things worse, the items aren't labelled, so you often have to hover
over each one to see whether it's the one you want. Mac OS X is very
new, so this situation should improve over time, but it will take a
while for Apple to eat some humble pie and make major changes to the
Dock. In the meantime, the Aqua HIGs recommend that apps have a `Window'
menu, so that users' ability to switch between windows can at least be
about the same as it was in Mac OS Classic.
> X11 window managers and the Windows taskbar don't group
> windows by app. This makes it harder to use the window manager
> facilities for switching between Mozilla's windows only, if there
> are a lot of other windows open.
You appear to be suggesting that if I am a Linux/Unix users, the UI for
switching between a window in my Web browser (Navigator) and a window in
my mail client (Mozilla Messenger) should be different than the UI for
switching between a window in my mail client (Mozilla Messenger) and a
window in my text editor (NEdit). I don't think that argument holds much weight.
Even if Mozilla's applications were separate executables, the presence
of a list of Navigator windows in the menus would imply that the UI for
switching between my online banking (Foo Bank Corp. in a Navigator
window) and my news reading (BBC News Online in a Navigator window)
should be different from the UI for switching between my online banking
(Foo Bank Corp. in a Navigator window) and my music searching
(Gnutella). I don't think that makes much sense either.
> Also, the names might be
> truncated.
Better that than on Mac OS X, where they're not shown at all. :-/ On
both Windows (98 and later) and Mac OS X, the full title is shown on
mouseover; Windows is better in this respect, because it at least shows
some of the title without mouseover.
> If the first few letters of the page title are
> indentical on all pages of a given site, a window swither that
> only displays truncated names is mostly useless.
Much more often it's the case that the first few *words*, or even the
entire page title, are identical on pages of a poorly-designed site. In
that situation, even a `Window' menu will be mostly useless, because all
the items in it (which will often themselves be truncated) will be the same.
> For example, in
> CDE on Solaris and IRIX, you have to turn on a pref to see the
> list of open windows in the first place. The window switcher that
> appears is badly designed and takes a lot of screen real estate.
> At least on Solaris, the names are truncated so much that they are
> next to useless.
I think it's fair to say that CDE is deprecated. :-)
> - To my knowledge, only Mac OS X, BeOS and (reportedly) Windows XP
> provide window manager level window switching with windows grouped
> by app.
I regard that as a bug, rather than a feature, for the reasons given above.
> - Despite the fact that Mac OS X provides window switching through
> the Dock, the UI folks at Apple have chosen to make the practice
> of including a "Window" menu explicit in the Aqua HIG.
So, they realize the problems the Dock has. My opinion of them just went
up an iota or two.
> * The name "Tools" has been suggested, but that doesn't make the open
> window list more discoverable, since the menu name is expected to be
> "Window"
That's rather disingenuous, because when I suggested the name `Tools' I
took care at the same time to recommend that the list of open windows be
removed from the menu. To have a list of open windows in a `Tools' menu
would be just as daft as having `Allow Cookies From this Site' in a
`Window' menu.
Another reason to have a separate `Tools' menu is that especially once
Mozilla reaches final release, I think there will be a lot of add-on
tools appearing, and a lot of people wanting to add their own favorite
feature to Mozilla (HTML validators, anonymizers, What's Related, etc).
I think a good way of managing the chaos would be to make such features
pluggable, and provide UI for them at the bottom of the `Tools' menu.
One such tool is the page translation feature which is currently
(incongruously) in the `View' menu.
> Questions:
> * Could the Tasks menu be renamed "Window" first and the extra
> submenus be relocated later?
Probably not, given that nearly *all* of the items in the menu are not
windowing-related. It would be quicker to introduce a new `Window' menu
on those platforms where the platform's own window-switching UI is
stuffed up for Mozilla to need such a menu (i.e. Mac OS), than to rename
the `Tasks' menu as `Window' and then move nearly all the items out of it.
> * Could the Tools and Privacy and Security submenus be moved to a
> separate top-level menu called "Tools" to enhance the
> discoverability of those items?
>...
That is exactly what I am suggesting.
--
Matthew `mpt' Thomas, Mozilla UI Design component owner
<http://mozilla.org/>
Henri Sivonen
(Matthew Thomas) wrote:
> Henri Sivonen wrote:
> >...
> > * Based on experience from other apps (on Mac and Windows at least),
> > the user expects to find a list of the open windows in a menu
> > calledM "Window".
>
> I don't think this is very accurate.
>
> On Windows, applications only have a `Window' menu if they have (or
> recently had) an MDI windowing model.
There are (unfortunately) quite a few MDI apps. Are you sure that
Windows users aren't trying to apply their MDI habits to SDI apps?
> > The is no menu called "Window" in Mozilla. This
> > makes the list of open windows harder to find.
>
> True, but only if you're expecting to find such a list.
At least Mac users are. Probably Windows users who are used to using
such a menu in MS Office are too, if they haven't made the careful
observation that the menu is usually present in MDI apps.
German: Are you allowed to disclose platform details of the usability
study findings?
> > * The Aqua HIG says that apps should provide a menu called "Window".
>
> Yes, and for that reason we should include such a menu on Mac OS X --
> and on Mac OS Classic, because it's semi-standard there. But we
> shouldn't force that on other OSes which don't need it.
On CDE platforms an app-provided window switcher is needed more badly
than on Mac OS X.
> > platforms is a reason enough to maintain different menu structures
> > for different platforms. If other platforms had an established
> > different name for such a menu, then an overlay would make sense.
>
> As I described above, non-MDI apps on other platforms typically don't
> have such a menu at all. So yes, I think an overlay makes sense.
Could the visibility of the "Window" menu be made a (hidden) pref
defaulting to "on" on Mac OS Classic, Mac OS X and CDE platforms and to
"off" elsewhere? Platform overlays can't be adjusted on a per user basis
but prefs can.
> The UI for window switching on Windows is reasonable, if you put aside
> Microsoft's flagrant disregard for Fitt's Law (placing the taskbar
> buttons a couple of pixels away from the bottom of the screen, thereby
> narrowly preventing quick use of the taskbar). In fact, it's probably
> the best window-switching UI I've seen (though there are probably better
> UIs, which I haven't seen, for various Unix window managers).
I am quite surprised. If you have a small screen and couple of dozen
top-level windows open, the Taskbar doesn't work well at all.
> The UI for window switching on Linux and other Unices depends entirely
> on what window manager you are using, and what other window-switching
> utilities you are running. If you find window switching too difficult,
> you are quite able (and, I would suggest, expected) to install the
> relevant software to make it easier.
Replacing the window manager is not always a realistic option.
For example, I use fvwm2 in an environment where the OS underneath the
window manager is GNU/Linux, Solaris, HP-UX or Tru64 Unix depending on
the computer in front of which I happen to sit down. If I wanted to
replace the window manager, I'd have to install and test binaries on
four platforms and make sure the same configuration files in my home
directory work on all the platforms. Of course, I'd have to convince the
admin staff that this sort of thing is worth the required disk space.
(Very unlikely to happen.)
> The UI for window switching on Mac OS X is awful, but in a whole
> different way. Open windows are represented in the Dock (which you might
> have hidden completely, since it takes up so much space) along with open
> applications, frequently-used applications, and the Trash,
That is not entirely accurate. Only *minimized* open windows, open apps,
frequently used apps, frequently used files, frequently used folders,
Docklings and the Trash appear in the Dock. It is actually surprisingly
easy to see the difference between the different kinds of items.
However, recognizing a particular minimized window among the other
minimized windows is difficult.
> > X11 window managers and the Windows taskbar don't group
> > windows by app. This makes it harder to use the window manager
> > facilities for switching between Mozilla's windows only, if there
> > are a lot of other windows open.
>
> You appear to be suggesting that if I am a Linux/Unix users, the UI for
> switching between a window in my Web browser (Navigator) and a window in
> my mail client (Mozilla Messenger) should be different than the UI for
> switching between a window in my mail client (Mozilla Messenger) and a
> window in my text editor (NEdit).
Yes, but only because Mail&News happens to be strangely implemented
inside the browser app. Normally, the mail app and the browser would be
separate.
> Even if Mozilla's applications were separate executables, the presence
...
If I have a dozen browser windows open and two dozen other windows open
and I want to switch from one browser window to another, I want to look
at a list of a dozen browser windows instead of a list of three dozen
windows.
> > Also, the names might be
> > truncated.
>
> Better that than on Mac OS X, where they're not shown at all. :-/
On Mac OS X, you can get a list of the window beloging to an app by
right-clicking, control-clicking or click&holding the icon of the app in
the Dock. The window list isn't visible on eg. WindowMaker either,
unless you invoke the menu using the mouse (in which case all the
windows of all apps appear in the same menu).
> > For example, in
> > CDE on Solaris and IRIX, you have to turn on a pref to see the
> > list of open windows in the first place. The window switcher that
> > appears is badly designed and takes a lot of screen real estate.
> > At least on Solaris, the names are truncated so much that they are
> > next to useless.
>
> I think it's fair to say that CDE is deprecated. :-)
Maybe so, but Mac OS Classic and Windows 9x are also deprecated and work
is still done to keep Mozilla running on those platforms.
I maintain a Mozilla installation in an environment, where we have
Solaris on Sparc, Solaris on Intel and IRIX systems. I think the other
users wouldn't have appreciated it if I had recommended they replace the
default window manager even if a binary might not be available on Intel
and the configuration changes on the Solaris side might break things on
IRIX.
> > - To my knowledge, only Mac OS X, BeOS and (reportedly) Windows XP
> > provide window manager level window switching with windows grouped
> > by app.
>
> I regard that as a bug, rather than a feature, for the reasons given
> above.
We disagree on this point.
> > * The name "Tools" has been suggested, but that doesn't make the open
> > window list more discoverable, since the menu name is expected to be
> > "Window"
>
> That's rather disingenuous, because when I suggested the name `Tools' I
> took care at the same time to recommend that the list of open windows be
> removed from the menu.
Based on subsequent comments made by other in bug 48748, I though that
merely renaming the menu to "Tools" was considered a candidate course of
action.
> > * Could the Tools and Privacy and Security submenus be moved to a
> > separate top-level menu called "Tools" to enhance the
> > discoverability of those items?
> >...
>
> That is exactly what I am suggesting.
Great.
But you are also suggesting removing the window list on non-Mac
platforms--including CDE platforms where I need the window list all the
time.
Matthew Thomas
>
> Jennifer Glick wrote:
> >
> > What about breaking it into 2 separate menus? Yes, that means more
> > menus but they would be more shallow and make it easier for people
> > to find what they are looking for.
> I think this could be a good solution, and would help avoid getting
> the bends diving into the cookie/password manager menus. ;-) Do we
> have enough space in all the menubars?
Not really ... unless (a) you have your windows maximized all the time,
or (b) you're on Mac OS with its global menu bar. (That wasn't a factor
in my recommendation that the `Window' menu only be present on Mac OS,
but it is a harmonious coincidence.)
On Windows, it's a continuing annoyance that the number of menus which
can be comfortably shown for a particular window is beholden to the
width of the window. In my experience, this often leads to windows being
maximized when they otherwise wouldn't have been, reducing my ability to
multitask effectively by showing more than one window on-screen at once.
Windows does wrap menu bars to multiple rows if the window is too narrow
to show them all in one row, but that has the severe problem that if you
accidentally click on a menu in the top row, menus on the lower row(s)
are hidden from view. (Blake tells me that XP Toolkit doesn't even do
the wrapping, yet, so if your window is narrow enough you lose the
rightmost menus completely. I wonder what happens if you navigate to the
missing menus using the keyboard ...)
Mac OS doesn't have so much of a problem here, because the menu bar goes
(nearly) all the way across the top of the screen no matter how big or
small the window is. Even so, on 640*480 Navigator's menus are pretty
close to running out of room, and Mac OS is scrunching up the menu
titles if you have anything more than a minimal clock (or an expanded
application menu, or any extra gadgets) in the menu bar. (At least
Seamonkey's message composition window isn't as bad in this regard as
4.x's one was.)
Generally, I think a Web browser should be simple and unobtrusive, to
offset the inevitable complexity and inconsistency of UI for the Web
pages which it shows. (Note that Jakob Nielsen thinks the opposite --
that Web browsers should become more powerful, and Web sites should
become simpler and more consistent with each other -- so you can take
anything I say with a grain of salt if you like.) As well as biffing the
`Debug' and `QA' menus, I'd like to turn the `Go' menu into a submenu of
the `View' menu (like it is in Internet Explorer for Windows), and get
rid of the `Search' menu (as Henri suggested).
> > What about using the name of the application for this menu item?
> > Similar to 4.x which used "Communicator". "Netscape" for the NS
> > version and "Mozilla" (or whatever is appropriate) for the Mozilla
> > version?
>
> I never thought that made much sense, it doesn't really tell you
> anything about what is in the menu.
>...
There are two other reasons not to do that. Firstly on Mac OS Classic,
if your application menu was expanded, you'd have two `Mozilla's in the
menu bar, which would be (and is, in 4.x) quite confusing. Secondly on
Mac OS X, there is (supposed to be) a `Mozilla' menu to the left of the
`File' menu already, so you'd have two `Mozilla's in the menu bar, which
would be quite confusing.
Henri Sivonen
(Matthew Thomas) wrote:
> Not really ... unless (a) you have your windows maximized all the time,
> or (b) you're on Mac OS with its global menu bar. (That wasn't a factor
> in my recommendation that the `Window' menu only be present on Mac OS,
> but it is a harmonious coincidence.)
>
> On Windows, it's a continuing annoyance that the number of menus which
> can be comfortably shown for a particular window is beholden to the
> width of the window. In my experience, this often leads to windows being
> maximized when they otherwise wouldn't have been, reducing my ability to
> multitask effectively by showing more than one window on-screen at once.
While I agree that compelling people to maximize windows is bad, I don't
think the width of the menubar is an issue that would block the Window
menu on Windows or X11. Although Mozilla's menubar (including the Seach,
Go, Debug and QA menus) just barely fits on a 800-pixel-wide screen on
Mac OS X, on X11 and (very likely) on Windows the menubar (including the
Seach, Go, Debug and QA menus) is just a little bit over 400 pixels
wide. If you resize the window to the menubar width, bugs 49543, 56995
and 80735 show up: http://www.pp.htv.fi/hsivone1/x11-menubar.png
> (Blake tells me that XP Toolkit doesn't even do
> the wrapping, yet, so if your window is narrow enough you lose the
> rightmost menus completely.
Luckily the rightmost menus are currently the Debug and QA menus.
> As well as biffing the
> `Debug' and `QA' menus, I'd like to turn the `Go' menu into a submenu of
> the `View' menu (like it is in Internet Explorer for Windows), and get
> rid of the `Search' menu (as Henri suggested).
I don't particularly like the two extra menus (Debug and QA), either.
(What's the point in having Verification in the Debug menu and Leak
Detector in the QA menu?) However, zapping them completely would
probably be vigorously objected. Could these menus be merged in one
pref-hideable menu called "QA"? ("QA" is shoter than "Debug".)
Henri Sivonen
Are we in agreement on splitting the "Tasks" menu into "Tools" and
"Window" on Mac OS Classic and Mac OS X?
What about other platforms? Does anyone object making the visibility of
the "Window" menu a hidden pref with a different default state on
different platforms? mpt, do you have further comments on CDE platforms?
Matthew Thomas
>...
> Are we in agreement on splitting the "Tasks" menu into "Tools" and
> "Window" on Mac OS Classic and Mac OS X?
>
> What about other platforms? Does anyone object making the visibility
> of the "Window" menu a hidden pref with a different default state on
> different platforms?
That all sounds good to me. Blake? Ben? Bueller?
> mpt, do you have further comments on CDE
> platforms?
>...
Is there an easy way to tell whether or not a user is running CDE?
Stuart Ballard
>
> Henri Sivonen wrote:
> >...
> > Are we in agreement on splitting the "Tasks" menu into "Tools" and
> > "Window" on Mac OS Classic and Mac OS X?
> >
> > What about other platforms? Does anyone object making the visibility
> > of the "Window" menu a hidden pref with a different default state on
> > different platforms?
>
> That all sounds good to me. Blake? Ben? Bueller?
I'm curious - which platforms do you think should have it invisible?
I admit that, as a GNOME user, I have pretty good window-switching
functionality built into my desktop environment, but I don't think it's
safe to assume that *all* users would be happy using that. I've noticed,
while watching less experienced users working on computers, that a lot
of people use really roundabout ways to do things, even when a faster or
more convenient way exists - a few years ago my wife would always use
File -> Exit instead of clicking the close box, and File -> Save even
when a toolbar save icon existed.
I don't think an extra menu is that great of an evil, and I do think
that redundant prefs are bad - actually it was your posts, Matthew, that
convinced me of this :)
So my question is - why shouldn't we show the Window menu on all
platforms?
Stuart.
Gervase Markham
Split the "Tasks" menu into "Tools" and "Window". (We need to choose an
order. Can someone say if it makes a difference?) It seems the Menu bar is
not going to be wider than 640px with this change (when Debug and QA go
away in a release build.)
It doesn't seem to have been decided where Navigator, Messenger, Compose
and Address Book live. I suppose this depends on whether Window is visible
on all platforms - if it is, I think they should live there. (Yes, the
line between the four main apps and others is a bit hazy, but I think it
can be drawn.) If not, they would have to go in Tools - but that sounds
counter-intuitive.
Other stuff goes in Tools. Things like View | Translate, Crash Recovery
(when it goes in) and so on can move there as well.
The Window menu is visible on MacOS Classic, MacOS X and possibly other
OSes. We need to decide which (see above). Is there any reason _not_ to
have it XP?
Hmm. My view is:
Make "Window" XP. Any Mozilla thing which is important enough to have a
Ctrl-<number> shortcut goes in at the top of this menu, with the
windowlist below it. If 3rd parties add an app of this importance, it
lives there too.
"Tools" has all the other stuff, like the Managers, History etc. If third
parties add a utility, we encourage them to put it in here. This menu
should be carefully designed so that random XPIs can add stuff here
without it becoming a mess (if that's possible.)
Order | Window | Tools | , as Window has the more important apps on.
Gerv
Henri Sivonen
<gervase...@univ.ox.ac.uk> wrote:
> It doesn't seem to have been decided where Navigator, Messenger, Compose
> and Address Book live. I suppose this depends on whether Window is visible
> on all platforms - if it is, I think they should live there.
Good point.
mpt, is the design from 2000-11-11 in bug 32502 your current preferred
design?
> Hmm. My view is:
> Make "Window" XP.
That would be my preferred way, too. (But if we can't agree on making it
XP, a hidden pref is better than hard-coding it per platform.)
> Order | Window | Tools | , as Window has the more important apps on.
I think the order should be | Tools | Window | Help |, because
* The established convention on Mac OS Classic is that the Window menu
is the next menu to the left from Help.
* The same ordering is carried over to Mac OS X. (Initially Apple had a
different ordering, but Apple chose to stick to the established
convention in the release version.)
* The KDE Standards say: "An application may have another menu on its
menubar, labelled Windows. If present, this should be the rightmost
entry (except for Help)."[1] (In practice Konqueror uses "Window"
without the 's'.[2])
* The Window menu is the next menu to the left from Help in Gnome.[3]
* The Window menu is the next menu to the left from Help on Windows.[4]
[1]
http://developer.kde.org/documentation/standards/kde/style/basics/windows
.html
[2] http://www.konqueror.org/pics/konq_navigate.png
[3]
http://developer.gnome.org/doc/API/libgnomeui/gnomeui-gnome-app-helper.ht
ml
[4] http://msdn.microsoft.com/library/books/winguide/ch10g.htm
Gervase Markham
> > and Address Book live. I suppose this depends on whether Window is visible
> > on all platforms - if it is, I think they should live there.
>
> Good point.
>
> mpt, is the design from 2000-11-11 in bug 32502 your current preferred
> design?
Oops. Hadn't seen that. Looks good to me, except I suspect people might
expect the "major apps" to be on the Window menu...
> > Hmm. My view is:
> > Make "Window" XP.
>
> That would be my preferred way, too. (But if we can't agree on making it
> XP, a hidden pref is better than hard-coding it per platform.)
>
> > Order | Window | Tools | , as Window has the more important apps on.
>
> I think the order should be | Tools | Window | Help |, because
<snip>
I'm convinced :-)
Gerv
Rolan...@seb.se
... | Tools | Window | Help ]
This would be at least consistent with most of the apps in Windows (MS
Office for example - and scince most of the peole who use Windows are also
to some degree familiar with at least MS Word/Excel it makes sense to
preserve familiar menu ordering)
> Order | Window | Tools | , as Window has the more important apps on.
>
> Gerv
>
Stuart Ballard
>
> It doesn't seem to have been decided where Navigator, Messenger, Compose
> and Address Book live. I suppose this depends on whether Window is visible
> on all platforms - if it is, I think they should live there. (Yes, the
> line between the four main apps and others is a bit hazy, but I think it
> can be drawn.) If not, they would have to go in Tools - but that sounds
> counter-intuitive.
Have we had the flamewar about what the "tools" menu should be called,
yet? :)
It's been a while since I used windows, but to the best of my memory the
Window(s) menu only had open windows in it. I'm sure that was true in
Windows 3.1, where the "Program manager" (remember that?) Window menu
allowed you to arrange your windows (tile/cascade), cycle through them,
or select one by title.
Therefore, I would expect Navigator, Messenger, Composer and Address
Book to be in the other menu, whatever it happens to be called. Given
that, I'd prefer to see one of the names other than "tools" for this
menu - I actually liked "Tasks", but other possibilities might be
"Applications", "Application", "Mozilla", "Suite", or even "Programs".
(I kind of like "Mozilla", because then you have the nice property that
you run Mozilla Mailnews by selecting Mozilla => Mailnews from the
menus. If we implement this correctly (ie as &brandShortName;) then it
would be the Netscape menu in NS6.5 and the Beonex menu in beonex 1.0 -
all of these keep the same nice property).
Thoughts?
Stuart.
Mark Anderson
>
> (I kind of like "Mozilla", because then you have the nice property that
> you run Mozilla Mailnews by selecting Mozilla => Mailnews from the
> menus. If we implement this correctly (ie as &brandShortName;) then it
> would be the Netscape menu in NS6.5 and the Beonex menu in beonex 1.0 -
> all of these keep the same nice property).
>
> Thoughts?
It would look bad on the Mac, where you'd actually have two Mozilla
menus. (Just as they do in Communicator.)
Matthew Thomas
>...
> mpt, is the design from 2000-11-11 in bug 32502 your current preferred
> design?
Very nearly so, yes.
Navigator
=========
_Tools Window
------ ------
_Navigator accel+1 Next Window Option+Tab
{mailer} accel+2 ------------------------------
{chat client} accel+3 Bug 32502 - Simplify Ta...
{editor} accel+4 BBC News Online - Front...
-------------------------------------- BBC News | UK | Oldham ...
_Search the Web ... Shift+accel+F
_Bookmarks accel+B
_History accel+H
_Password Manager
--------------------------------------
C_ustomize Tools ...
_Auto-Fill
_Import/Export
_Java Console
_Script Console
Trans_late
_What's Related
Messenger
=========
_Tools Window
------ ------
{browser} accel+1 Next Window Option+Tab
_Messenger accel+2 ------------------------------
{chat client} accel+3 Inbox
{editor} accel+4 Compose: Re: Reorganiz...
-------------------------------------- Card for “Henri Sivonen”
_Address Book
Message _Filters
--------------------------------------
C_ustomize Tools ...
_Import/Export
Composer
========
_Tools Window
------ ------
{browser} accel+1 Next Window Option+Tab
{mailer} accel+2 ------------------------------
{chat client} accel+3 dgsh
_Composer accel+4 The Odyssey of King Fre...
-------------------------------------- Untitled 1
C_ustomize Tools ... Untitled 2
Lin_k Check
Spe_ll Check
_Style Check
T_hesaurus
_Word Count
--
Matthew `mpt' Thomas, Mozilla UI Design component default assignee thing
<http://mozilla.org/>
Gervase Markham
So the Window menu for a given app only has windows from that app? I don't
think we should do this until the apps are crash-insulated from each other
;-)
I take it "Customise Tools" allows you to mess with the list? What use
does it have? Are people really going to care enough to want to make the
menu a couple of items shorter? And if they are adding stuff, the XPI will
do it for them.
> Matthew `mpt' Thomas, Mozilla UI Design component default assignee thing
<giggle> :-)
Gerv
Matthew Thomas
>
> Matthew Thomas wrote:
> >
> > Henri Sivonen wrote:
>...
> > > visibility of the "Window" menu a hidden pref with a different
> > > default state on different platforms?
> I'm curious - which platforms do you think should have it invisible?
Windows, GNOME, KDE, OS/2, BeOS -- any platform which has a decent
window-switching UI already, making an app-specific window-switching
menu more cluttersome and time-wasting than it would be useful. I.e.,
every platform other than Mac OS (and apparently CDE).
> I admit that, as a GNOME user, I have pretty good window-switching
> functionality built into my desktop environment, but I don't think
> it's safe to assume that *all* users would be happy using that. I've
> noticed, while watching less experienced users working on computers,
> that a lot of people use really roundabout ways to do things, even
> when a faster or more convenient way exists - a few years ago my wife
> would always use File -> Exit instead of clicking the close box, and
> File -> Save even when a toolbar save icon existed.
So we should provide a mechanism just to *allow* them to be slow like
this? I'm not sure I agree with that line of reasoning. :-)
> I don't think an extra menu is that great of an evil,
`Just one more' menu/item/button/checkbox/whatever never is.
> and I do think
> that redundant prefs are bad - actually it was your posts, Matthew,
> that convinced me of this :)
>...
Well, let's look at the problems which extraneous prefs cause
<http://groups.google.com/groups?ic=1&selm=396405D3.ED78FD16%40student.canterbury.ac.nz>,
and see which of them apply here.
* Bloat (download time, disk requirements, etc): applies. (How much
XUL and JS required to implement the overlay? A couple of
kilobytes, perhaps.)
* Usefulness (opportunity cost): doesn't apply. Lack of
app-independent window switching is a pretty major flaw in Mac OS,
so it's definitely worth implementing a workaround.
* Reliability (code maintenance, QA required, etc): doesn't apply,
since both options are being implemented anyway.
* Ease of use (prefs UI complexity, documentation complexity, etc):
doesn't apply, since the pref would have no UI.
So we could implement this through a platform-specific overlay. However,
there's no real point in not making it a pref-specific overlay instead,
since only one of the arguments against not making it a pref (the bloat
argument) applies to this case, and a few people might want a `Window'
menu on Windows or Linux. There are lots of other cases in Mozilla where
things that are platform-specific have been implemented as prefs rather
than as #ifdefs, with the prefs being given platform-specific default values.
> So my question is - why shouldn't we show the Window menu on all
> platforms?
Because most platforms provide better window-switching UIs already. On
these platforms, it would reduce usability in at least three ways.
Firstly it would be confusing to those subconsciously (and
understandably) expecting the `Window' menu to do what their OS's
window-switching UI does, i.e. list all open windows. I've lost count of
the number of times I've sat in puzzlement for a couple of seconds
staring at the `Window' menu in ShadowIRC wondering why it wasn't
listing my open Finder windows as well, and vice versa.
Secondly, the choice of two UIs for the same thing (e.g. Windows taskbar
and `Window' menu) would make users hesitate between the two, trying to
decide which UI they should use, thereby wasting them more time than
they would have saved by choosing whichever UI was the fastest (assuming
that what they wanted to do was indeed possible in both UIs, i.e.
switching to another Mozilla window).
<http://slashdot.org/article.pl?sid=01/05/12/2259254>
And thirdly, it would add clutter to the UI and increase the possibility
that (for a given window size) the `Help' menu would be pushed off the
edge of the window; or (once that XP Toolkit bug is fixed) that the
menus would take up two rows of the menu bar rather than one, taking up
space that would be otherwise available for the content you were viewing.
--
Nicholas Riley
m...@MailAndNews.com (Matthew Thomas) wrote:
> Composer
> ========
> _Tools Window
> ------ ------
> {browser} accel+1 Next Window Option+Tab
> {mailer} accel+2 ------------------------------
> {chat client} accel+3 dgsh
> _Composer accel+4 The Odyssey of King Fre...
> -------------------------------------- Untitled 1
> C_ustomize Tools ... Untitled 2
> Lin_k Check
> Spe_ll Check
> _Style Check
> T_hesaurus
> _Word Count
One minor suggestion, that the tool items be named more like tools, in
keeping with the menu title:
"Link Checker"
"Spelling Checker"
or else, as actions:
"Check Links"
"Check Spelling"
What's below the separator in the Tools menu above is neither, and seems
inconsistent.
--
Nicholas Riley <njriley@uiuc edu>
Gervase Markham
> understandably) expecting the `Window' menu to do what their OS's
> window-switching UI does, i.e. list all open windows.
I don't think that's true - on Windows, any app with a Window menu lists
only its own windows.
> Secondly, the choice of two UIs for the same thing (e.g. Windows taskbar
> and `Window' menu) would make users hesitate between the two, trying to
> decide which UI they should use, thereby wasting them more time than
> they would have saved by choosing whichever UI was the fastest (assuming
> that what they wanted to do was indeed possible in both UIs, i.e.
> switching to another Mozilla window).
> <http://slashdot.org/article.pl?sid=01/05/12/2259254>
Ooh, that's a reverse - I'm sure I've heard you arguing for multiple
access to some features in the UI in other circumstances ;-)
Gerv
barney
> Stuart Ballard wrote:
>>
>> So my question is - why shouldn't we show the Window menu on all
>> platforms?
>
> Because most platforms provide better window-switching UIs already.
As a Windows user, I have to disagree that it has a "decent"
window-switching UI already. It's only decent when there's just a couple
apps/windows open. Get 10 browser windows open, plus a few other apps
going in the middle of all that and the Windows Taskbar at the bottom of
the screen becomes pretty useless. There are work-arounds for this
deficiency, but your average-joe user isn't likely to be inventive
enough to use them. Personally, I miss the days when "Open Windows" was
on the mozilla taskbar. I thought it was a brilliant idea and used it a
lot. Maybe I was the only one who did?
> On these platforms, it would reduce usability in at least three ways.
>
> Firstly it would be confusing to those subconsciously (and
> understandably) expecting the `Window' menu to do what their OS's
> window-switching UI does, i.e. list all open windows.
Other apps that have a "window" menu show only their own windows. I have
yet to see an app that lists windows for another app.
> Secondly, the choice of two UIs for the same thing (e.g. Windows taskbar
> and `Window' menu) would make users hesitate between the two, trying to
> decide which UI they should use, thereby wasting them more time
This doesn't seem to be a problem with any other app that has a "window"
menu. Why would mozilla be any different?
> And thirdly, it would add clutter to the UI and increase the possibility
> that (for a given window size) the `Help' menu would be pushed off the
> edge of the window;
IMHO, this is the only argument that holds any water. It's not likely to
be a problem at my screen resolution, though.
my 2p. :)
Niko Pavlicek
>>
but this problem exists on much wider windows for the mail, navigation,
etc. toolbars, yet. And IMHO this is a more serious problem than the
disappearing Help menu.
Niko!
Rolan...@seb.se
Not just for the sake of the Window menu - If it is so cluttered that adding
one more menu will (possibly) hide another - something must be wrong...
Stuart Ballard
>
> Stuart Ballard wrote:
> >
> > functionality built into my desktop environment, but I don't think
> > it's safe to assume that *all* users would be happy using that. I've
> > noticed, while watching less experienced users working on computers,
> > that a lot of people use really roundabout ways to do things, even
> > when a faster or more convenient way exists - a few years ago my wife
> > would always use File -> Exit instead of clicking the close box, and
> > File -> Save even when a toolbar save icon existed.
>
> So we should provide a mechanism just to *allow* them to be slow like
> this? I'm not sure I agree with that line of reasoning. :-)
No, that wasn't my point :) My claim, which would have to be backed up
by a usability lab, is that there exist users who don't know how to use
their platform's window switching UI, and that for some of those users,
a "Window" menu would have greater discoverability than their platform
system.
If you generally use only one application at a time, for instance, it's
perfectly possible to use win95/98 without ever understanding the
taskbar beyond the existence of the start button. Launch all your apps
that way, and close your current app before opening another. I can
easily believe that there are users whose OS understanding is that
limited.
> > I don't think an extra menu is that great of an evil,
>
> `Just one more' menu/item/button/checkbox/whatever never is.
Point.
> > and I do think
> > that redundant prefs are bad - actually it was your posts, Matthew,
> > that convinced me of this :)
> >...
>
> Well, let's look at the problems which extraneous prefs cause
> <http://groups.google.com/groups?ic=1&selm=396405D3.ED78FD16%40student.canterbury.ac.nz>,
> and see which of them apply here.
> * Bloat (download time, disk requirements, etc): applies. (How much
> XUL and JS required to implement the overlay? A couple of
> kilobytes, perhaps.)
Point.
> * Usefulness (opportunity cost): doesn't apply. Lack of
> app-independent window switching is a pretty major flaw in Mac OS,
> so it's definitely worth implementing a workaround.
Misdirected argument. This is an argument in favor of the *feature* of
having a window menu, not in favor of making it a pref. You need to
argue for the usefulness of being able to turn it *off*.
> * Reliability (code maintenance, QA required, etc): doesn't apply,
> since both options are being implemented anyway.
If we made the menu always visible, then only one of the options (a
visible window menu) would be implemented. Admittedly making something
"display:none" based on a pref isn't something where I would be terribly
worried about QA and maintenance, but I can imagine for example an
engineer on a platform that sees the Window menu adding some required
piece of functionality to that menu, not realizing that it was only
available to a fraction of users.
> * Ease of use (prefs UI complexity, documentation complexity, etc):
> doesn't apply, since the pref would have no UI.
Point.
> So we could implement this through a platform-specific overlay. However,
> there's no real point in not making it a pref-specific overlay instead,
> since only one of the arguments against not making it a pref (the bloat
> argument) applies to this case, and a few people might want a `Window'
> menu on Windows or Linux. There are lots of other cases in Mozilla where
> things that are platform-specific have been implemented as prefs rather
> than as #ifdefs, with the prefs being given platform-specific default values.
I agree that if we're going to provide the option of making it
invisible, we should make this a pref rather than platform-hardcoded.
> Firstly it would be confusing to those subconsciously (and
> understandably) expecting the `Window' menu to do what their OS's
> window-switching UI does, i.e. list all open windows. I've lost count of
> the number of times I've sat in puzzlement for a couple of seconds
> staring at the `Window' menu in ShadowIRC wondering why it wasn't
> listing my open Finder windows as well, and vice versa.
At first I had a hard time seeing what you meant here: on Windows and
GNOME (the two systems I'm most familiar with) there isn't really any
possible confusion because the two UIs are entirely different. But I
know you're a Mac user, and I'm guessing that the Mac's native window
switching UI is a menu - thus the confusion. But didn't you say that the
Mac would be one of the two platforms where this menu *should* be
provided?
> Secondly, the choice of two UIs for the same thing (e.g. Windows taskbar
> and `Window' menu) would make users hesitate between the two, trying to
> decide which UI they should use, thereby wasting them more time than
> they would have saved by choosing whichever UI was the fastest (assuming
> that what they wanted to do was indeed possible in both UIs, i.e.
> switching to another Mozilla window).
I think that any user who knows how to use his OS's mechanism would use
it without hesitation - the Window menu is for discoverability in the
case of users who don't know their OS terribly well. In that case,
they're going to hesitate regardless... and without the menu, they may
not be able to achieve what they want at all.
> And thirdly, it would add clutter to the UI and increase the possibility
> that (for a given window size) the `Help' menu would be pushed off the
> edge of the window; or (once that XP Toolkit bug is fixed) that the
> menus would take up two rows of the menu bar rather than one, taking up
> space that would be otherwise available for the content you were viewing.
This argument I accept; there is a definite trade-off between this
greater discoverability and a usability flaw if you are using a very
small window with largeish fonts. I still lean towards the other side of
the tradeoff, though, especially since eliminating the window menu would
only *reduce*, rather than *eliminate*, this problem.
Stuart.
Matthew Thomas
>
> > Very nearly so, yes.
>
> So the Window menu for a given app only has windows from that app? I
> don't think we should do this until the apps are crash-insulated from
> each other ;-)
Good point. :-)
> I take it "Customise Tools" allows you to mess with the list?
In a future version, yes. I was just showing what this menu might look
like in a couple of years time.
> What use
> does it have? Are people really going to care enough to want to make
> the menu a couple of items shorter? And if they are adding stuff, the
> XPI will do it for them.
It's called reversibility. Where possible, you should be able to undo
with the UI anything you did with the UI. If you added XPIs, you should
be able to remove them too.
--
Matthew `mpt' Thomas, Mozilla UI Design component default assignee thing
Matthew Thomas
>
> Matthew Thomas wrote:
> > So we should provide a mechanism just to *allow* them to be slow
> > like this? I'm not sure I agree with that line of reasoning. :-)
>
> No, that wasn't my point :) My claim, which would have to be backed up
> by a usability lab, is that there exist users who don't know how to
> use their platform's window switching UI, and that for some of those
> users, a "Window" menu would have greater discoverability than their
> platform system.
Indeed it would. So you have to make the calculation (which, perhaps,
only free software projects or monopolistic software providers have the
freedom to make without damaging themselves slightly) about whether the
increased usability you are causing for the individual application
(providing an app-specific window switcher) is outweighed by the
degraded usability you are causing for the system as a whole
(discouraging users from becoming familiar with the platform's window switcher).
In this case, I think that on Windows and GNOME the platform's window
switcher is discoverable enough that users will be able to work it out
for themselves in the absence of an app-specific window switcher (as
indeed they do in Internet Explorer for Windows), rather than the UI
completely failing and the user not being able to switch windows at all.
The customers I see at the cafe who don't know how to use the Windows
taskbar are a subset, not a superset, of those who don't know how to use
an application's menu bar. More of them seem to know how to use the
taskbar than know how to use the menu bar.
If you're not sure what I mean about application usability vs. system
usability, here's a simpler example. Alerts in some applications have
`Don't show again' checkboxes (unchecked by default) which you can check
to turn the alert *off*. This contravenes the basic idea of checkboxes,
as controls which you check to turn something *on*. That's one of the
reasons that I try to get Mozilla programmers to use `Alert me whenever
{situation}' (checked by default) for such checkboxes instead.
Now, if you did a usability test on `Don't show again' vs. `Alert me
whenever {situation}', I suspect `Don't show again' would actually come
out slightly better. But what such a usability test *wouldn't* show is
that using `Don't show again' for a bunch of checkboxes would slow the
user down marginally for *every other checkbox* on their system. No
longer would they be able to automatically assume that a checkbox is for
turning something on, rather than off; so they'd have to spend a little
extra time thinking about every checkbox which they came across. A
usability test couldn't tell that, unless it had a truly massive budget
and studied users for months on end.
Similarly, if you had a `Window' menu on Windows, that might well
marginally speed up users' ability to switch between Mozilla windows.
But it would slow down users' ability to switch between Mozilla windows
and *every other window* on their system. Firstly because they'd be
instinctively expecting to find those other windows listed in the
`Window' menu as well, and secondly because they'd be less familiar with
the platform's window switcher than they would have been if they'd been
using that window switcher to switch between Mozilla windows as well.
>...
> > * Usefulness (opportunity cost): doesn't apply. Lack of
> > app-independent window switching is a pretty major flaw in Mac
> > OS, so it's definitely worth implementing a workaround.
>
> Misdirected argument. This is an argument in favor of the *feature* of
> having a window menu, not in favor of making it a pref. You need to
> argue for the usefulness of being able to turn it *off*.
My bad. (I thought there was something slightly screwy with that
argument, but I was too tired to work out exactly what it was.:-)
>...
> > Firstly it would be confusing to those subconsciously (and
> > understandably) expecting the `Window' menu to do what their OS's
> > window-switching UI does, i.e. list all open windows. I've lost
> > count of the number of times I've sat in puzzlement for a couple of
> > seconds staring at the `Window' menu in ShadowIRC wondering why it
> > wasn't listing my open Finder windows as well, and vice versa.
>
> At first I had a hard time seeing what you meant here: on Windows and
> GNOME (the two systems I'm most familiar with) there isn't really any
> possible confusion because the two UIs are entirely different. But I
> know you're a Mac user, and I'm guessing that the Mac's native window
> switching UI is a menu - thus the confusion.
No, Mac OS Classic doesn't have a native window switching UI *at all*.
It has application switching via the application menu, and applications
are expected to provide their own UI for switching between windows of
that app. This leads to all the problems I described in my original
message in this thread.
> But didn't you say that
> the Mac would be one of the two platforms where this menu *should* be
> provided?
Yes, because on Mac OS, the platform doesn't provide a window-switching
UI itself. That's the only reason for including the `Window' menu.
>...
> > And thirdly, it would add clutter to the UI and increase the
> > possibility that (for a given window size) the `Help' menu would be
> > pushed off the edge of the window; or (once that XP Toolkit bug is
> > fixed) that the menus would take up two rows of the menu bar rather
> > than one, taking up space that would be otherwise available for the
> > content you were viewing.
>
> This argument I accept; there is a definite trade-off between this
> greater discoverability and a usability flaw if you are using a very
> small window with largeish fonts. I still lean towards the other side
> of the tradeoff, though, especially since eliminating the window menu
> would only *reduce*, rather than *eliminate*, this problem.
>...
Something only being a partial cure for a problem doesn't necessarily
make it a bad idea. There are other menus we should get rid of too.
Matthew Thomas
>...
> As a Windows user, I have to disagree that it has a "decent"
> window-switching UI already. It's only decent when there's just a
> couple apps/windows open. Get 10 browser windows open, plus a few
> other apps going in the middle of all that and the Windows Taskbar at
> the bottom of the screen becomes pretty useless. There are
> work-arounds for this deficiency, but your average-joe user isn't
> likely to be inventive enough to use them.
Um. Your average-joe user probably has an average of about two windows
open at once. For them, the Windows taskbar is excellent. And the 0.1 %
of users who regularly have 20 windows open at once are highly
intersecting with the 0.1 % of users who know how to resize their
Windows taskbar to multiple rows (or who are running the Windows XP beta).
>...
> > Firstly it would be confusing to those subconsciously (and
> > understandably) expecting the `Window' menu to do what their OS's
> > window-switching UI does, i.e. list all open windows.
>
> Other apps that have a "window" menu show only their own windows. I
> have yet to see an app that lists windows for another app.
Exactly. All apps with a `Window' menu have that same problem.
> > Secondly, the choice of two UIs for the same thing (e.g. Windows
> > taskbar and `Window' menu) would make users hesitate between the
> > two, trying to decide which UI they should use, thereby wasting them
> > more time
>
> This doesn't seem to be a problem with any other app that has a
> "window" menu. Why would mozilla be any different?
I'm not saying Mozilla would be any different. I'm saying it's a problem
on all apps with a `Window' menu.
You don't notice the ~1 second wasted in working out whether you should
use the platform's window-switching UI or the app's window-switching UI.
Just as you don't notice the ~1 second it takes you to remember the
keyboard shortcut for an infrequently used command. Just as you don't
notice the ~0.5 seconds wasted by not being able to click a Windows
taskbar button by thumping your cursor against the bottom of the screen
and pressing the button (you have to move a couple of pixels upward
first). Just as you don't notice the ~1.5 seconds wasted by not being
able to open a menu by thumping your cursor against the top of the
screen and pressing the button (you have to move 20 pixels downward
first). You don't notice these delays, because you're busy thinking
about what you're doing the whole time.
> > And thirdly, it would add clutter to the UI and increase the
> > possibility that (for a given window size) the `Help' menu would be
> > pushed off the edge of the window;
>
> IMHO, this is the only argument that holds any water. It's not likely
> to be a problem at my screen resolution, though.
>...
That 0.1 % again ...
barney
> barney wrote:
>>...
>> As a Windows user, I have to disagree that it has a "decent"
>> window-switching UI already. It's only decent when there's just a
>> couple apps/windows open. Get 10 browser windows open, plus a few
>> other apps going in the middle of all that and the Windows Taskbar at
>> the bottom of the screen becomes pretty useless. There are
>> work-arounds for this deficiency, but your average-joe user isn't
>> likely to be inventive enough to use them.
>
> Um. Your average-joe user probably has an average of about two windows
> open at once. For them, the Windows taskbar is excellent. And the 0.1 %
> of users who regularly have 20 windows open at once are highly
> intersecting with the 0.1 % of users who know how to resize their
> Windows taskbar to multiple rows (or who are running the Windows XP beta).
Well, I'm gonna disagree, again. I know plenty of folks who are pretty
comfortable running multiple apps simultaneously, but don't know beans
about the O/S, customizing the desktop (except to change the wallpaper)
or anything else to get more out of whatever they're running. The vast
majority of the people I work with fall into this category. Even with a
multi-line taskbar, it's hunt-and-peck to find any one particular
window. You talk about saving .5 seconds here and there. I waste way
more time than that finding things in the Win taskbar. What Win XP may
or may not do isn't relevant, since I won't be upgrading unless I have
to (I already tried and threw away W2K. Once bitten, twice shy and all
that jazz).
>
>>...
>> > Firstly it would be confusing to those subconsciously (and
>> > understandably) expecting the `Window' menu to do what their OS's
>> > window-switching UI does, i.e. list all open windows.
>>
>> Other apps that have a "window" menu show only their own windows. I
>> have yet to see an app that lists windows for another app.
>
> Exactly. All apps with a `Window' menu have that same problem.
You are mistaken. Other apps with a "window" menu are most likely MDI,
and the menu is a necessity to switch between windows within the app,
since there's only one taskbar item regardless of the number of open
windows. MS Office 97, for example, and Word in particular. Word 2000 is
SDI, like mozilla, but still has the menus. It has the same problem when
multiple documents are open - one taskbar item for each window. For me,
the menu is by far the fastest way to switch between open docs, and not
just because it's what I'm accustomed to doing in O97. If a user is in
the habit of opening multiple windows in an MDI app, they know what the
menu is for. If a user runs an MDI app but only opens one window, they
have no use for the menu, but that's no reason to hide it.
>
>> > Secondly, the choice of two UIs for the same thing (e.g. Windows
>> > taskbar and `Window' menu) would make users hesitate between the
>> > two, trying to decide which UI they should use, thereby wasting them
>> > more time
>>
>> This doesn't seem to be a problem with any other app that has a
>> "window" menu. Why would mozilla be any different?
>
> I'm not saying Mozilla would be any different. I'm saying it's a problem
> on all apps with a `Window' menu.
So... I'm saying it's a *good* and usually necessary thing on all apps
with a "window" menu. The type of person you seem to be targeting here
probably never even looks at most menus. Heck, they don't understand
what prefs are, either, and leave everything set to the defaults that
get installed. You should read some posts in the N6 ngs. A fair number
of the "how do I/where is...?" questions would answer themselves if the
poster just wandered around menus and prefs a bit. They don't.
If a user doesn't understand what the menu is for, or only has one or
two windows open, then they are probably going to ignore the menu anyway
and just use the taskbar, since it's likely to be already there staring
them in the face. But why punish the rest of us?
>
> You don't notice the ~1 second wasted in working out whether you should
> use the platform's window-switching UI or the app's window-switching UI.
Just as you don't notice the 5+ seconds I can waste hunting through the
Win taskbar vs the ~2 seconds I spend looking at the menu.
>> > And thirdly, it would add clutter to the UI and increase the
>> > possibility that (for a given window size) the `Help' menu would be
>> > pushed off the edge of the window;
>>
>> IMHO, this is the only argument that holds any water. It's not likely
>> to be a problem at my screen resolution, though.
>>...
>
> That 0.1 % again ...
As somebody else already pointed out, the space taken up by an
additional menu doesn't come close to the space taken by any of the
toolbars. And I checked on my laptop, which has a hardware limitation of
800x600 for screen size. There is still plenty of empty space with the
current menu, even when the window is not maximized. I'd say I'm now
closer to the 90% bracket. And since Debug and QA menus aren't in a
commercial release, like N6, it will be only marginally more "cluttered"
than IE 5.0. It's really a wash, since IE throws several of the mozilla
menu items in a toolbar instead, forcing use of that blasted sidebar
thing, or some wizard popping up.
Speaking of IE, it is also SDI, but does have the list of open windows
buried in the View menu. IMO, mozilla beats IE in usability, because it
does have more top-level menus. I think it's more intuitive, and I can
shut off the sidebar and not miss anything. Can you tell I dislike the
sidebar? :)
AFAIC, I just blew your only real argument outa the water... ;)
The width of the URL box in the nav toolbar is a much bigger issue. On
my laptop, it's a passable size only when the window is maximized and
all the optional buttons are turned off.
Henri Sivonen
The following is clear, right?
* The "Tasks" menu should be split to "Tools" and "Window".
* If the "Window" menu isnat going to be visible everywhere, the
visibility should be a hidden pref.
* The "Window" menu should be visible on Mac OS 8.6...9.1 and on Mac OS X
* The "Tools" menu should be visible on all platforms.
* If present, the "Window" menu should be the next menu to the left from
"Help".
* The "Tools" menu should be the next menu to the left from "Window" (or
"Help" if "Window" isn't present.)
And then the unclear things:
Windows
* It seems to me that mpt still opposes to having the "Window" menu on
Windows.
* Does anyone want to go through another round of aguments about it?
I think we have three options:
- Those who want the "Window" menu give up, flip the hidden pref in
their personal copies of Mozilla and then wait and see how
people react to the disappearance of the open window list.
- mpt gives up.
- The "Tasks" menu restructuring stays in the limbo.
Unix-like platforms
* It seems to me that no one is objecting to enabling the "Window" menu
on CDE platforms.
* Does anyone object to enabling the "Window" menu on all Unix-like
platforms? (This is the easiest solution to the above bullet point.)
* If someone objects, what is the suggested alternative?
- Making the hidden pref tri-state (show, hide, check for CDE)?
(Requires CDE sniffing code eg. checking the list of processes.)
- Shipping different default prefs on platforms that come have CDE
installed by default? (Does the build system allow different default
prefs on different Unix-like platforms?)
- Other?
The exact contents of the menus is unclear, too, but I think it makes
sense to decide about the visibility of the Window menu before we can
discuss the exac menu items.
Rolan...@seb.se
> Windows
> * Does anyone want to go through another round of
> aguments about it?
No sense - It seems thet mpt does not want to listen...
> I think we have three options:
> - Those who want the "Window" menu give up, flip the
> hidden pref in their personal copies of Mozilla and
> then wait and see how people react to the disappearance
> of the open window list.
Seams reasonable enough...
> - mpt gives up.
... or moon will grow forest ;)
> - The "Tasks" menu restructuring stays in the limbo.
Not a choice - lack of it!
> The exact contents of the menus is unclear, too,
If there is a window menu - it makes sense to divide it in (at least) two
sectons - first window arranging (Tile, Cascade, whatever..) and then the
list of currently open app windows.
Tools would contain everything that coud be considered a tool (JS console,
Privacy configuration settings, etc.)
IMO the positioning of Navigator, Mail/News, etc would actually fit into
Window menu, because they are basically functions that open a new (or switch
to) application window of ceartain type (Navigator, Chat, Mail/News,
Composer, Aphrodite, Chameleon, etc.)... It seems logical to put them there,
scince they are more than just mere tools.
OTOH If the Window menu is going to be hidden by default in Win9x/NT/2K/XP,
these items can not be put in Window menu, scince then they will be hidden
by default also... and that is going to create definately loads of ...ee..
misunderstandings ;)
I'd vote for Window menu visible by default and hidden pref for those who
can live without ;)
my .05 EEK (estonian kronas ;))
Roland
barney
> Windows
> * It seems to me that mpt still opposes to having the "Window" menu on
> Windows.
>
> Unix-like platforms
> * It seems to me that no one is objecting to enabling the "Window" menu
> on CDE platforms.
Since mpt has already declared that a "Window" menu is needed on Mac,
that means only the Win platform would have it hidden by default? Why
bother?
Gervase Markham
This is why we have nightly builds. Let's make it a hidden pref, enable it
on all platforms for the moment and get user feedback.
Gerv