[Tracking Requested - why for this release]: See Attached

Plugin name is also truncated

I wonder if we should be dropping/shrinking the version number from the main list. What do you think Michael?

Adding a tracking flag for firefox41 as well.

So, the offending Bug 989469 should be backed out until Mozilla fix the problem.

It is time to back the rotten Bug989469 out, if you can not fix the glich.

I think we're beyond the point where a backout makes sense for such an issue. I'd right find a solution. Can anyone from UX help here?

This comes from the wish in bug 989469 comment 73 to center the buttons. Let's decide UX what should be done.

So we either (1) not center the buttons, at least as soon as we start truncating text. Or we (2) break the title in multiple lines instead of truncating. Or we (3) truncate the version as well and give it a tooltiptext containing the full version. I suggest to continue with option (3) (as mocked up in the attachment) as this would be necessary for (1) anyway - assuming versions can get even longer - and option (3) would unnecessarily increase the height of boxes with long names to give those add-ons more attention and break the vertical rhythm. In addition we should set a min-width (500px) for the scrollbox to not be able to compress everything too much and thus make it unreadable. (500px is the width in the attachment) As an advanced step we could replace the button-texts with icons when under a certain width to get some more space for the add-ons name. (This will require Michael helping us.) (as mocked up in the attachment)

updated truncated version length to match width.

(In reply to Dave Townsend [:mossop] from comment #2) > I wonder if we should be dropping/shrinking the version number from the main > list. What do you think Michael? Markus, can we just completely drop the version number from the list view? I don't think it's of much use there. For those few users who need it, it would remain in the details view.

I think that Icon is not necessary to manage addons Add-on name in warning description is redundancy Label of More and More information link is not necessary, if the description and warning were click-able link Name and Version are important to manage addon.

(In reply to Alice0775 White from comment #11) > I think that > Icon is not necessary to manage addons [...] > Name and Version are important to manage addon. The icon seems helpful for scanning the list and identifying add-ons. I still don't see how the version number is important here.

(In reply to Dão Gottwald [:dao] from comment #10) > (In reply to Dave Townsend [:mossop] from comment #2) > > I wonder if we should be dropping/shrinking the version number from the main > > list. What do you think Michael? > > Markus, can we just completely drop the version number from the list view? I > don't think it's of much use there. For those few users who need it, it > would remain in the details view. I agree with this. We can always include it in a tooltip or when the list view is wide enough to accommodate.

(In reply to Markus Jaritz [:maritz] (UX) from comment #8) > In addition we should set a min-width (500px) for the scrollbox to not be > able to compress everything too much and thus make it unreadable. (500px is > the width in the attachment) This will add a horizontal scrollbar to the content area when the browser window is shrunk too small, is that what we want or would it be better for the list to get a scrollbar instead?

The number version lets to know, for example, when an add-on is a 'beta' build, so it has a different update channel from AMO...

(In reply to Carlos [:nohamelin] from comment #15) > The number version lets to know, for example, when an add-on is a 'beta' > build, so it has a different update channel from AMO... The question is not whether the version number conveys any information, but whether that information needs to be part of and clutter up the list view rather than the details view.

Please do not swap problems. See Bug 989469 Mockup of list view, there are version #. The UX designer think version# is necessary. If version# is removed from list view, in this case, back Bug 989469 out first. And then, it should be remanded to the UX designer.

(In reply to Alice0775 White from comment #17) > See Bug 989469 Mockup of list view, there are version #. The UX designer > think version# is necessary. Bug 989469 was merely a restyling. Whether version numbers are necessary in the list view was never up for question there in the first place, and so no explicit decision has been made on that. We have pending needinfo requests for that here.

(In reply to Dave Townsend [:mossop] from comment #13) > (In reply to Dão Gottwald [:dao] from comment #10) > > (In reply to Dave Townsend [:mossop] from comment #2) > > > I wonder if we should be dropping/shrinking the version number from the main > > > list. What do you think Michael? > > > > Markus, can we just completely drop the version number from the list view? I > > don't think it's of much use there. For those few users who need it, it > > would remain in the details view. > > I agree with this. We can always include it in a tooltip or when the list > view is wide enough to accommodate. I did try to work with what we have, but if we want to raise this bug a level, sure, remove the version number and put it in the tooltip as Dave suggests, it will improve readability of the view for a lot of users, and make it appear a little less technical. As we have default auto update for add-ons I do not see a reason to show the version in the overview. (In reply to Dave Townsend [:mossop] from comment #14) > (In reply to Markus Jaritz [:maritz] (UX) from comment #8) > > In addition we should set a min-width (500px) for the scrollbox to not be > > able to compress everything too much and thus make it unreadable. (500px is > > the width in the attachment) > > This will add a horizontal scrollbar to the content area when the browser > window is shrunk too small, is that what we want or would it be better for > the list to get a scrollbar instead? Yes, it is either that, or list items that get very high when each word of a warning is an individual line. Under 500px a horizontal scrollbar is the lesser of two evils. (In reply to Carlos [:nohamelin] from comment #15) > The number version lets to know, for example, when an add-on is a 'beta' > build, so it has a different update channel from AMO... This is something a dev can also add to the add-on name (beta), indicate in the icon, or in the description. It is not necessarily the version number that needs to convey that. The version number is a detail to exactly know which version an add-on is, and thus can be place in the detail view and tooltip.

Looks like Markus has already answered everything here, so I'm removing my needinfo :) I agree that we can just remove the version numbers in the main UI.

I have a WIP here, just needs test fixes.

A little more tricky than expected since we show/hide the version depending on various things but this works. Much of the test changes are whitespace only.

Comment on attachment 8621713 [details] [diff] [review] patch >+ <tooltip id="addonitem-tooltip"> >+ <hbox> >+ <label id="addonitem-tooltip-name"/> >+ <label id="addonitem-tooltip-version"/> >+ </hbox> >+ </tooltip> Labels in tooltips should use the tooltip-label class, otherwise the tooltip has excessive padding. But if you add that class to your labels, there would be no room between the two labels, which we don't want either. Can you build the label from a localizable string, e.g. "%1$S %2$S"? Or maybe this doesn't need to be localized and you can just do name + " " + version?

(In reply to Dão Gottwald [:dao] from comment #23) > Comment on attachment 8621713 [details] [diff] [review] > patch > > >+ <tooltip id="addonitem-tooltip"> > >+ <hbox> > >+ <label id="addonitem-tooltip-name"/> > >+ <label id="addonitem-tooltip-version"/> > >+ </hbox> > >+ </tooltip> > > Labels in tooltips should use the tooltip-label class, otherwise the tooltip > has excessive padding. But if you add that class to your labels, there would > be no room between the two labels, which we don't want either. Can you build > the label from a localizable string, e.g. "%1$S %2$S"? Or maybe this doesn't > need to be localized and you can just do name + " " + version? I could just add some padding or a spacer between the tooltips. I assume that RTL languages would want the order reversed so it's either this or a localizable string and I wanted to avoid the latter to make uplift more likely. What do you think?

? No Addon name By the way, Do not remove version# in List View. It is important. "Update" is redundant

(In reply to Dave Townsend [:mossop] from comment #24) > > Labels in tooltips should use the tooltip-label class, otherwise the tooltip > > has excessive padding. But if you add that class to your labels, there would > > be no room between the two labels, which we don't want either. Can you build > > the label from a localizable string, e.g. "%1$S %2$S"? Or maybe this doesn't > > need to be localized and you can just do name + " " + version? > > I could just add some padding or a spacer between the tooltips. I assume > that RTL languages would want the order reversed so it's either this or a > localizable string and I wanted to avoid the latter to make uplift more > likely. What do you think? I don't think the order would be different for RTL; name + " " + version would probably work fine.

What's wrong with moving the button back down beside the description from where it is now where it achieves nothing but truncation a lot of useless empty space? (Meanwhile keeping important information visible)

Updated patch

Comment on attachment 8622567 [details] [diff] [review] patch >+ let addonItem = document.tooltipNode; Please use tooltip.triggerNode instead. >+ <tooltip id="addonitem-tooltip"> >+ <hbox> >+ <label id="addonitem-tooltip-label" class="tooltip-label"/> >+ </hbox> >+ </tooltip> Please get rid of addonitem-tooltip-label, i.e. replace the above with <tooltip id="addonitem-tooltip"/>, and use tooltip.label instead of label.value throughout the patch. r=me with that

Losing add-on version information at first sight should not be more important than an add-ons manager theme with oversized text labels. Please revert this change or make it optional.

(In reply to Dão Gottwald [:dao] from comment #29) > Comment on attachment 8622567 [details] [diff] [review] > patch > > >+ let addonItem = document.tooltipNode; > > Please use tooltip.triggerNode instead. Looks like this hasn't been addressed.

Sorry about that, landed the change.

Approval Request Comment [Feature/regressing bug #]: Bug 989469 [User impact if declined]: In smaller windows the add-on name gets extremely truncated. [Describe test coverage new/current, TreeHerder]: On m-c for two days [Risks and why]: Low, this is largely just a UI change [String/UUID change made/needed]: None

Comment on attachment 8624962 [details] [diff] [review] aurora patch Obvious and recent regression, has test, taking it.

The better solution would be to only show the option buttons when hovering the add-on, resulting in a more functional and cleaner UI. The solution would also only require a simple CSS change to only show the options' section when the mouse is over the respective add-on. See attachment for example.

(In reply to yonezpt from comment #40) > Created attachment 8627218 [details] > hovering to show option buttons > > The better solution would be to only show the option buttons when hovering > the add-on, resulting in a more functional and cleaner UI. The solution > would also only require a simple CSS change to only show the options' > section when the mouse is over the respective add-on. See attachment for > example. FWIW I don't think this is a good idea as it doesn't make it obvious to the user that they can do anything to add-ons in the list until they hover over one. However this isn't the place to discuss it. This bug is closed. Either file a new bug or discuss ideas in the newsgroups.

Shouldn't there at least be an option to add a "version number" line to the bottom of each addon, like in the plugins section?

I'm glad I finally found this bug so I can give my 2¢ ... removing version numbers globally from about:addons was a stupid change and makes for huge headaches trying to manage a ton of Greasemonkey scripts. Someone tell me, does Firefox not want developers to use this browser anymore?

(In reply to James Donohue from comment #43) > I'm glad I finally found this bug so I can give my 2¢ ... removing version > numbers globally from about:addons was a stupid change and makes for huge > headaches trying to manage a ton of Greasemonkey scripts. Someone tell me, > does Firefox not want developers to use this browser anymore? (In reply to johnsc301 from comment #42) > Shouldn't there at least be an option to add a "version number" line to the > bottom of each addon, like in the plugins section? (In reply to Aris from comment #32) > Losing add-on version information at first sight should not be more > important than an add-ons manager theme with oversized text labels. Please > revert this change or make it optional. (In reply to Alice0775 White from comment #25) > By the way, Do not remove version# in List View. It is important. We are optimizing for the majority of users, and most users do not need to know the version number as they are on auto-update and will always have the newest version. Questions like "Which add-ons do I have?", "Which add-ons are active?" and "What do these add-ons do?" are probably more frequent questions, than which version number is an add-on, or is it a beta version. Besides that, I do understand that for the (add-on) developers and heavy add-on users among our users the version number plays a more important role. And we do want to support those, but without breaking the main use cases. If you can elaborate on the use cases for which a version number is needed, and give your estimate of how many users are affected by it, we can consider those use cases in the upcoming iterations/improvements of add-on manager. I look forward to learn more about how your use the add-ons manager. Greasemonkey as an add-on uses the same appearance as extensions, but as add-ons do not need to follow our design, so they probably could have kept the version number if they saw the need for it.

(In reply to James Donohue from comment #43) > I'm glad I finally found this bug so I can give my 2¢ ... removing version > numbers globally from about:addons was a stupid change and makes for huge > headaches trying to manage a ton of Greasemonkey scripts. Someone tell me, > does Firefox not want developers to use this browser anymore? Use add-ons that are currently available to restore the version number (search AMO for "version number"). No Firefox UI change -as wrong as users might see it- ever got reverted. Some Mozilla guys think they know best and are constantly removing "features" using the same excuse: "the average user does not need this and that" or "we are optimizing for the majority of users", but these devs fail to see "the average user is using Internet Explorer and Google Chrome" without any need to switch to something else. @Markus What use case does the version number break? Please tell one. Of course long version numbers ala 1.4.808342.9820.beta7 may hide add-on names on low resolutions, but only because add-on managers theme for Fx40+ is badly designed (-> e.g. huge fonts and huge gaps for no reason). Everything was fine till Fx40. And btw. "the majority of users" do have big screens and are not using 800x600 resolutions on their desktop systems.

(In reply to Aris from comment #45) > No Firefox UI change -as wrong as users might see it- ever got reverted. > Some Mozilla guys think they know best and are constantly removing > "features" using the same excuse: "the average user does not need this and > that" or "we are optimizing for the majority of users", but these devs fail > to see "the average user is using Internet Explorer and Google Chrome" > without any need to switch to something else. If we should not aim for the majority of users, what are the users we should aim for, and will this support Mozilla's mission? (In reply to Aris from comment #45) > What use case does the version number break? Please tell one. Of course long > version numbers ala 1.4.808342.9820.beta7 may hide add-on names on low > resolutions, but only because add-on managers theme for Fx40+ is badly > designed (-> e.g. huge fonts and huge gaps for no reason). Everything was > fine till Fx40. To quote myself: (Quoting Markus Jaritz [:maritz] (UX) from comment #19) > I did try to work with what we have, but if we want to raise this bug a > level, sure, remove the version number and put it in the tooltip as Dave > suggests, it will improve readability of the view for a lot of users, and > make it appear a little less technical. As we have default auto update for > add-ons I do not see a reason to show the version in the overview. This can be seen as a step towards our effort to make add-ons more approachable for non-tech users, to get the awesomeness of add-ons out to even more users. And in this sens the use cases are the three questions I mentioned in my previous comment. And no, the version number does not break this use cases, but makes them a bit harder, as the version number is in those cases unneeded information the user has to filter out. Please provide your uses cases that need the version number as well. I am honestly interested in understanding those better to provide a good experience for devs as well. I think we need a good mix of users to keep Firefox an interesting browser with a lot of great add-ons developed and used by a broad audience. And yes, this is hard to achieve, as those groups are sometimes (very often) rather different, as we can see here.

You should not aim for "a majority" of users, but the remaining power users, that keep this browser alive. Like I said the average user does not even now there are different browsers out there. Either they click on the big "E" (Internet Explorer / Edge) to open "the internet (its what they call it)" or they use Google Chrome, that got installed automatically, which gets bundled with a lot of software packages nowadays and which they now from their Android device. Case 1 As an add-on developer it is often helpful to know which add-ons and add-on versions an "average user" has installed, if you want to find what causes conflicts for example. Since it is way to complicated to explain or guide them where to find complete lists and/or how to dump these lists and it is far too much effort to ask users to look up all versions by hovering over every add-ons name or open the more info page, the most common case to share installed add-on info is taking screenshots. Screenshots don't show version numbers. Case 2 If you run tests with different release and developer builds of an add-on and switch often between them, it is easier to see immediately which version an add-on offers. Such tests are not limited to add-on developers. Sometimes users need to run some tests too, if a dev asks them to do or if they are curious about which version of an add-on broke something. Case 3 Plugs-ins show version numbers too. It may be important to see which version the installed Adobe Flash player has. Flash player might not get updated automatically. This applies to other plug-ins too. Case 4 Greasemonkey scripts have versions too, that users and devs need to know (like James mentioned). We don't ask you to go against your initial goals (hardcore simplification of Firefox). Just provide a about:config pref to revert such changes for users who need them. But maybe this whole discussion is pointless anyway. After deprecation of XUL and XPCOM in 12-18 month Firefox most likely will die a fast death.

Aris: Version numbers are not coming back in vanilla Firefox (or Thunderbird, or SeaMonkey), but see https://addons.mozilla.org/addon/amversionnumber/

P.S. And even without adding anything, they are still visible in about:support (Help → Troubleshooting Information).

@Tony, you know that you linked my add-on, don't you? ;-) I only listed four cases on why the version numbers are important as an answer to Markus.

(In reply to Aris from comment #50) > @Tony, you know that you linked my add-on, don't you? ;-) Well, your name didn't ring a bell; but I love your extension. :-/