Closed Bug 462936 (tools-menu-bikeshed) Opened 16 years ago Closed 11 years ago

Update the tools menu

Categories

(Firefox :: Menus, defect)

Product:
Firefox
Component:
Menus
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: faaborg, Unassigned)

References

Details

(Whiteboard: [has patch][needs review beltzner])

Attachments

(6 obsolete files) 

By adding a private browsing mode menu item in 3.1 the tools menu is becoming increasingly complex.  I propose that we move Error Console and Page Info to a Developer submenu.

This will help to streamline the number of items directly displayed in the tools menu, and these two interfaces do not provide a great deal of value to mainstream users.

Mockup is in the larger privacy mockup:
http://people.mozilla.com/~faaborg/files/shiretoko/privacy_i2.png
In terms of cleaning up the tools menu, the "web search" item is awkward and inconsistent inside the tools menu, there's no "address bar" item. I know that's bug 242862, but thought it worth at least briefly raising in a Tools menu redesign bug.
>the "web search" item is awkward and inconsistent inside the tools menu

My impression was that we have that (admittedly rather awkward) command so that
users who are using a screen reader can discover the shortcut for quickly
accessing the Web search bar, without having to tab to it.  But I'm actually
not entirely sure if that is the case.  If it is, I wonder if we could try to
create menu items that are exposed to a screen reader, but are not actually
displayed.

Switching the description to the more general "update the tools menu"
Summary: Create developer submenu in the Tools menu → Update the tools menu
I also think we should provide consistent access to all of Firefox's sub windows, so that would mean including a menu item to get to the Library (bug 423309).
Depends on: 423309, 242862
It would be interesting to end up using the same ID for the popup in both Firefox and SeaMonkey for that submenu so extensions (like DOMi, venkman, etc.) adding items there can easily use one overlay for both apps. From what I see, SeaMonkey uses "toolsPopup" right now, which doesn't fit with Firefox having a very similar ID for the toplevel there, so I guess SeaMonkey should look into adopting whatever you come up with here.
Attached patch First Pass (obsolete) — — Splinter Review 
This should be pretty straightforward, dunno though what the intended fix for this bug is as it seems to be getting a bit morphed. ;)

->taking
Assignee: nobody → highmind63
Status: NEW → ASSIGNED
+              <menu id="devTools"
+                    class="menu-iconic"
+                    label="&devTools.label;">
+                <menupopup>

It would be great (from an extension authors point of view) to give the menupopup an ID such as devToolsPopup. For consistency with SeaMonkey it should be "toolsPopup" but I think that would lead to confusion.

<http://mxr.mozilla.org/comm-central/source/suite/common/tasksOverlay.xul#32>
The menupopup should definitely have an ID so extensions that add developer tools can overlay this element. I already mentioned this SeaMonkey case in comment #4
Attached patch Current wip (obsolete) — — Splinter Review 
It's late at night... but here's what I'm currently working on, it has basic functionality just need to work out a few bugs (and get feedback, if possible). About the menupopup id, I've included an id in this patch, just waiting on a final decision about the compatibility issue with seamonkey.

This patch is intended for bug 423309 as well.
Attachment #346201 - Attachment is obsolete: true
Attached patch wip ver. 1 (obsolete) — — Splinter Review 
Ok so this is where i'm holding on this now, just wanted know if this is an ok direction. Part of the code is commented out b/c it's returning an error that this._content.treeBoxObject.view.nodeForTreeIndex is not a function, I have no idea why, any suggestions?

mak77: what's you're take on this.
Attachment #346397 - Attachment is obsolete: true
i would let adding Library out of this, IIRC there was not a final decision over that, we already had a patch to persist the selection in the Library in bug 329853, but that was finally not taken since someone did not agree to add a second Library options (and we did not have a string after the freeze). I agree that with a Tools menu the "overcrowded" menu problem would be skipped, but i would leave adding Library for a followup, unless you get explicit ui-r on that.
Also i think that having a "Persist" argument is useless, if we don't ask explicitely for a selection we should restore previous selection.
for the this._content.treeBoxObject.view.nodeForTreeIndex i suppose the binding is not yet attached, it is after the call to this._content.focus()
Ok, didn't see that patch/bug there. Just gonna update the Developers sub-menu with this. I couldn't get the final decision on the SeaMonkey integration, so if anyone can just tell me if they want the same id or not, it'd be greatly appreciated.
Attachment #346961 - Attachment is obsolete: true
Attachment #347117 - Flags: ui-review?(faaborg)
Attachment #347117 - Flags: review?(gavin.sharp)
> +              <menu id="devTools" label="&devTools.label;">

SeaMonkey currently doesn't have an ID on our corresponding <menu> so we'll go with whatever you come up with.

> +                <menupopup id="devToolsPopup">

Currently we use "toolsPopup" but as KaiRo says we'll sync with whatever you choose. Some SeaMonkey extension authors will have to update their extensions (e.g. me), but then for SeaMonkey 2.0, they will have to anyway for other reasons.
If we take this, I think we need to:
-get this in before monday night for really-final string freeze, I think (mconnor/beltzner/axel?)
-post about this in the MozillaZine extensiondev forums: http://forums.mozillazine.org/viewforum.php?f=19
-add an entry for this in https://developer.mozilla.org/en/Firefox_3.1_for_developers
-fix DOM Inspector, if necessary. It uses insertafter="javascriptConsole"[1], but I'm not sure if javascriptConsole not being a child of menu_ToolsPopup anymore will break that.

[1] http://hg.mozilla.org/dom-inspector/file/f70f22b6a96e/resources/content/tasksOverlay-ff.xul

Even with all that I'm a bit concerned that we're changing something like this late in the cycle, given that a lot of extensions overlay this menu. Figuring out whether this will impact extensions that position items relative to the items we're moving would help measure the potential impact here - I don't know offhand how that works. Is the worst case that people will have incorrectly positioned items, or no items at all?
I've just tested Dom Inspector, it just places the entry at the end of the Tools Menu, which I guess would be the case with any extension that doesn't match the correct id in its overlay...
Since javascriptConsole isn't a sibling any more |insertafter="javascriptConsole"| is ignored and such extension items will get appended to the end of the Tools menu (the default behaviour).

Venkman will also need to be updated, but I don't know who should be CCed.

Thirdly Gavin raises a valid point. This late in the Beta cycle extensions authors should have a valid expectation that substantive changes have been frozen and all that remains are polish and fixes. Some of you may remember that during the 3.0 beta cycle there was a contretemps when a message was pushed out far and wide to the blogs that it was *safe* for extension authors to update their extensions for 3.0; and just after most of them had done so, Firefox developers changed the IDs of some very commonly overlaid and very well known anchor points in browser.xul causing more than a bit of heartburn in some extension authors (this change was eventually backed out before 3.0 went gold). I'd hate to see this happen again.

Perhaps this should be re-targeted at 3.1+ instead?
We're string frozen for 3.1, this landing had to be worth breaking string freeze post B2.

I'd say it's not.

I second the considerations wrt add-ons developers, too.
Comment on attachment 347117 [details] [diff] [review]
Just adding the Developers sub-menu

Moving the ui-review to beltzner since I filed the bug
Attachment #347117 - Flags: ui-review?(faaborg) → ui-review?(beltzner)
Comment on attachment 347117 [details] [diff] [review]
Just adding the Developers sub-menu

With comment 13 taken into account, r=me.
This getting targeted for beta 3 at all?
> This getting targeted for beta 3 at all?

Since this missed the string freeze, I'd say No. I doubt it will make 3.1RC either.
Attachment #347117 - Flags: review?(gavin.sharp) → review+
Comment on attachment 347117 [details] [diff] [review]
Just adding the Developers sub-menu

Huh, clearly I meant to mark this r+. Makes sense to take this now on the trunk if we're going to take it at all.

>diff --git a/browser/locales/en-US/chrome/browser/browser.dtd b/browser/locales/en-US/chrome/browser/browser.dtd

>+<!ENTITY devTools.label               "Developers">

Please add an accesskey?
Attached patch adds the accesskey (obsolete) — — Splinter Review 
for 1.9.2 (or whatever 3.next is), places all developer related tools into a sub-menu of Tools.
Attachment #347117 - Attachment is obsolete: true
Attachment #351726 - Flags: ui-review?(beltzner)
Attachment #347117 - Flags: ui-review?(beltzner)
Attached patch forgot to qrefresh... (obsolete) — — Splinter Review 
darn semi-colon ;)
Attachment #351726 - Attachment is obsolete: true
Attachment #351727 - Flags: ui-review?(beltzner)
Attachment #351726 - Flags: ui-review?(beltzner)
Page Info isn't strictly a developer related tool. It's the accessible way get security information, for instance.
(In reply to comment #2)
> >the "web search" item is awkward and inconsistent inside the tools menu
> 
> My impression was that we have that (admittedly rather awkward) command so that
> users who are using a screen reader can discover the shortcut for quickly
> accessing the Web search bar, without having to tab to it.  But I'm actually
> not entirely sure if that is the case.  If it is, I wonder if we could try to
> create menu items that are exposed to a screen reader, but are not actually
> displayed.

Shortcuts need to be discoverable to all, not just screen reader users. Furthermore, you can remove the search bar and still use your mouse to start a Web search via the menu item.
(In reply to comment #24)
> Page Info isn't strictly a developer related tool. It's the accessible way get
> security information, for instance.

Security information, aside from what's available in the site identity icon, is pretty much for developers. At least IMO ;)
Whiteboard: [has patch][needs review beltzner]
Saying "Security information, aside from what's available in the site identity icon" is problematic, because the site identity button isn't particularly discoverable and thus not really accessible. And "Permissions" are really there for the user rather than any developer whatsoever.

Also note that "developers" is quite squishy and, depending on the user's context, potentially unclear, confusing or wrong.
I propose "Advanced" instead of "Developers".
IMHO, Advanced is even more squishy than Developers, IMHO.

If we need an accessible and discoverable path to security information, I wouldn't let a submenu of the Tools menu pass for that. Oh yippie, lets turn this bug into an argument over the page info dialog :-). Sorry.
(In reply to comment #29)
> IMHO, Advanced is even more squishy than Developers, IMHO.

True, but it fits "Page Info" better, which is squishy in itself. Even those meanings of "Developers" that fit "Page Info" (e.g. "Software ~" and "Web ~") still don't cover it satisfyingly, as parts of it aren't for developers.
What does Advanced even mean? I know it's used in other pieces of software, but it's often used when they actually mean miscellaneous because they can't think of a good title to put something under.

I know an Advanced sub-grouping already exists in Firefox, I'd just like you to consider what is really means before assigning something this rather vague term.

Page Info, at least means some sort of information about the page your viewing, it's not the best term but at least it has some sort of correspondence with what your clicking. Anyway, just wanted to add a counter point to Advanced that goes a little further than "squishy" :).
"Advanced" means that the average user can ignore it. This meets the second paragraph of comment 0.

I don't understand why you're comparing "Page Info" to "Advanced" like that. I see the latter as a cover term for the former, but I didn't say that we should replace one with the other. Of course "Page Info" is more concrete than "Advanced", anything else would be wrong.
I was only comparing it because you said that "Page Info" was squishy in itself, I wasn't trying to imply to use it under any other circumstances than it currently is used.

Being not useful to the average user is more what it doesn't mean. If every item was named on the basis of keeping it away from users it's not meant for then it would end up with an unintuitive menu system. 

What I meant is what does it actually mean? Downloads means you can access downloads here, zoom means zoom options in this sub menu etc... Anyway, now I've clarified my point I'll ask you to think about it and I'll stop bug spamming now.
(In reply to comment #33)
> I was only comparing it because you said that "Page Info" was squishy in
> itself

Yeah, and let me be clearer: It's squishy in that it's both for users (this was a major achievement of bug 339102) and developers. Therefore, it can't be covered by "Developers".

> Being not useful to the average user is more what it doesn't mean. If every
> item was named on the basis of keeping it away from users it's not meant for
> then it would end up with an unintuitive menu system.
> 
> What I meant is what does it actually mean? Downloads means you can access
> downloads here, zoom means zoom options in this sub menu etc... Anyway, now
> I've clarified my point I'll ask you to think about it and I'll stop bug
> spamming now.

We're not talking about a new tool, we're talking about a label for a set of tools that "do not provide a great deal of value to mainstream users". A good definition of "Advanced tools" would be close to the definition of "Tools" rather than "Downloads" or "Zoom". It doesn't enable you to directly do a concrete job, and keeping the contained items further away from users is exactly the purpose of this bug.
Personally I think "Advanced" will just encourage extension authors to dump their menu items there (speaking as an extension author myself).
(In reply to comment #35)
> Personally I think "Advanced" will just encourage extension authors to dump
> their menu items there (speaking as an extension author myself).

Which, I agree, wouldn't make much sense, as users install extensions explicitly for a reason, in contrast to the error console for instance.
Then again, given that argument, why would an extension author want to do that?
Alias: tools-menu-bikeshed
might as well get some ui opinion on all this... (like the alias btw) ;)
Keywords: uiwanted
I prefer "Developer" to "Advanced" for a few reasons.

I think there are two important aspects to the name: it's ability to describe the items grouped under it, and it's ability to mesh with the user's intent.  In the case of "Developer" the error console is clearly a tool utilized by developers, and Page Info is about 75% percent developer centric, thanks to Jonhath's great work to make our security UI more approachable.  So I think that "Developer" for the most part describes what it contains.  Also, "Developer" is a term that people self associate with: "I am a developer."

Advanced is also a term that people self associate with, but it carries an implicit value judgment that "Developer" does not.  It is good to be advanced compared to novice, but the term "Developer" is neutral (no offense to all those cc'd).  So are users more advanced if they look for error messages and know the encoding of the page they are looking at?  "Advanced" sends a message that you don't really know how to make the ultimate use of Firefox until you have mastered the error console window.

It would also be useful to allow other developer tools to group themselves here, which likely wouldn't happen if the submenu was called advanced.  Instead we might see complex but user centric tools like advanced download managers being grouped along with the error console and the page info window, which isn't the overall intention of the submenu.
Keywords: uiwanted
(In reply to comment #38)
> It would also be useful to allow other developer tools to group themselves
> here, which likely wouldn't happen if the submenu was called advanced.  Instead
> we might see complex but user centric tools like advanced download managers
> being grouped along with the error console and the page info window, which
> isn't the overall intention of the submenu.

We want neither third-party advanced tools nor third-party developer tools there, I think. As said, the user installs these things intentionally, so they are likely primary tools to him. Putting them in a sub menu doesn't seem useful or in the spirit of this bug -- degrading what doesn't "provide a great deal of value to [mainstream] users."
(In reply to comment #39)
> We want neither third-party advanced tools nor third-party developer tools
> there, I think. As said, the user installs these things intentionally, so they
> are likely primary tools to him. Putting them in a sub menu doesn't seem useful
> or in the spirit of this bug -- degrading what doesn't "provide a great deal of
> value to [mainstream] users."

I disagree on developer tools for this, if the submenu is called "developer" - I for one would expect a developer tools to be added under Tools > Developer if that submenu existed. And I have never heard complaints about DOMi, venkman or the Java console being in Tools > Web Development in SeaMonkey.
Yes, it would make sense if random developer tools would be put in a hypothetical Developer submenu, but this doesn't mean that this is an improvement over the current situation. Similarly, it's not clear to me that SeaMonkey is more convenient than Firefox in this case. The nesting seems superfluous to me. Put another way: If there was no Developer submenu in the first place, you would expect DOMi & Co. to be just under Tools.
>As said, the user installs these things intentionally, so they
>are likely primary tools to him. Putting them in a sub menu doesn't seem useful

It depends on the nature of the tool, and is ultimately the call of the person creating the extension.  For instance, people use Firebug a whole lot, so placing it in a submenu would obviously suck.  The extension "Crash me Now" might fit better grouped with other developer tools.
Also discoverable keyboard shortcuts are key, especially for stuff like Dom Inspector, which is probably invoked pretty often.
Any chance of getting a ui decision/review here?
Flags: wanted-firefox3.6?
Not really working on this anymore, trying to go for non-bikeshed bugs...
Assignee: highmind63 → nobody
Status: ASSIGNED → NEW
Flags: wanted-firefox3.6?
Comment on attachment 351727 [details] [diff] [review]
forgot to qrefresh...

This is obsolete.

This is a _lot_ more prevalent now with the "Inspect" and "Heads Up Display" menu items...
Attachment #351727 - Attachment is obsolete: true
Attachment #351727 - Flags: ui-review?(beltzner)
Based on comment #1 (sorry, too many comments to read), this bug is fixed. We now have a Web Developer submenu in the Tools menu. More clean up could be performed, but a new bug should be filed to better target the necessary work.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: