UI: Feed Preview+Subscribe Screenshots
Ben Goodger
http://www.bengoodger.com/software/mb/feeds/feeds5.png
Reader selected:
http://www.bengoodger.com/software/mb/feeds/feeds4.png
Some notes:
- If "Open feeds with my chosen reader automatically, skipping the
preview page" is checked, clicking feed links takes you directly to the
reader.
- If this setting is chosen, holding down Shift+Alt while clicking on
the link shows the preview page anyway (key combo is the first that came
to mind).
This stuff is visible trunk and branch, add --enable-feeds to your
.mozconfig and use this page:
http://www.bengoodger.com/software/mb/feeds/test-registercontenthandler.html
to register web content handlers.
-Ben
Mark Pilgrim
> No reader selected (e.g. first run, or never subscribed):
>
> http://www.bengoodger.com/software/mb/feeds/feeds5.png
Some sites (notably on feedburner.com) put a reference to an XSL file
in their feeds that displays a similar (but site-specific) page. What
will Firefox do in this case? Will it override the site's defined XSL
and always display this generic page?
--
Cheers,
-Mark
Ben Goodger
Yes.
-Ben
Ben Goodger
Yes.
-Ben
Mike Beltzner
> .mozconfig and use this page:
And to think, I was gonna review the wiki stuff this evening. Heh.
This is great (and fast!) work, Ben. Some notes based on the
screencaps, more to come when I get the build up and running (/me
kicks his G4 a couple of times in the CPU):
* I've previously mentioned my assetion of there being the three
primary yet different usage styles for RSS (in short, 1. "I want to
see the most recent stuff, but don't mind missing posts", 2. "have to
read every post!", and 3. "it's just a transport mechanism for my
{video player|audio player|whatever}"). It has always seemed to me
that Live Bookmarks are geared towards use case 1, and external
applications (or extensions) are geared towards use cases 2 and 3.
These use cases seem distinct enough to me to deserve equal billing in
the subscription UI; I was wondering if it might not be sensible to do
something like:
[.))] Subscribe to this feed now using [$lastUsed; |v]
where &lastUsed; is the last used handler, either "Live Bookmark" or
the most recently used feed handler. The drop-down menu would contain
the other handlers (with Live Bookmark always being the second option
if it wasn't the last used option) as well as an "Other ..." option
which launches the modal dialog as you have it but without the "Live
Bookmarks" option.
This makes it easy to quickly pick the type of feed handling you want
for the podcast/photocast/blog/whatever it is that you've landed on.
Also, the "first feed" experience could end up having the exact same
functional widgetry, just with the introductory text about what a feed
is (which I think is great)
The function of skipping the preview sounds like the sort of thing
that should be in the application preferences (under "Content",
perhaps) and again with options for what the default handler using the
same sort of drop-down.
* should the subscribe action be a link or a button? a link implies
that the content will refresh, which makes sense, since I'm assuming
that once subscribed the page will be redirected to browser.back()?
* where are the large logos coming from? can that be specified in the
Atom/RSS? if it isn't, can we just use the favicon?
* will this preview page be the default location of clicks on a live
bookmark root?
cheers,
mike
--
/ mike beltzner / user experience lead / mozilla corporation /
Mike Beltzner
> Some sites (notably on feedburner.com) put a reference to an XSL file
> in their feeds that displays a similar (but site-specific) page. What
> will Firefox do in this case? Will it override the site's defined XSL
> and always display this generic page?
Does the parser not let us detect when we're being served XSLT'd XML
content? If so, I would expect that our default action would be to
render the XLST'd presentation but with the options to subscribe up at
the top.
Also, ben, have you looked into this:
http://www.kbcafe.com/rss/whatisthis.html#whatisusm
If you have, please forgive my ignorance ... I've been catching up
from CHI and am having a hard time remembering what I have seen vs.
imagined ;)
Mark Pilgrim
I would classify that as a bug. Microsoft made the same oversight in
IE7 beta 1 (don't know if they've fixed it yet in b2).
http://blogs.msdn.com/ie/archive/2005/08/02/446280.aspx
http://blogs.msdn.com/rssteam/archive/2005/08/02/446882.aspx
--
Cheers,
-Mark
Robert Sayre
>
> Does the parser not let us detect when we're being served XSLT'd XML
> content?
That would be very straightforward to enable, since the SAX interface
has a separate callback for processing instructions.
I disagree with markp, though. I don't think it's a bug. Is IE going to
honor the XSLT? I see some complaints, but there's no reason to believe
those comments represent our users.
-Rob
Mark Pilgrim
> I disagree with markp, though. I don't think it's a bug. Is IE going to
> honor the XSLT? I see some complaints, but there's no reason to believe
> those comments represent our users.
I just sacrified a goat and installed IE7 beta 2, and it still does
not respect custom XSLT in a feed.
Test cases:
http://diveintomark.org/public/2006/04/styled.xml
http://diveintomark.org/public/2006/04/unstyled.xml
I would still classify this as a bug (in both browsers), but since we
seem to be striving to repeat all of Microsoft's mistakes w.r.t. feed
handling, I suppose there's no point in discussing it further.
--
Cheers,
-Mark
Mike Beltzner
> I would still classify this as a bug (in both browsers), but since we
> seem to be striving to repeat all of Microsoft's mistakes w.r.t. feed
> handling, I suppose there's no point in discussing it further.
Out of curiousity ..:
1. Which other mistakes are we copying? The whole idea of in-browser preview?
2. Would my suggestion of rendering the styled content but injecting
the subscription UI at the top satisfy your particular itch?
Mark Pilgrim
> 1. Which other mistakes are we copying? The whole idea of in-browser preview?
The mistakes I was referring to aren't really UI-related. When IE7b1
came out, there was lots of discussion about their feed recognition
capabilities (including all combinations of MIME type, RSS version,
and content sniffing).
http://weblog.philringnalda.com/2006/02/01/nice-gorilla-whats-he-weigh#comments
Various Microsoft developers have commented on their algorithms.
http://blogs.msdn.com/rssteam/articles/PublishersGuide.aspx
http://72.14.203.104/search?q=cache:bl3pMZzMoYgJ:www.netcrucible.com/blog/CommentView,guid,4750f57c-1c98-4cb1-a0ce-e2f3318bcf8c.aspx
Their algorithms are stupid in several ways (not the least of which is
that they're doing content sniffing at all, but I realize that ship
has already sailed). They don't respect the Content-type or charset
parameter in the HTTP headers when determining a feed's character
encoding, so they get the encoding wrong a fair percentage of the
time. They don't recognize Content-type: application/rdf+xml (common
for RSS 1.0 feeds). They may not sniff your feed at all, depending on
the character encoding -- which, as I mentioned, they may get wrong.
If they do sniff, they'll miss feeds with namespaced root elements
(unless they're RSS 1.0, which they'll miss unless they're using a
generic Content-type). They recommend the (soon to be deprecated)
text/xml Content-type type for RSS feeds, which will only exacerbate
their other bugs related to encoding and sniffing.
Ben has publicly stated that (at least for content sniffing part)
we're striving to copy Microsoft's flawed algorithm. (
http://weblogs.mozillazine.org/ben/archives/010116.html ) Discussion
is ongoing to determine exactly how well we're copying their other
mistakes. Short answer: not so well so far, though honestly their
mistakes are so blatant that that might end up being a good thing.
--
Cheers,
-Mark
Robert Sayre
>
> Ben has publicly stated that (at least for content sniffing part)
> we're striving to copy Microsoft's flawed algorithm. (
> http://weblogs.mozillazine.org/ben/archives/010116.html ) Discussion
> is ongoing to determine exactly how well we're copying their other
> mistakes. Short answer: not so well so far, though honestly their
> mistakes are so blatant that that might end up being a good thing.
I see a lot of heat here, but I'm not sure what your point is. Are there
specific IE behaviors you're concerned about?
confused,
Rob
Mark Pilgrim
> I see a lot of heat here, but I'm not sure what your point is. Are there
> specific IE behaviors you're concerned about?
Those would be all the specific behaviors I detailed very clearly in
that big paragraph you cut.
--
Cheers,
-Mark
Robert Sayre
OK, thanks... but as I said, I wasn't sure what your point was. Maybe
the tone could be a little nicer? I thought you were referencing other,
unmentioned problems.
In any case, the latest parser patch listens for xml-stylesheet PIs, and
I added your test case. It only grabs the href attribute, and
interpretes that URI relative to the feed URI. It might be useful to
grab some of the other attributes. Probably the type attribute would be
handy to differentiate text/xsl and text/css.
-Rob
Ben Goodger
> Also, ben, have you looked into this:
>
> http://www.kbcafe.com/rss/whatisthis.html#whatisusm
I just read that. I think we're effectively implementing something
similar, except that our system is better: we don't require bloggers
reconfigure their server. Usually, I'd say "making the blogger
reconfigure the server is better, since it doesn't undermine the HTTP
spec" but since many folk don't have the ability to set the content-type
of their feed files since they don't manage the server, and EOMB
breezes through this by content sniffing, I'm less comfortable saying that.
As for XSLT stylesheets, I'd say that I agree that's a bug, but a nice
to have not a blocker. The reason is that sites have begun providing
XSLT stylesheets because of the limitations of the user agent.
-Ben
Mike Beltzner
> On 4/28/06, Ben Goodger <bengo...@gmail.com> wrote:
> screencaps, more to come when I get the build up and running (/me
> kicks his G4 a couple of times in the CPU):
Ben, Joe Hughes, Mike Connor and I got together this week and chatted
about the design and changes that were within scope for the short
term. Here's what we came up with, using beautiful ASCII art!
1. Preferences Panel (to be placed anywhere now, figure out best
location for it later).
- Feeds ---------------------------------------------------
When I click on a web feed,
( ) always subscribe with a Live Bookmark.
( ) always subscribe using the Feed Reader.
(o) ask me what to use.
Feed Reader [ %systemDefaultIfAny |v]
|-------------------------------|
| %availableReaders | |
| Other Program ... | |
'-------------------------------'
* feed reader section is disabled if the Live Bookmark option is checked
* web based and client based readers should be in the same list
* Other Program ... leads to a dialog that lets the user pick a client
app if we haven't been able to detect it using the OS level file
associations
2. Preview Subscription UI
| |
| [Subscribe] to this feed using [%lastUsedOption |v] |
| |
| [ ] Always use %lastUsedOption to subscribe to feeds |
'--------------------------------------------------------'
* %lastUsedOption is either "a Live Bookmark" or the name of the feed reader
* the drop down should also have an "Other Program ..." option that
works as in prefs
3. Confirmation dialog for adding a web based feed reader
.------------------------------------------------.
| .-----. |
| |~~~~,| Add %s as a feed reader? |
| |~~, )| |
| |O ) )| [ ] Make this my default feed reader |
| '-----' |
| [ No ] [ Yes ] |
'------------------------------------------------'
4. Holding down Accel when clicking on a link that leads to a feed (as
detected by the sniffer or when using the feed:// protocol) will force
the preview UI to load in a new tab (which will be given focus) even
if the "always subscribe" option is set.
5. Holding down Accel when clicking on the feed icon in the location
bar will change the verb from "Subscribe" to "View" and will load the
preview UI in a new tab (which will be given focus).
Mike Beltzner
> Ben, Joe Hughes, Mike Connor and I got together this week and chatted
Oh, duh, FTR, Brian Rakowski was there, too. :)
Adam Kowalczyk
probably missed it somehow.
As feed preview in the content is already implemented, could this form
of presenting a feed be exposed all the time, not only at subscribing?
Perhaps as an option at the bottom of the Live Bookmark folder?
In many ways, it's a much more convenient way of viewing feeds than Live
Bookmarks. I guess I don't need to elaborate on that since it's the way
every feed reader out there works. This single feature would make for a
huge improvement in Firefox's feed reading functionality. And it's
practically already in place!
-Adam
Mike Beltzner
> As feed preview in the content is already implemented, could this form
> of presenting a feed be exposed all the time, not only at subscribing?
> Perhaps as an option at the bottom of the Live Bookmark folder?
After the first time, if the user hasn't selected "Always ask me ..."
then they'll always get the content view. So it's basically the
default behaviour, and anytime they view a feed, they'd be able to
subscribe.
cheers,
mike
Adam Kowalczyk
> On 5/6/06, Adam Kowalczyk <ance...@o2.pl> wrote:
>> As feed preview in the content is already implemented, could this form
>> of presenting a feed be exposed all the time, not only at subscribing?
>> Perhaps as an option at the bottom of the Live Bookmark folder?
>
> After the first time, if the user hasn't selected "Always ask me ..."
> then they'll always get the content view. So it's basically the
> default behaviour, and anytime they view a feed, they'd be able to
> subscribe.
Well, it's a little late to be saying that but you probably
misunderstood me. Sorry if I was unclear.
What I meant is that content area preview should be available AFTER
subscribing, as an additional way of reading a feed, apart from Live
Bookmarks. It's hell of a lot easier to read feeds nicely styled in a
form of a webpage, than to read titles from a menupopup. It's the way
most other browsers are going.
Flock made the it their primary way of presenting feeds and they have it
nicely integrated with Live Bookmarks. If you click on a Live Bookmark,
the feed is presented in the content area. The Live Bookmarks still have
a dropdown arrow which you can click to see the feed in the ol' bookmark
folder-ish way.
- Adam
beltzner
>
> | |
> | [Subscribe] to this feed using [%lastUsedOption |v] |
> | |
> | [ ] Always use %lastUsedOption to subscribe to feeds |
> '--------------------------------------------------------'
>
> * %lastUsedOption is either "a Live Bookmark" or the name of the feed
> reader
> * the drop down should also have an "Other Program ..." option that
> works as in prefs
Feedback from a usability study at Google indicates that (1) the first
time users encountered this UI, they didn't realize that after picking
a feed reader they would need to click a button again, and (2) users
are thrown by the "Subscribe" button due to it being at the start of
the phrase as opposed to being at the end of it.
To solve both of these problems, I suggest that after the user has
selected a feed reader, we change the UI to something that looks a lot
different with a large, obvious button that indicates the action that
the user will want to take.
| |
| Subscribe to this feed using [%lastUsedOption |v] |
| |
| [ ] Always use %lastUsedOption to subscribe to feeds |
| |
| ( Subscribe Now ) |
'----------------------------------------------------------'
Ben, do you want me to file bugs to track these UI suggestions?
cheers,
mike
--
/ mike beltzner / phenomenologist / mozilla corporation /
Peter Lairo
> It's hell of a lot easier to read feeds nicely styled in a
> form of a webpage, than to read titles from a menupopup.
+1
--
Regards,
Peter Lairo
The browser you can trust: www.GetFirefox.com
Reclaim Your Inbox: www.GetThunderbird.com
Jesper Kristensen
When i first saw the current UI in the alpha, i thought i subscribed to
the feed by selecting a reader, and it surprised me, when i found out
that i had not. I think you should have a default reader selected from
the beginning. Firefox should work out of the box.
Also, Firefox do not show a meaningful message, when a default reader is
selected. A user may not know what a feed is, he selects a default
reader to find out, and decides not to subscribe. When he later visits
another feed and had forgotten, what a feed is, he is not told.
Based on my experience with subscription in the new UI, an earlier post
from Mike Beltzner and inspiration from GreaseMonkey, i have made a
suggestion:
- use a yellow browsermessage bar, like when a popup is blocked or
when installing Greasemonkey scripts (i think it brings more consistency
into the app, and it allows website stylesheets)
- Select the reader from a dropdown box WHEN subscribing, not before
subscribing
- Fix Bookmark this page (Crtl+D) to add a Live Bookmark?
About website style sheets:
There has been a long discussion in this newsgroup about consistent ui
and stylesheets. When i discuss with other people about if the website
should be able to use target="_blank" or to decide size and toolbars of
a popup window, it always end up in dead discussions like the one in
this newsgroup. I - as the end user - want to be in control of how the
browser is doing things, and likewise here, i would like consistent UI.
In my experience, non-technical users almost always prefer, that the
website decide. Therefore my opinion is to allow website styles, but
make it possible to turn it off for power users.
Just my opinion - sorry for my bad English.
--
Jesper Kristensen
Besøg www.MozillaDanmark.dk - Mozilla på dansk!