M3 mail & RSS-reader
NoAidee last edited by jane.n
When implementing this please do not mix these 3 vastly different functionalities.
RSS subscriptions are a special form of bookmarks, how to integrate with existing code/UI is more taste than technical decision. All a subscrition display needs is a way to query some feed metadata (already done for regular bookmarks).
Displaying RSS feeds requires "just" a special form of a chrome renderer to process special XML tags, keep track of entry tags (read/important/etc.) as part of parsing a feed and additional loading logic to append additional data for paged feeds. Keeping data other than a registry of entry tags should be an option (as well as purging tags for older entries) to save space and improve privacy.
I'm not quite sure I understand why people call RSS a form of bookmark instead of a message? Bookmarks are a static link that you click to pass a URL to the browser to open a page. An RSS feed has a sender, date, topic, and body (often a sample or preview of the page), like an e-mail message. The workflow that I, and others use, is to review the RSS feeds in the reader, which means 'opening the body' and rendering it like an e-mail. This allows us to decide which pages to open and which to skip. Old RSS notifications may be stored and reviewed at a later point, much like an e-mail message. For my workflow, a 3-pane display like the old M2 is ideal, whereas using a bookmark like interface would be useless.
@nemoanonymous M2 was almost perfect, it lacked ability to middle-click on second pane to open articles in new tabs (full pages, not whatever was embedded in feed)
True about middle-clicking the second pane, but most posts (third pane) have a link in them that you can middle-click to open the page, particularly if you have that assigned as opening in background tab. In fact, that functionality is what is missing from every other RSS feed and why, for certain high volume RSS feeds, I still use Opera 12.
- feed selection → Bookmark (URL to check regularly)
- feed content → metadata and items (for each feed)
The bookmark entries COULD be enhanced by the parser(/renderer) component with data retrieved from their corresponding feed or some other data related to feed-specific persisten storage (unread item count).
@nemoanonymous having to left click, move cursor to third pane, middle click, move back and so on isn't the most efficient way of using the reader imo
Still not sure I understand the point... An individual e-mail is a linear mime encapsulated document that has to be downloaded and parsed in its entirety, similar conceptually to an RSS feed. But more fundamentally e-mails are metadata and content just like RSS feeds whereas bookmarks lack content. Why break content and metadata apart when you already have a conceptual framework for handling both together? Particularly when there is an interest in at least a portion of the customer base to implement something similar to M2's functionality for RSS anyway? I don't understand what the gain is to move to bookmarks.
True enough it would be faster. I'd never really considered it that way, so it sounds like a good improvement to me, as long as the ability to open in a background tab is maintained. I typically go through my entire feed first before reading individual tabs, so opening them into the background saves a lot of time.
@nemoanonymous the distinction is feed-subscriptions and mail-accounts.
Interaction with the remote point (appart from reading) is vastly different.
RSS/Atom data is a
XMLfile (generally) retreived via
HTTP(S), containing some header info and (generally) only the latest (5, 10, whatever) "news" items in bulk. A feed subscription is just an URL to this file ("bookmark").
Mail servers provide various operations via user-authenticated sessions. Single message retreival is supported. Transfer protocols and (regular) content do not require an
There is no mention of deviating from the way M2 actually interacts with or displays feeds (from a user perspective) anywhere in this thread (to this point).
The (other) discussion is to give feeds their own side pannel (as I and others would prefer) or
misreuse the mail panel (again).
@nemoanonymous surely I meant "default browser behavior on middle click" so if you set m-click opens in bg then it opens in bg, but some people change that to fg so they are free to do so
@becm you are talking about so called "live bookmarks"
proper RSS reader caches contents and remembers stuff that got removed from feed itself due to size limitations (you can't expect feed to store all entries since the very beginning, can you?)
But yeah, I wouldn't use the mail "panel"/fullpage for that, just the almost exact clone of it to separate concerns
becm last edited by becm
@zakius the extent of feed related persistent data (history size, item flags) was not mentioned so far. I just suggested features to minimize or (partially) remove old/excessive metadata and content.
All functionality is contained within a feed processor/renderer instance and (removal and unread count aside) largely independent from an entry in a subscription overview on the side panel.
There is a more than ten year old RFC to refer to endpoints with older/special items (full history included). Server and client implementations are expected to support this by now.
I can't speak to the back end pieces and will defer to you on that. But there is one other aspect of end-user experience that is what caused me to question this. In other RSS implementation that leverage bookmarks in what I assume is a similar manner, they inevitably create another folder in the bookmarks hierarchy where they store all of these feeds. I find this highly annoying for the same reason you dislike merging mail and RSS: it doesn't belong and shoehorns functionality into a function that makes no sense for 90%+ of end users as most end users use bookmarks as static links. This additional folder becomes something they have to remember to ignore or they can break their RSS functionality (or whatever else is using it).
If the Devs decide to leverage bookmarks in the recommended fashion, I sincerely hope they hide it from the end users and leave it out of the bookmark UI.
@nemoanonymous as already mentioned: I'd prefere an additional side panel for feed subscriptions.
So the only difference to the "3-pane" display in Opera12/M2 for feeds would be no mail (folders/accounts) related distractions in the subscription list segment.