When you realize that almost every damn thing we do on the internet today is a vaguely e-mail-shaped object, the idea of a web browser really starts looking obsolete.

(Wikis and other reference material are really the biggest exception to this, just about everything else that's actually used fits into the e-mail-shaped model, if you can add a discovery mechanism to the e-mail-shaped UI.)

I'm wondering how a phone with no web browser at all, but robust server-assisted RSS reading (including retrieving the entire referenced article and all comments, and threading it all) integrated into an e-mail-like client would work.

Basically, I'm thinking... the Zen of Palm effectively says that a lot of things shouldn't be done on a palmtop at all, just provide a way to collect info so the user can do it at home on their real computer.

I'm wondering if web browsing (that is, going on the web to discover content) is actually one of those things. Use AvantGo-style preprocessing of web content to make existing streams of content readable on the go, but maybe don't even try for discovery.

@bhtooefr
There are email-shaped objects, wikis, and television-shaped objects. All three are pretty amenable to lazy loading.

Email-shaped objects are well-suited to store-and-forward (and even centralized ones have at best eventual consistency anyway so the same mechanisms can be used for offline-first systems the way SSB does).

Wikis need to be synced periodically but probably can be heavily compressed. Codebases are the same.

@enkiv2 I was actually counting the television-shaped objects in the e-mail-shaped object set, although there are differences in presentation.

(Fundamentally, a YouTube video is the root of an e-mail-shaped thread in my vision, just with the body being a video instead of text. Playing a video does require vastly different UI and has different data requirements, though.)

@bhtooefr
I'd distinguish them only insomuch as there are hugely different data requirements.

With any comment system, it's conceivable for any user to preemptively archive all the content the user is likely to want to read. I can put all of wikipedia and all of project gutenberg on my phone. I can't do that with the whole archive of one longish-running podcast.

@bhtooefr
However! Also, we can distinguish based on primacy of comments.

Video responses to youtube videos aren't given the same primacy as text comments to youtube videos, and text comments aren't given the same primacy as recommendations or subsequent playlist entries, and this might not be a bad thing. Seeing it as a series of media objects with one author, and with comments being separate and connected by references, makes sense with the way people consume it.

@enkiv2 That's an interesting thing, how threads are connected, too.

Anything that feels like a natural stream of content feels like the thread UI works well for it... but sometimes elements within that stream can have their own sub-threads. (e.g. YouTube videos could be a stream, but each video has its own attached threads. Fediverse timelines are streams, but have parts of threads interspersed within them.)

@bhtooefr
Yeah. I think of podcasts & youtube videos the same way I think of series on a streaming platform: a sequence of media objects with a specific order, where new elements are append-only.

Some of these things have other second-order things hanging off of them too, like comment threads, but the way I use them I don't actually end up looking at them.

This is an rss vs email distinction, too: is there one entity that controls each sequence, or is a sequence non-centrally controlled?

@enkiv2 I think the way to do it probably ends up looking like this:

The pre-chewing server implements a hierarchy of where things come from. So, you have an e-mail hierarchy, an RSS hierarchy, a Fediverse hierarchy, a YouTube hierarchy, a Facebook hierarchy, whatever, really. APIs and screenscraping are used to construct the hierarchies and the feeds.

There's also views of this content, based on various heuristics. (The master Inbox is basically where things deemed important go.)

@bhtooefr @enkiv2
This actually reminds me a lot of Gnus, the Emacs news reader. It started as a news reader, added email support, added rss support, and there are no doubt quite a few more exotic backends, all with the same threaded presentation.

Follow

@gcupc @bhtooefr @enkiv2

Is Gnus’s RSS module any good? I tried Gnus for email for a while before abandoning it for the vm email reader.

(I still use Gnus for my dwindling Usenet traffic.)

@wrenpile @bhtooefr @enkiv2
It is okay; it does about what you would expect. My main gripe with it was that every feed is a 'group', which you then have to manually organize into topics (if you use gnus-topics). So having a lot of feeds is like subscribing to a lot of newsgroups, and I liked my Gnus main page to look cleaner.

It was better than the other emacs RSS reader, IIRC.

Sign in to participate in the conversation
Mastodon

Follow friends and discover new ones. Publish anything you want: links, pictures, text, video. This server is run by the main developers of the Mastodon project. Everyone is welcome as long as you follow our code of conduct!