405888 - Remove the "Information" button at the right of every download row

Status: VERIFIED FIXED

(Toolkit :: Downloads API, enhancement)

Description

[Madhava Enros [:madhava]]

[actually nominating for wanted]

As shown in this mockup (attached to bug 397655) :
https://bugzilla.mozilla.org/attachment.cgi?id=288692

As of bug 405884 (show date and time for each download), all of the user tasks associated with information behind the information button are supported even without the button.  See below for the reasoning.

Given that fact, the value of having a button here is outweighed by the simplicity we can achieve by removing it.

Rationale:

No need for the source URL:
The two user-tasks associated with seeing the source information are (a) going
there and (b) using some part of that information to tell you what the download
is.  In the first case, we've supported that by making "Go to Source Location"
(and copy for good measure) available in the right-click menu, which is a
shorter path than viewing, copying, opening a tab, and pasting.  In the latter
(b), we made this simpler by listing the TLD inline with each download.

No need for the local location:
The tasks are (a) getting to the download to launch it, and (b) to see where you put it.  Double-clicking the row (or, for discoverability, right-clicking) launches the download, so that's (a) covered. As for (b), "Open Containing Folder"/"Show in Finder" is in the right-click menu.

No need for the date/time:
As of bug 405884, the date/time is put in a location that's better suited to its use in helping users find the downloads that they're looking for.

In other words, we've supported the user tasks (in fact, made them quicker!)
while streamlining the UI.

Comment 1

[aja+bugzilla]

FWIW, seems to me to be bad from a keyboard/non-pointing device/accessibility point of view.

Comment 2

[aja+bugzilla]

(In reply to comment #1)
> FWIW, seems to me to be bad from a keyboard/non-pointing device/accessibility
> point of view.
> 
Partial retraction, if the same info's available in context menu:
Context menu can be accessed via Shift-F10 (or via Menu key on 104-key keyboards).
Discoverability may remain an issue.

Comment 3

[Ed Lee :Mardak]

Attachment: screenshot of v1

Info button is gone.

Comment 4

[Ed Lee :Mardak]

Attachment: v1

Clear up the info button functionality, UI, styling.

Comment 5

[Shawn Wilsher :sdwilsh]

(In reply to comment #1)
> FWIW, seems to me to be bad from a keyboard/non-pointing device/accessibility
> point of view.
a11y bugs are being addressed in another bug (there's about 20 DM bugs being actively worked on, and the comments are in one of them.  Sadly, I don't know which offhand...).

Comment 6

[Shawn Wilsher :sdwilsh]

Comment on attachment 291536 [details] [diff] [review]
v1

>-
>-// If the user has interacted with the window in a significant way, we should
>-// not auto-close the window. Tough UI decisions about what is "significant."
>-var gUserInteracted = false;
> 
> // These strings will be converted to the corresponding ones from the string
> // bundle on startup.
> let gStr = {
>   paused: "paused",
>   statusFormat: "statusFormat2",
>@@ -231,13 +226,13 @@ function autoRemoveAndClose(aDownload)
>     // opened by the download process, rather than by the user, it should
>     // auto-close if the pref is set that way. If the user opened it themselves,
>     // it should not close until they explicitly close it.
>     var autoClose = pref.getBoolPref(PREF_BDM_CLOSEWHENDONE);
>     var autoOpened =
>       !window.opener || window.opener.location.href == window.location.href;
>-    if (autoClose && autoOpened && !gUserInteracted) {
>+    if (autoClose && autoOpened) {
please don't remove this.  It's rather important!

Also, update http://mxr.mozilla.org/seamonkey/source/toolkit/themes/gnomestripe/mozapps/downloads/downloads.css

r=sdwilsh with these fixed.

Comment 7

[Shawn Wilsher :sdwilsh]

(In reply to comment #5)
> (In reply to comment #1)
> > FWIW, seems to me to be bad from a keyboard/non-pointing device/accessibility
> > point of view.
> a11y bugs are being addressed in another bug (there's about 20 DM bugs being
> actively worked on, and the comments are in one of them.  Sadly, I don't know
> which offhand...).
Looks like I was thinking of Bug 357540.

Comment 8

[Reed Loden [:reed]]

(In reply to comment #0)
> No need for the date/time:
> As of bug 405884, the date/time is put in a location that's better suited to
> its use in helping users find the downloads that they're looking for.

I disagree completely with this. This _removes_ my ability to see the exact date/time for when I downloaded something. I'm now stuck with "Yesterday", "Tuesday", etc. What about the hour and minute? I find that extra tidbit of info extremely useful. I would be ok with it if that same info was included in the normal view (e.g., "Tuesday, 3:12pm" instead of just "Tuesday"), but without that, removing the info button is a regression in functionality and usefulness.

Comment 9

[Shawn Wilsher :sdwilsh]

(In reply to comment #8)
> I disagree completely with this. This _removes_ my ability to see the exact
> date/time for when I downloaded something. I'm now stuck with "Yesterday",
> "Tuesday", etc. What about the hour and minute? I find that extra tidbit of
> info extremely useful. I would be ok with it if that same info was included in
> the normal view (e.g., "Tuesday, 3:12pm" instead of just "Tuesday"), but
> without that, removing the info button is a regression in functionality and
> usefulness.
Sorry, but I think we are going to stick with this for Firefox 3 (unless there's a massive outcry after B3).  You are more than welcome to make an Add-on to get it back.

Comment 10

[Ed Lee :Mardak]

Attachment: v1.1

r+ sdwilsh

(In reply to comment #6)
> >-var gUserInteracted = false;
> >-    if (autoClose && autoOpened && !gUserInteracted) {
> please don't remove this.  It's rather important!
Restored the gUserInteracted stuff.

> Also, update
> http://mxr.mozilla.org/seamonkey/source/toolkit/themes/gnomestripe/mozapps/downloads/downloads.css
Updated to remove info stuff.

Comment 11

[Reed Loden [:reed]]

(In reply to comment #9)
> Sorry, but I think we are going to stick with this for Firefox 3 (unless
> there's a massive outcry after B3).  You are more than welcome to make an
> Add-on to get it back.

Sorry, but I want a UX answer to my statement in comment #8, and I'd prefer it before this patch lands.

Comment 12

[Madhava Enros [:madhava]]

(In reply to comment #11)

So, about this:

"I disagree completely with this. This _removes_ my ability to see the exact
date/time for when I downloaded something. I'm now stuck with "Yesterday",
"Tuesday", etc. What about the hour and minute? I find that extra tidbit of
info extremely useful. I would be ok with it if that same info was included in
the normal view (e.g., "Tuesday, 3:12pm" instead of just "Tuesday"), but
without that, removing the info button is a regression in functionality and
usefulness."

We removing some detail, yes, but I disagree that it's a regression in usefulness.  It's not free, in terms of a user's information-processing time, to include extra information that is likely to be useful only in unusual circumstances.  By removing it, we make the information that is more likely of use -- a sense, with sufficient granularity, of when the download was downloaded -- much more prominent and scannable.

That said, I'm curious to hear about your scenario where that level of detail is valuable.  Also, in The Future, when we have a Downloads section in Places Organizer, we could certainly list the exact date and time.  The task in that case won't be scanning through a list, so there would be no downside.


> (In reply to comment #9)
> > Sorry, but I think we are going to stick with this for Firefox 3 (unless
> > there's a massive outcry after B3).  You are more than welcome to make an
> > Add-on to get it back.
> 
> Sorry, but I want a UX answer to my statement in comment #8, and I'd prefer it
> before this patch lands.
> 

Comment 13

[Ed Lee :Mardak]

Checking in toolkit/locales/en-US/chrome/mozapps/downloads/downloads.dtd;
/cvsroot/mozilla/toolkit/locales/en-US/chrome/mozapps/downloads/downloads.dtd,v  <--  downloads.dtd
new revision: 1.21; previous revision: 1.20
done
Checking in toolkit/mozapps/downloads/content/download.xml;
/cvsroot/mozilla/toolkit/mozapps/downloads/content/download.xml,v  <--  download.xml
new revision: 1.47; previous revision: 1.46
done
Checking in toolkit/mozapps/downloads/content/downloads.js;
/cvsroot/mozilla/toolkit/mozapps/downloads/content/downloads.js,v  <--  downloads.js
new revision: 1.116; previous revision: 1.115
done
Checking in toolkit/mozapps/downloads/content/downloads.xul;
/cvsroot/mozilla/toolkit/mozapps/downloads/content/downloads.xul,v  <--  downloads.xul
new revision: 1.40; previous revision: 1.39
done
Checking in toolkit/themes/gnomestripe/mozapps/downloads/downloads.css;
/cvsroot/mozilla/toolkit/themes/gnomestripe/mozapps/downloads/downloads.css,v  <--  downloads.css
new revision: 1.3; previous revision: 1.2
done
Checking in toolkit/themes/pinstripe/mozapps/downloads/downloads.css;
/cvsroot/mozilla/toolkit/themes/pinstripe/mozapps/downloads/downloads.css,v  <--  downloads.css
new revision: 1.21; previous revision: 1.20
done
Checking in toolkit/themes/winstripe/mozapps/downloads/downloads.css;
/cvsroot/mozilla/toolkit/themes/winstripe/mozapps/downloads/downloads.css,v  <--  downloads.css
new revision: 1.25; previous revision: 1.24
done

Comment 14

[Stephen Donner [:stephend] Not actively reading bugmail]

https://litmus.mozilla.org/show_test.cgi?id=4569 and
https://litmus.mozilla.org/show_test.cgi?id=4551 have both been smitten.

in-litmus+

Comment 15

[Stephen Donner [:stephend] Not actively reading bugmail]

Verified FIXED using:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b3pre)
Gecko/2007123104 Minefield/3.0b3pre

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b3pre) Gecko/2007123104
Minefield/3.0b3pre

--and--

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b3pre) Gecko/2007123105
Minefield/3.0b3pre

Comment 16

[u294409]

So, info bubble has been removed?

Comment 17

[Shawn Wilsher :sdwilsh]

(In reply to comment #16)
> So, info bubble has been removed?
yes