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.

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

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

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

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

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

*** Bug 348826 has been marked as a duplicate of this bug. ***

WONTFIX. Discussed at the meet-up by the development team.