Closed Bug 287705 Opened 19 years ago Closed 17 years ago

manage RSS feeds in Camino

Categories

(Camino Graveyard :: General, enhancement)

Product:
Camino Graveyard
Component:
General
Platform:
PowerPC
macOS
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED WONTFIX
Milestone:
Future

People

(Reporter: jaas, Unassigned)

References

Details

(Whiteboard: [read COMMENT 34 before commenting])

Attachments

(1 file)

toolbar icon mockup
11.65 KB, image/jpeg
Details 
I would like to see RSS support in Camino (something like FF live bookmarks?). I
am not sure how I'd like to see it done, so please discuss here.
Severity: normal → enhancement
Status: NEW → ASSIGNED
Target Milestone: --- → Camino1.0
Dupe of 287313?
No - we don't necessarily want live bookmarks.
i would like to see camino detect rss feeds and gracefully pass them to an
external handler.

between mananging refresh times, handling enlosures/podcasts, dealing with
separate prefs for external images/css or plugins/javascript, etc.  I just don't
see how camino can do rss reading well (and no, i don't think firefox does it
well either)

besides, isn't one of the design goals for camino to keep things small?
Sometimes to the point of removing hidden prefs to safe a few bytes, while many
other times just focusing on simple and clean /browser/ UI?

I dunno, from where I sit this would be a dissapointing addition to camino.
I agree with chris that we should do gracefull passtrhough and also detect
wheter a page has rss feed(s).
sorry josh ;)
Target Milestone: Camino1.0 → Camino1.1
Atom! Atom! Atom!

(1.0 and 0.3)
I'm going to agree with Chris and Jasper on this one; we're better off passing
off feeds neatly to NetNewsWire (or whatever people use) than having a
half-baked RSS/Atom/feed-format-du-jour implementation in Camino itself.

Suggested UI:
1. If a page with a feed is detected (by some algorithm) we display a suitable
icon in the status bar, probably in the same area as the popup-blocker icon.

2. The icon acts as a draggable proxy for the feed URL. (Pick the first if the
page exposes multiple feed URLs, e.g. Atom and RSS?)

3. The icon has a pop-up menu that lists the available feeds and provides
options to copy their URL to the pasteboard or open them in your feed reader (by
asking the O/S to open the URL with http: replaced by feed:?)

4. [Possiby - not sure this is obvious enough] : Allow the user to double click
the icon to pass it across to their feed reader.


For the feed detection we can use a similar algorithm to Firefox. However I
think we should only consider feeds mentioned in <link> tags in the HTML, rather
than trying to brute force fetch "/feed.xml" (or whatever the file is) that
Firefox does. We've got the code to process <link> tags following the overhaul
of the favicon code.

Any thoughts on or improvements to this UI suggestion appreciated. cc'ing Jasper
for his UI comments.
I like Bruce's suggestions.  One thing to keep in mind is that some people want
to be able to hide the status bar (bug 159233), so we've been trying to limit
the UI that is *only* accessible via the status bar.  The RSS item might run in
to similar issues as in bug 272171.
I am completely behind passing it off to an external reader. Camino should be
the best browser it can be- I woud leave RSS to other apps.

However, it's a tough question on how to implement RSS auto-detection in the UI.
Safari's implementation isn't quite good, because it would confuse users- Camino
uses that place in the URL bar as a sort of 'extra status' bar, displaying the
lock on HTTPS sites and so on.

Bruce's way (similar to Firefox) is okay, but runs into a similar usability
problem: people like hiding the status bar. Perhaps it could also be part of the
right-click context menu "Available Feeds", and maybe in the View menu grouped
with View Source?

Just a shot in the dark, there. Maybe put it in the Bookmarks menu, that might
make more sense than View.

Only detecting <link> tags is also how I would do it. Trying to 'help' badly
coded sites shouldn't be the goal, here.
By the way; it sould not be called RSS since apps like Safari does even call
Atom-feeds for RSS even Atom is another format than RSS.

What about using the Dock icon? -adding an round, red oval circle with "FEED" in?
(In reply to comment #10)
> By the way; it sould not be called RSS since apps like Safari does even call
> Atom-feeds for RSS even Atom is another format than RSS.
> 
> What about using the Dock icon? -adding an round, red oval circle with "FEED" in?

You're completely right on the RSS-centric phrasing. Calling all feeds RSS is a
stupid thing I'm guilty of more than I'd like. Old habits die hard! "Feeds" is a
much better term.

I would imagine any menu that existed would have "Available Feeds" and then
"Feed Name - Format" or something. Users could be confused by the different
types, but that's a problem with syndication, and not something we can change
singlehandedly.

Dock icon isn't a bad idea, but I know I for one rarely look down at the dock
(auto-hide exists for a reason). Perhaps a combination of a few of these would
maximize the visibility (and usability) of this feature.

This is a BIG deal for me with Camino. I've been using nightlies for a month or
so, and the lack of feed handling is easily my biggest gripe. I'd say that's a
good thing, in a way : )
(In reply to comment #11)
> (In reply to comment #10)
> > By the way; it sould not be called RSS since apps like Safari does even call
> > Atom-feeds for RSS even Atom is another format than RSS.
> > 
> > What about using the Dock icon? -adding an round, red oval circle with
"FEED" in?
> 
> You're completely right on the RSS-centric phrasing. Calling all feeds RSS is a
> stupid thing I'm guilty of more than I'd like. Old habits die hard! "Feeds" is a
> much better term.
> 
> I would imagine any menu that existed would have "Available Feeds" and then
> "Feed Name - Format" or something. Users could be confused by the different
> types, but that's a problem with syndication, and not something we can change
> singlehandedly.
> 
> Dock icon isn't a bad idea, but I know I for one rarely look down at the dock
> (auto-hide exists for a reason). Perhaps a combination of a few of these would
> maximize the visibility (and usability) of this feature.
> 
> This is a BIG deal for me with Camino. I've been using nightlies for a month or
> so, and the lack of feed handling is easily my biggest gripe. I'd say that's a
> good thing, in a way : )

What about having the icon jump? A red, jumping icon is hard to miss! ;)
> What about having the icon jump? A red, jumping icon is hard to miss! ;)

I will assume you're joking, and say this: Ouch.

Naturally, having the dock icon bounce every time you visit a website would most
likely cause hundreds of geeks to commit suicide, so at least it would thin out
the workforce.
(In reply to comment #13)
> > What about having the icon jump? A red, jumping icon is hard to miss! ;)
> 
> I will assume you're joking, and say this: Ouch.
> 
> Naturally, having the dock icon bounce every time you visit a website would most
> likely cause hundreds of geeks to commit suicide, so at least it would thin out
> the workforce.

I agree with Christian that this is a big deal. I've been using the nightlies
for only about two weeks or so, after having become hopeless that Safari RSS
will become a stable entity (several sites I visit often starting crashing the
bejeezus out of it after the most recent "upgrade"). 
I LOVE Camino, but darn it, if an orange "XMLfeed" label appeared in the address
bar (a la Safari RSS), the only other thing I'd want would be the ability to
save directly to PDF. Can't think of anything else I'd want from a browser.
Today, anyway.

Personally I can't understand this dislike of the status bar, but we do need a
second place to get to the functionality.

The context menu may be the right place for it (just after "Bookmark this
page..."), but we'll also need a spot for it in the main menus (as with any
context menu item). Either the View or Go (but please lets rename this... "Page"
or something) menus would be suitable locations.

I agree that we need to provide a sub-menu for pages that expose multiple feeds.
If the <link> element provides a title I think we should just display that, and
not confuse the user with feed types. If there are no title tags then we need to
try to translate the type attribute into something human readable, which could
be a challenge. For pages that only expose a single feed it would be nice to do
away with the submenu, and just provide allow the user to select the Subscribe
option. However I'm not sure if this is supported or recommended by the HIG.

I don't think the URL field can take any more visual clutter. Imagine a secure
page with a feed - there would be three icons in quite a small space. Neither do
I think badging the dock icon is particularly good. Badging the dock icon is
good if you need to draw attention to your application ("new mail needs reading,
new articles available" etc.) But just because a feed is available on the page
you are reading doesn't require you to suddenly pay more attention to Camino (or
to click on its dock icon if they're doing something else). As for bouncing dock
icons: the less said the better!

We should probably check at startup whether an application is registered for
handling feeds, and if not just disable the menu items whether or not a feed is
detected in the page.

This still means that the status bar is the only way of discovering this feature
that doesn't require the user to do something. The only other option I can think
of for keeping it discoverable is to have a "subscribe" toolbar button (not in
the default set though). This could neatly act like the back and forward toolbar
buttons (single click = subscribe to first available feed, press and hold = drop
down list of available feeds). Whether the button was enabled or not would
indicate whether a feed is available. [Jasper: any thought s on this, or what
the icon could be?]
I think that putting a "feed/rss" icon in either the status bar or the url field
would clutter our UI in gerenral. But if I had to choose, I would go for the
toolbar. Why? Well because I think that the context of the url bar and thus the
url is the correct place for indicating that that url/webpage has feeds
available. Just that simple. But. I do agree that in combination with the
security icon it gets a bit crowded.

So my idea was also to create a special toolbar item with the functionality
descibed by Burce, we could even think of a badge that on the feed/rss icon that
would indicate how many feeds are available!

But the difference between creating a new toolbar item or adding a "small" icon
to the url bar is so small considering UI clutter I'm not sure what's best :D
I guess my problem with a toolbar item is what to do with sites without feeds? I
would imagine the icon wouldn't be used a whole lot, and it's a big deal to add
to the UI up there.

Maybe make the Bookmarks icon into a hybrid? With the functionality Jasper
outlined, perhaps the bookmarks icon would have a little number on it with the
RSS icon to indicate if there were feeds, then clicking on it would give you the
context menu described earlier.

This could be the solution to both issues, or at least come close. What do you
guys think? A small RSS/Number Icon on the Bookmarks Icon, clicking and holding
gives you the context menu, just like the Back/Forward buttons, and clicking
normally just takes you to your bookmarks, like normal.
Remember that the toolbar also can be hidden, so putting things there really
isn't any better than using the statusbar :-(
Yes, the tooblar can be hidden.

No, the status bar can't be, but that may change.

But I don't think either of those issues matter -- and I think we're getting
ahead of ourselves.

There are a pile of different schenarios to take into account, we don't know
what casses the auto-detection code is going to pick up or ignore, and there are
other scenarios that aren't detectable ahead of time (like a clicked link with
the proper headers). So why are we going back and forth about UI that will
probably be hideable no matter where it show up ("NO! IT SHOULD BE A POPUP!"),
and need a menu item of some if access is deemed always needed. (which I don't
think is really clear either)

What are we dealing with here?

* User may not have a reader or use feeds, but page has feeds
* Site may not have any feeds, but user is looking for them
* Site is determined to have feeds, but user has aready subscribed, in a
different app
* User clicks on a feed link in a page, triggers a download due to an unhandled
(but specific) object type
* User brings up a context menu on a link that is clearly distinqushable (to the
eye) as a link

We need to take into account the above (and realize there are some scenarios
like text feed vs. podcast which we can't hope to handle well), and come up with
all the pieces needed to get this functionality to run smoothly and be
discoverable by someone just trying this "RSS" thing. And while I lean towards a
status icon personally*, I'm up for whatever is determined to fit the overall
solution the best.

* as someone who uses feeds heavily (175ish in NNW), but doesn't add new ones
often anymore it would fit /my/ usage pattern best
I don't think we've been getting ahead of ourselves at all here- we're just
trying to find the solution to a couple of the problems you just outlined, as
opposed to -all- of them.

If the user is already subscribed and clicks on the feed link, passing it off to
another app (at least NNW does this, and it would be expected behavior, I should
think) the app of choice would simply focus to that feed. Trying to integrate
every feed reader out there's data with Camino would be a pandora's box sort of
thing, I think.

And the proposed solution takes into account the fact that the toolbar can be
hidden. If the toolbar and status bars are both hidden, there really isn't any
way for a user to be visually told there are feeds available. However,
right-cick context menu would give them the available feeds, as per
https://bugzilla.mozilla.org/show_bug.cgi?id=287705#c9
Attached image toolbar icon mockup — 
This is what I had in mind for the Feed toolbar icon.
(In reply to comment #21)
> Created an attachment (id=196795) [edit]
> toolbar icon mockup
> 
> This is what I had in mind for the Feed toolbar icon.

This is a good idea but the problem is : what happen when no feeds are
discovered ? You have a unused button in your toolbar, which isn't very user
friendly. And displaying new button in the toolbar just when it's need isn't a
standard behavior either.

People are already used to look in the URL bar for SLL or favicon. The best way
would be just like Safari RSS to include a symbol inside the URL-bar. (having a
SLL and a FEED symbol isn't a big deal since this won't occur very often)
Clicking on the Feed symbol will either display a context menu when several
feeds are discoverd, or just pass the feed url via feed:// to a 3rd party
software when only one feed is discovered.

Of course, having the RSS symbol in the status bar isn't a good solution either,
since the user may want to hide it (personnaly, I think the status bar is
useless, or at least, it should only be displayed when the page is loading) but
this has already been sayed ;-)
(In reply to comment #22)
> (In reply to comment #21)
> > Created an attachment (id=196795) [edit] [edit]
> > toolbar icon mockup
> > 
> > This is what I had in mind for the Feed toolbar icon.
> 
> This is a good idea but the problem is : what happen when no feeds are
> discovered ? You have a unused button in your toolbar, which isn't very user
> friendly. And displaying new button in the toolbar just when it's need isn't a
> standard behavior either.
> 
> People are already used to look in the URL bar for SLL or favicon. The best way
> would be just like Safari RSS to include a symbol inside the URL-bar. (having a
> SLL and a FEED symbol isn't a big deal since this won't occur very often)
> Clicking on the Feed symbol will either display a context menu when several
> feeds are discoverd, or just pass the feed url via feed:// to a 3rd party
> software when only one feed is discovered.
> 
> Of course, having the RSS symbol in the status bar isn't a good solution either,
> since the user may want to hide it (personnaly, I think the status bar is
> useless, or at least, it should only be displayed when the page is loading) but
> this has already been sayed ;-)

I really think that it should say FEED and not just RSS. Having it say FEED whould support other 
formats and don't favorite anyone over the other. Personaly I prerfear Atom, but I don't want the 
icon/button/thing to say that either.

What about having the button apear between the adressbar and the searchfield?
I think the toolbar is the right place for this button. Unlike the secure icon
its not a purely informational icon, it requires action to do something useful
(i.e. to subscribe to the feed). The right place for this sort of button is the
toolbar, its quite normal to have toolbar buttons that are disabled when their
action isn't possible.

Having it as a toolbar button will allow users to put it wherever they like
(e.g. between the URL and search fields as per comment 23), including hiding it
altogether if they don't use a feed reader.

I agree that we should use the generic term "feed", although we may end up
displaying "RSS" etc. in the title where there are multiple feeds; that's up to
the markup in the page.
*** Bug 310376 has been marked as a duplicate of this bug. ***
Safari's approach to feeds via the icon in the URL bar works because there is no
next action for a user. They click that button, Safari's subscribes to the feed
and displays the feed items all in one swoop. 

Safari also assumes I'm interested in the feeds thing to begin with. If I decide
"I just don't dig this feed thing" the RSS icon is taking a promiment, albiet
small, portion of real-estate.

It would be nice if Camino offered the flexibility of turning any feed discovery
off altogether via the preferences. I suppose as of today it would go under the
Web Features "tab" in the prefs.

[ ] Discover Syndication Feeds

----

I like Jasper's icon and I think it is probably a more usable approach
considering it is far more logical to have a menu appear after clicking on a
toolbar item than to see one coming from your URL bar. This also has the benefit
of making it an optional item, since you could drag it in and out of the toolbar
via the customize functionality. That would probably elimnate any need for a
preference option to enable/disable feed discovery.

Personally, Safari took feed reading too far as I don't think there is (or will
be) an overwhelming public interest in doing it. (Don't get me wrong, feeds are
great... I am using them in lots of different ways.)
Using the toolbar just to notify of feed discovery is to misuse and destroy one
of the interface paradigms, those we are working so hard to live up to already.
The only widget we already have that is comparable to the proposed one is the
pop-up blocker icon, which can be clicked. I'm not saying we should put the RSS
label there, though.

I'd like it to go in the location bar, like Safari's. If we then make the
padlock open info about the security of a site when clicked, we keep consistency.
Taking
Assignee: joshmoz → nick.kreeger
Status: ASSIGNED → NEW
*** Bug 315674 has been marked as a duplicate of this bug. ***
With the recent release of iLife '06, perhaps we should think about better ways to pass off different types of feeds. For example, give the user the option to "Subscribe to a PhotoCast with iPhoto", "Subscribe to Podcast with iTunes", "Subscribe to feed with <insert feed reader here>", or "View with Camino." I see no reason why Camino couldn't have a built-in CSS stylesheet for RSS and Atom that would be simple and elegant, and yet allow for reading (and bookmarking) the feed in Camino. Otherwise, the default user action would be "View Feed with Safari" and would push users away from Camino instead of to it.
(In reply to comment #30)
> With the recent release of iLife '06, perhaps we should think about better ways
> to pass off different types of feeds. For example, give the user the option to
> "Subscribe to a PhotoCast with iPhoto", "Subscribe to Podcast with iTunes",
> "Subscribe to feed with <insert feed reader here>", or "View with Camino." I
> see no reason why Camino couldn't have a built-in CSS stylesheet for RSS and
> Atom that would be simple and elegant, and yet allow for reading (and
> bookmarking) the feed in Camino. Otherwise, the default user action would be
> "View Feed with Safari" and would push users away from Camino instead of to it.
> 

Not everyone has iLife '06. We don't want to add these additional features since a majority of our users will not have '06. I personally don't even use the iLife suite. 

Also this is not the place to discuss the full implementation of RSS, we are only sniffing out the feeds and passsing them off to the users chosen RSS app.
(In reply to comment #31)
> (In reply to comment #30)
> > With the recent release of iLife '06, perhaps we should think about better ways
> > to pass off different types of feeds. For example, give the user the option to
> > "Subscribe to a PhotoCast with iPhoto", "Subscribe to Podcast with iTunes",
> > "Subscribe to feed with <insert feed reader here>", or "View with Camino." I
> > see no reason why Camino couldn't have a built-in CSS stylesheet for RSS and
> > Atom that would be simple and elegant, and yet allow for reading (and
> > bookmarking) the feed in Camino. Otherwise, the default user action would be
> > "View Feed with Safari" and would push users away from Camino instead of to it.
> > 
> 
> Not everyone has iLife '06. We don't want to add these additional features
> since a majority of our users will not have '06. I personally don't even use
> the iLife suite. 
> 
> Also this is not the place to discuss the full implementation of RSS, we are
> only sniffing out the feeds and passsing them off to the users chosen RSS app.
> 


I feel that being able to read RSS feeds in Firefox for Mac is one of the most useful features. I strongly encourage the inclusion of the ability to read RSS feeds in Camino, not just detect the feeds. It remains the single factor that holds me back from making Camino my default browser. I rely on the ability to read multiple RSS headlines and click on them for further info in Firefox (by the way I much prefer Firefox's rendition of the RSS experience over the Safari approach). Simply put it is a matter of time and convenience for the user. Please take this as a strong vote for inclusion of the RSS experience in Camino.
Sorry I thought this was bug 316232, my applogies. 
Please note: This is a bug, not a forum. If you have comments you wish to make, please make them in a forum post on mozillaZine. If you only wish to voice your desire for this feature, vote for it, don't comment.

This bug is for those discussing which way would be best to implement this. It's a bug that hasn't been WONTFIXed, which means it's still on the table for potentially doing.
Whiteboard: [read COMMENT 34 before commenting]
*** Bug 331724 has been marked as a duplicate of this bug. ***
As for clicking on RSS links, please see 333751 and 325081 for information on how this is being done in Firefox. We have a content sniffer to detect feeds from misconfigured servers, and are able to show in-page data instead of raw XML or garbage. You may like to copy some of the code there and build your own UI.

Also, Robert Sayre is working on a generic feed parsing component in 325080, you should try and use that. We're going to convert live bookmarks over to use it, and Scott will make tbird use it. It will handle all feed formats. This component is a js component and is not Firefox or XUL specific.
Assignee: nick.kreeger → nobody
QA Contact: general
Target Milestone: Camino1.1 → Future
*** Bug 348826 has been marked as a duplicate of this bug. ***
WONTFIX. Discussed at the meet-up by the development team.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WONTFIX
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: