Closed Bug 578967 Opened 14 years ago Closed 14 years ago

Remove feed/RSS button from top-level GUI for Firefox 4 (move to bookmarks menu)

Categories

(Firefox :: Address Bar, defect)

Product:
Firefox
Component:
Address Bar
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Firefox 4.0b7
Tracking Flags:
Tracking Status
blocking2.0 --- -

People

(Reporter: fryn, Assigned: fryn)

References

Details

(Whiteboard: SEE COMMENT 122 AND COMMENT 147 BEFORE COMMENTING!)

Attachments

(2 files, 4 obsolete files)

patch v1 for mozmill (removes ref to feed-button in testToolbarAPI)
1.05 KB, patch
whimboo
: review+
Details | Diff | Splinter Review
patch v1 mini 2g [r+a=dolske,ui-r=faaborg] (un-bitrotted; adds 'Subscribe to this page...' to bookmarks menu button menu)
16.76 KB, patch
Dolske
: review+
Dolske
: approval2.0+
Details | Diff | Splinter Review 
      No description provided.
Some month ago I remove the feed button using userChrome.css. That's really a pain to search the feed if there is no visual indication that there is a feed and you can just click the button to be redirected to it.Of course there is "Subscribe to this Page" in the Bookmarks menu, but that's one vs. two click(s) again.. Also you could land on a site which looks interesting and when seeing the feed button you might want to subscribe to it. IMO always having to look into the bookmarks menu wether the subscribe item is enabled or not is not really convenient.
(In reply to comment #1)
Of course there is
> "Subscribe to this Page" in the Bookmarks menu

UX team already required us to remove that entry from bookmarks menu multiple times during menus cleanup, the fact we still did not do that does not mean is not planned. Indeed if you check the duplicated bookmarks menu in the button it has gone there.
(In reply to comment #2)
> UX team already required us to remove that entry from bookmarks menu multiple
> times during menus cleanup, the fact we still did not do that does not mean is
> not planned.

It will be needed for keyboard access, won't it? That said, even if the item stays I agree with Michael that it doesn't really replace the button adequately -- even more so where the menu bar is off by default.
Have there been any replacement UI indicators for when a page has a feed that have been proposed? You might as well remove feed support entirely if there isn't ~some~ obvious indication of the existence of a feed.

For reference, this bug comes from bug 578025 and bug 578929.

Frank, for the benefit of the discussion in a bug, it would help if you at least posted bug numbers and/or links to previous discussion. An empty orphan bug for a significant GUI change makes Chompy sad. :(
Blocks: 578025
As Comparison:
MSIE 8, Opera 10.6 & Safari have a Feed Icon at the same Position in the Location Bar.
For Chrome there's an open Issue tracked per http://code.google.com/p/chromium/issues/detail?id=21421.
Why should this be changed if everyone else followed us? Rather the Mockups should be adjusted - at least to show a "RSS Feed available" state, no?
(In reply to comment #4)
> Have there been any replacement UI indicators for when a page has a feed that
> have been proposed?

Yes, the current direction is to put it in the new unified menu when the links are present in a page.

The reason is that RSS as a user-facing feature isn't really used much, and pretty much all sites that want you to subscribe to their feed will have dedicated icons/links on their website to do this.

Having it as a top-level UI element (especially when it isn't clear what it's really for) doesn't make a lot of sense. We see people clicking it errroneously — and even when they click it on purpose, they don't understand what it does, and it becomes one of those buttons they just "stay away from".

I use the button myself as a convenient shortcut (just so you don't think I'm any kind of RSS hater ;), but it's hard to justify the prominent placement it currently has. Pretty much every site out there has RSS feeds these days, and it's not really a button you want to click all the time — it's very much a setup action. People tend to have a core set of RSS feeds, and don't change them much after the initial discovery phase.

As another example, if you think about how microformats should work if they were supported in the core of Firefox, you wouldn't want every single site to advertise a hCard, hEvent or similar — you'd want to seek those out when needed, but not have them pop up in the UI every time a site had them defined. 

Furthermore, I did have some insight into Google Reader back in the day when I worked at Google, and you'd be surprised at how few people add feeds through the RSS buttons/links as opposed to searching for the site to add from within Reader. I obviously can't share specifics, sorry about that. :)

More background info:
http://www.micropersuasion.com/2008/10/rss-adoption-at.html
http://www.readwriteweb.com/archives/rss_reader_market_in_disarray.php
You have a compelling argument, the problem is that while this move would simplify the UI for the lowest common denominator (which is frequently a good thing) it would drastically reduce discoverability for feeds support. I could personally live without the icon, though there are plenty of pages you wouldn't think to have RSS (ex: some AMO pages) that do and wouldn't be discoverable anymore. I'm also worried that once it's gone that effectively marks the end for any possible new adoption.

(In reply to comment #6)
> (In reply to comment #4)
> > Have there been any replacement UI indicators for when a page has a feed that
> > have been proposed?
> 
> Yes, the current direction is to put it in the new unified menu when the links
> are present in a page.

Wouldn't having it in the bookmarks menu make more sense? It is basically a type of bookmark, after all.

Is a (non-GUI) pref a possibility here or is the idea to relegate any desire for a button to addon-land?
Blocks: 578964
(In reply to comment #7)
> Wouldn't having it in the bookmarks menu make more sense? It is basically a
> type of bookmark, after all.

It is already in the bookmarks menu for the old-style menus and on OS X.
I am not sure what is going in the bookmarks toolbar button's menu.
 
> Is a (non-GUI) pref a possibility here or is the idea to relegate any desire
> for a button to addon-land?

Once this lands, there will be an add-on to add this back in. ;)
Depends on: 544816
This should land/be applied after the combined stop/reload/go button patch (bug 544816) and before the star button movement patch (bug 578964).

I may need to upload another version to adjust line numbers, since bug 544816's patch is not yet final.
Assignee: nobody → fyan
Status: NEW → ASSIGNED
Attachment #459083 - Flags: review?
Attachment #459083 - Flags: review? → review?(dao)
Attachment #459084 - Flags: review?(hskupin) → review+
(In reply to comment #6)
> The reason is that RSS as a user-facing feature isn't really used much, and
> pretty much all sites that want you to subscribe to their feed will have
> dedicated icons/links on their website to do this.

I'm not sure the "pretty much all" part holds. AMO has been mentioned, and I happen to own pages where it isn't the case. It's kind of the point of <link rel="alternate" type="application/atom+xml"...> that sites don't need to do this. Even for the many sites that do include visible links or icons, a button that's always in the same place seems like a nice convenience.
Blocks: 579521
Attachment #459083 - Flags: ui-review?(limi)
This is a pretty controversial thing to remove (we've tried to do it before!) and I've heard the assumption that websites often have their own UI for subscription but that doesn't match my experience browsing over recent months and years.

I would rather we eliminate the preview portion, and move the subscribe interaction into a panel element like the bookmark button, perhaps overloading that button.

We should chat about this in dev-usability before just making a ui-r decision that removes this feature, I think.
Could we have a preference to put it back in the URL strip?

> I would rather we eliminate the preview portion, and move the subscribe
> interaction into a panel element like the bookmark button, perhaps overloading
> that button.

I definitely think this is a good idea.
What's the need of hurrying in removing that small icon? locationbar has usually a lot of blank space and it doesn't look like cluttering the UI. Even if web pages give their own ui to subscribe feeds, it's often hard to find it, there is no standard in presenting that, and we are assuming user wants to lose time searching for a small icon in the page, when we were giving him a fixed point where to look to discover feeds. If I should vote, it'd be a "no thanks".
The idea to merge it to the bookmark button is interesting, but which button? the star?
How about adding "Subscribe to this Page" to the bookmark button? Even give it an access key to make it easier. Ctrl+shift+F would do.
(In reply to comment #15)
> How about adding "Subscribe to this Page" to the bookmark button? Even give it
> an access key to make it easier. Ctrl+shift+F would do.

there were requests to remove that menuitem from the bookmarks menu as well because we had the icon, so someone should clarify what we really want.
What's wrong with the icon? It'd fit in perfectly with the bookmarks button seeing as it's mostly all icons and favicons.
Ermm, a Menu Entry cannot ever be a proper Substitution to an "On-Demand" Feature like Feed Discovery as currently implemented for obvious Reasons.

There was a Reason it got implemented this Way (1st Level/Primary UI/visually/iconic) - even so that all the other Browser Vendors (minus Google, but see Comment 5) got convinced.

Should further Discussion go to mozilla.dev.apps.firefox?
(In reply to comment #18)

What on demand feature? The button only acts as a link to the real rss page.
And I suppose there could be an about:config pref if you're so opposed to removing it.
(In reply to comment #19)
> What on demand feature? The button only acts as a link to the real rss page.

A link that only appears if there is a feed to go to. It both acts as a link and as an indication that a feed actually exists for the given page.
(In reply to comment #21)

Couldn't the same be done for the bookmark's button? When they're aren't any discoverable feeds, gray out the menu item?
(In reply to comment #22)
> When they're aren't any discoverable feeds, gray out the menu item?

Yes, of course it'd be disabled with no feeds, however menu items are only visible at all when the menu is open. The feed icon is always visible if a feed exists. It's an automatic indicator.
I suppose but what's the point of always showing it? I doubt the majority of Firefox users need to always see it. (Faaborg's heatmap: https://heatmap.mozillalabs.com/mozmetrics/?os=all&colorscheme=hsl&skill=all)

If they need it, accessing it through the bookmarks menu would be easy enough. And aren't feeds basically bookmark folders that update regularly? They fit under the bookmarks menu.
A heatmap of what's clicked won't tell you if people are looking at it to know if a feed exists, just if they actually click on it.

I do agree that the majority may not use it. (the argument in comment 6)
The heat map actually suggests that the feed button is used by half as many people as the star, which is a lot, way more than I would have expected. If that data is vaguely representative, this bug really lacks merit.
If that's the case, why not move it to the star?
(In reply to comment #27)
> If that's the case, why not move it to the star?

Maybe change the star's appearance a bit to note that RSS is present?
(In reply to comment #26)
> The heat map actually suggests that the feed button is used by half as many
> people as the star, which is a lot, way more than I would have expected. If
> that data is vaguely representative, this bug really lacks merit.

Agreed, I move for RESOLVED WONTFIX.
(In reply to comment #27)
> If that's the case, why not move it to the star?

What exactly does "that" refer to? By "move it to" I assume you mean merging them? Where are you drawing the conclusion from that this would be beneficial?
Making the star a drop down only hides the feed icon and annoys the 14% of users that use it as per the heatmap. The problem with a heatmap is that once you'd added an RSS feed, you rarely need to click it on the browser, however people do add bookmarks and/or use them to skim site content. 

I know that I brought up the idea of making the feeds more complete and it was stated that it's Reader is one of Google's most unused services, however people that use RSS's, use them a lot. Even if not consistently.
(In reply to comment #30)

Move as in relegate it to the menu that popups up when you bookmark a page. 
There's little reason to remove it, however the same could be said about keeping it.

If there's so much opposition towards removing it, mark this accordingly. I suppose they'll be some way to deal with this in the future.
Attachment #459083 - Flags: review?(dao) → review?(dolske)
(In reply to comment #32)
> Move as in relegate it to the menu that popups up when you bookmark a page. 

Ok. Why do you think this would be a better UI?

> There's little reason to remove it, however the same could be said about
> keeping it.

Not sure what backs up the second part. There has been speculation that people do use the button, and now there's data which seems to support this. Until we have a reason to believe the opposite, this seems like a sound reason to keep the button.
Attachment #459083 - Flags: review-
(In reply to comment #33)
> (In reply to comment #32)

Less clutter? Weak reason aside, removing it would get it out of the way. For the 7.3% that use it, I think moving it elsewhere would do just fine.
If we do wish to keep the icon the problem stated in comment 6 is still an issue: this is the one button in the top-level GUI that a low-knowledge user would not necessarily be able to figure out what it is as easily. Maybe instead of removing it we can improve this experience somehow for users who don't know what it is. One idea might be to make the default feed view page more user-friendly and self-explanatory.

(In reply to comment #34)
> I think moving it elsewhere would do just fine.

If an icon like this belongs anywhere in the top level GUI, it probably should stay right next to the star.
(In reply to comment #34)
> Less clutter? Weak reason aside, removing it would get it out of the way.

If we had agreed that it was clutter, we wouldn't be having this conversation.

> For the 7.3% that use it, I think moving it elsewhere would do just fine.

Depends on where "elsewhere" is. Making it a menu item would break feed discoverability.

7.3% seems slightly bogus, btw, as it doesn't fit the numbers for Beginner/Intermediate/Advanced. Anyway, put in perspective with the star button it doesn't seem like a neglectable user share.
If this bug is WONTFIXed please also WONTFIX bug 578964 at the same time. If the RSS icon stays in the address bar, then it should stay next to the star. They go together, and moving the star to the left whilst still keeping the RSS icon on the right wouldn't balance anything as discussed elsewhere. The RSS icon can't go to the left with the star because it's not always shown and we don't want the domain button moving around depending on if there's a feed or not. Thus, I think bug 578964 might make sense with this one done, but it doesn't make sense if this one is not done and thus should be either WONTFIXed or FIXED together.
(In reply to comment #36)

Under all OSes and all users, it's 7.3%
I'm still not getting the discoverability argument. If you don't regularly use feeds, there's no reason it should appear in the locationbar. 

Imagine this: you go on to a site, say Engadget. If you're not that interested in the site, the rss icon's useless. The users who do use it regularly would know when they want to subscribe to the page, thus they'd find it under the firefox/bookmarks menu. 

Discoverabilty only seems to apply to new users. If they've never noticed this feature, they probably don't need it. And if they do it, they'd know where to find it.
(In reply to comment #38)
> Under all OSes and all users, it's 7.3%

Under all OSes and "Beginner", it's 8.1%.
Under all OSes and "Intermediate", it's 9.7%.
Under all OSes and "Advanced", it's 9.7%.
Unless there's a fourth hidden group, this doesn't quite work.

> I'm still not getting the discoverability argument. If you don't regularly use
> feeds, there's no reason it should appear in the locationbar. 

Correct, but the hypothesis you need to challenge is that there is a large enough group using feeds regularly.

> The users who do use it regularly would
> know when they want to subscribe to the page, thus they'd find it under the
> firefox/bookmarks menu. 

No, the menus don't say "you can subscribe to this page, open me to do so".
https://heatmap.mozillalabs.com/mozmetrics/?os=all&colorscheme=hsl&skill=all

(In reply to comment #39)
> (In reply to comment #38)
> > Under all OSes and all users, it's 7.3%
> 
> Under all OSes and "Beginner", it's 8.1%.
> Under all OSes and "Intermediate", it's 9.7%.
> Under all OSes and "Advanced", it's 9.7%.
> Unless there's a fourth hidden group, this doesn't quite work.

Yeah, I think there's something wrong with these numbers from this heatmap. Those 4 numbers are what the page reports when you select each group. Somehow "all" is less then any of the three groups it supposedly breaks down into.

For the sake of argument, lets just say in the order of one in ten for now. ;)
An about:config pref would resolve this bug, don't you think?
(In reply to comment #40)
> Yeah, I think there's something wrong with these numbers from this heatmap.
> Those 4 numbers are what the page reports when you select each group. Somehow
> "all" is less then any of the three groups it supposedly breaks down into.

Standard stats; this is Simpson's paradox (http://en.wikipedia.org/wiki/Simpson%27s_paradox). Just an ordinary effect when working with data. The point is that in each class, there are users who use the button a lot, but they are drowned out in the aggregate count.

Regarding the decision itself: The button is only useful where it is because it provides visual feedback that there is a feed, rather than because it can be clicked. It is important that there be a way to restore it, but an extension could fix that whatever the outcome. In the end, I am not a typical user and do not really understand typical users, so I suggest we techies defer to the UI team since if it seems that so few use the button. It is a nuisance to everybody on a menu though.
I don't want to reiterate all of the points in comment #6, but I certainly agree with them.  If we include controls in primary UI for 10% use, by that logic we should be creating toolbar buttons for really standard stuff like copy and paste, and printing.

The Web feed control isn't used regularly enough (even by the heavy users of it) to place it on par with the location bar, or back and forward.

Currently, especially in conjunction with the open search glow, the lucky charms area of our UI is getting visually crufty.

I think we should continue to provide access to subscribing to a page through three paths:

Primary: the content itself provides the link or icon
Secondary: entry in the Firefox menu under send
Secondary: context menu of the page (with icon for increased discoverability once the context menu is displayed)
We should also keep in mind that removing functionality (or in this case slightly obfuscating it) is considerably harder to do than adding functionality.  But the only alternative is to allow an interface to continue to gain complexity until it is replaced by a leaner rival.  This was the very strategy that Firefox itself very successfully deployed against the Mozilla Suite.
(In reply to comment #43)
> I don't want to reiterate all of the points in comment #6, but I certainly
> agree with them.  If we include controls in primary UI for 10% use, by that
> logic we should be creating toolbar buttons for really standard stuff like copy
> and paste, and printing.

You can always copy/paste something selected and can always print. Not every page has a feed. The button part of this icon is fairly irrelevant. It's the indication of the existence of a feed that's important here.

Yes, many pages with feeds have a link/button somewhere in them. However this button is not guaranteed to be the same or in the same place and not every page will necessarily have a button. The button is standardized(-ish).

If feeds were 100% ubiquitous, yes, the button could probably go. If we were starting from scratch and creating feed capability from the beginning, yes, we could probably do without the button. In the existing world we have, where some have feeds and others don't and everyone has been used to having a feed button in every browser until very recently, the button is fairly important.

Let me give a real world instance where removal of the feed button is a big problem. Let's go to the BBC news website:
http://www.bbc.co.uk/news/

Say we removed the feed button and the user goes down and clicks on the "feed" link with the RSS icon on the page itself. What do you get? You get a page explaining to users what feeds are and how to use them. Their explanation on how to get a feed: click the orange feed button in your browser when you're at a page that shows it. This was the first news site I thought to try, by the way. Many other sites do say the same thing, though there are others that actually give a page of RSS feed links.

You could argue that we should evangelize the idea of always linking to feeds simply from pages that have them, but I don't think it's worth the effort. This is existing functionality that is in pretty much every browser and it is expected to be there. (if IE ditched this, things might be different) I cannot argue against the main point of comment 6 that this button is alien to some users in comparison to others, and having it as is may not be ideal, but removing the button may not be the best route to deal with things here. (see comment 35)
feeds has been a top level ui for a while now and hasn't caught on. i think it is now time to retire it.

also, i think there is a lot of rss readers that do a bettter job at this than firefox.
I'm sorry, "it's doomed" doesn't feel like a compelling enough argument.

If IE and other browsers with this icon have even half as decent stats on feed button usage, that means in the order of one tenth or so of the general user population uses this thing, which is a not insignificant number.

And yeah, Firefox may suck as a feed reader by itself, but that's what addons are for. Besides, the icon is needed to discover feeds after which you can put them in whatever reader you want.
What about moving the feed button to the status bar and then adding the ability to open the page's feed in a tab or panel from there?
(In reply to comment #48)
> What about moving the feed button to the status bar and then adding the ability
> to open the page's feed in a tab or panel from there?

The plan was to not have a status bar by default at some point.
Since this was an old bug that was "adopted" for this purpose for Firefox 4, let me recap what the intended changes are:

* Move the RSS indicator to the new bookmarks menu
* Keep its current functionality wrt. listing multiple feeds

The basic logic here is that it's a one-time use button only, similar to bookmarking a site. You add it once, and you are fine with entering a menu to do this. It doesn't deserve top-level placement of a similar priority as back/forward, stop/reload or even bookmarking.

And before you say "but the bookmarks star is the same thing!", the star exists primarily to boost ranking in the awesomebar results, and as a quick "remember this" function, as well as an indicator for "did I capture this page". The equivalent function to the RSS subscription would be either clicking "Bookmark this page" in the bookmarks menu — or clicking the star twice — so you can decide where it goes and edit its details.

I have also renamed the title of this bug to be a bit less drastic (we're not removing the RSS button, we're moving it).
Summary: remove feed button in location bar → Move feed button to bookmarks menu in Firefox 4
Alexander, I think you've missed the entire primary argument for keeping the button, at least based what you've said in comment 50. Let me sum this up. There are two distinct and separate, though related, uses for the feed button:

1) It's a button. If you click on it you get a list of available feeds from which you can subscribe.

2) It's an icon. Seeing it tells the user that at least one feed is available for the current page.

You seem to be focusing only on #1. I think it's nice to be able to list multiple feeds and subscribe from the button, but honestly, I don't care where that part is.

#2 is the very important part here. If it's moved out of the top-level GUI, meaning into another menu or wherever, that means there will no longer be any immediate indicator that a feed exists when one browses to a page. Having the icon in a menu doesn't count; you don't open that menu every single time you view a page. Moving the feed button to anywhere that is not automatically visible is functionally equivalent to removal in the context of use method #2.

Also, please see the example in comment 45. Browsers are "supposed" to have an orange feed button in the top-level GUI. We can and are debating this point, but nonetheless it is an assumption that exists in a large user base and I think that removing it will create more headaches than it will solve.
Summary: Move feed button to bookmarks menu in Firefox 4 → Remove feed/RSS button from top-level GUI for Firefox 4 (move to bookmarks menu)
As a compromise, how about this:
Move the subscribe functionality into the bookmarks menu, as Alexander explained it.
If a feed is present on the current page, change the bookmarks menu's button to include the RSS icon to indicate the presence of the feed.

With this, there's no extraneous icons in the locationbar, yet it still lets users know that the page has a feed.
(In reply to comment #50)
With moving this Item you're totally ignoring the Discovery Point made in (at least) comment 18.
Moreover the Comparison Argument made clear by Comment 5 is being ignored totally as well whereas on other Bugs filed against UI Changes References against to Competitors are allowed and justified.
This Reasoning ("just do as it fits") sucks, TBH.
(In reply to comment #53)

You can't quote yourself to try and prove your point.

As for the discovery issue, it isn't really an issue. It's been a top level item since Firefox 1.x, probably even longer. And judging by the heatmaps Faaborg published, it's not used enough to warrant the same attention as the bookmark star, back/forward buttons, etc. To be blunt, not a lot of users care for it. 

Seeing as how users use bookmarks quite a bit, relegating the rss function to the bookmark/Firefox button might actually improve discoverability.
(In reply to comment #54)

In the order of one in ten people use this. (maybe more, maybe less, but somewhere in that area; specifics aren't that important) Yes, that sounds like a very small population, and if that's the number of people who might use a new feature, yes, I might agree that it's not enough to warrant top level addition. However, that's not the case; it's already in use where it is. There is a higher threshold that has to be met to remove something that's used than to add something new.

Even if we're only talking 5-10% of the Firefox user-base caring about this button, that translates to tens of millions of people. (keeping vague here to avoid getting bogged down in precision irrelevant to the argument) This button is also in other browsers in a vaguely standardized form, so many millions more use it there. Let's keep in mind that "not a lot" is actually quite a lot. There are quite a few features in Firefox that are used WAY less, so numbers isn't an argument by itself. In my opinion, the numbers argument isn't that important in this instance. The "alien button I don't know what it does" argument made by Alexander is, and again, I think removal is not the best solution to that. (but I'm repeating myself here)

As to adding some form of feed/rss thing to the bookmarks menu, yes, of course, something needs to go in there just like it is/was in the old bookmarks menu. I'm not arguing against that, but again, that is not the point here. The real point is comment 51. People who don't care about feeds just don't seem to grok this point at all as it's getting talked past instead of about.

(In reply to comment #52)
> If a feed is present on the current page, change the bookmarks menu's button to
> include the RSS icon to indicate the presence of the feed.

This is an interesting idea and might be workable, but I don't believe it's worth the effort. (something similar I think was suggested somewhere above or in another place) We currently have a perfectly fine indicator. The user experience on clicking it is where the legitimate complaints really start. It is new user unfriendly.

> With this, there's no extraneous icons in the locationbar

Well, not by default anyway, if you don't count all those others that may end up being added. (bug 578964 comment 12) And, also if you don't count other icons added by addons to this area, such as by Read It Later or Flagfox or others.
Attachment #459083 - Attachment description: patch v1 (removes and moves it to the app button if available) → patch v0 (removes and moves it to the app button if available)
Attachment #459083 - Attachment is obsolete: true
Attachment #459083 - Flags: ui-review?(limi)
Attachment #459083 - Flags: review?(dolske)
(In reply to comment #50)

> And before you say "but the bookmarks star is the same thing!", the star exists
> primarily to boost ranking in the awesomebar results, and as a quick "remember
> this" function, as well as an indicator for "did I capture this page". The
> equivalent function to the RSS subscription would be either clicking "Bookmark
> this page" in the bookmarks menu — or clicking the star twice — so you can
> decide where it goes and edit its details.

warning. off topic. TO Limi

1. i think using a star for boosting raking in the awesomebar is a hackish way to do it. there should be another button increase relevance without populating my bookmarks with not actual bookmarks.

2. "remember this" is another function firefox needs. i use "read it later" for this now. firefox needs this built in.

where is a better avenue for discussing this type of thing?
(In reply to comment #56)
> warning. off topic. TO Limi
If you have to say this, it doesn't belong in the bug.  Please see https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

(Frankly, this whole discussion belongs in the newsgroups where it is far more accessible to other people than bugzilla).
Actually, there are those that find Bugzilla more accessible. (yes, I'm aware this comment is off topic too)
>Actually, there are those that find Bugzilla more accessible.

sure, but if we debate this here most people won't see that it was discussed (and subsequently draw incorrect conclusions that we aren't transparent about our design decisions).  Also, for the people actually working on the bug, it's useful for comments to be actionable and specific to the implementation.
(In reply to comment #57)
> (In reply to comment #56)
> > warning. off topic. TO Limi
> If you have to say this, it doesn't belong in the bug.  Please see
> https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
> 
> (Frankly, this whole discussion belongs in the newsgroups where it is far more
> accessible to other people than bugzilla).

(In reply to comment #57)


sorry, hot trying to be rude. i'm not familiar with how this open source thing operate exactly. 

just trying to elicit a url of where the discusion is supposed to take for things like this. thank you.
(In reply to comment #60)
> sorry, hot trying to be rude. i'm not familiar with how this open source thing
> operate exactly. 
Nobody should ever complain about someone asking where the right place to discuss things is (unless it's already been answered in the bug).

> just trying to elicit a url of where the discusion is supposed to take for
> things like this. thank you.
You want to go to dev.usability:
http://www.mozilla.org/about/forums/#dev-usability
(In reply to comment #61)
> http://www.mozilla.org/about/forums/#dev-usability
That's 404. I would assume you meant some way to this:
http://groups.google.com/group/mozilla.dev.usability/topics
(or some other way to read the same group)

Though, whilst the groups occasionally have an important discussion somewhere, if you can find it, they're also a wasteland of spam and useless junk. Something like comment 56 doesn't belong here and could go there, but I disagree entirely that the main discussion here belongs elsewhere, so long as it actually stays on topic and stops repeating points... which yeah, it's not.
Shawn's link isn't 404 anymore. Must've been a transient problem. Don't know.
This is going to impact the relative discoverablity of core browser controls when bug 544816 lands, and removing this control is a component of our overall theme refresh.

We've moved the functionality to the bookmarks menu (which needs to be mirrored with the bookmarks menu off of the navigation toolbar).  Primary UI notification of the existence of a feed should appear in the content area, with the styling and context being controlled by the author.
blocking2.0: --- → ?
> Primary UI
> notification of the existence of a feed should appear in the content area, with
> the styling and context being controlled by the author.

Is this supposed to be a proposed policy or reflect the status quo?
I wouldn't go as far as to call it a policy as much as an implication of the design change.  Either way it's definitely the status quo in that many sites advertise their feeds to users in the context of their content.
On the other hand, it's not the status quo in that other sites don't advertize their feeds or, while advertizing them, tell users to click the feed icon in the location bar...
Those sites are going to have some issues with users on chrome and apparently IE9 as well.
I hadn't heard anything about IE9 yet. Got a link?

Chrome is a minority browser, so those sites are unlikely to care.
(In reply to comment #68)
> Those sites are going to have some issues with users on chrome and apparently
> IE9 as well.

Meh... If IE9 completely does away with this in the top-level GUI then I reluctantly agree we may need to consider it too. (though I'd still rather not) I would still highly encourage a replacement top-level indicator of some kind.
Attached patch patch v1 (obsolete) — — Splinter Review 
Removes the feed button and places 'Subscribe to This Page' in the bookmarks menu button's menu in the same location in which it appears in the menu bar's Bookmarks menu.
Attachment #472329 - Flags: ui-review?(faaborg)
Attachment #472329 - Flags: review?(dolske)
(In reply to comment #69)
> I hadn't heard anything about IE9 yet. Got a link?

I haven't found a definitive official announcement stating IE9 dropping top-level RSS support. Please don't move forward with this bug without knowing this.

Because the icon removal is clearly controversial, might I suggest having one patch for that and another bug and patch for adding a subscribe feature to the new bookmarks button. The later is generally agreed upon.
Attachment #472329 - Flags: ui-review?(faaborg) → ui-review+
There is no official announcement, no - Alex is going off of the leaked screenshot (which may or may not be accurate) which shows IE9 dropping a great number of its top-level buttons and UI features:

http://www.webmonkey.com/2010/08/leaked-screenshot-shows-a-cleaner-simpler-ie9/

I'm happy with the approach in comment 71, though I'd prefer if there was also a way to add an RSS feed from the "Add Bookmark" panel, and when RSS is available, have the "Add Bookmark" panel show on the first instead of the second click.
We aren't going to let IE9 or any other product dictate our design, I was just referencing both of them in response to the premise that browsers aren't allowed to change course and go back on a previous decision.  Clearly that is possible, especially for our competitors who do not take the time to engage in a public debate over the choices they are making and why they feel they are taking the best course of action.
My primary concern about IE9's route is just cross-application consistency that already exists. If that breaks in a big way, users and websites won't continue to expect this to be there as much and part of my argument against removing the top-level GUI icon goes away. I would still argue for us keeping it, though not as much.

(In reply to comment #73)
> There is no official announcement, no - Alex is going off of the leaked
> screenshot (which may or may not be accurate) which shows IE9 dropping a great
> number of its top-level buttons and UI features

In my opinion, the leaked screenshot is worthless as any predictor. Microsoft has had development builds with minimal GUI for testing before, thus without context any screenshot of an unreleased version could be of anything from a quick test to the intended look. (same thing for anything that would be of a Mozilla try server build, for example)

> a way to add an RSS feed from the "Add Bookmark" panel, and when RSS is
> available, have the "Add Bookmark" panel show on the first instead of the
> second click.

Neat idea. It would add some good discoverability in a new and natural way.

(In reply to comment #74)
> We aren't going to let IE9 or any other product dictate our design

I think we can all agree with that.
Push just met shove. I do not think the product would be significantly worse if we shipped without this change, so blocking-. Drivers, countermand me here if you feel different.

Would take a safe patch, but agree with Beltzner that a nice bookmark panel UI would make the change more palatable.
blocking2.0: ? → -
>I do not think the product would be significantly worse if
>we shipped without this change

In the case of 

[feed][star][drop down][reload]

it is too difficult for the user to discover and target reload.  These changes need to be considered in aggregate.  If we don't make this change that I believe that we have to keep reload next to home on the navigation toolbar.

There are a lot of dependencies here, and I know that makes individual triage of issues difficult, but we really need to look at full context and then designed to go with all of one approach, or all of another.
>though I'd prefer if there was also
>a way to add an RSS feed from the "Add Bookmark" panel, and when RSS is
>available, have the "Add Bookmark" panel show on the first instead of the
>second click.

If we have the user create a bookmark just to discover if their peripheral action of sending the link to another application is available, it feels like we are increasing the cost to finding out if the page has a feed (and even if it does, we causing the user to toss a meaningless bookmark into unsorted or their last location, in order to carry out the action).
(In reply to comment #76)
> Push just met shove. I do not think the product would be significantly worse if
> we shipped without this change, so blocking-. Drivers, countermand me here if
> you feel different.

We're moving a lot of new functionality to this area with the Stop/Reload/Go combination, so we should get RSS out of the way.

It's one of the lowest-used button in our entire UI, even among our power users (beta users that supply the test pilot data), with only 3% of users *ever* clicking it even once during the test period:

https://heatmap.mozillalabs.com/

> Would take a safe patch, but agree with Beltzner that a nice bookmark panel UI
> would make the change more palatable.

We shouldn't let the perfect be the enemy of the good. Getting RSS out of the way for most users is good, we can improve on it later — but I can't see moving the RSS menu (because it is a menu) in a 1:1 transplant to the Bookmarks menu being very demanding implementation-wise?

Re-requesting blocking, since there is already an approved patch for this. Let me know if I'm mis-reading anything regarding the patch's readiness. :)
blocking2.0: - → ?
(In reply to comment #79)
> only 3% of users *ever* clicking it even once during the test period:

To repeat myself again, the important bit about the icon is that it only shows when a feed exists and tells the user it is available in a consistent and cross-application way. The clicky part you learn from a heatmap isn't as important.


Patch is just for removal and add to new bookmarks button. Would need a new one to add it to the add bookmark dialog in some fashion as well as per Beltzner in comment 73. Moving feed awareness to the add bookmark panel seems like a welcome compromise here.
>Moving feed awareness to the add bookmark panel seems like a
>welcome compromise here.

I don't see how that is better than the patch here that moves it to bookmarks menu (both one click, although this one is always one click instead sometimes one click, and it doesn't create user data as a side effect of inspecting if the feed exists).
(In reply to comment #80)
> To repeat myself again, the important bit about the icon is that it only shows
> when a feed exists and tells the user it is available in a consistent and
> cross-application way. The clicky part you learn from a heatmap isn't as
> important.

Those two statements aren't related, but this is getting a bit out of hand. :)

I agree that it has an indicator function as well as an action function — we just disagree with how important the indication case is on the current web, where pretty much every web site has an RSS feed — and you will find it if you go looking for it.

In summary: if you use RSS, and want to subscribe to a site, having it be one click away to discover the feed menu is considered an acceptable compromise as far as the UX team is concerned.
(In reply to comment #81)
> >Moving feed awareness to the add bookmark panel seems like a
> >welcome compromise here.
> 
> I don't see how that is better than the patch here that moves it to bookmarks
> menu (both one click, although this one is always one click instead sometimes
> one click, and it doesn't create user data as a side effect of inspecting if
> the feed exists).

You go to the bookmarks menu to open a bookmark.
You go to the add bookmark pane to add a bookmark.

When adding, that's when you'd probably like to be told about a feed you might want.

Putting some indicator in both places makes sense.
(In reply to comment #79)
> (In reply to comment #76)
> > Push just met shove. I do not think the product would be significantly worse if
> > we shipped without this change, so blocking-. Drivers, countermand me here if
> > you feel different.
> 
> We're moving a lot of new functionality to this area with the Stop/Reload/Go
> combination, so we should get RSS out of the way.
> 
> It's one of the lowest-used button in our entire UI, even among our power users
> (beta users that supply the test pilot data), with only 3% of users *ever*
> clicking it even once during the test period:
> 
> https://heatmap.mozillalabs.com/
Note that blocking- does not mean we wouldn't take it.  I don't see why this patch wouldn't get approval to land as long as it gets review.

Seeing as how it's one of the least frequently used button, it seems that people already ignore it, so leaving it there doesn't make us significantly worse if we shipped without this change.  Yeah, I agree that it sucks, but I also agree with dietrich that this doesn't block the release.
blocking2.0: ? → -
(In reply to comment #84)
> Note that blocking- does not mean we wouldn't take it.  I don't see why this
> patch wouldn't get approval to land as long as it gets review.

Yeah, sorry for conflating the issues. I was moving fast, I apologize — it's a sad tendency in Bugzilla that only bugs that have blocking get reviewed/landed these days.

Let's see if we can get it reviewed and landed separately. Thanks!
(In reply to comment #85)
> it's a
> sad tendency in Bugzilla that only bugs that have blocking get reviewed/landed
> these days.

Actually, that's a sign that people are working on the highest priority bugs. Which is the only possible way that we'll ship Firefox 4 before the end of the Mayan calendar.
(In reply to comment #86)
> Actually, that's a sign that people are working on the highest priority bugs.
> Which is the only possible way that we'll ship Firefox 4 before the end of the
> Mayan calendar.

Thank you Dietrich, that gave me a good laugh. :D

New Firefox 4 motto: "It'll probably be released before the end of time!"
>Actually, that's a sign that people are working on the highest priority bugs.

Right, but from the UX team's perspective, getting a pixel perfect main window free of clutter and noise is of the utmost importance.  Even without blocking status, we want to reiterate how much we want to clean up this area of the UI (also, we'll buy the reviewer lots of bacon).

>Which is the only possible way that we'll ship Firefox 4 before the end of the
>Mayan calendar.

If we hurry we can still beat the release of Duke Nukem Forever as well!
(In reply to comment #88)
> (also, we'll buy the reviewer lots of bacon).

Bad tactic; this would cut out many potential reviewers due to religious and cultural practices. :p
One more note about degrading relative discoverability for all other controls: it would be good if we kept the color orange exclusive to the Firefox button in our UI for over the telephone support.

A: ok, do you see the orange Firefox button
B: yes
A: click that and select options
B: ok, so I see a, t, o, m and rsssses 2 dot 0, which one of those is options again?

>due to religious and cultural practices.

a love of bacon is dolske's personal religion, but we are happy to offer alternative gifts to other browser peers reviewing this patch.
(In reply to comment #90)
> One more note about degrading relative discoverability for all other controls:
> it would be good if we kept the color orange exclusive to the Firefox button in
> our UI for over the telephone support.

Good point.

> a love of bacon is dolske's personal religion

Sounds like a yummy religion. :)
I have used this button many times, but as a percentage of page views, yes it is small. But the same is true of the reload button, the bookmarks star, the identity button and many others.

I have used it on pages where there isn't an obvious indication of a feed otherwise. The icon is also becoming more and more recognisable, with many products and sites adopting it.

The main usability issue I see here is that I will now have to open the bookmarks menu on every page I am interested in following just to see whether a feed exists, as opposed to just flicking my eyes up to the right of the location bar.

Something like comment 52 I think is the best solution. A small indication on the bookmarks button that a feed is available, similar to the search engine glow when a search engine is available.
I think bug 592900 and this one need to land at the same time.
see comment 93 and bug 592900 comment 10.
Attachment #472329 - Attachment is obsolete: true
Attachment #474367 - Flags: ui-review?(faaborg)
Attachment #474367 - Flags: review?(dolske)
Attachment #472329 - Flags: review?(dolske)
(In reply to comment #94)
> Created attachment 474367 [details] [diff] [review]
> patch v1 mini (just removes the feed button, so wait until bug 592900 adds the
> menu item)
> 
> see comment 93 and bug 592900 comment 10.

So what then about Beltzner's suggestion from comment 73 to tell about RSS in the create bookmark dialog and open it on first click? New bug for that?
Attachment #474367 - Flags: ui-review?(faaborg) → ui-review+
(In reply to comment #95)
> So what then about Beltzner's suggestion from comment 73 to tell about RSS in
> the create bookmark dialog and open it on first click? New bug for that?

Yes, let's handle that separately. Getting this into Firefox 4 is more important than having the additional functionality and convenience that would add.
wowowow, guys, please don't remove RSS button - it also serves us as an indicator whether the page has RSS feed or not.
If you hide it behind the bookmarks - people will have to click it everytime they need just to check whether the site has an RSS feed or not.
You might make a bookmarks button on nav-bar change it's state into RSS icon, if the viewing page has RSS feed, but not everyone is having this button shown on the panel and no one will place it on the panel just as an indicator, because the old (current) behavior doesn't require a place anywhere on the addressbar/nav-bar when there is no RSS, the RSS icon appeared only in case there is RSS feed and it occupied no space, if there's not.
(In reply to comment #97)

Read the past 90+ comments
(In reply to comment #98)
> (In reply to comment #97)
> 
> Read the past 90+ comments

I did. The adequate people say the same as I do. I just show my protest against cutting features just because some statistics say that people don't use rss button.
Since bugzilla doesn't support voting against bugs - all I can is to leave a comment.
plz, dont remove RSS button
Please, don't remove RSS.

Because
1) It helps us to subscribe much easier;
2) (and it's the major!) it provides information that this site allows us to read it via RSS.
Sorry, but it is very stupid decision.
Please don't remove this button.
We don't need yet another add-on like Element properties, Go Button, etc.
Yet again. Please, don't remove those button.

It looks nice, it's an indicator `is there rss?', it's a good shortcut to subscribe.

As a solution 'in the middle' - adding pop-up with confirmation 'do you want to subscribe' or something like that (to not make scary peoples, who don't know what is RSS)
(In reply to comment #103)
> As a solution 'in the middle' - adding pop-up with confirmation 'do you want to
> subscribe' or something like that (to not make scary peoples, who don't know
> what is RSS)

Yes, I think the better solution would be to enlighten and educate people what is RSS used for, instead of hiding it, like it is something evil that should be kept away from users.

Since I know mozdev management doesn't care about users' opinion - could you at list not cut this feature but just use the "display:none;" for it, so users like me could easli enable it by a userstyle?
I suppose moveable RSS icon by "Customize toolbar" option, optimal decision.
I think it's not needed! Don't remove button or transfer to other place what not hidden in menus!
I think you're a little late on this one guys, but a compromise is, is that a bug be filed to create an RSS button, which you can apply to the Firefox chrome yourselves. That was it can be applied in the title bar, navigation bar, tab bar or the new addons bar.
(In reply to comment #107)
> I think you're a little late on this one guys, but a compromise is, is that a
> bug be filed to create an RSS button, which you can apply to the Firefox chrome
> yourselves. That was it can be applied in the title bar, navigation bar, tab
> bar or the new addons bar.

We are not late, since that bug hasn't yet landed. And even if it would - it is still not late, since the bugs can be REOPENed.
Little late?!Those button was present, usefull. No one was thinking, that someone gonna remove it.So when this bug was created - no one from posted here wasn't have any mind about that.And now, when so many peoples voted to reject it... it's too late...
I cast "summon beltzner" (not belzebooth, but near) to judge us who's right and whether the functionality should be cut or not.
(In reply to comment #109)> Little late?!Those button was present, usefull. No one was thinking, that> someone gonna remove it.So when this bug was created - no one from posted here> wasn't have any mind about that.And now, when so many peoples voted to reject> it... it's too late...This discussion got hashed out a long time ago, unless there's new information, I'm not sure what you're hoping to achieve. I too was firmly against having the button removed but I got used to the idea soon enough. Data suggests that most users use the button once per site and on a small fraction of the sites they visit. If the button makes up such a small percentage of clicks in a browsers lifecycle it's understandable that it's being removed.I am a big fan of RSS feeds and as such even attempted to make it more usable within the browser: http://groups.google.com/group/mozilla-labs/browse_thread/thread/1356c6545ab6f063 and http://groups.google.com/group/mozilla.dev.usability/browse_thread/thread/3d1e24561028c4fe but disappointed as I was at the compelling argument that "man power / usage = loss" I moved on.Browsers evolve and this is part of the evolution of firefox. 90% of sites that use RSS do them automatically and provide an in page means of finding the feed. Thus in the grand scheme of things, this really isn't that great a loss.
(In reply to comment #111)
> Data suggests that most users use the button once per
> site and on a small fraction of the sites they visit.

No surprise here. We don't expect users to subscribe to loads of sites and subscribing is a one-time action.

> 90% of sites that use RSS do them automatically and provide an in page means of
> finding the feed.

Where have you got that number from?
I also would like to see the statistics about how often people used this button as just a visual indicator, without clicking it. Do you have such statistics? No. You can't state that people don't watch at it. They do. They need to get informed even when they don't plan to click that button.
and even more: does this button occupy so much space that you want to cut it?
does it distract users' attention so much that you want to cut it?
just wanted to say, that I, too, often look at RSS indicator, to know whether
the site contains RSS fedds.
Bad idea to remove so usefull button.
You may add it to the bookmarks menu, but let it stay in the adress bar.
>just wanted to say, that I, too, often look at RSS indicator

Yep, maybe statistics about clicks on that button is bad, but how can you calculate, how many times user looked at those button to check RSS availability?
Dear crap. I'm busy for a few days and I see a slew of email notifications from this bug. This recent pile of panicky comments is not befitting of Mozilla and does not belong on Bugzilla.
https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

For the record, which most of you don't seem to have read above, I and others have been debating for a good solution here and have been on the side of keeping this thing since the beginning. There is a beginning; it's up top; read it. Yes, it's long; deal with it.

I would personally like the button to stay, yes, be we, us here, people who know how to use a computer, are not the only audience to aim for. This is the one button in the top level GUI that is remotely "advanced", i.e. not immediately figure-out-able by someone who doesn't know what they're doing. They need to use the Internet too. Some changes are needed here, and while I'm not perfectly satisfied with the end result of the discussions, the compromise Beltzner suggested is a good one. (see comment 96)

A different compromise might be to only show a feed icon as needed if a user has at least once used the feed system beyond the default. After which point it would have it as an easily user configurable option of some kind. (though I'm apparently only coming up with this now, and it'll be burred in the new deluge of panic)

I now intentionally and knowingly violate Bugzilla etiquette to say this to newbies to this bug:  shut up
I apologize to those not new to this bug for my tone. I've had a crappy week.
I really, really dislike this change. However if it will help beginners then ok. But make it optional please because not all sites shows own RSS button and not all sites shows it in easy to spot place. This button always wisible.
Maybe it will be good idea to implement separate button which will be shown as icon in urlbar if you place it to the right from urlbar. 

Just give ability to put it back, please. Even about:conf option will be ok for me.
I would prefer some kind of an in-GUI option or an about:config option for this too, but it doesn't look like we're going that route right now.

Firefox's raison d'être is addons. At least one addon will be created to add this back, probably with new and better features. As was said prior, this you can count on, always. ;)
As Dave notes, this bug is not the proper forum for users to advocate for against a change purely on grounds of their own personal preference.  Please move discussion to dev.apps.firefox, so that everyone can participate in a centralized location, and so that Bugzilla can remain focused purely on developement.
Follow up bug 596731 proposes adding this optional control to the toolbar customization palette.
(In reply to comment #113)> I also would like to see the statistics about how often people used this button> as just a visual indicator, without clicking it. Do you have such statistics?> No. You can't state that people don't watch at it. They do. They need to get> informed even when they don't plan to click that button.https://heatmap.mozillalabs.com/index.html3% of all users in a 117,000 user study clicked the RSS button.  It is the 6th least used UI element in the main UI.  The last five are:3% Scroll Right2% More Info2% Bookmark Star: Remove Bookmark2% Site Identity (EV)1% Scroll LeftScroll Right - Most users don't encounter this because it is on the horizontal scroll bar which barely ever shows.More Info - Not sure what this is but I'm quite sure it barely ever showsBookmark Star: Remove Bookmark - Understandable because I'm sure most users keep their bookmarks for long periods of time and use the Library to organize their bookmarks.  Plus this is in the same spot as the add bookmark star which 23% of users clicked.Site Identity (EV) - Understandable because the colors and size of the indication of the security and I'd think most users don't really care who issued the certificate and have learned by now what the colors of the buttons mean.Scroll Left - Most users don't encounter this because it is on the horizontal scroll bar which barely ever shows.So there you have it.  The least used main UI element is *drum roll*...the RSS button.  Let's get this patch in and reduce the UI noise of a barely used UI element.
Sorry, not sure what the heck happened with the last comment.  I wrote it in the comment box and it looked fine when I submitted it.

(In reply to comment #113)
> I also would like to see the statistics about how
often people used this button

https://heatmap.mozillalabs.com/index.html

3% of all users in a 117,000 user study clicked the RSS button.  It is the 6th least used UI element in the main UI.  The last five are:

3% Scroll Right
2% More Info
2% Bookmark Star: Remove
Bookmark
2% Site Identity (EV)
1% Scroll Left

*Scroll Right - Most users don't encounter this because it is on the horizontal scroll bar which barely ever shows.
*More Info - Not sure what this is but I'm quite sure it barely ever
shows
*Bookmark Star: Remove Bookmark - Understandable because I'm sure most
users keep their bookmarks for long periods of time and use the Library to
organize their bookmarks.  Plus this is in the same spot as the add bookmark
star which 23% of users clicked.
*Site Identity (EV) - Understandable because the colors and size of the indication of the security and I'd think most users
don't really care who issued the certificate and have learned by now what the
colors of the buttons mean.
*Scroll Left - Most users don't encounter this because it is on the horizontal scroll bar which barely ever shows.

So there you have it.  The least used main UI element is *drum roll*...the RSS button.  Let's get this patch in and reduce the UI noise of a barely used UI element.
and two more stats from that heatmap and refer to explanations in above comment about the other UI elements that are under the RSS:

0.05 RSS
0.03 More Info
0.03 Bookmark Star: Remove Bookmark
0.03 Site Identity (EV)

And the numbers barely change between begineer, intermediate, and advanced users.
(In reply to comment #125)
Clicks and visual indication is a big difference. For example I don't even have back-fwd buttons in interface but I really want to see RSS-button.
I guess people don't use it because they don't understand WHAT is it and how they can benefit from it. I once told friend of mine that he can subscribe to rss-feed of forum which he likes and recieve news about new posts without opening it and searching through it. At first he don't even believe me, lol.
And now it will be removed because most of people don't understand it. Great.
(In reply to comment #125)
> Sorry, not sure what the heck happened with the last comment.  I wrote it in
> the comment box and it looked fine when I submitted it.

Bugzilla can do odd things sometimes, as can its users... ;)

(In reply to comment #125 - comment #127)
Kurt & Lain: In response to the heatmaps & button vs. visual indicator issue, AGAIN, just read the comments above all about it. I got annoyed at myself when I was the one repeating things, lets not have everyone else do it too, please.

We're up to comment 128 here. Just because that's a lot isn't an excuse for not reading them ALL before posting.
Blocks: 596731
Comment on attachment 474367 [details] [diff] [review]
patch v1 mini (just removes the feed button, so wait until bug 592900 adds the menu item)

Looks like this can also remove feed-icons.png (OS X) and feed-icons-16[-aero].png (Win), as they're now unused.
Attachment #474367 - Flags: review?(dolske)
Attachment #474367 - Flags: review+
Attachment #474367 - Flags: approval2.0+
Per comment 93, still want bug to land along with this.
Whiteboard: [needs fix for bug 592900]
Blocks: 596783
Per Alexander Limi in comment 96 I filed bug 596783 for the idea to add feed handling to the "Add Bookmark" pane from Mike Beltzner in comment 73.
Kurt Schultz, Im really not sure that data adequate...
If I use mouse gestures its not clear how this interpreted in stats :(

PS only 7 votes... why it should be done at all?
(In reply to comment #133)
> PS only 7 votes... why it should be done at all?

Votes mean nothing. Votes determine nothing.

My primary use for them is so that I can follow a bug without having to change the CC field and use different email notification prefs for it sometimes.
Whiteboard: [needs fix for bug 592900] → SEE COMMENT 122 BEFORE COMMENTING! [needs fix for bug 592900]
don't remove it plz or do option in about:config which stay rss icon.
Please do not remove the RSS icon in the location bar!
And if so want to remove, then do in the Preferences another tab "RSS", which among other settings, the output feeds, was able to return the icon in the location bar.
FOR THE LAST TIME: stop spamming this bug.

Actually read what's been written before you comment. Right under the bug name, it says [SEE COMMENT 122 BEFORE COMMENTING!]

Do we need to add flashing neon lights for it to be noticed?
(In reply to comment #137)
> FOR THE LAST TIME: stop spamming this bug.
> 
> Actually read what's been written before you comment. Right under the bug name,
> it says [SEE COMMENT 122 BEFORE COMMENTING!]
> 
> Do we need to add flashing neon lights for it to be noticed?

no, you need to close that damned bug
since you treat users like ****, call **** and tell them to shut up - why they shouldn't treat you as well?
I would to once again provide a calm and polite reminder for everyone to debate this change on its merits, as opposed to personal preference and personal attacks.
Attachment #475688 - Attachment description: patch v1 nano (un-bitrotted and also remove unused feed icon png's) [r+a=dolske, ui-r=limi] → patch v1 nano (un-bitrotted and also remove unused feed icon png's) [r+a=dolske, ui-r=faaborg]
Blocks: 592900
No longer depends on: 592900
Whiteboard: SEE COMMENT 122 BEFORE COMMENTING! [needs fix for bug 592900] → SEE COMMENT 122 BEFORE COMMENTING!
Comment on attachment 476402 [details] [diff] [review]
patch v1 mini 2g [r+a=dolske,ui-r=faaborg] (un-bitrotted; adds 'Subscribe to this page...' to bookmarks menu button menu)

>+++ b/browser/base/content/browser.xul
...
>+            <menuitem id="BMB_subscribeToPageMenuitem"

The top of the menu isn't a great place for this, but other spots are not much better. So, I think this is fine, and bug 592900 will take care of improving the order (of everything there).

Also wonder if the RSS icon should be shown when the menuitem is active, ala the Windows AppButton ("#appmenu_subscribeToPage:not([disabled])" in winstripe's browser.css). Guess bug 592900 can figure that out too.
Attachment #476402 - Flags: review+
Attachment #476402 - Flags: approval2.0+
http://hg.mozilla.org/mozilla-central/rev/2f764a75af1b
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
No longer blocks: 578964
Depends on: 597632
No longer depends on: 597632
Depends on: 597644
Verified fixed

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b7pre) Gecko/20100918 Firefox/4.0b7pre
Status: RESOLVED → VERIFIED
Target Milestone: --- → Firefox 4.0b7
Henrik, could you check in the patch to mozmill?
Flags: in-testsuite?
Why do core changes like this only appear on Planet Mozilla once they have been well and truly debated in bugzilla (where I'm always told people should not debate changes anyway!)

This is a very stupid idea.
Flags: in-litmus?
We simply have to design for mainstream users if we are going to survive in this increasingly competitive marketplace.  Everyone seems extremely interested in their own personal usage, and being informed well enough in advance of a otherwise pretty minor modification so that they can riot and attempt to prevent any type of change.  All of our usage metrics point to the fact that this control isn't used enough to warrant inclusion in primary UI.  We're designing a product for 400 million people. This bug could contain a million comments calling us stupid and it still wouldn't change our desire to create a product targeting mainstream users.
Why not just have one single 'interact' button right next to the end of the url bar that onclick opens a doorhanger with many common actions inside it? (rss, sharing, etc) That way, when you want to add other actions that are based on a given page's contents, there is a common place for it.

Just my 2 cents.

PS - I think the official 2 cents count on this thread is up to about $3.58, any one want to go for bubble tea with our bug earnings?
(In reply to comment #147)
> We simply have to design for mainstream users if we are going to survive in
> this increasingly competitive marketplace.  Everyone seems extremely interested
> in their own personal usage, and being informed well enough in advance of a
> otherwise pretty minor modification so that they can riot and attempt to
> prevent any type of change.  All of our usage metrics point to the fact that
> this control isn't used enough to warrant inclusion in primary UI.  We're
> designing a product for 400 million people. This bug could contain a million
> comments calling us stupid and it still wouldn't change our desire to create a
> product targeting mainstream users.

Your usage metrics aren't accurate.. I use the icon as a visual reference to rss feeds.. yet I don't click on the icon.. I didn't know it was a button.  RSS technology is still unknown by most users.. removing the icon isn't going to help people learn about it.. it will just kill it.. this was a very stupid move.  Please bring back the icon!!!  Why go backwards?  I know votes don't mean much to you folks, but there are more votes to keep the button than to remove it.. check out the user comments on the Mozillazine forum and on the Firefox 4 Beta forum.. not one user wants to get rid of the icon, but all want to keep.  Why don't you listen to the users?
To all users who are "voting" against this:

1) Your arguments have already been made above.

2) When there is a bug that some population hates, they all show up and complain. Focus on the "all" part of that statement. The ones who are fine with it don't. Saying "look at all the complaints on the forums" like going to the hospital and complaining that all the people there are sick. Hospitals are where sick people go; support forums are where people go to complain about software. (and this is not a forum)

3) If you were paying attention, the RSS button will probably end up as a toolbar customizable button. (bug 596731)
Whiteboard: SEE COMMENT 122 BEFORE COMMENTING! → SEE COMMENT 122 AND COMMENT 147 BEFORE COMMENTING!
(In reply to comment #150)
> To all users who are "voting" against this:
> 
> 1) Your arguments have already been made above.
> 
> 2) When there is a bug that some population hates, they all show up and
> complain. Focus on the "all" part of that statement. The ones who are fine with
> it don't. Saying "look at all the complaints on the forums" like going to the
> hospital and complaining that all the people there are sick. Hospitals are
> where sick people go; support forums are where people go to complain about
> software. (and this is not a forum)
> 
> 3) If you were paying attention, the RSS button will probably end up as a
> toolbar customizable button. (bug 596731)

So if you know of all the arguments.. why not change this bug?  Do you really think the icon is taking up valuable space.. get real.
@Dave

I find your second comment insulting. The people that go to Mozilla forums are not a bunch of complainers.  We are Firefox USERS and Firefox FANS that want to check up on the latest and greatest with the upcoming releases.  We only complain when something like a useful feature is UNNECESSARILY removed.

About the button.. that is definitely going backwards as it WILL take up valuable space.  The icon IS useful and in the URL bar it doesn't take up any valuable space.. so what is the problem.. why remove this feature.. what harm does it do?

By the way I don't think you bunch are stupid.. I just think this idea/bug is stupid.. you all are very smart.. I thank you for all your hard work.
(In reply to comment #151)
> So if you know of all the arguments.. why not change this bug?  Do you really
> think the icon is taking up valuable space.. get real.

I've had to explain this concept to a few people who have started yelling in recent new bugs: some things get real debates (not arguments) but real debates end. The result of this bug was a series of compromises in addition to the main part going through, and even if I personally wanted to keep the icon, it's simply NOT my decision.

(In reply to comment #152)
> I find your second comment insulting.

I find your comments insulting. Any offense from my second point of comment 150 (which I assume you're referring to, rather than my second comment in the bug up in comment 7) was generated by yourself, because it didn't come from me.

People are complaining that they're loosing a feature they use, but you can't point to other complaints as evidence of validity of your own complaint. It doesn't work like that, which is what I was pointing out.

> The people that go to Mozilla forums are not a bunch of complainers.

This is not a forum. Also, complaining itself is not necessarily bad. Complaining here, without new arguments, way after the fact, is.

> We are Firefox USERS and Firefox FANS that want to
> check up on the latest and greatest with the upcoming releases.  We only
> complain when something like a useful feature is UNNECESSARILY removed.

The discussion happened before you were here, and right now, you have no say in the matter. Bugzilla etiquette point #2: "Open Source" is not the same as "the developers must do my bidding."
https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

Again, for the umpteenth time, a feed toolbar button is being added and there WILL be an addon to add it back to the address bar. If anything annoys anyone in any new major Firefox version, at least one person always creates an addon to add it back. The only debate is essentially over defaults, so if you want your browser your way you won't really be affected all too much in the end.

> what harm does it do?

This question was answered earlier in this bug. If you can't find the answer or haven't thoroughly read the previous 150 comments, then honestly, you shouldn't be commenting in the bug.

> By the way I don't think you bunch are stupid.. I just think this idea/bug is
> stupid.. you all are very smart.. I thank you for all your hard work.

You can't be rude and erase it with a catchall. That too, doesn't work like that.

The world has not ended with this bug landing, and no comment added to this bug will do anything but fill up the inboxes of the people listening here. Even if this change were to be reverted, it would probably be done in a new bug. This bug is closed and done. All new work and discussion is in follow up bugs. Stop posting here please.
@Dave

Okay you win.. this will be my last post here.  You sure like to twist peoples words, and place blame on the users.  The developers have been ignoring this in the forums.. that's why I came here.  I've read the reason why.. because of some usage metrics.. doesn't seem like a good enough reason to me.. specially since not all users click on the icon, yet like to know that the RSS content is on the site (meaning being used, but usage not recorded).  From what I've read, there are more reasons to keep the icon, than to remove it.  The reason I didn't bring this issue up earlier is obvious.. I didn't know about it till last week.. you're not getting out to the users.  Most of us just found out about this.. How could we have discussed this on the forums/blogs if it wasn't brought up there (that I've seen)?  And yes I know this isn't a forum, yet it doesn't mean I can't comment here.  Me rude?.. I think you're talking about yourself.

IMO user surveys should be done before removing a feature such as this and usage metrics is not a survey.

To everyone else.. Thanks for your hard work! :-)
Blocks: 599735
No longer depends on: 597644
Surveys are a weak mechanism for design. Data should be collected in order to feed the process, which is itself an art not a science.

Evangelism is not welcome in Bugzilla. I'm removing myself from this noisy bug, please do not re-add me. We're done here, although several virtuous followups should be followed-up so that RSS becomes part of the bookmarking experience.
Is it possible to restore this in userChrome.css?

The urlbar icon (present/absent) works much better as an indicator than a button (enabled/disabled)
About the significance of feed discoverability:  Most sites are created not from scratch but with some CMS package/app (blog, forum, etc...) and support feeds out of the box.  The creator/maintainer of such a site may not even know anything about feeds or underestimate their utility, he may neglect to add or actually remove the subscription ui from whatever template he uses, but the site will continue to support feeds, and the browser ui will be the only indicator/interface to them.  Removing this ui by default, has the effect of deprecating feeds.  I only discovered the ubiquity and subsequently utility of feeds(in other circumstances than a blog) due to the Fx ui.
How come none of the proponents of this change have addressed the autodiscovery issue? The reason this argument is being repeated is that it is being ignored. 

"Hide it in a menu" is not a solution because that makes the feed discoverable only to those looking for it, i.e. not discoverable in a meaningful way. Firefox doesn't hide the SSL indicator or the "loading" indicator or the "searchplugin available" indicator or the favicon or page title in a menu, nor should it. Not many people click on those and yet they're useful.

"Should appear in the content area" is not a solution because there's no standard place for it, and in many cases it doesn't, and in other cases an apparent feed icon on a page doesn't link to that page's feed. There is a reason <link alternate> is defined in the HTML spec for that purpose and used on almost every site that has a feed.

The argument that inexperienced users wouldn't know what the feed icon means, evades me completely. Strange icon appears -> mouseover, read explanation -> click on it, see what it does -> decide if I need it -> use or ignore/hide. That's how people learn UIs, no?

Btw there's another state the feed icon communicates, one that I find very useful. Just as the active star says "I've bookmarked this", the opaque feed icon says "I've subscribed to this, I will get updates."

A combined bookmark/feed icon in the addressbar wouldn't take up one pixel more. This would only imply an extra step when trying to bookmark a page that offers a feed. Something like the dialog that comes up when clicking on "star" on an already starred page, with a "subscribe" button in addition to the default action "bookmark this". It makes sense to present users with that option -- sometimes a live bookmark is what they really want.
(In reply to comment #159)
Your comment is over the top and a clear violation of bugzilla etiquette, and as a result, is not welcome here.  Of course, you know your comment is inflammatory given the number of bugzilla accounts you have had disabled due to etiquette violations.

This behavior is not acceptable.
I don't think the RSS button should be moved. I rely on this button to pick up RSS feeds when they're available to add them to Google Reader. This is an important piece of functionality for me. Please re-consider.
Beating a dead horse, blah blah, etc.
http://bugzilla.mozilla.org/page.cgi?id=etiquette.html
This might already be reported, but I didn't see anything after a quick search and seems to be regression from this change.

In FF4.0b8 / windows the bookmarks "subscribe to this page" functionality does not appear to work.

Steps to reproduce:
1. http://news.valex.com.au/
2. Subscribe to this page

Expect:
User is taken to the feed preview / subscription UI for http://news.valex.com.au/?q=rss.xml in a similar fashion to clicking on the old RSS icon.

Actual:
User is taken to feed://http//news.valex.com.au/?q=rss.xml ; which is not handled by firefox.
(In reply to comment #163)
> Steps to reproduce:
> 1. http://news.valex.com.au/
> 2. Subscribe to this page
> 
> Expect:
> User is taken to the feed preview / subscription UI for
> http://news.valex.com.au/?q=rss.xml in a similar fashion to clicking on the old
> RSS icon.
> 
> Actual:
> User is taken to feed://http//news.valex.com.au/?q=rss.xml ; which is not
> handled by firefox.

I'm running the nightly builds from http://nightly.mozilla.org, and it works fine here.

Check that you don't have any extensions that may interfere with this (starting in safe mode or with a clean profile), and/or try the latest nightly build, please. :)
(In reply to comment #147)
> We simply have to design for mainstream users if we are going to survive in
> this increasingly competitive marketplace.  Everyone seems extremely interested
> in their own personal usage, and being informed well enough in advance of a
> otherwise pretty minor modification so that they can riot and attempt to
> prevent any type of change.  All of our usage metrics point to the fact that
> this control isn't used enough to warrant inclusion in primary UI.  We're
> designing a product for 400 million people. This bug could contain a million
> comments calling us stupid and it still wouldn't change our desire to create a
> product targeting mainstream users.

Those usage metrics capture only clicks. They do not capture any status-like information:

For example, a heatmap does not show loading icons, throbbers, which urls are loading, “Done” message, etc. In fact, any status-like information won’t show up in a clicks heatmap. So if that information does not show up in a clicks heatmap, it does not mean these status-like must be removed from the UI.

Well, I noticed that all those status-like information have been removed from Firefox 4.

As for the feed button available in the customize toolbar, it does not show a status. We need to click on it to see if there are any feeds available.

Is there an issue number to fix this button to at least highlight when a feed is available?
Flags: in-testsuite?
This removal is nonsense, and all the arguments have been made to defend it. However the minimum compromise I expect is that the icon be removed by default but if you drag it from the icon customizations to the toolbar it gets fused into the address bar as per FF3.5 behavior.
The old behaviour was really great ! Please put it back.
(In reply to comment #167)
> The old behaviour was really great ! Please put it back.

Mr. Beltzner and the moz-dev team already said that they don't give a **** about what you ask. Like it that way, or change the browser.
RSS icon in location bar immediately gives you the answer - is there any RSS feeds for this page or not. It is shown to each user of the browser and there's no chance user may miss the RSS of the page. Let's say it is auto-discover of information - site RSS feeds.

Having in mind that feeds gives ability to manage the information stream - it makes it really important and handy.

Removing RSS icon simply kills auto-discovering RSS feeds - you wouldn't ever see page feeds if you didn't intend subscribing to it. Both RSS button and feeds submenu in bookmarks.

If developers f**k your opinion - simply use https://addons.mozilla.org/ru/firefox/addon/rss-icon/

And yes, it looks really fine RSS icon and bookmark icon together in location bar. Google Chrome is not a good idol to follow.
(In reply to comment #169)
> Both RSS button and feeds submenu in bookmarks

they don't satisfy these needs
I have to agree with comment #166.

This is like the http:// removal in the address bar, for which I've never seen a good argument on desktop browsers (aside from as a workaround for IE9's broken decision to cram the address bar into the same line as the tabs) and for which Chrome tried to solicit feedback, but just killed the discussion when all they received was solid arguments to revert that decision.

(Things like the counter-intuitiveness and fragility of making copying to clipboard less WYSIWYG)

As much as I distrust extensions for being potentially leakier than userChrome.css, I always use them to fix these sorts of issues when given the choice so they'll show up in Test Pilot studies.
Stephan, this is Mozilla, no one gives a f^Wcare of what users want.
Mister limi decides what users want, not the users themselves.
True. At least we've got about:config and extensions that can truly modify the UI. The poor souls on Chrome don't even have that.
@174:

I'd happily sign and share that petition, but I never sign anything on Change.org because their system refuses the address I give them... I assume, because they're insisting I include an exact street address, rather than just a municipality, province, and country.

It's suspicious enough that they're region-locating using something other than my postal code.
@175:

Change.org seems to be quite popular and that was the reason of choice. Other ideas?
@175:

I'm not sure. I have to deal with so much information in any given day that I don't really keep track of which petitions are hosted where.

I only remember Change.org being one I've encountered before because it's the only place I've ever seen that expects you to enter your full address in a single text field and then hands it off to Google for parsing.
...and there's that "@bugNo" typo I knew I'd make someday.
A petition signed by a relatively small group of people is not something that's going to be considered by those in a position to change things here. In fact, this sort of thing is pretty bad etiquette here. It's a long since settled decision. Let it go.

For those who don't bother reading all the comments here, or even those up top, the reason it was removed was not just due to lack of use. It was the only top-level thing in the default UI that could not be easily learned by a novice just clicking around. It was prone to confusing people that clicked on it. (yes, really) Yeah, it kinda sucks that things were changed to be better for the lowest common denominator here, but you have to admit that this is often necessary for software used by millions.

I was personally against removing it, though I couldn't disagree that much with the argument for doing so. After quite a while with it gone, however, I don't really miss it. I so rarely add new RSS feeds that I've not had a problem with just using the bookmarks menu to get it. Yeah, the primary benefit to the button was its indication if a feed existed, but it turns out that's not really as useful as I thought, at least to me. If it really is to you, there are addons to add it back or you can use the built-in toolbar button. Again, yeah, it would've been much better to have a built-in option to add it back to the address bar instead of the location bar, but they didn't do that. This is not a battle worth digging up to fight again...
For reference, the toolbar button can be added by right-clicking on the toolbar and dragging the icon to wherever you want it. Here's an addon to put it in the address/location bar:
https://addons.mozilla.org/en-US/firefox/addon/rss-icon-in-awesombar/
> It was the only top-level thing in the default UI that could not be easily learned by a novice just clicking around.

May be better just to tell users what is that instead of removing? Each time when Google Mail interface changes it would be much more confusing if the didn't explain changes. But they do.
I want to reopen this discussion because I think RSS deserves a better visibility. The “adoption” term has been mentionned earlier in the comments. The truth is that since this icon has disappeared and moreover since the last comment, some new ways for following sources are displayed more and more prominently on websites whereas RSS icons disappear slowly. I am naturally speaking about Facebook, Twitter, Google+, Pinterest or other services like that. The problem is that those platforms are the opposite of the open Web that Firefox promotes since its begin. I plead for a better visibility of the RSS icon not in an UI point of view but more in a philosophical one.
(In reply to Dave Garrett from comment #180)
> For reference, the toolbar button can be added by right-clicking on the
> toolbar and dragging the icon to wherever you want it. Here's an addon to
> put it in the address/location bar:
> https://addons.mozilla.org/en-US/firefox/addon/rss-icon-in-awesombar/

I like this extension, but it doesn't work for newer Firefox versions.

The toolbar icon works, but

1. Many users don't know there is such an icon because it doesn't show by default. They have to carefully examine the web page to find an RSS link.
2. The icon is always there, grayed out if there are no RSS sources in the web page. The one in awesomebar will only appear when the web page has RSS sources, and it doesn't take extra space in the crowded toolbar.

It would be great if I can add that icon into the awesomebar as the extension did. Sadly it no longer works.
(In reply to lilydjwg from comment #183)
> (In reply to Dave Garrett from comment #180)
> > For reference, the toolbar button can be added by right-clicking on the
> > toolbar and dragging the icon to wherever you want it. Here's an addon to
> > put it in the address/location bar:
> > https://addons.mozilla.org/en-US/firefox/addon/rss-icon-in-awesombar/
> 
> I like this extension, but it doesn't work for newer Firefox versions.
> 
> The toolbar icon works, but
> 
> 1. Many users don't know there is such an icon because it doesn't show by
> default. They have to carefully examine the web page to find an RSS link.
> 2. The icon is always there, grayed out if there are no RSS sources in the
> web page. The one in awesomebar will only appear when the web page has RSS
> sources, and it doesn't take extra space in the crowded toolbar.
> 
> It would be great if I can add that icon into the awesomebar as the
> extension did. Sadly it no longer works.

These days, I'm using Classic Theme Restorer as an all-in-one source for most of my UI customization and it has that as an option. ("Urlbar settings -> RSS feed-button")
(In reply to Stephan Sokolow from comment #184)
> These days, I'm using Classic Theme Restorer as an all-in-one source for
> most of my UI customization and it has that as an option. ("Urlbar settings
> -> RSS feed-button")

Thank you, I'll try that when I have to upgrade from Firefox 28.
(In reply to Stephan Sokolow from comment #184)
> (In reply to lilydjwg from comment #183)
> > (In reply to Dave Garrett from comment #180)
> > > For reference, the toolbar button can be added by right-clicking on the
> > > toolbar and dragging the icon to wherever you want it. Here's an addon to
> > > put it in the address/location bar:
> > > https://addons.mozilla.org/en-US/firefox/addon/rss-icon-in-awesombar/
> > 
> > I like this extension, but it doesn't work for newer Firefox versions.
> > 
> > The toolbar icon works, but
> > 
> > 1. Many users don't know there is such an icon because it doesn't show by
> > default. They have to carefully examine the web page to find an RSS link.
> > 2. The icon is always there, grayed out if there are no RSS sources in the
> > web page. The one in awesomebar will only appear when the web page has RSS
> > sources, and it doesn't take extra space in the crowded toolbar.
> > 
> > It would be great if I can add that icon into the awesomebar as the
> > extension did. Sadly it no longer works.
> 
> These days, I'm using Classic Theme Restorer as an all-in-one source for
> most of my UI customization and it has that as an option. ("Urlbar settings
> -> RSS feed-button")

Thank you so much! It works for me greatly. The current version of Firefox and extensions work much better than the last time I tried :-)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: