Usually, the menu for switching between different windows is called "Window" or "Windows". Even though there might be a task associated with each window, "Tasks" as a menu name is a bit obscure compared to "Window".

But it's not necessarily window switching. There are currently a number of menu items listed under Tasks: -------------------- Navigator Mozilla Mail Newsgroups Composer -------------------- Address Book IRC Chat -------------------- Privacy and Security -> list of related managers) -------------------- Tools -> list of tools -------------------- [List of currently running tasks] -------------------- Now, though it may be true that the last bit, "[List of currently running tasks]", is more commonly seen as a list of open windows, usually in its own menu ("Window"), all the other items in this menu deal not only with switching to that task, but more importantly starting that task if none is running yet. This is something which usually isn't found in a "Window" menu. A new menu ("Window") could be added which just lists the currently open Mozilla/Communicator windows, or we could do what Communicator 4.7x does. In Communicator 4.7x, the "Tasks" menu is named "Communicator"(*) and has the list of open windows in a submenu called Window. So, as to this bug, I would suggest "WONTFIX", and you could file a new bug with the above suggestion. Alternatively we can morph this bug. (*) I assume it's called Tasks in Mozilla because Mozilla != Communicator and it is a better name for the menu than "Communicator" is anyway.

All the menu items in the Tasks menu either open a window or switch to a window that is already open. It is not far-fetched to call the menu "Window". Contrary to what you are suggesting, there are quite a few well-known apps that include items that may open new windows in the Window menu. So I wouldn't mark this WONTFIX.

Can you give me a few examples of those "quite a few well-known apps that include items that may open new windows in the Window menu."? I don't seem to know them / use them. Here's what I found on apps on my system: Eudora 4.3.2, Acrobat Reader 4.0, Quicktime 4 and Microsoft Access 97 allow just window / MDI switching (in case of MDI there's also tiling, cascading, ...) Internet Explorer 5.0 doesn't seem to have a Window menu or anything like it. Microsoft Word allows me to switch between documents and also open a new one. Netscape has starting a new Navigator/Messenger/Composer/AIM/etc. under Communicator and switching between windows under Communicator -> Window. So, I don't really see a standard way of doing things here, but maybe I'm just looking at the wrong software :-) Regardless, I don't think "Tasks" is an obscure name for a menu which allows you to start / switch to tasks. It also seems more generic to me than "Window", which is rather GUI specific.

>Can you give me a few examples of those "quite a few well-known apps that >include items that may open new windows in the Window menu."? Adobe Photoshop 5.5, Adobe ImageReady 2.0, likely other Adobe authoring tools, FreeHand 8, likely other Macromedia authoring tools and AppleWorks 5.0 have palette management commands in the Window menu. IE 5 for Mac has commands for opening Download Manager, Favorites and History in the Window menu. Anarchie has commands for showing the transcript, the log etc. windows in the Window menu. MT-NewsWatcher has commands for accessing filters and group list through the Windows menu. And so forth and so on... >It also seems more generic to me than "Window", Sure, but it isn't a familiar term to users who are used to having a Window menu. >which is rather GUI specific. Mozilla has a GUI!

Calling it `Window' wouldn't make much sense for most of the `Privacy & Security' sub-sub-(ugh)-items ... but then they don't make much sense anyway. So I'd say it's a good idea (more discoverable), but it's dependent on getting rid of those sub-sub-items -- either by removing the need for them, or pushing them into the relevant dialogs as buttons. CCing Blake, who knows more than I do about that sort of thing.

Reassigning from bdonohoe to hangas

Henri, thanks for the list. Re: the GUI part, I was thinking of using say a two way audio interface, but for that a new locale could be created. A new chrome would most likely be needed anyway. This leaves us with just a simple naming question. Now, I feel "Windows" is inadequate for the content, and I don't feel that just beacuse others are giving it an inadequate name is a reason for us to do that too. You argue along the lines of culture shock, that people will have trouble with finding under "Tasks" what they're finding elsewhere under "Window". I sincerely hope that after the first "Hmmm, where did they put this? Ah, here it is", they will remember the next time. I also wonder, when the UI specs for Mozilla were written, changing the word "Communicator" to "Window" must've been thought of, but "Tasks" was chosen in the end. Why?

Window was probably rejected because in Netscape 6, `Tasks' is going to contain quite a lot of hardcoded bookmarks, which won't open their own Window (or switch to a different existing window). That's not an issue for Mozilla, though.

Meaning that will never happen in Mozilla (as in, Bad Thing We'll Never Do)? Otherwise, why limit Mozilla?

Well the answer is that we will not be changing this for N6. I personally do not have an attachment to the word Tasks but the decision has been made that N6 will use Tasks. Marking wontfix. Mozilla might use a different word, or we might change it after N6, but not now.

Sorry Paul, I think you forgot which bug database you were using for a moment. Reopening. > Well the answer is that we will not be changing this for N6. Not really relevant to Mozilla. > I personally do not > have an attachment to the word Tasks Neither do I, but that's not relevant to Mozilla either. The question is, will the purpose of the menu be more obvious to Mozilla users if it is called `Window' than if it is called `Tasks'? A usability test to find this out could be done on a very low budget. > but the decision has been made that N6 > will use Tasks. So go tell Bugscape. > Marking wontfix. Mozilla might use a different word, In which case this bug should stay open, and not be resolved wontfix. > or we > might change it after N6, but not now. In which case the bug should be marked `Future', and not resolved wontfix.

Mathew as a mozilla bug this should stay open. I am sending this to you so that you can help make it happen.

Sending to Mathew.

So it's my decision now??? In that case, WONTFIX. While Mac users might be used to having a `Window' menu which contains items for things other than open windows, users of other platforms are not -- except in MDI applications on Windows, and Mozilla is (thankfully) not an MDI application. Henri, if you want to file an RFE for a separate `Window' menu on Mac OS -- which contains items for open windows (moving them from the Tasks menu), and a `Next Window' command (bug 53505) -- go right ahead. But for platforms other than Mac OS, the platform's built-in window-switching mechanisms are quite sufficient, so the location of the list of open windows does not need to be more obvious than it is now.

vrfy wontfix

*** Bug 79476 has been marked as a duplicate of this bug. ***

What we have learned from Netscape 6 and the actual RTM is that "Tasks" was technically the right term and indeed a suitable compromise, and I was personally arguing in favor of it as well as I am sure you remember. But observing how people used the actual RTM of time there was a smaller number of people then expected that used this menu. There are a number of precendents of other apps using windows to bring up functionality of the product or switch to another part, such as many MS and Adobe products, so this scenario should not be unfamiliar to our users.

Rename it in the commercial Netscape, then?

German, before reconsidering this bug, I would like you to expand on the following aspects of your rationale for reopening it: (1) how you learnt from Netscape 6 in particular that `Tasks' was technically the right term for the menu; (2) what the difference is between `Netscape 6' and `the actual RTM'; (3) what the `RTM of time' is; (4) a list of the `many' MS apps (other than those produced specifically for Mac OS, where bug 75546 applies) which use `Window' as a title for a menu in which most of the items are non-windowing functions; (5) what you thought you were achieving by making almost identical comments in two bugs (this bug and bug 79476) within three minutes of each other; (6) whether you agree with the supposition that users are not using this menu as much as `expected' (expected by whom?) not just because it has a non-obvious name, but also because its structure is generally borked (bug 32502, bug 48860, bug 50494, etc.); (7) to what extent your concerns would be addressed by renaming the menu as `Tools', which (IMO) more accurately covers the contents of the menu, and which is due to be implemented as part of bug 32502.

The comment in the duped bug was: "Improving usability of app and discoverability of items under this menu, change name on top of menu from "Tasks" to "Window"" So to go along with Matthew's comments, I would like to know why users are more inclined to understand that they can access functionality other than window- switching from this menu if you rename it to Window, from Tasks.

(1) usability testing before Netscape 6 ship (2) Netscape 6 PR releases vs the actual final release (3) a typo (4) aside from all MS apps on Mac MS Word and Excel specifically let you either create new windows from that menu or switch to open windows which is what this was designed for. In addition most apps let users bring up certain types of special windows. (5) I was thinking about taking over the world. No seriously I was adressing a different set of reporters and cc'd people and the new bug as well as the original one (which we could not find at first, hence that new bug got filed) (6) and (7) I don't agree, I think "Tasks" is a barrier to entry as much as tools would be, we spec. received many comments that both had negative connotations in terms 'work', 'unpleasant' etc. In summary I strongy believe it's the right thing to do for our users for the next release of Netscape 6.x

Marking bug nsbeta1+ sending to andreww with milestone 0.9.1

4. Word and Excel let you bring up what is essentially a duplicate of the current window. There are no functions in there that open a new tool. 7. Tools is a little more intuitive to me than Tasks. Ask someone to give you an example of a tool and you'll get a fairly consistent set of answers - hammer, screwdriver, etc. Ask for examples of a task and the answers will be all over the map. "In summary I strongy believe it's the right thing to do for our users for the next release of Netscape 6.x" So does this mean that it will be done for the NS commercial build only, and we can take more time discussing what's best for Mozilla, perhaps taking in feedback from the next release?

Microsoft Word 2000 (on Windows) has these items in its Window menu: New Window Arrange All Split ----------- Window List Ours currently has: Navigator Mail Composer Address Book ------------ Privacy and Security > (submenu with a bunch of different managers) ------------ IRC Chat Tools > (submenu with access to history, js/java console, and import wizard) ------------ Window List So if the functionality of the Window menu in apps like MS Word is the purpose of the Tasks menu as you say, we haven't been doing a very good job, have we? The menu in Word provides window-specific features and is deserving of the name "Window." Ours provides everything under the sun with a window list tacked on at the end, and is deserving of the name "Tools/Window." We're having trouble giving this menu the appropriate name because it's trying to do too many things at once. And no, I don't think the solution is splitting it into two top-level menus; I think we should do what Matthew has suggested in other bugs, namely remove the window list on Linux and Winddows and turn it into a Tools menu (containing the items in 32502).

r= hangas, sr=hewitt

Maybe I'm missing something here, but I don't see a consensus on this change.

Ok then, fine. If you're going to reassign this bug away from me when I'm clearly not neglecting it, and if you're going to rush through this change without any sort of UI process, then this bug is Netscape only. You can maintain the fork, and you can work out what to do in your tree when bug 75546 is implemented. If this menu is renamed to `Window' in the Mozilla tree, without first moving all (or at least most) of the non-window-management items out of the menu, that will be treated as a usability regression. To have items such as `Allow Cookies From This Site' in a `Window' menu would be just absurd.

Patch checked into tree. Just my 2cents, but perhaps it'd be a good idea to have some kind of UI pow-wow for all persons concerned to iron out this an many other issues before the next milestone so we can all work from understanding, and all feel like we are making this the best browser possible.

I agree with mpt and blake. mpt's solutions in other bugs have proposed 'Tools' as an XP solution to the title for this menu. This is consistent with the examples that blake etc have provided, and consistent with Internet Explorer, which offers access to mail, etc. Tools is also probably the most generic and correct name for the menu based on its contents. (unless anyone wants to suggest better) I think this patch went in a little too quickly. Both Matthew and Blake expressed concern, and that should have been enough to put the brakes on as far as mozilla is concerned. mpt has or is filing a bug on calling this item "Tools," and if that indeed makes the most sense that is what should be chosen. I'll let him add the relevant bug number(s) here. Please, let's not let Netscape's deadlines interfere with correctness. It's not like fixing this correctly would have taken days of deliberation and discussion.

What kind of bullshit is this, exactly? The UI:DF owner has given objections that nobody has responded meaningfully to, and yet you just went and slammed in this patch against his-and-blake's wishes. _After_ rudely taking the bug from him. This isn't how we work around here. I'm going to sleep right now. Somebody back this change out, sr=shaver@mozilla.org.

Renaming the menu as `Tools' is described as part of my 2000-11-11 spec for bug 32502. If people want me to file a separate bug (a dependency of that one) for just the menu title, I'll do that.

backed out, as per comments above

I started a thread called "Reorganizing/renaming the Tasks menu" in n.p.m.ui.

Reopening this due to backout. Andrew, I know you were instructed to make this change by your manager (who is notorious for misunderstanding or ignoring Mozilla), but it still seems awfully arrogant and ignorant to say that we should discuss this UI -- that's what the rest of us were doing while you checked in. Moving back to UI Design Feedback because Henri actually followed standard procedure and started a newsgroup discussion. Hey, see how easy things are when we follow the rules?

--> Matthew, because in the design stage this bug still belongs to him, and he was never consulted. Netscape's beta requirements do not preclude Mozilla's processes. (As a side note, isn't it just fitting that one of the people causing the trouble here has most notifications off, and isn't hearing anything about this?)

So now we're back to square one: UI discussion. Your basis for making this change was usability data and feedback collected from Netscape 6.0. Why can't some of this data be published (if in very generalized terms)? Specifically, I would be interested in knowing: * 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". * 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. * Why changing this menu's name from version to version until you get it right will *reduce* confusion among users. In general, I think people are tired of this confidential usability info that seems to change from version to version.

* 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). Coomunicator 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 iterated beyond 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.

I think it is difficult to find an accurate name for this menu item because it is sort of a mixed bag of stuff. 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 items

I like jglick's suggestion a lot. Can't we all just get along? Not with unilateral decisions and bug-grabbing. /be

I agree with Jennifer about the problem, but not the solution (see "And no, I don't think the solution is splitting it into two top-level menus..." in my 5/8 comment ;-) Actually, I can't speak for the other platforms, but Windows (and presumably Linux) shouldn't even have this window list (we have another bug on that). The OS does quite a fine job of handling and switching between open apps. (Future versions of Window, specifically Whistler, render the list even more unnecessary with the notion of app-specific taskbar groupings.)

Thanks for the understanding comments Blake. I was only following orders (shoots self in the head). With the localization freeze and other things I was under the impression that it was ready to go and change. And I can understand how it seems to have been rushed to change.

andreww: I don't know in which comments blake showed understanding (about your boss making you do it? That went out a long time ago as an excuse), but do not ever again steal a bug assigned and currently owned by someone else. That kind of thing would not be tolerated if practiced by non-netscape.com contributors against netscape.com owners. It is not tolerated by staff@mozilla.org. /be

andreww: sorry, I didn't View Bug Activity. So hangas reassigned this and you went along with that. I guess I'll have to mail hangas directly, as blake says he doesn't get notified on bug changes. I'm this >< close to revoking his editbugs capability. Feel free to tell him to get in here and respond to the reactions to his action. /be

Yes I did assign this bug to andreww. I had bug 79476 marked as a dup of this bug by mpt. Since mpt had this bug open and he marked mine as a dup of this bug and there were comments in this bug suggesting that mpt still wanted to see this bug fixed I saw no reason to argue about which of the two bugs we fix. I simply moved the bug to andreww to replace the one that mpt marked dup and gave it the nsbeta1+ that was on the dup bug. You will notice that I was the original owner of this bug and gave it to mpt some time ago.

Since this menu is a mix of Window and Tools/Tasks related items, its tough to find a word that accurately describes its contents. 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 regret to say that after that comment, I am even more concerned about Hangas's actions than I was before. No, I did not `have this bug open'. It had been resolved as WONTFIX since 2000-09-21, for the reasons I gave then, and I still think those reasons are perfectly valid. The bug was reopened by German (2001-05-08), presumably at his manager's behest, with an explanation that I found very difficult to understand on both a grammatical and a logical level. (My earlier reopening of this bug (2000-09-20) was not because I thought Henri's suggestion should be implemented, but because Hangas had resolved it on inappropriate grounds.) Whether this bug was resolved or not does not affect in any way the fact that bug 79476 was an exact duplicate. I cannot help but think that Hangas filed the duplicate bug with malice aforethought, given that (as he has just pointed out) he had owned the original bug and obviously knew of its existence. Even if he had forgotten about it, a Bugzilla search for all words `tasks menu' in the summary would have found it (and the other bugs associated with the design of the Tasks menu) with no trouble at all. No, there are not `comments in this bug suggesting that mpt still wanted to see this bug fixed'. Since I'd resolved the bug as WONTFIX, I cannot see how Hangas could be under that impression. Initially (2000-08-23) I said I thought calling the menu `Window' was a good idea, *provided that* the non-windowing-related items were removed from the menu. Since then, however, more and more non-windowing-related items have been added to the menu, to the extent where (in an average scenario, say, two browser windows open) the windowing functions comprise less than 10 percent of the menu (2 items out of 28). To rename the `Tasks' menu as `Window' in such a circumstance would be akin to renaming the `File' menu as `Disk' on the grounds that 2 of its 15 items involve disk I/O. And no, this bug should not have been reassigned, regardless of who owned a duplicate of it. I have no problem with bugs being reassigned away from default owners, if the default owners are placeholders (e.g. Browser-General, or HTML Elements), or if they are on sabbatical (e.g. Style System), or if they don't read their bugmail (e.g. Bookmarks), or if they don't respond to the bugs for months (e.g. Search). (Some of my bugs haven't been touched for months, but that's only because I'm still trying to catch up with the backlog I inherited from Hangas.) What I do object to, however, is when a `bug' in the User Interface Design component -- which is not a place for bugs to get fixed, but a place for user interface design issues to get answered and either wontfixed or reassigned -- gets taken away from me when I'm obviously giving it my full attention. As for the design question itself, I agree entirely that `Tasks' is a poor name for the menu, but I think that -- given the menu's contents -- `Window' is considerably worse. Since this is a complicated issue which will inevitably involve the content and structure of the menus itself, a linear and already unwieldy Bugzilla report is probably not an appropriate forum in which to have this discussion. So I'd like interested parties to please participate in the n.p.m.ui thread instead. Thankyou.

Ok. The following had broad agreement on n.p.m.ui (this is paraphrasing from a post by Henri Sivonen): * Split the `Tasks' menu into `Tools' and `Window', in that order. * If the `Window' menu is not present on all platforms, its visibility is controlled by a non-GUI pref so users can override it. * The `Window' menu should be visible on Mac OS (bug 75546). The following was stuck in terminal disagreement: * Whether the `Window' menu should be visible on platforms other than Mac OS. - I argue that it's unnecessary and confusing for the majority of users whose window manager UI works just fine for the small number of windows they have open; and that Internet Explorer doesn't have it. - Several others argued that a `Window' menu should be included because it's more convenient when you have lots of Mozilla windows open; and that MS Office and MDI apps have it. So I guess the lucky Ben gets to decide.

moving the implementation of this bug to Future.

mpt: before someone decides to implement this... {MacOS - or any wierd platform decides to show the menu while there are no windows open} If there are no open windows, is the Window menu disabled? Should the tools items still remain as a submenu? ben: i know some manager just futured this bug, but would you please sign off in advance on as many of the decissions as you support to save any implementors agony later?

I'm not mpt, but: The Cocoa framework doesn't disable the Window menu when no windows are open. However, it looks like a bug and not like a deliberate feature. (I think the Window menu should be disabled, if there are no windows open. I'm assuming that none of the menu items makes sense when there are no windows open.) |Window| Close Window // Mac OS X (accel in File->Close) Zoom Window // Mac OS X (same as the title bar zoom button) Minimize Window accel-M // Mac OS X ----------------------- Bring All to Front // Not applicable on Mac OS 8.5...9.1 Next Window opt/alt-tab // bug 53505 (but see also bug 55486) ----------------------- {list of open windows}

For Mac OS, what Henri said. For the `Tools' submenu, we obviously couldn't have `Tools' > `Tools'. I think that `History' would probably go into the top level; `Import Utility' would become `Import ...' (and hopefully, one day, `Import/Export ...') in the `File' menu; and lesser used stuff like the Cookie Manager, the Image Manager, and the Script Console and Java Console would probably go into a `Utilities' submenu.

Quick question about this, Where are the top level component launchers going to live? In windows or tools? If they are going to be under tools, and windows will only have open window switching, then I really want to see it off on windows and linux, as I like the way my OS works. If Windows will have the major components under it, I'd like to see the open windows put into an "Open Windows" menu or hidden entirely on windows and linux, for the same reason. I find the open windows list to be stupid and ugly anyways, as it lists the title of the email, browser page, or composer page open. If I have a mozillazine page open in an email message, the browser, and composer, there is no way to tell them apart, and that makes the menu utterly useless. (4.x preceded the title of the menu with what type of window it was open in - Web Page, Email, Composer)

> Where are the top level component launchers going to live? In windows or > tools? Tools. (That's what they are.) > If they are going to be under tools, and windows will only have open window > switching, then I really want to see it off on windows and linux, as I like > the way my OS works. Right. Window switching is the job of the window manager, but Mac OS sucks at it (Classic and OS X in different ways), so we'd work around that using a menu.

*** Bug 117526 has been marked as a duplicate of this bug. ***

I wouldn't call this a blocker for the 10899

-> me

fixed.

This is in regards to the next window functionality which apparently is going to be assigned to Apple-Option-Tab. Mac OS X CoCoa application use Apple-` to switch between Windows (e.g. Mail). It does not seem like Carbon Windows do the same (in fact Apple-` acts the same as Apple-~ in the Finder). I know this is late, but I just learned this trick from one of the Mac sites.

Tasks has now been refactored into the Tools and Window menus. vrfy'd fixed, 2002.04.09 comm bits on linux rh7.2, win2k and mac 10.1.3.