Content Handling UI

10 views
Skip to first unread message

Alex Faaborg

unread,
May 22, 2007, 5:28:56 AM5/22/07
to dev-apps-firefox, Johnathan Nightingale, Mike Connor, Mike Beltzner
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

Gervase Markham

unread,
May 22, 2007, 6:58:44 AM5/22/07
to
Alex Faaborg wrote:
> 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

unread,
May 22, 2007, 2:06:28 PM5/22/07
to
Alex Faaborg wrote:

> 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

unread,
May 22, 2007, 2:55:26 PM5/22/07
to
Colin Barrett wrote:

> 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

unread,
May 22, 2007, 4:18:25 PM5/22/07
to
Dan Mills wrote:

> 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

unread,
May 22, 2007, 5:52:28 PM5/22/07
to
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

Alex Faaborg

unread,
May 22, 2007, 7:07:44 PM5/22/07
to Gervase Markham, dev-apps...@lists.mozilla.org

> - 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

unread,
May 22, 2007, 8:20:08 PM5/22/07
to dev-apps-firefox
The page on content handling UI of other browsers raised a few
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

unread,
May 22, 2007, 9:29:49 PM5/22/07
to Clint Talbert, dev-apps-firefox, 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?

-Alex

Clint Talbert

unread,
May 22, 2007, 10:20:05 PM5/22/07
to
Clint Talbert wrote:
> ** 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).
>
Point of clarification here -- I meant to say unsigned/unrecognized
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

unread,
May 23, 2007, 4:51:40 AM5/23/07
to
Alex Faaborg wrote:
> 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

unread,
May 23, 2007, 4:53:20 AM5/23/07
to
Alex Faaborg wrote:
> 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

unread,
May 23, 2007, 2:55:20 PM5/23/07
to
Alex Faaborg wrote:
>
>> - "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

unread,
May 23, 2007, 3:05:02 PM5/23/07
to
Alex Faaborg wrote:
> 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

unread,
May 23, 2007, 4:44:13 PM5/23/07
to Dan Mosedale, dev-apps...@lists.mozilla.org
Yeah, in the current design the unified UI for content handling is
integrated into the preview page in the case of feed handling.
-Alex

Alex Faaborg

unread,
May 23, 2007, 7:09:44 PM5/23/07
to dev-apps-firefox
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.
===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

unread,
May 23, 2007, 7:26:32 PM5/23/07
to
Alex Faaborg wrote:
> 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

unread,
May 23, 2007, 8:36:00 PM5/23/07
to dev-apps-firefox, Colin Barrett, Mike Connor, Mike Beltzner
> 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.

[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

unread,
May 23, 2007, 8:38:19 PM5/23/07
to dev-apps-firefox, Mike Beltzner
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

==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

unread,
May 24, 2007, 1:22:22 AM5/24/07
to
I would really welcome it if you guys do not "overlook" extensions this
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

unread,
May 24, 2007, 3:38:36 AM5/24/07
to
Alex Faaborg wrote:
> 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

unread,
May 24, 2007, 4:32:35 AM5/24/07
to Axel Hecht, dev-apps...@lists.mozilla.org
> Podcast seems to be a very iPod-ish name. Not idea how much it is used
> 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

unread,
May 24, 2007, 5:07:45 AM5/24/07
to dev-apps-firefox
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

On May 24, 2007, at 12:38 AM, Axel Hecht wrote:

Alex Faaborg

unread,
May 24, 2007, 4:24:12 AM5/24/07
to Nils Maier, dev-apps-firefox, Dan Mosedale
> I would really welcome it if you guys do not "overlook" extensions
> 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

unread,
May 24, 2007, 5:30:13 AM5/24/07
to
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.)

>> 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

unread,
May 24, 2007, 5:35:09 AM5/24/07
to
Alex Faaborg wrote:
> 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

unread,
May 24, 2007, 5:35:44 AM5/24/07
to
Alex Faaborg wrote:
> 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

unread,
May 24, 2007, 5:36:50 AM5/24/07
to
Alex Faaborg wrote:
> [starting new thread]

In News, just changing the title doesn't do that. You need to create a
new message.

Gerv

Gervase Markham

unread,
May 24, 2007, 5:45:43 AM5/24/07
to
Alex Faaborg wrote:
> 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

unread,
May 24, 2007, 5:46:16 AM5/24/07
to
Alex Faaborg wrote:
> Here are some mockups of possible changes to Firefox's preferences dialog:

You are far too prolific :-) Comments tomorrow.

Gerv

Simon Bünzli

unread,
May 24, 2007, 6:02:21 AM5/24/07
to
Alex Faaborg schrieb am 24.05.07 11:07:

> 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

unread,
May 24, 2007, 9:43:08 AM5/24/07
to
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).

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

unread,
May 24, 2007, 12:16:46 PM5/24/07
to
Gervase Markham wrote:
> 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

unread,
May 24, 2007, 12:40:58 PM5/24/07
to dev-apps...@lists.mozilla.org
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

Michael Vincent van Rantwijk, MultiZilla

unread,
May 24, 2007, 12:57:04 PM5/24/07
to
Jesper Kristensen wrote:
> 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

unread,
May 24, 2007, 3:00:11 PM5/24/07
to
Alex Faaborg wrote:
> 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

unread,
May 24, 2007, 3:10:35 PM5/24/07
to
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.

> 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

unread,
May 24, 2007, 4:08:01 PM5/24/07
to
Alex Faaborg wrote:
> 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

unread,
May 24, 2007, 4:26:35 PM5/24/07
to
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

Dan Mosedale

unread,
May 24, 2007, 4:47:49 PM5/24/07
to
Jesper Kristensen wrote:
> 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

unread,
May 24, 2007, 5:46:59 PM5/24/07
to
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. 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

unread,
May 24, 2007, 7:38:03 PM5/24/07
to mv_van_...@yahoo.com, dev-apps...@lists.mozilla.org
>> I don't like to use Apple's trademarks in the Firefox UI

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

unread,
May 24, 2007, 7:22:32 PM5/24/07
to dev-apps-firefox

> - 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

unread,
May 24, 2007, 8:06:51 PM5/24/07
to
Deb Richardson wrote:
> * 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

unread,
May 24, 2007, 8:14:42 PM5/24/07
to
Alex Faaborg wrote:
>
>> - 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

unread,
May 24, 2007, 8:21:03 PM5/24/07
to Deb Richardson, dev-apps...@lists.mozilla.org
> * 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?

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

unread,
May 24, 2007, 8:28:59 PM5/24/07
to Dan Mosedale, dev-apps...@lists.mozilla.org
I should add to my list concerns increased mouse distance, along with
"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

unread,
May 24, 2007, 8:37:11 PM5/24/07
to Dan Mosedale, dev-apps...@lists.mozilla.org
> 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.

> * 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

unread,
May 24, 2007, 9:49:57 PM5/24/07
to
Dan Mosedale wrote:
> 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

unread,
May 25, 2007, 1:03:31 AM5/25/07
to
On May 22, 9:29 pm, Alex Faaborg <faab...@mozilla.com> wrote:
> > 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

unread,
May 25, 2007, 6:58:33 AM5/25/07
to Dan Mosedale
Dan Mosedale wrote:
> 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

unread,
May 25, 2007, 7:02:35 AM5/25/07
to
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.

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

unread,
May 25, 2007, 11:51:22 AM5/25/07
to
just some thoughts
* 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

unread,
May 25, 2007, 12:51:38 PM5/25/07
to Gervase Markham, dev-apps...@lists.mozilla.org
> Alex: what do you think?

Yeah, I think a single tab in preferences called "Applications" is a
great idea.
-Alex

Clint Talbert

unread,
May 25, 2007, 3:15:37 PM5/25/07
to
Alex Faaborg wrote:
> 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).
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.

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