Content Handling UI
Alex Faaborg
Firefox 3. We need to get this decided reasonably soon since it's
currently blocking dmose. cc'ing johnath for his comments on the
security aspects of these dialogs.
==Background==
Inventory of content handling UI in Firefox 2: http://
wiki.mozilla.org/ContentHandling:User_Interface/Firefox_2
Analysis of content handling UI in Firefox 2, showing how each dialog
essentially has three core elements: http://wiki.mozilla.org/
ContentHandling:User_Interface/Firefox_2_Analysis
Content handling UI in IE7, Opera 9 and Safari 2: http://
wiki.mozilla.org/ContentHandling:User_Interface/Other_Browsers
==Proposed UI==
Consistent user experience for handling RSS, microformats, external
protocols, file downloads, and application downloads: http://
wiki.mozilla.org/ContentHandling:User_Interface/Proposed_UI
Right now these are shown as modal dialogs. Ideally I would like to
make them tab-modal, but I think we should consider that a separate
issue from the design of the dialogs themselves.
Cheers,
-Alex
Gervase Markham
> Consistent user experience for handling RSS, microformats, external
> protocols, file downloads, and application downloads:
Yeeha!
I like your breakdown into "information about the content", "choose a
route for the content", and "execute decision" - although perhaps
actually the last two are quite closely related.
> http://wiki.mozilla.org/ContentHandling:User_Interface/Proposed_UI
Thoughts:
- Let's use verbs on the buttons
- Remember my choice needs to be scoped; "Always take this action for
this type of content" or similar
- "Choose Application..." -> "Another Application..." if there is one or
more already in the list
- We should display only information that's really relevant to making
the decision. For example, when will the file size affect your decision
about what to do with the content?
- The last one is a bit confusing, visually and textually. When there's
only one entry in the list of things to do, it looks rather like a big
button. And it says "Would you like to save this file?" "Download
Application", which is a bit odd.
- Sidenote: we need to do much better with date display. I'd like
something like (getting further away each time):
Tomorrow (Saturday 12th), 7pm - 9pm
Next Friday (Monday 18th), 8.30am - 12.30pm
Monday 30th, ...
Tuesday 16th July, ...
Friday 26th October 2009, ...
Gerv
Colin Barrett
> Consistent user experience for handling RSS, microformats, external
> protocols, file downloads, and application downloads:
> http://wiki.mozilla.org/ContentHandling:User_Interface/Proposed_UI
Over all, I like it. But I think we could save a bunch of visual space
and make it a bit more familiar of a UI if we used a menu instead of a
list for selecting the choice.
I like the proposal though, I think unifying these types of dialogs is good.
I also like, in principle, the yellow box around the OK button. I'm not
sure about the last one though, where the error comes up above the OK
button, but that's a minor thing.
-Colin
Dan Mills
> Over all, I like it. But I think we could save a bunch of visual space
> and make it a bit more familiar of a UI if we used a menu instead of a
> list for selecting the choice.
By menu, do you mean a drop-down? The Windows dialogs for choosing what
applications to use for each file type look more like the proposal than
a drop-down, so they would be familiar to most users imo. But maybe I
misunderstood which widget you are talking about.
Dan
Colin Barrett
> By menu, do you mean a drop-down? The Windows dialogs for choosing what
> applications to use for each file type look more like the proposal than
> a drop-down, so they would be familiar to most users imo. But maybe I
> misunderstood which widget you are talking about.
Yeah. I talked about it with Alex, and it turns out that what I really
was objecting to was the list being a heterogeneous collection of items
-- I thought of using a drop-dop at first because drop-down menus
can have dividers to group things into homogeneous sets.
A divider in the box would probably work too. Mostly
interested/concerened about this will end up looking like on the Mac,
although I understand why the mockups are done for Vista.
-Colin
Clint Talbert
> Hey folks, let's use this thread to discuss content handling UI in
> Firefox 3. We need to get this decided reasonably soon since it's
> currently blocking dmose. cc'ing johnath for his comments on the
> security aspects of these dialogs.
>
> ==Background==
>
> ==Proposed UI==
* On the Open file dialog, you have a note about how the user can
reverse the "remember this" decision. This might be a good idea, but it
would need to be on each dialog. However, I do wonder how many users
would read that, and of those, would enough remember that in order to
justify taking up the space?
* On the calendar specific dialogs, we definitely want to do better with
date handling. I liked Gerv's suggestions there.
* I have a "flow of control" question. If you double click one of the
middle choices (say Google Calendar, for example), would that shortcut
to the OK functionality? I think it would be tedious if advanced users
had to click the middle choice then click ok.
* I find the "application" dialog really awkward.
** In all the other dialogs the user has a meaningful choice to be made
in the center of the dialog. Here, the user does not. I think that is
the primary source of the awkwardness.
** I'd like to see a difference between an unrecognized/unsigned
application and a recognized/signed application too. I don't think that
the yellow box is sufficient enough warning in the unrecognized/unsigned
case, especially since the user would be accustomed to seeing yellow
boxes around the OK button on other, less dangerous dialogs (such as
your calendar one here).
This question might be out of scope in this thread, but I feel it is
important for us to also consider. There is obviously going to be an
options page for the user to change the "remembered" choices here. It
would be good to see a prototype design for this page as well.
Overall, very nice work.
Clint
Alex Faaborg
> - Let's use verbs on the buttons
Yeah, I'm going to customize the OK button based on the type of
content handling action in the next iteration (Subscribe, Save File,
Send, etc.)
> - Remember my choice needs to be scoped; "Always take this action for
> this type of content" or similar
Yeah, I'll scope based on content type in the next iteration
"Remember my choice for TIF files."
> - "Choose Application..." -> "Another Application..." if there is
> one or
> more already in the list
How about "Select another application..."?
> We should display only information that's really relevant to making
> the decision. For example, when will the file size affect your
> decision
> about what to do with the content?
Certainly: if it the file is 2 Terabytes, you will probably choose
not to download it.
> The last one is a bit confusing, visually and textually.
Yeah the unified UI totally falls apart when n=1, I'm going to
redesign that dialog.
> we need to do much better with date display.
Agreed, thanks for all the feedback!
-Alex
> _______________________________________________
> dev-apps-firefox mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-firefox
Alex Faaborg
questions over what Safari is doing (since it has "no dialog" listed
for all categories except an application download). I put up this
page to explain their approach:
http://wiki.mozilla.org/ContentHandling:User_Interface/SafariFlow
-Alex
On May 22, 2007, at 2:28 AM, Alex Faaborg wrote:
> Hey folks, let's use this thread to discuss content handling UI in
> Firefox 3. We need to get this decided reasonably soon since it's
> currently blocking dmose. cc'ing johnath for his comments on the
> security aspects of these dialogs.
>
> ==Background==
>
> Inventory of content handling UI in Firefox 2: http://
> wiki.mozilla.org/ContentHandling:User_Interface/Firefox_2
>
> Analysis of content handling UI in Firefox 2, showing how each dialog
> essentially has three core elements: http://wiki.mozilla.org/
> ContentHandling:User_Interface/Firefox_2_Analysis
>
> Content handling UI in IE7, Opera 9 and Safari 2: http://
> wiki.mozilla.org/ContentHandling:User_Interface/Other_Browsers
>
> ==Proposed UI==
>
> Consistent user experience for handling RSS, microformats, external
> protocols, file downloads, and application downloads: http://
> wiki.mozilla.org/ContentHandling:User_Interface/Proposed_UI
>
> Right now these are shown as modal dialogs. Ideally I would like to
> make them tab-modal, but I think we should consider that a separate
> issue from the design of the dialogs themselves.
>
> Cheers,
> -Alex
Alex Faaborg
> would need to be on each dialog.
In the current design it only appears after checking the checkbox.
> If you double click one of the
> middle choices (say Google Calendar, for example), would that shortcut
> to the OK functionality?
That sounds like a good accelerator for advanced users, but some
novice users double click in all situations, so they will find the
behavior surprising. The microformat content handling UI will also
be available in context menus, so using that or selecting default
behaviors (remember my choice) is probably a better way for advanced
users to avoid the dialog. Beltzner: what do you think?
-Alex
Clint Talbert
> ** I'd like to see a difference between an unrecognized/unsigned
> application and a recognized/signed application too. I don't think that
> the yellow box is sufficient enough warning in the unrecognized/unsigned
> case, especially since the user would be accustomed to seeing yellow
> boxes around the OK button on other, less dangerous dialogs (such as
> your calendar one here).
>
file/application. Seeing that we currently have two dialogs for a
recognized file and an unrecognized file, I was wondering how the
unrecognized file dialog would look in the new design.
I don't think that Firefox should necessarily "go Vista" with alerting
the user to every signed/unsigned state of an application, but that
might be a point worth considering too.
Sorry for any confusion.
Clint
Gervase Markham
> That sounds like a good accelerator for advanced users, but some novice
> users double click in all situations, so they will find the behavior
> surprising. The microformat content handling UI will also be available
> in context menus, so using that or selecting default behaviors (remember
> my choice) is probably a better way for advanced users to avoid the
> dialog. Beltzner: what do you think?
I've never set much store by that argument. Either a platform (OS)
distinguishes between single and double click and sometimes/always does
different things for each, or it doesn't, and treats the two the same
always. If the former, we do the user no favours by trying to pretend
they are the same for our application only. It'll just lead to confusion
long term.
Gerv
Gervase Markham
> http://wiki.mozilla.org/ContentHandling:User_Interface/SafariFlow
Their version effectively makes every installed application part of the
web-facing security interface.
Of course, one could argue that this is true of Firefox anyway, because
users are hardly going to back out at the intermediate stage we insert.
Gerv
Dan Mosedale
>
>> - "Choose Application..." -> "Another Application..." if there is one or
>> more already in the list
>
> How about "Select another application..."?
Maybe "Choose another application"? It's shorter, and "Select" seems
overly formal to me.
Dan
Dan Mosedale
> http://wiki.mozilla.org/ContentHandling:User_Interface/Proposed_UI
>
> Right now these are shown as modal dialogs. Ideally I would like to
> make them tab-modal, but I think we should consider that a separate
> issue from the design of the dialogs themselves.
The "Web Feeds" proposal doesn't look particularly dialog-like to me.
Is it intended to be part of the preview page as it is now?
Dan
Alex Faaborg
integrated into the preview page in the case of feed handling.
-Alex
Alex Faaborg
from this thread:
http://wiki.mozilla.org/ContentHandling:User_Interface/Proposed_UI2
==Changes==
*Added an example of handling RSS feeds differently based on content
inspection (text, images, video).
*Improved date handling for the hCalendar dialog
*Added an example of an unknown protocol request
*Added a horizontal bar in between actions like Download and Display
in Firefox, and applications.
*Cleaned up the download application dialog
==Open Questions==
===Web Feed content inspection===
* Do we want to have custom icons for image feeds and video feeds?
* Are there any other types of content we should be looking for in
feeds that we can hand off to particular applications? Microformats?
*Should we follow Apple's lead and use the terminology: Podcast,
Video Podcast, Photocast?
*cbarrett isn't sure if you can subscribe to any RSS feed of images
as a Photocast he's checking into it though.
===Launching Applications===
*Should we say "this Web site would like to send information to an
application" or "this Web site would like to launch an application?"
-Alex
On May 23, 2007, at 1:44 PM, Alex Faaborg wrote:
> Yeah, in the current design the unified UI for content handling is
> integrated into the preview page in the case of feed handling.
> -Alex
>
> On May 23, 2007, at 12:05 PM, Dan Mosedale wrote:
>
Colin Barrett
> New version of the unified content handling UI, based on feedback from
> this thread:
>
> http://wiki.mozilla.org/ContentHandling:User_Interface/Proposed_UI2
>
> ==Changes==
> *Added an example of handling RSS feeds differently based on content
> inspection (text, images, video).
> *Improved date handling for the hCalendar dialog
> *Added an example of an unknown protocol request
> *Added a horizontal bar in between actions like Download and Display in
> Firefox, and applications.
> *Cleaned up the download application dialog
>
> ==Open Questions==
> ===Web Feed content inspection===
> * Do we want to have custom icons for image feeds and video feeds?
> * Are there any other types of content we should be looking for in feeds
> that we can hand off to particular applications? Microformats?
> *Should we follow Apple's lead and use the terminology: Podcast, Video
> Podcast, Photocast?
> *cbarrett isn't sure if you can subscribe to any RSS feed of images as a
> Photocast he's checking into it though.
Yeah, it looks like iPhoto only subscribes to special iPhoto photocasts
that you can only create on .Mac. Pretty limiting. Who knows about 10.5
though, they may add that sort of support, they may not.
> ===Launching Applications===
> *Should we say "this Web site would like to send information to an
> application" or "this Web site would like to launch an application?"
One thing that is extremely hard to find is exactly what kind of
protocol it is. It's only stated in the "remember my choice" label. This
could be confusing to 1) basic users "remember my choice for what? what
are they talking about?" 2) advanced users, who want to know what type
of URL it is and would handle it differently (e.g. they for some reason
want Yahoo! messenger to open for ymsgr: links but aim: and xmpp: URLs
should go to Adium).
Would it be possible at some point when these mockups are more finalized
to get a look at what they will look like on Mac OS X and Linux? Or will
that only really happen when the UIs are prototyped. I totally get why
we need to design for Vista/XP, but I don't want to end up with a UI
that looks bad on the Mac.
There's a much larger issue of following native interface guideline
rules on various platforms, however I don't want to derail this thread
talking about that. A "yes, we can do that" or "no, we don't plan to
until the UI's been prototyped/implemented" from Alex or Beltzner will
be OK.
-Colin
Alex Faaborg
> rules on various platforms, however I don't want to derail this thread
> talking about that. A "yes, we can do that" or "no, we don't plan to
> until the UI's been prototyped/implemented" from Alex or Beltzner will
> be OK.
[starting new thread]
I'm happy to branch different parts of the design to different
platforms as we go, assuming Beltzner is ok with that. However the
larger issue is deciding exactly where the user interface is going to
differ on each platform.
In general we decide to go with the UI we think is the most usable,
regardless of violating specific platform guidelines. For instance,
the new bookmark dialog has a mac-like expansion arrow to display a
tree view of folders, even on Windows.
The content handling UI shows a list of applications, which is only
reminiscent of other interfaces on Windows. However, if we feel this
is more usable than a combo box, or a combination of radio buttons
and a combo box (in the current UI), that could potentially justify
bringing it to the Mac, even if it violates native platform guidelines.
> I don't want to end up with a UI that looks bad on the Mac.
One of the reasons Mac users don't like Firefox is our rationale of
violating standards or "looking bad" if we think a particular UI is
more usable. Should we reconsider this position for the Mac if it is
alienating users (like what happened with hover buttons in Firefox 2)?
Cc'ing beltzner and mconnor to get their opinions.
-Alex
Alex Faaborg
controversial, and I'm not sure I'm even sold on the idea yet:
http://wiki.mozilla.org/ContentHandling:User_Interface/Tab-Modal_Dialogs
==Pros==
*We no longer use pop-up windows
==Cons==
*The tab-modal sheet obscures the content area, which for some types
of content handling (like microformat detection), could be problematic.
*The close button on the notification bar may be confused with the
close button on the tab due to the similar color.
*This UI is spoofable
-Alex
On May 23, 2007, at 4:26 PM, Colin Barrett wrote:
Nils Maier
time.
At least FlashGot and DownThemAll "fight" the current download dialog,
trying to add their own content handlers.
Had to write a nasty hack to revert the UI to a list type. [1]
Other extensions might as well like to add to feeds, calendars, whatever
actions.
Nils
[1]
http://bugs.code.downthemall.net/trac/browser/trunk/chrome/content/integration
(saveas.*)
--
DownThemAll - http://www.downthemall.net/
Axel Hecht
> New version of the unified content handling UI, based on feedback from
> this thread:
>
> http://wiki.mozilla.org/ContentHandling:User_Interface/Proposed_UI2
>
> ==Changes==
> *Added an example of handling RSS feeds differently based on content
> inspection (text, images, video).
> *Improved date handling for the hCalendar dialog
> *Added an example of an unknown protocol request
> *Added a horizontal bar in between actions like Download and Display in
> Firefox, and applications.
> *Cleaned up the download application dialog
>
> ==Open Questions==
> ===Web Feed content inspection===
> * Do we want to have custom icons for image feeds and video feeds?
> * Are there any other types of content we should be looking for in feeds
> that we can hand off to particular applications? Microformats?
> *Should we follow Apple's lead and use the terminology: Podcast, Video
> Podcast, Photocast?
Podcast seems to be a very iPod-ish name. Not idea how much it is used
outside of Macs.
From an i18n point of view, international users do have problems with
liking stuff that has an English name, the extent of which varies from
culture to culture. And at least on wikipedia, podcast doesn't translate.
Axel
Alex Faaborg
> outside of Macs.
The term is becoming increasingly mainstream in the US. Major news
networks and politicians all offer "podcasts."
> Not idea how much it is used outside of Macs.
Quite a bit due to the iPod/iTunes market share (~70% I think)
extending well into the Windows world. However the Windows Media
Player team has yet to add any RSS functionality.
> international users do have problems with
> liking stuff that has an English name
We should localize to whatever syndicated audio is commonly referred
to in each local.
-Alex
Alex Faaborg
dialog:
Feeds:
http://wiki.mozilla.org/ContentHandling:User_Interface/Preferences_Feeds
Microformats:
http://wiki.mozilla.org/ContentHandling:User_Interface/
Preferences_Microformats
(in progress) MIME Types, Files and Protocols:
http://wiki.mozilla.org/ContentHandling:User_Interface/
Preferences_Content
-Alex
On May 24, 2007, at 12:38 AM, Axel Hecht wrote:
Alex Faaborg
> this
> time.
Make sure you touch base with dmose to make sure he knows what kinds
of hooks extension developers are going to need in order to replace
our content handling UI.
> Other extensions might as well like to add to feeds, calendars,
> whatever
> actions.
Yeah, it is really important that extensions can easily register as
content handlers. Not just to make life easier for extension
developers, but to create a fair and competitive playing field
amongst application providers.
-Alex
Gervase Markham
>> We should display only information that's really relevant to making
>> the decision. For example, when will the file size affect your decision
>> about what to do with the content?
>
> Certainly: if it the file is 2 Terabytes, you will probably choose not
> to download it.
Then let's only display this information if it's relevant - say if the
file size is over 10MB.
(Yes, I know "relevant" will have different values for different people.
I pick 10MB because it's larger than an MP3 of a 4-minute song.)
>> The last one is a bit confusing, visually and textually.
>
> Yeah the unified UI totally falls apart when n=1, I'm going to redesign
> that dialog.
Will n ever be 1? After all, there's always "Choose another application..."
>> we need to do much better with date display.
>
> Agreed, thanks for all the feedback!
Including (viewing your mockups) the ability for localisers to make sure
it's correct for their locale.
Gerv
Gervase Markham
> Here is a mockup of tab-modal dialog boxes. This is likely to be
> controversial, and I'm not sure I'm even sold on the idea yet:
> http://wiki.mozilla.org/ContentHandling:User_Interface/Tab-Modal_Dialogs
Is the drop shadow intentionally on three sides? It doesn't look 3D that
way.
Oh: would you change the verb on the confirm button depending on the
chosen option? That would be cool. (Save/Display/Open)
> *The tab-modal sheet obscures the content area, which for some types of
> content handling (like microformat detection), could be problematic.
I certainly think we don't want to bring one of these up except in
response to user action.
Can we put it most of the way to the right, instead of centred? This
means that, for standard wider-than-high monitors with maximised
windows, it probably wouldn't overlap content. Or would do so less often.
> *The close button on the notification bar may be confused with the close
> button on the tab due to the similar color.
> *This UI is spoofable
Well, not 100%; you couldn't spoof the continuation of colour with the tab.
I don't immediately see any problems that could occur if someone spoofed
it. It's like spoofing an Alert box - why would you want to? Can you
think of any?
Gerv
Gervase Markham
> The term is becoming increasingly mainstream in the US. Major news
> networks and politicians all offer "podcasts."
Same in the UK. Irritating but true.
Gerv
Gervase Markham
> [starting new thread]
In News, just changing the title doesn't do that. You need to create a
new message.
Gerv
Gervase Markham
> http://wiki.mozilla.org/ContentHandling:User_Interface/Proposed_UI2
Definitely better. :-)
- The Web Feeds one should be consistent; if it's a Web Feed, it should
be called that in the intro text.
- Any chance of a (huh?), (what's this?) or equivalent hyperlink next to
new terms like Web Feed, Video Podcast and so on?
- Is "Only click Open if you expected this" permanent?
- For hCalendar, "Open" should be "Send"
- What happened to "Choose another application..."? Can the number of
apps ever be 1 if this option is always present.
- If the protocol is unknown, how do we know the website would like to
send information to Skype?
- Can we do better than "TIF file" for known file types? E.g. "TIFF
image file", "MP3 audio file" and so on. We could even pinch the
left-hand half of the MIME type if we didn't know better. So audio/au
"AU audio file" and so on.
- I'm not sure if "You can change this choice in Options > Content" is
sufficient. It doesn't say where to find "Options", and I don't know if
many users will understand this use of the greater-than sign.
"You can change this choice from the Content tab of your Preferences"?
(hey, I'm on Linux :-)
I know that makes it two lines.
- It says: "only download this application if you trust its source".
What is its source?
Should we be doing:
Name: evil.exe
Type: Executable Application
Source: evil.com
with the Source line highlighted in the same way, or something?
Gerv
Gervase Markham
> Here are some mockups of possible changes to Firefox's preferences dialog:
You are far too prolific :-) Comments tomorrow.
Gerv
Simon Bünzli
> Here are some mockups of possible changes to Firefox's preferences dialog:
Feeds and Pointers seem to get an unproportional amount of UI space in
these mockups. Already Firefox 2.0's feed pane would have been unneeded
(see https://bugzilla.mozilla.org/show_bug.cgi?id=347320#c0 ).
What about merging "Feeds" and "Pointers" and maybe also "Content" ->
File Types into one new "(External) Applications" pane instead?
Alternatively, have you considered extending the Download Actions dialog
(from Content -> File Types) into a more general Content Handling
dialog, including also listings for Feed and Pointer handlers - and then
having that dialog as a "(Non-browser) Content" pane? As long as Feeds
and Pointers appear at the top of that list, this might not make that
big a difference for the user - and she might even discover the settings
for disabling an annoying plugin or something...
Cheers,
Simon
Jesper Kristensen
> New version of the unified content handling UI, based on feedback from
> this thread:
>
> http://wiki.mozilla.org/ContentHandling:User_Interface/Proposed_UI2
>
I don't like to use Apple's trademarks in the Firefox UI (Potcast).
Some time ago one of the largest Danish TV stations was sued because they
used the word "Potcast". It is a state owned TV station, and they are not
allowed to send commercials. The use of Potcast was seen as a commercial for
Apple because some people would believe that they had to use Apple's iTunes
to play the content. The case was dropped when they changed the name to Audio
Feed.
> http://wiki.mozilla.org/ContentHandling:User_Interface/Preferences_Microformats
I don't like the name Pointers, but I cannot come up with a good name either.
Maybe merge build in microformat and addon microformat into one list or at
least order the columns the same way in both lists. I cannot see from your
mockup how an addon microformat with more than one application is handled.
fantasai
> Alex Faaborg wrote:
>>> We should display only information that's really relevant to making
>>> the decision. For example, when will the file size affect your decision
>>> about what to do with the content?
>>
>> Certainly: if it the file is 2 Terabytes, you will probably choose not
>> to download it.
>
> Then let's only display this information if it's relevant - say if the
> file size is over 10MB.
>
> (Yes, I know "relevant" will have different values for different people.
> I pick 10MB because it's larger than an MP3 of a 4-minute song.)
Lots of people are still on slow dial-up connections. If the
issue were whether to pop up a dialog or not, then ok -- but
the dialog is already up, so the cost of showing this information
is minimal. Also leaving it out on some downloads but showing it
on others is confusing.
~fantasai
Deb Richardson
* When I see a multi-item select list (such as in the Web Feed "Subscribe to this feed using:" list) I expect to be able to select multiple items from that list. Would that be possible here? For example, I could see the possible use for adding an hCal to both my iCal and Google Calendars with a single action.
* Is "Only click Open if you expected this" proposed as final text for that particular warning? It could use some finessing, I think.
* What does "Remember my choice" mean? Will the dialog always open and offer the user the chance to make a decision (but default-selecting the previously remembered choice), or does this really mean "Always do this for this type of content"? If the latter, it's not very clear. Also, if it's the latter, the warning around the "Open" button seems somewhat moot.
* I'm not sure why everything is a dialog except the Web Feeds. It seems inconsistent, particularly when there are other feeds being discussed (calendar feeds, etc). Is there no way to render a preview page for a calendar feed so "feeds" would at least be consistent? Alternately, do we really need to preview a Web feed? I understand the whole "foolish consistency is the hobgoblin of little minds" and so forth, but I just want to make sure that this is deliberately inconsistent rather than just inconsistent because web feeds have always had a preview page but all the new stuff doesn't.
* In the "Download Application" dialog, the "[icon] Download Application" thing in the middle looks like a big, clickable button. That, combined with the poorly worded warning around the "OK" button, is very confusing. The "OK" button after "Only download application if you trust its source" seems like the user is saying "OK I understand the warning" rather than "OK, download the application". That whole dialog might need to be revisited -- it just seems very busy and overly confusing with all the round-cornered buttons and boxes and such.
* I'm confused by the proposal for differentiating between Podcasts and Video Podcasts and such. There's no guarantee that today's video podcast isn't going to include an audio podcast or a bunch of images as enclosures tomorrow. Is this intended to be where the user can specify what to do with different types of enclosures included in any subscribed feed?
* If you're talking about dealing with different enclosure types rather than different feed types (which really makes more sense, imho), then I don't think the podcast/video podcast/photocast terminology is appropriate (possible trademark issues aside). It strikes me that different enclosure types are simply different file types, and we might be able to use the simpler "video", "audio", and "image" terminology and file-type handlers for those.
* I am somewhat stumped by the "Pointers" terminology and design. What are pointers? Could you walk through that in a little more detail (or point me at more info if it's available)?
* For Prefs -- are Feeds and Pointers really not just sub-types of content? Maybe there should be a unified Content Handling prefs pane that includes sub-sections or sub-tabs for Feeds, Pointers, and such?
* Has there been thought put into how "Content Handling" and "Download Management" revisions will fit together at this point?
Thanks
~ deb
Michael Vincent van Rantwijk, MultiZilla
> Alex Faaborg skrev:
>> New version of the unified content handling UI, based on feedback from
>> this thread:
>>
>> http://wiki.mozilla.org/ContentHandling:User_Interface/Proposed_UI2
>>
>
> I don't like to use Apple's trademarks in the Firefox UI (Potcast).
Since when did Apple invent podcast? There is prior art in this case of
at least two people, one being Adam Curry and before him another chap,
one I don't know by name from the top of my head.
Dan Mosedale
> Here is a mockup of tab-modal dialog boxes. This is likely to be
> controversial, and I'm not sure I'm even sold on the idea yet:
> http://wiki.mozilla.org/ContentHandling:User_Interface/Tab-Modal_Dialogs
That looks pretty strange. Did you try adding some horizontal lines to
to separate the drop down from the notification bar (and maybe the
notification bar from the tab header)? It currently is a rather oddly
shaped blob...
The mockup might feel more real if it illustrated the more frequent case
where there is actually content in the window, and the notification
appeared because of a link clink. The use case currently illustrated
with no content in the background happens pretty rarely, I think.
Dan
Dan Mosedale
> I would really welcome it if you guys do not "overlook" extensions this
> time.
We definitely would like to play as nicely with extensions as we can;
thanks for chiming in.
> At least FlashGot and DownThemAll "fight" the current download dialog,
> trying to add their own content handlers.
> Had to write a nasty hack to revert the UI to a list type. [1]
I don't have much context with that code; it would help me if you
described in a bit more detail exactly what the high-level problem you
ran into was as well as the low-level details of how you ended up
hacking around it.
> Other extensions might as well like to add to feeds, calendars, whatever
> actions.
If by that you mean that there should be an easy programmatic way to
insert items into the "Where to send it" list in Alex' mockups, that
totally makes sense to me. Is that what you meant?
Dan
Dan Mosedale
> Here are some mockups of possible changes to Firefox's preferences dialog:
>
> Feeds:
> http://wiki.mozilla.org/ContentHandling:User_Interface/Preferences_Feeds
I like it. Am I understanding correctly the semantics of "Save To Disk"
would be that, like Live Bookmarks, we'd go get these on a timer and
just keeping filling up a directory with this content over time?
> Microformats:
> http://wiki.mozilla.org/ContentHandling:User_Interface/Preferences_Microformats
Also looks good. A couple of thoughts:
* Putting pointers as a top-level icon in the options box gives it a
total of 8 icons, which seems a bit cluttered to me. I wonder if it
shouldn't just be accessible from the Content pane. On the other hand,
it does play up a new feature that might be big.
* What's the benefit to using generic icons before the handlers are set
and then changing them to something else after they get set? Given that
the new icons are still different from the icons of the apps that will
be doing the handling, this seems pretty confusing.
> (in progress) MIME Types, Files and Protocols:
> http://wiki.mozilla.org/ContentHandling:User_Interface/Preferences_Content
Looks good so far.
Dan
Jesper Kristensen
> Here are some mockups of possible changes to Firefox's preferences dialog:
>
> Feeds:
> http://wiki.mozilla.org/ContentHandling:User_Interface/Preferences_Feeds
>
> Microformats:
> http://wiki.mozilla.org/ContentHandling:User_Interface/Preferences_Microformats
>
>
> (in progress) MIME Types, Files and Protocols:
> http://wiki.mozilla.org/ContentHandling:User_Interface/Preferences_Content
>
> -Alex
I don't think you should be the only one posting pictures, Alex :)
http://temp.jesperkristensen.dk/mozilla/content_handling/prefs_proposal.html
Dan Mosedale
> I don't think you should be the only one posting pictures, Alex :)
>
> http://temp.jesperkristensen.dk/mozilla/content_handling/prefs_proposal.html
>
There's definitely something nice about how much less UI there is when
all these get consolidated.
The fact that such a list would likely be very long seems like a
possible problem, though. Adding a search box that filters for items
seems like it could mitigate that problem to some degree.
Dan
Jason Douglas
>
> http://wiki.mozilla.org/ContentHandling:User_Interface/Proposed_UI2
>
> ==Changes==
> *Added an example of handling RSS feeds differently based on content
> inspection (text, images, video).
>From my experience managing a large feed aggregation infrastructure
(millions), this will be incredibly difficult to implement... if not
impossible. The problem is there is no strict test of whether a feed
is just text, or a podcast or a video podcast. Apple gets away with
it because they place additional requirements on the feed provider to
get listed in iTMS (or on the application itself in the case of
"photocasting").
However, feeds in the wild can (and do!!) contain an ever-changing
variety of media. Some feeds are mostly text but have an occasional
audio or video attachment, some always have readable text *and* audio,
some have strictly media objects. Any given snapshot of the feed is
not going to give you an indication of that, though.
I think the options are to either:
1. List all possible apps as feed handlers (so include iTunes,
Democracy, whatever) and let the app deal with whether it has the
right stuff
2. Treat media attachments to feeds more like microformats in a web
page, which have a similarly unpredictable and instance-specific
likelihood of being present and acted upon
Alex Faaborg
I don't want to rat-hole on this too much, but I looked into this a
bit, and here is what I found:
There have been 27 trademark attempts for podcast, and the only one
approved is for "Podcast Ready." Last September Apple sent them a
cease and desist letter, which many people believe they did in an
attempt to increase their chances of getting the trademark
"iPodcast," which has been denied several times. In November Apple
backed off, sending letters from their trademark office saying that
they no longer object to third party use of the word "Podcast."
http://en.wikipedia.org/wiki/Podcast
http://www.engadget.com/2006/09/24/with-pod-on-lockdown-apple-goes-
after-podcast/
http://blogs.zdnet.com/ip-telephony/?p=1252
http://www.flickr.com/photo_zoom.gne?id=309396084&size=l
-Alex
On May 24, 2007, at 9:57 AM, Michael Vincent van Rantwijk, MultiZilla
wrote:
Alex Faaborg
> - Is "Only click Open if you expected this" permanent?
Everything in the mockups is up for debate. It's certainly argueable
if these types of messages actually change user behavior and to what
extent they are simply the browser vender transferring blame for
malicious content.
> - For hCalendar, "Open" should be "Send"
If make that change for microformats, we should do it for protocols
as well.
> - What happened to "Choose another application..."? Can the number of
> apps ever be 1 if this option is always present.
In some cases you have to scroll down to see it, on the unknown
protocol mockup I forgot to add it.
> - If the protocol is unknown, how do we know the website would like to
> send information to Skype?
My understanding is that in this example Skype registered for the
protocol, but it is "unkown" in the sense that we don't have custom
text and an icon for it. We could make the registration process more
heavy weight to include these additional types of metadata, or we
could create a generic dialog like the one shown to handle these cases.
> "You can change this choice from the Content tab of your Preferences"?
Yeah, that sounds good.
> Should we be doing:
>
> Name: evil.exe
> Type: Executable Application
> Source: evil.com
Since this information is for the most part self describing, I think
we should reduce complexity and remove the labels.
> - It says: "only download this application if you trust its source".
> What is its source?
Overall I'm not really happy with these warnings. It seems like the
only purpose they serve is to place blame on the user for downloading
and running an exe from evil.com. In the case of IE7's dialogs, they
are basically fine print below the choices. However, attempts to
make these warnings shorter and visually tie them to the action of
clicking Yes don't seem to be working too well.
-Alex
On May 24, 2007, at 2:45 AM, Gervase Markham wrote:
Definitely better. :-)
Should we be doing:
Gerv
_______________________________________________
Dan Mosedale
> * I'm not sure why everything is a dialog except the Web Feeds. It
> seems inconsistent, particularly when there are other feeds being
> discussed (calendar feeds, etc). Is there no way to render a preview
> page for a calendar feed so "feeds" would at least be consistent?
Sounds doable, though possibly time-consuming (or maybe not, if we find
the appropriately licensed code).
One terminology oddity that may (or may not) be worth keeping in mind is
that many sites offer updating calendars as ICS files, there are also
sites in the wild that offer them as snippets of HTML inside RSS (see
<http://www.dnalounge.com/xml/> for examples of both). Depending on
which you select, you'll get different UI. I don't have a good feel for
how common the HTML-in-RSS approach is.
> Alternately, do we really need to preview a Web feed? I understand
> the whole "foolish consistency is the hobgoblin of little minds" and
> so forth, but I just want to make sure that this is deliberately
> inconsistent rather than just inconsistent because web feeds have
> always had a preview page but all the new stuff doesn't.
Web feeds differ widely in how closely they match with the page that
they are advertised as an alternate representation of. Some have just
little headlines of the items on the page; others have complete html.
As result, some RSS is sufficient to notice when a change has
happened, but can't be used to read the entire content of the feed in a
reader (you have to click through to the home site on every item). My
understanding is that the preview page allows users to decide if a
particular feed is good enough. Perhaps someone who was more involved
in the original design can supply more detail here.
> * In the "Download Application" dialog, the "[icon] Download
> Application" thing in the middle looks like a big, clickable button.
> That, combined with the poorly worded warning around the "OK" button,
> is very confusing. The "OK" button after "Only download application
> if you trust its source" seems like the user is saying "OK I
> understand the warning" rather than "OK, download the application".
> That whole dialog might need to be revisited -- it just seems very
> busy and overly confusing with all the round-cornered buttons and
> boxes and such.
Seconded.
> * I'm confused by the proposal for differentiating between Podcasts
> and Video Podcasts and such. There's no guarantee that today's video
> podcast isn't going to include an audio podcast or a bunch of images
> as enclosures tomorrow. Is this intended to be where the user can
> specify what to do with different types of enclosures included in any
> subscribed feed?
Yes, this is a reference to enclosure types. Many feeds in the wild are
intended for subscriptions by a specific type of app (e.g. iTunes for
audio, Democracy Player (maybe iTunes too?) for video, etc.). Current
theory is that we should be able to look at all the items in a feed at
the time of subscription, and, if they're all of the same type, assume
that that will continue and dispatch appropriately. Not perfect, but
perhaps good enough. More data on the distribution of multi-media feeds
in the wild would be very helpful here, I suspect.
> * If you're talking about dealing with different enclosure types
> rather than different feed types (which really makes more sense,
> imho), then I don't think the podcast/video podcast/photocast
> terminology is appropriate (possible trademark issues aside). It
> strikes me that different enclosure types are simply different file
> types, and we might be able to use the simpler "video", "audio", and
> "image" terminology and file-type handlers for those.
That's a good point; those terms will certainly be clearer for novice users.
> * Has there been thought put into how "Content Handling" and
> "Download Management" revisions will fit together at this point?
Not as far as I'm aware. At this point, the content handling stuff is
getting most of our attention. We'll need to circle back around to the
download stuff later, I think, as that's lower priority on the PRD.
Dan
Dan Mosedale
>
>> - If the protocol is unknown, how do we know the website would like to
>> send information to Skype?
>
> My understanding is that in this example Skype registered for the
> protocol, but it is "unkown" in the sense that we don't have custom text
> and an icon for it. We could make the registration process more heavy
> weight to include these additional types of metadata, or we could create
> a generic dialog like the one shown to handle these cases.
Actually, the registration process does give us custom text. We could
conceivably use either the site's favicon or notice any relevant <link
rel="shortcut-icon"> in the registration page. Section 4.10 of
<http://ww.whatwg.org/pecs/web-apps/current-work/#custom-handlers> has
more details.
Dan
Alex Faaborg
> "Subscribe to this feed using:" list) I expect to be able to select
> multiple items from that list. Would that be possible here?
The two interfaces this most consistent with are associating
applications with file types in Windows, and the Autoplay UI. Both
of those do not allow multiple selection. Also I think this type of
behavior is really a boundary case and leads to an unnecessary level
of complexity.
> * Is "Only click Open if you expected this" proposed as final text
> for that particular warning? It could use some finessing, I think.
Absolutely nothing is final :) ideally we will be able to get through
quite a few iterations of these mockups before anything is implemented.
> * What does "Remember my choice" mean? Will the dialog always open
> and offer the user the chance to make a decision (but default-
> selecting the previously remembered choice), or does this really
> mean "Always do this for this type of content"? If the latter,
> it's not very clear.
Perhaps we should reword to: "Automatically open [content type] with
[application name]."
> if it's the latter, the warning around the "Open" button seems
> somewhat moot.
Yeah, and it is hard to explain the tradeoff between security and a
streamlined UI without writing a small paragraph.
> * I'm not sure why everything is a dialog except the Web Feeds. It
> seems inconsistent, particularly when there are other feeds being
> discussed (calendar feeds, etc). Is there no way to render a
> preview page for a calendar feed so "feeds" would at least be
> consistent? Alternately, do we really need to preview a Web feed?
> I understand the whole "foolish consistency is the hobgoblin of
> little minds" and so forth, but I just want to make sure that this
> is deliberately inconsistent rather than just inconsistent because
> web feeds have always had a preview page but all the new stuff
> doesn't.
In many cases the feed content is different from the content on the
page, so I think the overall purpose of the preview has less to do
with choosing a particular app, and more to do with deciding if you
want to subscribe at all. Showing a preview page for webcal is an
interesting idea, although it will be extra work. One of the main
reasons feeds have a preview while the other content types don't is
that (for most content types) we can't actually render a preview in
any meaningful way.
> * In the "Download Application" dialog, the "[icon] Download
> Application" thing in the middle looks like a big, clickable
> button. That, combined with the poorly worded warning around the
> "OK" button, is very confusing. The "OK" button after "Only
> download application if you trust its source" seems like the user
> is saying "OK I understand the warning" rather than "OK, download
> the application". That whole dialog might need to be revisited --
> it just seems very busy and overly confusing with all the round-
> cornered buttons and boxes and such.
I'll drop the outline so it doesn't have any button-like visual
affordance (good call), and all "Ok" buttons should have been
changed to the respective verb, in this case it should have been
changed to "Download." This should clear up the confusion over what
action the button maps to.
We are obligated to provide some type of "do you really want to run
executable code from evil.com" warning, I'm waiting for some of our
security folks (or anyone really) to chime in with a better UI to get
the warning actually read and mentally processed by our users.
> * I'm confused by the proposal for differentiating between Podcasts
> and Video Podcasts and such. There's no guarantee that today's
> video podcast isn't going to include an audio podcast or a bunch of
> images as enclosures tomorrow. Is this intended to be where the
> user can specify what to do with different types of enclosures
> included in any subscribed feed?
No, like all of the other dialogs, this is a decision of what
application you want to send the entire feed to. These feeds really
should declare what types of content they contain, but since that
isn't standardized yet, we are going to try to figure it out based on
content inspection. We reorder the list of applications, but we
don't remove any, so you can still use a normal feed reader if you
think a feed is going to have mixed types of content. Without a
better way of knowing what to do with a particular feed, we really
have to leave it up to the user to choose the appropriate application.
Perhaps we should scale back our wording, saying "This feed appears
to be a video podcast," in cases where we can't be sure.
> * I am somewhat stumped by the "Pointers" terminology and design.
> What are pointers? Could you walk through that in a little more
> detail (or point me at more info if it's available)?
I haven't had a chance to do a full set of microformats mockups, but
the the overall idea is that your mouse pointer will change when
hovering over microformatted content. A right click will produce the
usual context menu with additional options to send the content to the
associated application, and a left click will produce the unified
content handling dialog being discussed in this thread (if no default
application has been set yet).
> * For Prefs -- are Feeds and Pointers really not just sub-types of
> content? Maybe there should be a unified Content Handling prefs
> pane that includes sub-sections or sub-tabs for Feeds, Pointers,
> and such?
Yeah, after looking at Jesper's mockup, I like the idea of a unified
content handling tab.
> * Has there been thought put into how "Content Handling" and
> "Download Management" revisions will fit together at this point?
None yet.
Thanks for the feedback,
-Alex
On May 24, 2007, at 9:40 AM, Deb Richardson wrote:
> I just have some quick notes and questions:
>
> * When I see a multi-item select list (such as in the Web Feed
> "Subscribe to this feed using:" list) I expect to be able to select
> multiple items from that list. Would that be possible here? For
> example, I could see the possible use for adding an hCal to both my
> iCal and Google Calendars with a single action.
>
> * Is "Only click Open if you expected this" proposed as final text
> for that particular warning? It could use some finessing, I think.
>
> * What does "Remember my choice" mean? Will the dialog always open
> and offer the user the chance to make a decision (but default-
> selecting the previously remembered choice), or does this really
> mean "Always do this for this type of content"? If the latter,
> it's not very clear. Also, if it's the latter, the warning around
> the "Open" button seems somewhat moot.
>
> * I'm not sure why everything is a dialog except the Web Feeds. It
> seems inconsistent, particularly when there are other feeds being
> discussed (calendar feeds, etc). Is there no way to render a
> preview page for a calendar feed so "feeds" would at least be
> consistent? Alternately, do we really need to preview a Web feed?
> I understand the whole "foolish consistency is the hobgoblin of
> little minds" and so forth, but I just want to make sure that this
> is deliberately inconsistent rather than just inconsistent because
> web feeds have always had a preview page but all the new stuff
> doesn't.
>
> * In the "Download Application" dialog, the "[icon] Download
> Application" thing in the middle looks like a big, clickable
> button. That, combined with the poorly worded warning around the
> "OK" button, is very confusing. The "OK" button after "Only
> download application if you trust its source" seems like the user
> is saying "OK I understand the warning" rather than "OK, download
> the application". That whole dialog might need to be revisited --
> it just seems very busy and overly confusing with all the round-
> cornered buttons and boxes and such.
>
> * I'm confused by the proposal for differentiating between Podcasts
> and Video Podcasts and such. There's no guarantee that today's
> video podcast isn't going to include an audio podcast or a bunch of
> images as enclosures tomorrow. Is this intended to be where the
> user can specify what to do with different types of enclosures
> included in any subscribed feed?
>
> * If you're talking about dealing with different enclosure types
> rather than different feed types (which really makes more sense,
> imho), then I don't think the podcast/video podcast/photocast
> terminology is appropriate (possible trademark issues aside). It
> strikes me that different enclosure types are simply different file
> types, and we might be able to use the simpler "video", "audio",
> and "image" terminology and file-type handlers for those.
>
> * I am somewhat stumped by the "Pointers" terminology and design.
> What are pointers? Could you walk through that in a little more
> detail (or point me at more info if it's available)?
>
> * For Prefs -- are Feeds and Pointers really not just sub-types of
> content? Maybe there should be a unified Content Handling prefs
> pane that includes sub-sections or sub-tabs for Feeds, Pointers,
> and such?
>
> * Has there been thought put into how "Content Handling" and
> "Download Management" revisions will fit together at this point?
>
> Thanks
>
> ~ deb
Alex Faaborg
"rather oddly shaped blob" :)
I'll try a few more iterations with this thing and try to touch base
with Beltzner to see if he thinks tab-nodal is still the way to go.
> The use case currently illustrated with no content in the
> background happens pretty rarely, I think.
That was more of me cutting corners with the mockup than an actual
use case.
-Alex
Alex Faaborg
> just keeping filling up a directory with this content over time?
Yep, and last night I had the idea of placing a shortcut in the
folder called "manage subscription" that would launch Firefox and
display the appropriate UI for removing the feed. This is
particularly important on windows where there really aren't any
applications installed by default to handle podcasts and video podcasts.
> * What's the benefit to using generic icons before the handlers are
> set
> and then changing them to something else after they get set?
We need some type of icon that describes the content type, and we
can't set any app the default to begin with because that wouldn't be
fair (and we honestly don't know what application the user wants to
use). However once the user has selected the app, that icon is going
to be more recognizable. For instance, if the user sees a google
earth icon under their pointer they will more likely think "ah, if I
click this it will load in google earth" as opposed to our generic
location icon.
> Given that the new icons are still different from the icons of the
> apps that will
> be doing the handling, this seems pretty confusing.
The new icons are the same as the apps they get set to. The mockup
is a little confusing since I was using 20x20 icons for the pointers
and 16x16 icons in the menulist, and in the case of the two windows
apps these were using different icons for the smaller resolution.
However, the 20x20 icons will have a closer match to the 32x32 we are
using in the unified content handling dialog.
-Alex
Nils Maier
> Nils Maier wrote:
>> I would really welcome it if you guys do not "overlook" extensions this
>> time.
>
> We definitely would like to play as nicely with extensions as we can;
> thanks for chiming in.
>
>> At least FlashGot and DownThemAll "fight" the current download dialog,
>> trying to add their own content handlers.
>> Had to write a nasty hack to revert the UI to a list type. [1]
>
> I don't have much context with that code; it would help me if you
> described in a bit more detail exactly what the high-level problem you
> ran into was as well as the low-level details of how you ended up
> hacking around it.
There are two notable issues (I'm aware of):
* The last-remember option has to be "hijacked", as there is no
"built-in" way to use it. Currently FlashGot uses code that prevents dTa
from using that option (without flashgot-compatiblity-fixes :p)
This is more or less our problem, not FXs fault (it's simply lacking
some functionality only important to extensions)
* The more serious problem was the redesign of the "Application"
download dialog. FX2.0 introduced a simplified interface for such
downloads basically hiding all options except the Save button.
We had to hack around this by reverting the UI (and even added code for
FlashGot again).
This was and is a real dirty solution, as you can see the UI elements
de-collapsing once the dialog shows up.
And again, the mockups show such simplified interface for Application
downloads.
>> Other extensions might as well like to add to feeds, calendars, whatever
>> actions.
>
> If by that you mean that there should be an easy programmatic way to
> insert items into the "Where to send it" list in Alex' mockups, that
> totally makes sense to me. Is that what you meant?
>
> Dan
Yes, I'd like to ask for a built-in way so that extensions might add
their own entries to downloads, feeds, calendar, whatever.
The proposed system itself should be modular and extensible.
I would imagine an appropriate idl to implement + registration of that
component in categories manager, so that extensions do not even need to
add xul-overlays to the dialog(s).
Some interface like this (just a quick "draft" ;)
interface mozIDownloadConsumer : nsISupports {
[readonly] attribute string name;
[readonly] attribute nsIURI icon;
[readonly] attribute boolean allowRemember;
boolean wouldConsume(in nsIRequest);
void consume(in nsIRequst);
};
The UI would then simply query the corresponding category, negotiate via
|wouldConsume| and finally call |consume| for the selected item and
store rememberLast.
The built-in consumers as well as extensions would implement that/those
interfaces, et voilà.
Is there a bug#, btw?
Nils
Mike Beltzner
> > his might be a good idea, but it
> > would need to be on each dialog.
>
> In the current design it only appears after checking the checkbox.
>
> > If you double click one of the
> > middle choices (say Google Calendar, for example), would that shortcut
> > to the OK functionality?
>
> That sounds like a good accelerator for advanced users, but some
> novice users double click in all situations, so they will find the
> behavior surprising. The microformat content handling UI will also
> be available in context menus, so using that or selecting default
> behaviors (remember my choice) is probably a better way for advanced
> users to avoid the dialog. Beltzner: what do you think?
Yeah, it's an interesting idea, Clint, but I don't see it as being
very consistent in terms of user experiences with any other modal
confirmation dialog that's out there, and selecting an option (even
when that option is to launch an application) should probably not be
confused with confirming that you want to take that action.
So I think it would end up doing more harm than good. What we *should*
be doing is remembering the last taken action and always having that
as the selected one, to make it more likely that a user can one-click
their way to success!
cheers,
mike
>
> -Alex
>
> On May 22, 2007, at 2:52 PM, Clint Talbert wrote:
>
> > Alex Faaborg wrote:
> >> Hey folks, let's use this thread to discuss content handling UI in
> >> Firefox 3. We need to get this decided reasonably soon since it's
> >> currently blocking dmose. cc'ing johnath for his comments on the
> >> security aspects of these dialogs.
>
> >> ==Background==
> > Very good presentation, thanks.
>
> >> ==Proposed UI==
> > * On the Open file dialog, you have a note about how the user can
> > reverse the "remember this" decision. This might be a good idea,
> > but it
> > would need to be on each dialog. However, I do wonder how many users
> > would read that, and of those, would enough remember that in order to
> > justify taking up the space?
>
> > * On the calendar specific dialogs, we definitely want to do better
> > with
> > date handling. I liked Gerv's suggestions there.
>
> > * I have a "flow of control" question. If you double click one of the
> > middle choices (say Google Calendar, for example), would that shortcut
> > to the OK functionality? I think it would be tedious if advanced
> > users
> > had to click the middle choice then click ok.
>
> > * I find the "application" dialog really awkward.
> > ** In all the other dialogs the user has a meaningful choice to be
> > made
> > in the center of the dialog. Here, the user does not. I think that is
> > the primary source of the awkwardness.
> > ** I'd like to see a difference between an unrecognized/unsigned
> > application and a recognized/signed application too. I don't think
> > that
> > the yellow box is sufficient enough warning in the unrecognized/
> > unsigned
> > case, especially since the user would be accustomed to seeing yellow
> > boxes around the OK button on other, less dangerous dialogs (such as
> > your calendar one here).
>
> > This question might be out of scope in this thread, but I feel it is
> > important for us to also consider. There is obviously going to be an
> > options page for the user to change the "remembered" choices here. It
> > would be good to see a prototype design for this page as well.
>
> > Overall, very nice work.
>
> > Clint
> > _______________________________________________
> > dev-apps-firefox mailing list
> > dev-apps-fire...@lists.mozilla.org
> >https://lists.mozilla.org/listinfo/dev-apps-firefox
Gervase Markham
> There's definitely something nice about how much less UI there is when
> all these get consolidated.
I agree. If we are unifying the handling UI, it would be great to use
the same ideas to unify the preferences UI as well. I'm not sure
Jesper's mockup is quite as simple as it could be, but I'm right behind
the unification idea.
Alex: what do you think?
> The fact that such a list would likely be very long seems like a
> possible problem, though. Adding a search box that filters for items
> seems like it could mitigate that problem to some degree.
Possibly, although I'm not sure users would immediately know what to
type in it. If it searched on feed type and current application name as
well (so I could type "skype" and get all the feeds/types which were
handled by Skype) that might help.
Gerv
Gervase Markham
> I just have some quick notes and questions:
>
> * When I see a multi-item select list (such as in the Web Feed
> "Subscribe to this feed using:" list) I expect to be able to select
> multiple items from that list.
Just as a UI note: this type of list doesn't necessarily imply
multi-select. The two behaviours are controlled by different attributes
in HTML, for example.
> Would that be possible here? For
> example, I could see the possible use for adding an hCal to both my
> iCal and Google Calendars with a single action.
Who (apart from some of us) has more than one calendar (or, at least,
more than one calendar provider)?
I'm not saying we should forbid this, but if it's extra implementation
effort, I'm not convinced it's a common case.
> * Is "Only click Open if you expected this" proposed as final text
> for that particular warning? It could use some finessing, I think.
Yes.
> * What does "Remember my choice" mean? Will the dialog always open
> and offer the user the chance to make a decision (but
> default-selecting the previously remembered choice), or does this
> really mean "Always do this for this type of content"? If the
> latter, it's not very clear. Also, if it's the latter, the warning
> around the "Open" button seems somewhat moot.
Fair points. We have to balance the convenience of "Always do this" with
the increased attack surface each such automatically-invoked application
presents. Tough call.
> * I'm not sure why everything is a dialog except the Web Feeds. It
> seems inconsistent, particularly when there are other feeds being
> discussed (calendar feeds, etc). Is there no way to render a preview
> page for a calendar feed so "feeds" would at least be consistent?
> Alternately, do we really need to preview a Web feed? I understand
> the whole "foolish consistency is the hobgoblin of little minds" and
> so forth, but I just want to make sure that this is deliberately
> inconsistent rather than just inconsistent because web feeds have
> always had a preview page but all the new stuff doesn't.
I'm also not convinced of the utility of feed preview. Perhaps my use
cases are different to everyone else's, but it always seems to me that
I've just been viewing the web page version of the content before I
subscribe to a feed of it anyway.
> * In the "Download Application" dialog, the "[icon] Download
> Application" thing in the middle looks like a big, clickable button.
> That, combined with the poorly worded warning around the "OK" button,
> is very confusing. The "OK" button after "Only download application
> if you trust its source" seems like the user is saying "OK I
> understand the warning" rather than "OK, download the application".
> That whole dialog might need to be revisited -- it just seems very
> busy and overly confusing with all the round-cornered buttons and
> boxes and such.
Agree.
> * I am somewhat stumped by the "Pointers" terminology and design.
> What are pointers? Could you walk through that in a little more
> detail (or point me at more info if it's available)?
I believe they are microformats :-)
Gerv
jpr...@ision.nl
* why don't we include the 'install extension/add-on' dialog in this
discussion?
* on tab-modal: it seems a bit odd,
would the yellow strip be an option for this? If we arrange the 1.
content / 2. where to / 3. decision horizontally it would perfectly
fit,
use a combo-box for multiple 'where - to',
another idea: when a user selects 'remember this', the next you show a
yellow bar for 5 sec's where user can see the status
(downloading... or something) and an option to revert his decision.
Also I would like to see some kind of indicator (flash) for tabs that
are in the background, so you can see the tab is waiting for input.
Alex Faaborg
Yeah, I think a single tab in preferences called "Applications" is a
great idea.
-Alex
Clint Talbert
> I haven't had a chance to do a full set of microformats mockups, but the
> the overall idea is that your mouse pointer will change when hovering
> over microformatted content. A right click will produce the usual
> context menu with additional options to send the content to the
> associated application, and a left click will produce the unified
> content handling dialog being discussed in this thread (if no default
> application has been set yet).
off, there is the "Myst problem" that someone brought up earlier about
having to mouse over the entire page before finding an actionable link.
Furthermore, I went and did some checking around to find out what's been
done on this. I found the following information (hCalendar specific).
== Here is a sample test to follow ==
This site contains an hCalendar link for the fundraising event:
http://www.friendsofthechildrenny.org/events.html
View it and note that the giant image advertising the event is already a
link to the registration page. There is no hCalendar information or
visible element whatsoever.
Now, install this prototype hCalendar handler here:
http://greasemonkey.makedatamakesense.com/google_hcalendar/
Now, go back to our site in question:
http://www.friendsofthechildrenny.org/events.html
You'll note the handy "Google Calendar" button that will add it to your
google calendar.
My point here is that this feature is going to have to be more
discoverable than changing the mouse pointer on a page. What would
happen if you clicked on a link while you have this new "microformat
alert" mousepointer? Would it take you to the link? Would it take you
to the new content handling UI?
Here are other examples of sites with hCalendars on them:
http://microformats.org/wiki/hcalendar-examples-in-wild
Clint
Dan Mosedale
>
> I think the options are to either:
> 1. List all possible apps as feed handlers (so include iTunes,
> Democracy, whatever) and let the app deal with whether it has the
> right stuff
According to a recent post by Alex:
<http://groups.google.com/group/mozilla.dev.apps.firefox/msg/1bf86e7746782be2>
the idea is to use our guess as to podcast type as a hinting mechanism
for how to order the possible handlers in the preview page. This sounds
like it covers it to a large degree, though it might imply that the
"remember my choice for video podcasts" checkbox should just go away.
Do you have any sort of feel of the distribution of "pure" media
podcasts vs semi-random or multimedia podcasts? Generally speaking,
we'd like to optimize for the most common case, if we think we know what
that is...
> 2. Treat media attachments to feeds more like microformats in a web
> page, which have a similarly unpredictable and instance-specific
> likelihood of being present and acted upon
I'm not sure what that would mean. Can you elaborate?
Dan
Dan Mosedale
>> we'd go get these on a timer and
>> just keeping filling up a directory with this content over time?
>
> Yep, and last night I had the idea of placing a shortcut in the folder
> called "manage subscription" that would launch Firefox and display the
> appropriate UI for removing the feed. This is particularly important on
> windows where there really aren't any applications installed by default
> to handle podcasts and video podcasts.
Hmmm, this seems like something that would be easy to forget and have
chew up a lot of disk. Now we could address that by then having
expiration policy... but that sounds like it's like to require a
per-feed preference. And what are they going to view it with? To me,
this really feels like "application creep". Rather than providing an
(extremely) poor man's podcast subscription app, I'd much rather see
some links or UI that would direct the user to a web page where they
could select and download appropriate apps.
>> * What's the benefit to using generic icons before the handlers are set
>> and then changing them to something else after they get set?
>
> We need some type of icon that describes the content type, and we can't
> set any app the default to begin with because that wouldn't be fair
We generally try and seed the search box default with the provider that
we think will provide the best user experience to users in a locale, and
because forcing people to make decisions rather than having something
that Just Works is generally a user experience lose. I believe that
logic applies here too. My belief is that most of our users will be
less happy if we start trading away ease-of-use in favor satisfying an
abstraction like "market fairness".
> (and
> we honestly don't know what application the user wants to use).
Of the three microformats currently on the table, one (geo) isn't really
about personal data and could easy be defaulted to web site. The other
two, hCalendar and hCard are going to be translated to macroformats
(iCalendar and vCard) which do already have OS application defaults.
Right now, we just use those OS defaults. With the advent of web-based
content handlers, though, the decision becomes less obvious. Forcing a
choice here is one option; starting with the OS default and allowing for
a choice is another, though I'm not sure how one would do that in a
discoverable way. Thoughts?
> The mockup is a little confusing since I was using 20x20 icons for
the pointers and
> 16x16 icons in the menulist, and in the case of the two windows apps
> these were using different icons for the smaller resolution.
This was actually the source of most of my confusion, I think.
Dan
Jesper Kristensen
> I'm not totally convinced this strategy is going to be effective. First
> off, there is the "Myst problem" that someone brought up earlier about
> having to mouse over the entire page before finding an actionable link.
Maybe we should develop some kind of standard for websites to use to indicate
a microformat. Like blue and underlined indicates a link. But unlike links, I
don't think we can put some default CSS on it without breaking some website
designs, especially because microformats are already used out there, and
websites that use them are not created with whatever default style we may
choose in mind.
Alex Faaborg
Right, we would want to throw a notification when a download
completes. In terms of chewing up a lot of disk space, I think we
can set a reasonable default, like 10 or 15 files per audio or video
feed.
> Rather than providing an
> (extremely) poor man's podcast subscription app
Kind of like Live Bookmarks are a poor man's feed reader. I
personally think these features are more meaningful if they have the
core functionality without requiring extra software. Also, podcast
subscription apps don't need a lot of features, simple (poor man)
is... simpler.
> I'd much rather see some links or UI that would direct the user to
> a web page where they
> could select and download appropriate apps.
Either way I think we should promote democracy/miro in this list.
> if we start trading away ease-of-use in favor satisfying an
> abstraction like "market fairness".
Throwing up the content handling dialog wouldn't make the interaction
particularly hard to use, just a little more tedious the first time
the user sees it, and exactly the same as clicking on a file.
Also, if we pick a default the user doesn't like (like Windows
Calendar when they actually use Yahoo Calendar) the user won't like
the feature, since it "only works with this calendar I don't use,"
and they won't know that they can change the default application
without proactively digging around their preferences.
Choosing a default provider for maps makes sense (although this may
chance over time has people store more personal data with their map
provider).
-Alex
Alex Faaborg
personally worried that injecting buttons into pages is going to
*really* piss of Web designers, and it is in general a line that
browsers don't usually cross. (Greasemonkey scripts are of course
totally fair game, since the user is installing them.)
The mouse cursor change was proposed in the comments of this post,
where I talk a lot about various UIs that overlay the page: http://
blog.mozilla.com/faaborg/2007/02/04/microformats-part-4-the-user-
interface-of-microformat-detection
I think in addition to a mouse cursor change, we should very faintly
show an outline of what the user is acting on.
> What would
> happen if you clicked on a link while you have this new "microformat
> alert" mousepointer? Would it take you to the link? Would it take you
> to the new content handling UI?
On links inside microformatted content, the mouse cursor would change
to a hand, and it would act on the link, not the microformat.
I agree that this is overall confusing, I'm going to work on some
mockups to hopefully clean up the interaction by showing outlines on
hover. The behavior will be similar to images on flickr that have
specific parts of them tagged.
-Alex
Clint Talbert
> Mike Beltzner has been arguing for a similar approach. I'm personally
> worried that injecting buttons into pages is going to *really* piss of
> Web designers, and it is in general a line that browsers don't usually
> cross. (Greasemonkey scripts are of course totally fair game, since
> the user is installing them.)
>
was no indication whatsoever of a microformat at all. And on a page as
busy as that one, I'd be hardpressed on where to indicate a microformat.
> The mouse cursor change was proposed in the comments of this post, where
> I talk a lot about various UIs that overlay the page:
> http://blog.mozilla.com/faaborg/2007/02/04/microformats-part-4-the-user-interface-of-microformat-detection
>
> I agree that this is overall confusing, I'm going to work on some
> mockups to hopefully clean up the interaction by showing outlines on
> hover. The behavior will be similar to images on flickr that have
> specific parts of them tagged.
I'll look forward to them.
Clint
Alex Faaborg
>
> http://temp.jesperkristensen.dk/mozilla/content_handling/
> prefs_proposal.html
Woohoo! I'm not the only one working on mockups :)
I've posted the stencils I am using here: http://wiki.mozilla.org/
Mockups in case anyone else is interested in creating mockups using
the same tools I am.
The preferences redesign look great, I really like the idea of
integrating Feeds and Smart Elements/Pointers/Microformats into a
single tab called Applications.
In update 2, I think putting the applications a separate column that
is still left justified might look better.
Having both a "default application" menulist and a checkbox for
"always use iTunes" seems like a boundary case. Do we expect a lot
of users to configure which application they want selected, but still
want to see a dialog box when clicking on a piece of content?
You should make sure to link to these mockups from http://
wiki.mozilla.org/ContentHandling:User_Interface
Great work!
-Alex
On May 24, 2007, at 1:26 PM, Jesper Kristensen wrote:
> Alex Faaborg skrev:
>> Here are some mockups of possible changes to Firefox's preferences
>> dialog:
>>
>> Feeds:
>> http://wiki.mozilla.org/ContentHandling:User_Interface/
>> Preferences_Feeds
>>
>> Microformats:
>> http://wiki.mozilla.org/ContentHandling:User_Interface/
>> Preferences_Microformats
>>
>>
>> (in progress) MIME Types, Files and Protocols:
>> http://wiki.mozilla.org/ContentHandling:User_Interface/
>> Preferences_Content
>>
>> -Alex
>
> I don't think you should be the only one posting pictures, Alex :)
>
> http://temp.jesperkristensen.dk/mozilla/content_handling/
> prefs_proposal.html
Robert Sayre
> On May 23, 4:09 pm, Alex Faaborg <faab...@mozilla.com> wrote:
>> http://wiki.mozilla.org/ContentHandling:User_Interface/Proposed_UI2
>>
>> ==Changes==
>> *Added an example of handling RSS feeds differently based on content
>> inspection (text, images, video).
>
>>From my experience managing a large feed aggregation infrastructure
> (millions), this will be incredibly difficult to implement... if not
> impossible. The problem is there is no strict test of whether a feed
> is just text, or a podcast or a video podcast.
That's a smaller problem if the behavior for feeds detected as
"podcasts" or whatever get a choice UI. The problem with the current
interface is that it's possible for users to send feeds, whatever they
contain, to one provider, bypassing all UI.
- Rob
Robert Sayre
Jesper Kristensen
Michael Vincent van Rantwijk, MultiZilla
"Applications" was previously known as "Helper Applications" so that is
fine.
The text: "Here you can configure Firefox to let your favorite
application handle different types of content" is way too log now. My
father would have said: "If the user doesn't immediately understands
what it is, the UI is wrong".
The tree (or whatever element is used) can be clear, and in your
previous mockup you had dotted lines, but I would prefer an odd/even
background color change, just like Apple would have done here.
"Content type" isn't exactly what is it to the regular end user, so IMHO
that should be changed to plain simple "Type" for example.
"Automaticly find known types of content in websites" this checkbox
should be removed, and that should be the default way of handling
things, simply because that is what people expect, right?
Jesper Kristensen
preferences UI, they are evolving to look more and more like the current file
type dialog. Maybe that dialog could be used as a starting point for a
unified app selection UI. But how visible should it be? Should it stay as a
button under the Content tab, should it have is own tab, should i be in a
sub-tab of the Content tab or something else?
Jesper Kristensen
> "Automaticly find known types of content in websites" this checkbox
> should be removed, and that should be the default way of handling
> things, simply because that is what people expect, right?
>
I am not sure if it is clear, but the checkbox is for turning microformat
parsing on and off. You may be right that it should not be a visible
preference, and if it should, it should be in the Content tab or the Advanced
tab instead of the Applications tab.
Michael Vincent van Rantwijk, MultiZilla
Are you getting confused about two different things? I mean there is
the options dialog, to change already set content types, and there is
you as website visitor running into an unknown content type. To me,
that's what Alex Faaborg was trying to address with his mockups, while
you are taking the preference manager approach, right?
Jesper Kristensen
>> Looking at my own proposals for a unified feed/microformat/file
>> type/protocol preferences UI, they are evolving to look more and more
>> like the current file type dialog. Maybe that dialog could be used as
>> a starting point for a unified app selection UI. But how visible
>> should it be? Should it stay as a button under the Content tab, should
>> it have is own tab, should i be in a sub-tab of the Content tab or
>> something else?
>
> Are you getting confused about two different things? I mean there is
> the options dialog, to change already set content types, and there is
> you as website visitor running into an unknown content type.
I was talking about
http://temp.jesperkristensen.dk/mozilla/content_handling/prefs_proposal.html
http://wiki.mozilla.org/ContentHandling:User_Interface/Preferences_Feeds
http://wiki.mozilla.org/ContentHandling:User_Interface/Preferences_Microformats
http://wiki.mozilla.org/ContentHandling:User_Interface/Preferences_Content
I was NOT talking about
http://wiki.mozilla.org/ContentHandling:User_Interface/Tab-Modal_Dialogs
http://wiki.mozilla.org/ContentHandling:User_Interface/Proposed_UI2
http://wiki.mozilla.org/ContentHandling:User_Interface/Proposed_UI
To me,
> that's what Alex Faaborg was trying to address with his mockups, while
> you are taking the preference manager approach, right?
>
Nearly. Alex has actually posted mockups for both.
Michael Vincent van Rantwijk, MultiZilla
Oh, so in that case I was confused ;)
Gervase Markham
This looks good. I'd like to see Alex's riff on it, but some thoughts:
- The text is a bit cumbersome. I think we could get down to:
IC Web Feed
ON Use: * Firefox Preview
IC Contacts
ON Use: * Thunderbird
IC Phone numbers
ON Ask me every time
- We don't need an "Always use iTunes" box - you should be able to
select "Ask me every time" from the dropdown list. The functionality is
pretty much the same - I think the two use cases are "I always use the
same app" and "I need to think about this one".
Gerv
ja...@mozilla.com
> for how to order the possible handlers in the preview page. This sounds
> like it covers it to a large degree, though it might imply that the
> "remember my choice for video podcasts" checkbox should just go away.
>
> Do you have any sort of feel of the distribution of "pure" media
> podcasts vs semi-random or multimedia podcasts? Generally speaking,
> we'd like to optimize for the most common case, if we think we know what
> that is...
It never seemed clear-cut to me. We resorted to just providing the
count of various media objects and letting each of the individual
sites apply their own logic. Some wanted to index all audio files...
some wanted to handle only "pure" podcasts. Unfortunately, there is
no standard for this... although FeedBurner uses the mediaRSS category
tag to map to the iTunes schema:
<media:category scheme="http://www.itunes.com/dtds/
podcast-1.0.dtd">Audio Blogs</media:category>
However, these are intended to describe the content (other categories
are things like Business) and not the format.
> > 2. Treat media attachments to feeds more like microformats in a web
> > page, which have a similarly unpredictable and instance-specific
> > likelihood of being present and acted upon
>
> I'm not sure what that would mean. Can you elaborate?
Yeah, what if you configured which app to send the audio attachments
to (or any other media type), rather than the whole feed? This is
what some newsreaders do. For example, NetNewsWire can be configured
to automatically download and hand-off all audio files to iTunes. It
even goes a step further and allows you to have them all added to NNW
playlist, or to separate playlists named after the feed itself.
Dan Mosedale
>>> 2. Treat media attachments to feeds more like microformats in a web
>>> page, which have a similarly unpredictable and instance-specific
>>> likelihood of being present and acted upon
>> I'm not sure what that would mean. Can you elaborate?
>
> Yeah, what if you configured which app to send the audio attachments
> to (or any other media type), rather than the whole feed? This is
> what some newsreaders do. For example, NetNewsWire can be configured
> to automatically download and hand-off all audio files to iTunes. It
> even goes a step further and allows you to have them all added to NNW
> playlist, or to separate playlists named after the feed itself.
Interesting idea; that's a somewhat different factoring in the sense
that sending the whole feed is a one-time thing, this seems like it
would require a whole new class of UI or some sort of live bookmarks
integration to present the entire content to the user in an ongoing way.
It seems like it'd be difficult to do without increasing our scope
substantially.
For any near term work, the hinting mechanism as suggested by Alex, or
perhaps not re-ordering but simply changing the default but still
querying on feeds that we suspect are pure, typed multimedia seems the
most tractable.
Dan
Dan Mosedale
> There are two notable issues (I'm aware of):
> * The last-remember option has to be "hijacked", as there is no
> "built-in" way to use it. Currently FlashGot uses code that prevents dTa
> from using that option (without flashgot-compatiblity-fixes :p)
> This is more or less our problem, not FXs fault (it's simply lacking
> some functionality only important to extensions)
Would adding some sort of extension hook here in Fx be helpful?
> * The more serious problem was the redesign of the "Application"
> download dialog. FX2.0 introduced a simplified interface for such
> downloads basically hiding all options except the Save button.
> We had to hack around this by reverting the UI (and even added code for
> FlashGot again).
> This was and is a real dirty solution, as you can see the UI elements
> de-collapsing once the dialog shows up.
> And again, the mockups show such simplified interface for Application
> downloads.
The design of various UI elements in Firefox is pretty much guaranteed
to evolve over time. Keeping old designs around so that extensions can
still use them seems like the wrong trade-off to me (code
complexity/maintainability, download size, etc). If I were in your
position of preferring the old UI, I'd probably fork the old code and
include that in my extension directly and simply replace the current
dialog with the forked version. I don't really see what else can or
should be done at the Firefox level. Do you?
> Yes, I'd like to ask for a built-in way so that extensions might add
> their own entries to downloads, feeds, calendar, whatever.
> The proposed system itself should be modular and extensible.
>
> [...]
>
> The built-in consumers as well as extensions would implement that/those
> interfaces, et voilà.
OK, that makes sense. It sounds worth trying to put in once we get to
the new dialog infrastructure. Exactly how much infrastructure overhaul
we have time to do between now and Firefox 3 remains to be seen, though.
I'll add a link to this post to the bug so that we don't lose track of
this suggestion.
> Is there a bug#, btw?
Bug 377782
Dan
Jason Douglas
> Interesting idea; that's a somewhat different factoring in the sense
> that sending the whole feed is a one-time thing, this seems like it
> would require a whole new class of UI or some sort of live bookmarks
> integration to present the entire content to the user in an ongoing way.
Why would there be any ongoing UI? I think you could do it with just
two more preferences:
- Checkbox of whether to automatically download attachments (to
download folder)
- Checkbox of whether to automatically launch helper app for
attachments (by registered type)
I believe most desktop feed readers take this approach (...probably
worth surveying them). The biggest issue with this approach that I
can see, is that it will only work if FFx is the default reader and
doing the ongoing updating of feeds. So maybe these are just
preferences for LiveBookmarks.
I'm just very skeptical about getting the logic right for determining
the feed type... not to mention the lack of predictability for users.
What if I get used to always immediately accepting the dialog (w/
default action) whenever I click on the feed icon, then one day a feed
gets handed off to a different application and I don't even realize
it?
IHMO, the feature is not enough of a slam dunk to bake into the core
UI yet (extension?).
Deb Richardson
> two more preferences:
> - Checkbox of whether to automatically download attachments (to
> download folder)
> - Checkbox of whether to automatically launch helper app for
> attachments (by registered type)
For what it's worth, this is the general idea of what I was trying to get across earlier in this thread -- Jason just expressed it much more clearly than I did :)
I think this is the simplest and most logical way to approach this.
~ deb
Jesper Kristensen
> New version of the unified content handling UI, based on feedback from
> this thread:
>
> http://wiki.mozilla.org/ContentHandling:User_Interface/Proposed_UI2
Maybe Addons should be part of this?
Example:
http://temp.jesperkristensen.dk/mozilla/content_handling/AddonInstallUI.png
Alex Faaborg
>> attachments (by registered type)
It seems like we wouldn't want to launch the helper app, as much as
find a way to hand it the content in the background. For instance,
you wouldn't want iTunes opening and taking the focus anytime a
podcast downloaded, or Democracy launching and taking the focus if a
video podcast came in.
Also, these applications have their own interfaces for handling
feeds, so it seems like a better overall user experience to give the
application the entire feed than it is to give the application
individual files. For instance, both iTunes and Democracy organize
information by feed, and they both track which files have been played.
I understand that feeds contain mixed content types, and that sending
any mixed content feed to a particular application means that the
user is going to miss some content. But handling the feed ourselves
and trying to push content to the correct applications after download
doesn't strike me as the simplest and lost logical way to approach this.
-Alex
Alex Faaborg
knowing which application they are for. If we show both options one
of them isn't going to work. Probably the most direct way to solve
this problem would be to give Firefox and Thunderbird extensions
different MIME types.
If we wanted to use the unified content handling dialog for addons,
we would need to add the additional security cues in the current
dialog (signed/unsigned, multiple warnings).
One reason to unify this dialog box would be so that we could also
use the 5-second waiting period button for executables (which I guess
we don't currently use because the executable code downloads instead
of automatically installing?)
-Alex
Gervase Markham
> We should really be able to hand addons to Firefox or Thunderbird by
> knowing which application they are for. If we show both options one of
> them isn't going to work. Probably the most direct way to solve this
> problem would be to give Firefox and Thunderbird extensions different
> MIME types.
Another solution would be to serve non-browser addons with
Content-Disposition: attachment, meaning they download rather than
install by default. There's a bug on this; it got closed a while back
when we served addons from FTP mirrors which couldn't do this, but as
that's no longer true, I've reopened it.
The problem with fiddling the MIME types is that some addons are Firefox
only, some are Firefox + Mozilla, some are Firefox + Mozilla + Flock,
and so on. You could even imagine an addon ("Make Default Text Bigger")
which was both Firefox and Thunderbird.
Gerv
Jesper Kristensen
How to deal with non-browser apps wasn't really my point. My point was (1) to
add this dialog to the unified content handling UI, so that it looks similar
to the other dialogs (it should still have the warning message and the
timeout), (2) to make it clear to the user what app they are installing the
addon into, and (3) to offer download of the addon instead of installing it.
http://temp.jesperkristensen.dk/mozilla/content_handling/AddonInstallUI2.png
Robert Kaiser
> We should really be able to hand addons to Firefox or Thunderbird by
> knowing which application they are for. If we show both options one of
> them isn't going to work. Probably the most direct way to solve this
> problem would be to give Firefox and Thunderbird extensions different
> MIME types.
That would mean that we'd need different MIME types for every XULRunner
apps that comes along and supports extensions, and it still wouldn't
handle the "This extension supports multiple applications" case that we
already have with extensions like DOMI, Chatzilla, and others.
> If we wanted to use the unified content handling dialog for addons, we
> would need to add the additional security cues in the current dialog
> (signed/unsigned, multiple warnings).
Probably. Giving the user a unified experience on "you're downloading
some content here" is probably a good idea though. And the possibility
of selecting a different app to handle it with is important in the
Firefox vs. Thunderbird extension case.
When we'd be very intelligent, we'd download the package and look into
its install.rdf to detect the apps it supports - but I guess that might
be problematic in its own way (waiting for download, etc.)
Robert Kaiser
Jesper Kristensen
> http://wiki.mozilla.org/ContentHandling:User_Interface/Proposed_UI2
I don't see why there should be a yellow warning message in the microformat
and protocol dialog.
Deb Richardson
1) Firefox itself is a feed handler, but as a feed handler it currently doesn't do anything with feed enclosures. The question here is: Do we want Firefox to do something with feed enclosures if a user subscribes to that feed as a Live Bookmark? I was assuming "yes" here, and suggesting that we treat those enclosures as simple downloads -- add them to the download manager/history list, put the downloaded files into the specified download folder(s), etc. Again, this is where content handling and download management would overlap, and we might want think about how those systems will fit together.
2) Giving the user the ability to specify within Firefox that a particular application handle all feeds of a particular "type". So all feeds that "look" like podcasts (ie: they have a bunch of audio enclosures) go to the audio application the user specifies, etc. My primary issue here is that analysing feeds for "type" is going to be potentially error prone. Unless feed publishers have some way of indicating what type of feed it is?
~ d
Nils Maier
Yeah. I'm not saying that these changes were all wrong.
Just tried to outline problems extension authors had in the past and
making suggestions on how to avoid them in the future.
However, I would have welcomed it if the devs who did this change would
have looked into possible extension incompatiblities, notified the
authors or even got in touch with them.
On the other hand, extension author didn't seem to care until it was too
late (including me).
Not trying to blame anyone here. ;)
>> Yes, I'd like to ask for a built-in way so that extensions might add
>> their own entries to downloads, feeds, calendar, whatever.
>> The proposed system itself should be modular and extensible.
>>
>> [...]
>>
>> The built-in consumers as well as extensions would implement that/those
>> interfaces, et voilà.
>
> OK, that makes sense. It sounds worth trying to put in once we get to
> the new dialog infrastructure. Exactly how much infrastructure overhaul
> we have time to do between now and Firefox 3 remains to be seen, though.
> I'll add a link to this post to the bug so that we don't lose track of
> this suggestion.
I did a trunk patch adding similar functionality to the sanitize feature:
https://bugzilla.mozilla.org/show_bug.cgi?id=328463
So it seems it isn't that hard to realize such a modular system.
Jason Douglas
> 1) Firefox itself is a feed handler, but as a feed handler it currently doesn't do anything with feed enclosures....
> 2) Giving the user the ability to specify within Firefox that a particular application handle all feeds of a particular "type".... My primary issue here is that analysing feeds for "type" is going to be potentially error prone. Unless feed publishers have some way of indicating what type of feed it is?
Thank you for (correctly) separating the issues. :-)
Unfortunately, there is no standardized way for publishers to indicate
type. One option would be to create a new namespace for the
<category> tag (in both RSS & Atom) and advocate that, but building
adoption of that maybe an uphill slog. (Being clear about the content-
handling benefit/behavior could help, though.)
I agree that guessing is going to be very error-prone, however. Maybe
we could defer just the dynamic re-ordering / defaulting based on feed
type part until we've had a chance to sort through the options better?
Alex Faaborg
>> My primary issue here is that analysing feeds for "type" is going
>> to be potentially error prone
If all we are doing is reordering the list of applications, and we
are providing a preview, I don't think we need to worry too much
about errors. Either way, I am all for us pushing some way for these
feeds to identify themselves through a standards body.
-Alex
Alex Faaborg
microformat could leverage vulnerabilities in the client side
applications we are pushing the content to, like Outlook, or Google
Earth. We haven't done a full security review of how we are going to
inspect data before sending it, but are aware of the issues here.
The same is true for protocols. For instance, malformed urls with
the the ms-its:// protocol allowed arbitrary code execution in IE 6
(http://www.microsoft.com/technet/security/Bulletin/MS04-023.mspx)
-Alex
Jesper Kristensen
> It's theoretically possible that malicious content stored in a
> microformat could leverage vulnerabilities in the client side
> applications we are pushing the content to, like Outlook, or Google
> Earth. We haven't done a full security review of how we are going to
> inspect data before sending it, but are aware of the issues here.
>
> The same is true for protocols. For instance, malformed urls with the
> the ms-its:// protocol allowed arbitrary code execution in IE 6
> (http://www.microsoft.com/technet/security/Bulletin/MS04-023.mspx)
But isn't that a security hole in IE6? I don't think we should warn that
there could potentially be security holes in other apps. Should we also
display a warning every time a user enters a HTML page because it may exploit
unknown security holes in Firefox? Keeping security warnings to a minimum is
critical, or users will ignore them. There might be valid security concerns
for displaying the warning, but i don't think your example is one of them.
DigDug
different approach for this because I'm curious.
Is it possible at all to associate these web-content handlers with
their content at the OS level? Perhaps setup so that calendars were
associated with something like (again, I reiterate, I don't even know
if this is possible):
firefox.exe --handler=googleCalendar
When the user clicked on some content that Firefox couldn't handle it
would get fired to the OS, which would then callback to Firefox I
guess, asking it to use a certain content handler? Left clicked links
to content could open in the default application. Context clicks could
bring up something OS appropriate, so that on Windows you had: "Open,
Open With, and Save" in the popup, just like when you context click a
document on the desktop? I don't know if thats impossible, or possible
and has been discarded. I just don't want to have to manage content
associations in more than one place.
Mike Beltzner
> On Jun 5, 7:07 am, Deb Richardson <d...@mozilla.com> wrote:
>> 1) Firefox itself is a feed handler, but as a feed handler it
>> currently doesn't do anything with feed enclosures....
Correct. And there's no real plan to become anything more than that,
beyond giving extension authors some really great tools (parser,
moz-storage, XUL) to build a kick ass fully-featured feed reader.
I'd like to do some polish to our feed handling, mostly along the lines
of what you proposed (way back when) here:
http://wiki.mozilla.org/User:Dria/On_Web_Feeds#Toolbar_notifications
But that's a different discussion :)
>> 2) Giving the user the ability to specify within Firefox that a
>> particular application handle all feeds of a particular "type"....
>> My primary issue here is that analysing feeds for "type" is going
>> to be potentially error prone. Unless feed publishers have some
>> way of indicating what type of feed it is?
>
> Thank you for (correctly) separating the issues. :-)
>
> Unfortunately, there is no standardized way for publishers to
> indicate type. One option would be to create a new namespace for the
> <category> tag (in both RSS & Atom) and advocate that, but building
> adoption of that maybe an uphill slog. (Being clear about the
> content- handling benefit/behavior could help, though.)
These are good points, but I feel like we can probably do some lazy
prediction here based on the content. Like, if something contains only
enclosures of audio files, it's probably a podcast feed. If something
contains only enclosures of video files, it's probably a video podcast feed.
If something doesn't match that heuristic, we throw up the general "this
is a feed" preview and let the user decide (since their other
applications will be in there). If it's a mixed content feed anyway,
chances are that they want it in a feedreader.
cheers,
mike
Jesper Kristensen
According to WHATWG, web based content handlers are for feeds only [1][2]. I
don't know why they call the function registerContentHandler() and why they
require a MIME type as a parameter.
According to the mailing list discussion [2], implementing web based content
handlers would be an unnecessary security risk, and users should instead
download the content to their computers and then manually upload it to the
web app using a normal file upload form.
I thought this was such a great feature until I realized that it was just the
feed handlers already implemented in Firefox 2.
[1] http://www.whatwg.org/specs/web-apps/current-work/#custom-handlers
[2] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2006-April/006231.html
Dan Mosedale
A few of us have talked about this some, but haven't come to any real
conclusions as to where we want to go with it. This probably won't
happen in the Firefox 3 timeframe, as we'd like to have more experience
with the basic in-browser web-based handling before taking it the next
level. In particular, there are complex use case and security questions
to sort out here...
Dan
Dan Mosedale
>
> According to WHATWG, web based content handlers are for feeds only
> [1][2].
Having followed both of those links, I'm curious what makes you draw
that conclusion (it's incorrect).
> I don't know why they call the function registerContentHandler()
> and why they require a MIME type as a parameter.
The intent is specifically to allow for handling of arbitrarily
MIME-typed content.
> According to the mailing list discussion [2], implementing web based
> content handlers would be an unnecessary security risk, and users should
> instead download the content to their computers and then manually upload
> it to the web app using a normal file upload form.
There is indeed a complex set of security tradeoffs around that sort of
functionality. That doesn't mean that it's not worth attempting to
understand those tradeoffs and figuring out what functionality is
reasonable to provide. That said, that's probably not something we'll
be trying to do in the Firefox 3 cycle.
Dan
Jesper Kristensen
> Jesper Kristensen wrote:
>>
>> According to WHATWG, web based content handlers are for feeds only
>> [1][2].
>
> Having followed both of those links, I'm curious what makes you draw
> that conclusion (it's incorrect).
Theoretically there may be other use cases, but practically no.
Example: With the current spec it is not possible in many cases to find an
ODF tile at some website and open it in Google Docs without (1) downloading
the file, (2) open Google Docs and (3) uploading the file manually. It might
be possible in a few cases, but a functionality that works half the time is
not good, and there is no way in many cases for Firefox to know weather it
will work or not (there is many unknown factors that influences if a
transaction is idempotent or not). Therefore it would be a bad thing to
register a content handler for ODF.
>
>> I don't know why they call the function registerContentHandler() and
>> why they require a MIME type as a parameter.
>
> The intent is specifically to allow for handling of arbitrarily
> MIME-typed content.
Many feeds out there use a wrong MIME type. Therefore Firefox 2 requires that
websites use "application/vnd.mozilla.maybe.feed" as the first parameter for
registerContentHandler. That doesn't help in interoperability between
different browsers.
Benjamin Hawkes-Lewis
> Theoretically there may be other use cases, but practically no.
>
> Example: With the current spec it is not possible in many cases to find an
> ODF tile at some website and open it in Google Docs without (1) downloading
> the file, (2) open Google Docs and (3) uploading the file manually. It might
> be possible in a few cases, but a functionality that works half the time is
> not good, and there is no way in many cases for Firefox to know weather it
> will work or not (there is many unknown factors that influences if a
> transaction is idempotent or not). Therefore it would be a bad thing to
> register a content handler for ODF.
Can you clarify whether there is a fundamental problem here, or just a
flaw in the WHATWG draft? It would be nice functionality to have, to say
the least.
--
Benjamin Hawkes-Lewis
Jesper Kristensen
Some restrictions are caused by security concerns, others by the way the
functionality is implemented in the spec. When you want to send some content
to a web content handler, you send the URL. This is limited to public HTTP
URLs, thus preventing content from intranet sites, sites protected by login,
secure sites or your local machine to be sent to a web handler.
Many sites use cookies for login, and the browser won't know if a cookie is
for login or just for statistics or other stuff. And when you are behind a
login, the browser cannot know if the file would have been available if you
wasn't logged in. This is just one of the cases where the browser don't know
if it can use the online content handler.
Dan Mosedale
> Dan Mosedale skrev:
>> Jesper Kristensen wrote:
>>>
>>> According to WHATWG, web based content handlers are for feeds only
>>> [1][2].
>>
>> Having followed both of those links, I'm curious what makes you draw
>> that conclusion (it's incorrect).
>
> Theoretically there may be other use cases, but practically no.
Here are a few use cases:
* a web site (e.g. upcoming, eventful, etc) offers you a snippet of
ICS, it can be sent to your online calendar (eg 30boxes)
* a web site offers you a PDF or .doc file; you can send it to an online
PDF -> HTML converter (PSView works for this today)
* a web site offers you KML, you can send it to Google Maps
There are plenty of others.
<Discussion of "sometimes works" elided; I'll address this is another post>
> Many feeds out there use a wrong MIME type. Therefore Firefox 2 requires
> that websites use "application/vnd.mozilla.maybe.feed" as the first
> parameter for registerContentHandler. That doesn't help in
> interoperability between different browsers.
I agree that that particular thing should change. What we should
probably do would be to register based on the real MIME-types, and
dispatch the content based on sniffed MIME type. If you wanted to file
a bug on that and CC me, that would be great!
Dan
Jesper Kristensen
> it can be sent to your online calendar (eg 30boxes)
ICS files are sometimes used as a feed AFAIK, so that goes in under the feed
category, I think.
> * a web site offers you a PDF or .doc file; you can send it to an online
> PDF -> HTML converter (PSView works for this today)
Most public sites I know is written in HTML. I most often get PDF, DOC or ODF
documents on intranet sites and webmail. If I was a web content handler, I
would not want to register handlers that would result in an error most of the
time, because I would be the one people blamed.
> * a web site offers you KML, you can send it to Google Maps
OK, that might be a content type that would be mostly used on public sites.
But still, I think registerContentHandler has a buggy spec.