Closed Bug 988969 Opened 10 years ago Closed 10 years ago

[UX work] Design Australis downloads widget

Categories

(Firefox :: Downloads Panel, defect)

x86
macOS
defect
Not set
normal

Tracking

()

VERIFIED FIXED
Firefox 31

People

(Reporter: zfang, Assigned: zfang)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

(Whiteboard: [ux] p=5 s=it-31c-30a-29b.3 [qa-])

Attachments

(1 file)

Design the download button when it's moved into the menu panel.
Whiteboard: [ux] p=0
Assignee: nobody → zfang
Status: NEW → ASSIGNED
Whiteboard: [ux] p=0 → [ux] p=5 s=it-31c-30a-29b.2 [qa-]
I'm working on the design for downloads panel when moved into the menu, and I'd love to know the technical constraints early on. For example is there anything that's impossible or really hard to do in the menu subview vs. the door hanger that I should know? maybe the progress bar? actions to open/pause a file? I'm referring to shorlaner's mockup here: http://people.mozilla.org/~shorlander/mockups-interactive/australis-interactive-mockups/windows8.html 
 
Marco, I know you've been working on the download panel in the tool bar, could you shed some light on this?
Flags: needinfo?(mak77)
No longer blocks: fxdesktopbacklog
Flags: firefox-backlog+
As far as I can tell, we can plug whatever XUL we want into the menu, so I don't think there's anything impossible to port from the downloads arrowpanel to the menu. The only tricky part may be to handle the menu closing at the right time (some actions should likely close it, while other should not) but off-hand it's just more code to write.
Flags: needinfo?(mak77)
the only think I just came to my mind now, is that the horizontal space in the menu may not be enough for the status text of each download (consider the mockup is en-us and other localizations may take up more space). we can crop the filename but I'm not sure we want to crop the status line. And I don't think we want the menu to grow. The arrow panel can grow horizontally instead.
(In reply to Marco Bonardo [:mak] from comment #3)
> the only think I just came to my mind now, is that the horizontal space in
> the menu may not be enough for the status text of each download (consider
> the mockup is en-us and other localizations may take up more space). we can
> crop the filename but I'm not sure we want to crop the status line. And I
> don't think we want the menu to grow. The arrow panel can grow horizontally
> instead.

Given the mentioned constraints, that actually require a different design and some adjustments on the go, and not just a port of the existing design, are we taking into account the other options?

* We could just show a list of filenames, similar to the one in the History submenu. After all, the use case mentioned in bug 947250 comment 2 is just about opening recently completed downloads.
* We could make the Downloads Button just open the Library window, no subview. The introduction of a subview will make users that _want_ to use the button to open the Library window require at least one more click.
* We could move the Library window to be in-content, or switch to an in-content Downloads view for all windows. This will probably alleviate the expressed need to avoid opening the Library window from the panel in the first place.

Also, have we measured how many users in the beta channel do actually customize away the Downloads button? Removing the button actually removes the feature of seeing the progress indication in the first place, so I see little reason to remove it from the toolbar. While it would be great to have any possible interaction available by default in the browser, we have to evaluate the cost of maintaining different combinations of button placements, and whether it would make sense to have add-ons provide the features that are required less often.
> Given the mentioned constraints, that actually require a different design
> and some adjustments on the go, and not just a port of the existing design,
> are we taking into account the other options?
> 
> * We could just show a list of filenames, similar to the one in the History
> submenu. After all, the use case mentioned in bug 947250 comment 2 is just
> about opening recently completed downloads.

I agree that opening a recently completed download is probably the main use case, but it might be confusing if we don't show the currently downloading file or don't differentiate them from the completed ones.

> * We could make the Downloads Button just open the Library window, no
> subview. The introduction of a subview will make users that _want_ to use
> the button to open the Library window require at least one more click.

Opening the Library is what the button does right now. Like you said, most users probably want to open a recently downloaded file than go to the Library. So showing recently downloads in the subview is way more helpful than just opening the Library. Just like showing a History subview is helpful than just open history in library when clicking on the history button.

> * We could move the Library window to be in-content, or switch to an
> in-content Downloads view for all windows. This will probably alleviate the
> expressed need to avoid opening the Library window from the panel in the
> first place.

Moving library in-content is currently in bug 697359

> Also, have we measured how many users in the beta channel do actually
> customize away the Downloads button? Removing the button actually removes
> the feature of seeing the progress indication in the first place, so I see
> little reason to remove it from the toolbar. While it would be great to have
> any possible interaction available by default in the browser, we have to
> evaluate the cost of maintaining different combinations of button
> placements, and whether it would make sense to have add-ons provide the
> features that are required less often.

I assume currently not many people put the download button into the menu because it doesn't do much, and that's why we need to design a subview to make it useful. Noted that we are not creating subview for every function in the menu, we only use subview when we think it has user value, and I think downloads button is one of them.
Attached image DownloadPanel.jpg
Update on Design

I made a mockup based on shorlander's design for the downloads panel. They look pretty similar, except I made the file icon smaller and changed the file size "1023/1040" into a percentage in the secondary text, so that it fits the width in the sub view.

I know there's some concerns on localization and layout, and if the issue is relevant to both the downloads panel and the downloads subview, please comment also on bug 963745
Depends on: 963745
Whiteboard: [ux] p=5 s=it-31c-30a-29b.2 [qa-] → [ux] p=5 s=it-31c-30a-29b.3 [qa-]
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
Target Milestone: --- → Firefox 31
Summary: [UX work] Design download button when it's moved into the menu panel → [UX work] Design Australis downloads widget
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: