377782 - Simplify content-handling UI

Status: NEW

(Firefox :: File Handling, defect)

Description

[Dan Mosedale (:dmosedale, :dmose)]

Previous discussions with mconnor suggest this primarily relates to the various save dialogs and the user experience surrounding that.  mconnor, can you fill in any other details here?

Comment 1

[Mike Connor [:mconnor]]

One item is to make Open in the Open/Save dialog work like the Download Manager or IE's dialog, and just call nsIFile.launch().  How this intertwines with "Open with web handler" is TBD.  But keeping our own mimetypes system, that we only use when directly opening, and not when we're opening from a temp file, seems broken to me.

There's some potential sanitizing work in the Download Actions window, which is rather lacking in ease of use, but that might be ok...

Comment 2

[Christian :Biesinger (don't email me, ping me on IRC)]

Perhaps the other possibility would be to make the dl manager's "launch" code use the mime type system?

Comment 3

[Shawn Wilsher :sdwilsh]

This is my attempt to clarify this bug into something that I can actually work with. :)

As I see it now, we have three dialogs for content-handling:
1) Downloads
2) Open (which is just a file picker, and we then do something with the content)
3) Save (which is again just a file picker)

The idea behind this bug (as I see it) is to make all these behave in the same manner with a given content type.  Right now, a download will check nsIExternalProtocolService to see what it should do (http://mxr.mozilla.org/seamonkey/source/toolkit/mozapps/downloads/content/downloads.js#881).  Open calls openUILink which ends up just opening a file uri (http://mxr.mozilla.org/seamonkey/source/browser/base/content/utilityOverlay.js#116).  Save and Save As... call internalSave (http://mxr.mozilla.org/seamonkey/source/toolkit/content/contentAreaUtils.js#199) which eventually uses nsIWebBrowserPersist to save the content.

I think that fixing Bug 142102 will help out our Save/Save As... support, but I haven't looked into nsIWebBrowserPersist much yet because I'm a bit confused by it still.

As for open, if we don't handle it natively we try to download it.  That doesn't seem right at all, and I'm not sure how we want to go about fixing that.

I think that the download manager checking nsIExternalProtocolService is the right thing to do.  So, if we want to change that behavior, which checks for user prefs as to what they want it to open in (as opposed to OS prefs), it will fix the download manager's behavior.

Perhaps we should have open do the same thing as the download manager, but then there could be an issue if firefox isn't the default browser on the system (a user might open an HTML page, and they'd expect it to open in firefox but the OS would send it elsewhere).

So, I'm not really sure where mconnor/dmose wants me to go from here, so I'm going to wait for some guidance.

Comment 4

[Dan Mosedale (:dmosedale, :dmose)]

Discussion and mockups have happened in m.d.a.firefox in the Content-Handling thread.  They're not yet final, but give a sense of where we may want to go.  One post of note that will be handy come implementation time is a suggested extensibility API: <http://groups.google.com/group/mozilla.dev.apps.firefox/msg/99762afeb38859d0>.

Comment 5

[Mike Beltzner [:beltzner, not reading bugmail]]

Let's get rolling on some implementation of what's come out of the discussions. Our goal should be to implement the content handling dialogs like those mocked up at  http://wiki.mozilla.org/ContentHandling:User_Interface/Proposed_UI2, but with the following changes ...

- for files, "Save file to disk" should always be the first option

- default OS application should be first in list

- any applications that the user has selected as handlers should come next, in MRU order

- for files, we should display metadata like:

~~~  File name here with.extension
~~~  100 {KB|MB} TYPE file
     from domain.com

- nothing is preselected, such that the first click selects the action, the second clicks OK; this should prevent punch-the-monkey attacks

- "Always do this for {content type}" label is unchecked; checking it bypasses the dialog

- no need for a "Download application" entry when we only allow the user to Save the file to disk, we can just ditch that, I think

- skip the yellow-box-around-the-OK-button for now, I'm not sure it's going to be an effective strategy for warning users, and worry that it just adds clutter.

Alex and I chatted on IRC about how we think the "Select another application" element should appear:

18:49 <faaborg> how about "choose another application" in text, and a button [Select] below that
18:49 <faaborg> or to the right of the text
18:49 <beltzner> yeah, that sounds good
18:50 <faaborg> and give it the generic application icon for each platform?
18:50 *** beltzner nods
18:50 <faaborg> ok, after selecting the app should we insert it in the list?
18:50 <faaborg> or actually open
18:51 <beltzner> insert and select, focus on the OK button

So it would appear as:

  .-------------------------------.
  | ** Save file to disk           |
  | **                            |
  | ----------------------------- |
  | ** Default application        |
  | **                            |
  |                               |
  | ** MRU application            |
  | **                            |
  |                               |
  | ** Choose another application |
  |                 ( Select ...) |
  '-------------------------------'

Comment 6

[Jesse Ruderman]

> nothing is preselected, such that the first click selects the action, the
> second clicks OK; this should prevent punch-the-monkey attacks

That sounds lame: it sacrifices a whole bunch of usability (you can no longer just click once for a common action) and it doesn't really prevent clever bug 162020-style attacks.

Comment 7

[Dan Mosedale (:dmosedale, :dmose)]

> default OS application should be first in list
>
> any applications that the user has selected as handlers should come next, 
> in MRU order

I assume the set of MRU applications will include whatever defaults that we ship, (e.g. for mailto: handlers, popular webmail providers for a given locale).  Correct?

In the diagram, "MRU application" should be "MRU applications", right?  If so, do we have a maximum number of apps we want to show?

I can see why it would make sense to seed the OS default application at the top of the list the first time the user sees the feature.  However, in subsequent invocations, shouldn't it just be part of the MRU list?

Comment 8

[Mike Beltzner [:beltzner, not reading bugmail]]

(In reply to comment #6)
> That sounds lame: it sacrifices a whole bunch of usability (you can no longer
> just click once for a common action) and it doesn't really prevent clever bug
> 162020-style attacks.

I don't know how the "this button is disabled, no, hey, wait a second, it is enabled!" is any more usable, per se, but am willing to be shown the error of my ways.

I take it the attack you mean is one where someone gets the user to press the accesskey? School me with words and facts, Jesse, not simply scorn and derision! :)

(In reply to comment #7)
> I assume the set of MRU applications will include whatever defaults that we
> ship, (e.g. for mailto: handlers, popular webmail providers for a given
> locale).  Correct?

Correct. I was thinking, though, that we'd have Save to disk, a separator, local application handlers (if applicable), "Select Application ...", a seperator, then web-based handlers. This was to divide local vs. web and also to make it clear that "Select Application ..." was only for local applications.

But maybe that's wrong. Is it hard to start this way and then change it later if it feels strange?

> In the diagram, "MRU application" should be "MRU applications", right?  If so,
> do we have a maximum number of apps we want to show?

Let's say ... 5? And then things fall off the MRU list?

> I can see why it would make sense to seed the OS default application at the 
> top of the list the first time the user sees the feature.  However, in 
> subsequent invocations, shouldn't it just be part of the MRU list?

Good point. Yes.

Comment 9

[Jesse Ruderman]

Not selecting an action only protects users from bug 162020-style attacks if the most I can convince users to do is click once (on the Save/Open/OK button) within their reaction time.  But I can probably also convince a user to double-click (on the action), or click (on the action) and quickly press enter, etc.

If the visual "disabled" look is confusing, maybe it should be disabled invisibly instead of visibly.  Also, maybe the button doesn't need to be disabled at all if the selected action is "Save" or "Display in Firefox" or "Display using a plugin".

I'd love to get rid of the delay (see bug 363142) but I can't think of a better solution for content-handling.

Comment 10

[Dan Mosedale (:dmosedale, :dmose)]

In discussion with beltzner on IRC yesterday, we clarified that he's interested in  being able to experiment with different sorts and behavior of the list.  In particular, his initial suggestion is that local application handlers should be one MRU list, and web-based handlers another.  One could also imagine a single MRU list of all apps.  So it probably makes sense to expose the "most recently used" date to the dialog and allow for various collation routines to live there.

Comment 11

[Dan Mosedale (:dmosedale, :dmose)]

<http://groups.google.com/group/mozilla.dev.platforms.linux/browse_thread/thread/50696750ce3fb045/d03ada05265e9034#d03ada05265e9034> contains a thread about how various platform requirements for the unknown content-type handler dialog.  When we get to the point of actually coalescing the new dialog into usability for the unknown content-type handler case (almost certainly post Firefox3), we should go through and audit against the points made in this thread.

Comment 12

[Mike Connor [:mconnor]]

Missing the freeze, moving out.

Comment 13

[Dan Mosedale (:dmosedale, :dmose)]

At this point, this bug is a tracking bug.  The concrete piece that needs to be targetted and block Firefox 3 is happening in other bugs.  Removing the target milestone and blocking flags stuff here.

Comment 14

[Dan Mosedale (:dmosedale, :dmose)]

mconnor and I just spent some time talking this over.  Though the new content-handling dialog is going to wait until we get to the web-based content handling work itself, we do have several good wins in this area:

a) Easy-to-use MIME-type configuration system (bug 377784)

b) cleaner protocol handler dialog (bug 385065)

Written, but not yet landed:

c) windows application picker (bug 348808)

This makes it seem reasonable to say that once 348808 lands, we will have simplified the content-handling UI significantly enough to declare victory here.  Making the dependency tree reflect this.

Comment 15

[cmtalbert]

(In reply to comment #14)
> This makes it seem reasonable to say that once 348808 lands, we will have
> simplified the content-handling UI significantly enough to declare victory
> here.  Making the dependency tree reflect this.
> 
I'm not so sure it will be that easy. Marcia brought this to my attention last week (I think I was a little too close to the UI to realize this):

With the current FFx 3 we now have:
1. A specialized protocol handling dialog
2. The standard "Save As" dialog for content items (like zip files)
3. The feed picker "yellow bar" for the specific feed protocol handling.
4. An applications preference pane that controls all three of the above items.

Given the fact that most users are hard-pressed to define the difference between feed and content, it seems to me that they may not understand the reason or need for a different dialog in case 1 and 2 (at least, not in the way that it is currently presented).  

Perhaps we can either: 
A) Modify the protocol handling dialog somehow to illustrate that there is no "file" to be saved, that this is going to transfer data to the application you choose. 
B) Make the "save/open file" content handling dialog look more like the protocol handling dialog (as described above).

And then there is the entirely separate handling of feed URLs which breaks both of these visual paradigms. I think the feed URL might be OK since this is the same UI from FFx 2, and people might be accustomed to it.  But, it does beg the question of why we are differentiating that protocol from all the others.

The other naive user question would be, if you can configure all these things via one preference pane dialog, why does it take on three different representations in the browser when you're interacting with that information?

The proper response would be "because by having three different representations, we add value/understanding to the user's experience".  

I'm not really sure that we add value/understanding given the UI in the current nightlies. I think this must be improved before closing this bug, and before shipping FFx 3.

Comment 16

[Dan Mosedale (:dmosedale, :dmose)]

With a few exceptions, I'm mostly focused on MailCo-related hacking now.  Reassigning a bunch of bugs to default component owners.  I'm happy to help with brainstorming/advice as needed, however.  

Search for the string MAILMONKEY to delete any bugmail generated by this change.

Comment 17

[Alex Limi (:limi) — Firefox UX Team]

I have no idea what this is, this is from way before my time at Mozilla. If anyone wants to educate me and still need UX input, CC me on the bug with an explanation. Removing uiwanted for now.