Closed Bug 569816 Opened 14 years ago Closed 6 years ago

Implement way to open Live Bookmark in a new tab

Categories

(Firefox :: Bookmarks & History, enhancement)

enhancement
Not set
normal

Tracking

()

RESOLVED INACTIVE

People

(Reporter: tiago.morbus.sa, Unassigned)

Details

Attachments

(3 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 (.NET CLR 3.5.30729)

The problem:
Users don't have an easy to way to see their Live Bookmarks with the whole info they have available (images, summary and all), and most assume they can only see them in their Live Bookmark format, which is titles and permalinks only.

The concept:
Basically, we already have the technology to do this. If we open a Live Bookmark in a tab (like so: http://news.google.com/news?output=rss ), it will display their whole content. So the idea is to allow the user to open the feed in a tab. There are two simple ways to do this, that I can think of. One is to place a small icon somewhere in the bookmark that the user can click to open the live bookmark in a tab. This has the benefit of being discoverable, but has the downside of being potentially hard to design. Another way is to create a contextual menu entry (or an entry in the live bookmark itself) to "See full information" or something like that. This is less discoverable, but it's simple to design (you just need a proper label, see full info isn't really ideal, I think). I'll upload a mockup right way.

Target for implementation:
I believe we should have this in by Firefox 4. A user raised a valid point (here: http://groups.google.com/group/mozilla.dev.usability/browse_thread/thread/3d1e24561028c4fe ) that it's something to think about, what with the AppTabs and the in-content UI and all, and I agree with it. Considering this is easy to implement and test, I can't see a time/resources related issue with this.

Emergent design problems:
There may be one or two minor details with this implementation. The first and most obvious being the question "why can't we subscribe a RSS feed like a normal page, and open it in a tab like a normal page?" I don't think allowing the user to subscribe to a feed in a normal bookmark is easy to implement, but I also don't think this is a more pressing question with the implementation I proposed than with the current Firefox implementation. There is also another minor issue in terms of interface, which is we shouldn't ask the user to subscribe to an already subscribed feed. This is also relevant to the current implementation, and shouldn't be exceedingly hard to fix: if it's already bookmarked (and the browser detects it is, because the star is yellow), the browser should just display the feed and shut up, or, better yet (maybe?), show a smaller prompt, in case the user wants to change his subscription method. This isn't a pressing issue, in any case.

Reasons not to implement:
Besides laziness/lack of resources (which I don't think happens here because this is mighty simple), I don't really see any reason not to implement this. Unless you're going for a design decision of "no! we DON'T want the user to easily see the whole content of the feed!"

Mockups:
I'll upload them right away

Reproducible: Always
This clearly shows the idea for my second (easier) solution. In terms of interface, of course. In terms of implementation, it should be mighty simple.

My first idea is way harder to design, and I can't really think of an effective way that doesn't clutter the interface and make it overly complex.
Version: unspecified → Trunk
Assignee: nobody → rogerio.rag
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Attachment #586642 - Flags: review?
Open in a new tab is already possible with ctrl + click (default behavior).
Attachment #586642 - Flags: review? → review?(firefox-reviewers)
Attachment #586642 - Flags: review?(firefox-reviewers) → review?(mak77)
most of the livemarks implementation is changing towards an async one in bug 613588, that also changes 90% of the code touched here, so this is somehow complicated to evaluate now and I'd probably delay it a bit to build on top of the new code.
I'm mostly puzzled by the feedWriter change, looks a bit too hackish and out of context as it is... Though atm I have no ideas on how to handle loading the feed preview without header in a more generic way.
The new code preserves the same behavior, that is the same screen is displayed when adding a new feed?

When the new code will be available?

The changes are simple, adds a menu item and filter if the feed has been subscribed and hiding your subscriptions.

If it's important we can try to apply the idea to the context of the new code.
Comment on attachment 586642 [details] [diff] [review]
Patch to this bug.

(In reply to Rogério Gonçalves from comment #6)
> The new code preserves the same behavior, that is the same screen is
> displayed when adding a new feed?

Yes, what changes is the livemarks service api.

> When the new code will be available?

Hope really soon, I'm working on it to try finalizing for current v12.

> The changes are simple, adds a menu item and filter if the feed has been
> subscribed and hiding your subscriptions.

Yes, the first part is fine, I just have some doubt on the second part, since the user may want to change his default rss handler while this way we hide that possibility for existing live bookmarks, even just visiting again a feed while browsing, not just from the menu link. Thus I wonder if there may be a better way to ask opening the preview without the header.
Mano knows the feed preview code deeper and may have ideas regarding that.
Attachment #586642 - Flags: feedback?(mano)
Another possibility would be create a show/hide button on the feed preview header.
So the user can change the default rss handler when previewing the feed.
When a new rss feed is previewed, the header is shown.
After adding the rss feed the preview shows the header collapsed, with the show/hide button.
Attachment #586642 - Flags: review?(mak77)
Marco, I'm working with Rogério. Could you please let us know when the new RSS Feed code will be available?
Sorry, I have another feature to finish along these days, then I can come back to that. Hope to have it for the next week.
sorry for late (really), the new code landed in central, so you should be able to build on top of it
Comment on attachment 586642 [details] [diff] [review]
Patch to this bug.

Couple of things:
1. This needs ui-spec/ui-review (probably very little, but still). In particular, a decision is needed for the current purpose of the feed preview page. I suggest you take care of that before continuing your work on this patch.

2. If this mode (preview, not subscribing-oriented) is introduced, it shouldn't depend on livemarks, at least not in the "API" level. That is, the non-subscribing mode should be set somewhere outside of the FeedWriter.

3. Don't refer to bug numbers in code when there's no good reason (workaround, usually ).
4. If we end up just hiding the subscription area in this mode, use the hidden property. Otherwise, you should set some attribute on the body and tweak the page for this mode in the style sheet.
5. Don't use hard tabs.
Attachment #586642 - Flags: feedback?(mano) → feedback-
Assignee: rogerio.rag → nobody
Status: ASSIGNED → NEW
Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: