Jennifer Morrow [:Boriss] (UX) Reporter
	Description • 14 years ago

Currently, in the add-ons manager list view, the date that each add-on was last updated is visible on each add-on's entry.  The design has been modified to remove this date, for a few reasons.

1. The intended purpose of the list view is to give a brief overview of the state of add-ons and to provide only the minimal, most used functionality.  To this end, we're trying to simplify the information displayed in list view and show only the information most useful to give an overview of installed add-ons.  By removing the last updated date, we not only provide more space per line, but eliminate the need for a sorting bar at the top of the UI.

2. Sorting by last updated date when updates are automatic does not provide useful functionality for most users.  It allows users to see which add-ons have been updated most recently, but does not give any details about that update nor provide tools to interpret the information.  Though some developers may use the last updated date as a diagnostic tool to identify which add-on updates may be causing recent problems in Firefox, the date makes a very poor diagnostic tool.  One reason is that the date does not give any information about the size nor scope of the update, and thus can only be used for diagnosis by disabling one add-on at a time.  In many cases, a  problem in Firefox caused by an add-on would in many cases be instantly identifiable as being caused by a particular add-on (eg broken toolbar).  Even if the update were not easily identifiable as a particular add-on, it could be caused by any number of reasons, and the chances of it being a recent add-on update would be only so large.  Even if we did give fuller and more useful diagnostic information with the updated date, this is far removed from other diagnostic tools.  It may be more helpful to provide information about add-on updates for problem diagnosis, but with other diagnostic tools in the UI.

3. The intended purpose of automatic updates is to remove updating from the list of things the user has to care about or remember.  By exposing updated date in main UI, we insinuate both that updated date is important and possibly that this is a process the user should manage.

4. The reason sorting was proposed in the design in the first place was to give users the ability to sort their add-ons by performance.  Sorting by performance would give a quick overview of which were the "biggest" add-ons in terms of metrics like startup time and memory.  This would be particularly useful if add-ons the user does not want were large drains on Firefox's perforamnce.  However, the ability to rank an add-on's performance is not going to be a part of Firefox 4.0, making the remaining sorting categories (alphabetic and updated date) much less useful.

	Henrik Skupin [:whimboo][⌚️UTC+1]
	Comment 1 • 14 years ago

(In reply to comment #0)
> 4. The reason sorting was proposed in the design in the first place was to give
[..]
> of Firefox 4.0, making the remaining sorting categories (alphabetic and updated
> date) much less useful.

Please keep in mind that users want to flip between ascending vs. descending sorting order. So I wouldn't remove the header. Even looking into the future, when we probably have to add another sorting preference. Then we would have to re-implement everything.

	Dave Garrett
	Comment 2 • 14 years ago

(In reply to comment #1)
> Please keep in mind that users want to flip between ascending vs. descending
> sorting order.

With a statically sorted list, switching between ascending and descending view only entails scrolling up from the bottom instead of down from the top. I think the added UI complexity isn't really warranted for this edge case.

The more important sort would be to sort the enabled addons up top in a group and the disabled addons down below in another group. This has been discussed before; there a bug for this yet? (all I see is bug 562232, but that asks for an option not a permanent sort into two labeled/headered groups)

	Dave Townsend [:mossop]
	Comment 3 • 14 years ago

(In reply to comment #0)
> 2. Sorting by last updated date when updates are automatic does not provide
> useful functionality for most users.  It allows users to see which add-ons have
> been updated most recently, but does not give any details about that update nor
> provide tools to interpret the information.  Though some developers may use the
> last updated date as a diagnostic tool to identify which add-on updates may be
> causing recent problems in Firefox, the date makes a very poor diagnostic tool.
>  One reason is that the date does not give any information about the size nor
> scope of the update, and thus can only be used for diagnosis by disabling one
> add-on at a time.

I disagree with this. If a user knows that their Firefox started behaving poorly since yesterday or a few days ago then the last update date will tell them what add-ons were updated in that range giving them a hint about what to start disabling.

	Luke Iliffe (Harlequin99)
	Comment 4 • 14 years ago

In either safe mode or when extensions.checkCompatibility.4.0 is set to false the same bar is shown (bug 566194). Presumably this bar will still be displayed even if it is not present when the above conditions are not met.

	Geoff Lankow (:darktrojan) Assignee
	Comment 5 • 14 years ago

I've only hidden the appropriate elements from view, is there any supporting code that also needs to be removed? I guess leaving the properties available is handy for extension developers.

	Geoff Lankow (:darktrojan) Assignee
	Comment 6 • 14 years ago

Whoops, just realised there's a test that relies on #list-sorters. I could change it to test #updates-sorters or #search-sorters (ick), or change it to test the sort code but not the buttons. Suggestions?

	Dave Townsend [:mossop]
	Comment 7 • 14 years ago

Comment on attachment 503763 [details] [diff] [review]
patch

When removing elements that are never going to be visible do so in the XUL/XBL rather than just hiding them in the CSS. This patch looks like it completely hides the global warning area for the list view though which isn't what we want here.

Boriss says we want to keep the last update date in the search view, you'll need to check that the searching tests actually verify it is there and correct.

	Geoff Lankow (:darktrojan) Assignee
	Comment 8 • 14 years ago

(In reply to comment #7)
> Comment on attachment 503763 [details] [diff] [review]
> patch
> 
> When removing elements that are never going to be visible do so in the XUL/XBL
> rather than just hiding them in the CSS. This patch looks like it completely
> hides the global warning area for the list view though which isn't what we want
> here.

I've hidden the date rather than removing it because that binding is also used for the other views which still want the date.

The global warning area is only hidden when there's no warning.

	Dave Townsend [:mossop]
	Comment 9 • 14 years ago

Note that this would probably need to land before the last beta to give bug 624808 a chance at landing

	Geoff Lankow (:darktrojan) Assignee
	Comment 10 • 14 years ago

I've repurposed browser_sorting.js to test the sorting code sans UI. Also changed browser_recentupdates.js and browser_searching.js to check the UI is visible and working.

	Dave Townsend [:mossop]
	Comment 11 • 14 years ago

Comment on attachment 505006 [details] [diff] [review]
patch v2

Blair ought to be able to give this a pass sooner than me

	Henrik Skupin [:whimboo][⌚️UTC+1]
	Comment 12 • 14 years ago

As comment by myself already on bug 624808, I have to add the same comment here again:

As more as I think about we should really keep the sort bar and add the "by state" sorting order. With a dozen of add-ons installed it's hard to find the one you are looking for otherwise. I feel it will be a major loss of functionality.

	Geoff Lankow (:darktrojan) Assignee
	Comment 13 • 13 years ago

(In reply to comment #12)
> As comment by myself already on bug 624808, I have to add the same comment here
> again:
> 
> As more as I think about we should really keep the sort bar and add the "by
> state" sorting order. With a dozen of add-ons installed it's hard to find the
> one you are looking for otherwise. I feel it will be a major loss of
> functionality.

I'm partial to doing it this way myself, we don't have the string(s) for it however. Is it too late?

	Dave Townsend [:mossop]
	Comment 14 • 13 years ago

(In reply to comment #12)
> As comment by myself already on bug 624808, I have to add the same comment here
> again:
> 
> As more as I think about we should really keep the sort bar and add the "by
> state" sorting order. With a dozen of add-ons installed it's hard to find the
> one you are looking for otherwise. I feel it will be a major loss of
> functionality.

I'm not sure that sorting really helps you in that case unless you happen to be looking for an add-on that was updated recently. That is really the one remaining use case for the sort bar and it is basically only useful for troubleshooting situations which immediately (hopefully) makes it not for the common users. I am a little on the fence about it myself but Boriss has convinced me that this is a worthwhile improvement.

	Jennifer Morrow [:Boriss] (UX) Reporter
	Comment 15 • 13 years ago

(In reply to comment #12)
> As comment by myself already on bug 624808, I have to add the same comment here
> again:
> 
> As more as I think about we should really keep the sort bar and add the "by
> state" sorting order. With a dozen of add-ons installed it's hard to find the
> one you are looking for otherwise. I feel it will be a major loss of
> functionality.

I don't think that Last Updated date would necessarily help users find a particular add-on.  They'd either need to 1. know when a particular add-on was updated, or 2. be manual updating add-ons.  The global search bar would be a much faster way if a user knows the name of an add-on rather than it's Last Updated date, which I'm assuming would be most cases.

	Henrik Skupin [:whimboo][⌚️UTC+1]
	Comment 16 • 13 years ago

(In reply to comment #15)
> I don't think that Last Updated date would necessarily help users find a
> particular add-on.  They'd either need to 1. know when a particular add-on was
> updated, or 2. be manual updating add-ons.  The global search bar would be a

I have never told about last update date. IMO the most used sort criteria would be by name and by status (and second by name).

	Dão Gottwald [:dao]
	Comment 17 • 13 years ago

http://hg.mozilla.org/mozilla-central/rev/2b66675f6750

	Henrik Skupin [:whimboo][⌚️UTC+1]
	Comment 18 • 13 years ago

Dave, from your inspection, do we need a manual test?

	Xleon
	Comment 19 • 13 years ago

What another pointless change.. I want to be able sort addons by Name and Last Updated at times.. and especially not have to go into each extensions view just see that last updated info....now its gone, I use a LOT more than 5 extensions unlike it seems those wanting these changes.

This also effects the development AIOS with more unnecessary work because loss of functionality been removed 3 files.

extensions.js 
extensions.xul 
browser_recentupdates

When display:none on the sort bar /last updated details could have been just fine your Borgiss.

You know if were going on this remove everything direction, why not remove the "description info ....More" totally pointless that, then bump up [Options] [Disable] [Remove] buttons so its all slimmer and we don't have this bloated extensions list! .. oh no... must have bloated looking list views with lots of empty blank space. Urrrgh

	Dave Townsend [:mossop]
	Comment 20 • 13 years ago

(In reply to comment #18)
> Dave, from your inspection, do we need a manual test?

No I think we're fine without

	makondo
	Comment 21 • 13 years ago

This is beyond 'surprise!' - you're removing the most useful info and function to 'provide more space per line' for what reason? it's empty! Who needs a plain list of exts. (which, btw, can't be even copy/pasted as the Lclick menu isn't there)? That's what people want - glance and quickly get an idea about what they have and what is happening with their addons. Why would anybody want to stare at a plain list and then go clicking around just to see when an ext. has been updated last? Why cancel sorting when it's one of the reasons people install MR Tech Toolkit? - to complete what's missing!
No sense, whatsoever.

	Csaba Kozák [:WonderCsabo]
	Comment 22 • 13 years ago

I agree. I used that feature many times. If you really want to "clear" the UI, why don't you just hide the sortings by default?

	Xleon
	Comment 23 • 13 years ago

Pointless change is pointless, 

Status change: resolve as BROKEN

This gets worse.. (disabled) extensions now all stack at the bottom of panel instead of adhering to at least some alphabetical order within the existing INSTALLED list extensions (like it always used to be!), they were easier to find and spot why the change now??...also [enable] does nothing.. I'm guessing its this nonbug that caused the regression.

Do these counter issues and reasons for leaving things that work alone when you're not really improving the functionality at all, really have to be spelled out in big painted picture detail for it to be understood.

Mokonda, I know, I know, design logic fail.. *features and functionality confusing* No sense monkey throw out.

"Why cancel sorting when it's one of the reasons people
install MR Tech Toolkit? - to complete what's missing!"

Something tells me that useful extension ain't going to be coming back for LONG time what with this addon panel mess up and continued pointless cosmetic changes that aren't even wide user benefiting improvements.. like making the lists slimmer so as to decrease teh scrolling. Seeing  as every last bit of actual useful information is being chucked out.. now that's an idea.

	Xleon
	Comment 24 • 13 years ago

"extensions now all stack at the bottom of panel
instead of adhering to at least some alphabetical order within the existing
INSTALLED list extensions (like it always used to be!), "

I forgot to add...disabled extensions at bottom in... NON alphabetical order.. I'm lovin' it. <sigh>

	Dave Townsend [:mossop]
	Comment 25 • 13 years ago

This bug is now resolved, if you want to start a discussion on why you think it is a bad idea then the most appropriate place is the newsgroups, mozilla.dev.apps.firefox probably.

	Xleon
	Comment 27 • 13 years ago

Following on.. they might be in some order but there is no SORT bar to say. And that other last updated field information is no longer displayed for me to see.... so I haven't a clue what dis'order' disabled extensions are actually in. It's just not the same as enabled ones.. could be last updated? I guess I've got to just individually check them all.

p.s I've come up with a new addons manager direction... see attachment above. :)

	Xleon
	Comment 28 • 13 years ago

Roger that Dave... I'll head there right now.

	Xleon
	Comment 29 • 13 years ago

Personally I think the best place to discus it is right here, where its been messed up.

	Shawn Wilsher :sdwilsh
	Comment 30 • 13 years ago

(In reply to comment #29)
> Personally I think the best place to discus it is right here, where its been
> messed up.
That's nice, but doing so would be a violation of bugzilla etiquette and could result in your account being disabled:
https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

	Dave Garrett
	Comment 31 • 13 years ago

Comment on attachment 506893 [details]
rude mocking of design

Don't upload junk out of spite. Better yet, don't be spiteful.

I'm getting sick and tired of a vocal minority of very rude individuals spamming bugs whenever there's even the most minor of changes they don't like. Please, stop clogging up our inboxes with rants. (though I expect instead a rude reply)

I'm not going to bother defending the changes made here because they're fairly well thought out and get rid of things that nobody really needs. Yeah, there may be one or two that might care, and at least one is here complaining, but that does not mean that it wasn't the best move for the other few hundred million users.

(In reply to comment #24)
> I forgot to add...disabled extensions at bottom in... NON alphabetical order..

I don't see that here, but if you can reproduce that please file a new bug.

	Henrik Skupin [:whimboo][⌚️UTC+1]
	Comment 32 • 13 years ago

Verified fixed with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b11pre) Gecko/20110127 Firefox/4.0b11pre. Also checked safe-mode for the global warning box.