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

Show thread

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.

Show thread

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.

Show thread

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

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.

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

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

Ahhh. OK.

I was thinking of this in terms of trying to categorize stuff for the sake of organizing synchronization & distribution, assuming that basically all technologies would be reinvented for it anyway.

If you're thinking of an email-inbox/rss-reader style periodic-syncing local-storage interface for existing things, that's a pretty different situation -- one that's a little easier to implement but harder to guarantee good performance from.

@enkiv2 Note that a lot of performance issues can be solved by throwing a modern desktop computer or rackmount server at the problem, instead of trying to do it on the phone, though...

(That said, that's no excuse for not writing tight code, but it means that techniques that are only barely practical on a modern smartphone application processor can be done on a server, letting the smartphone have what would be considered a microcontroller nowadays.)

I think @drwho might be worth bringing into the conversation since he already has a framework for pulling down content he's subscribed to and preprocessing it. From what I understand, the processing isn't optimized for making it easier to handle on lower-spec machines, but maybe some ideas are applicable to low-connection and low-spec machines.

@enkiv2 @drwho Oh, and another element of this is... I'm kinda in a mood to kill the web - suck its brains (content) out, put it into another form that's easier to work with.

Of course, I realize some issues here - web-style search actually is a very common usage model for mobile internet, for starters. (People do use phones for up-to-the-minute unpredictable reference material - "is this business near me open?" as an example. That's not something you can easily cache on the device.)

@enkiv2 @drwho And, another model that I just thought of that phones are used for: commerce.

That could be contorted into a threaded model (here's a stream of the products available), but wow that would be ugly. And, store-specific apps won't happen (critical mass needs to happen for that), and sucking brains out of something handling payment information is questionable, so... shit, I think there does have to be a web browser.

· · Web · 1 · 1 · 0

@bhtooefr @drwho
Is that a bug? Because, that sort of sounds like a feature :P

@enkiv2 @drwho The problem is, I think for a lot of people, it would make the platform a non-starter, not being able to shop for or buy shit.

(And note that comparison shopping while in brick and mortar stores is a common use case of smartphones, too.)

And yes, even people on here. After all, lots of us buy things off of eBay, or give to people's Patreons, ko-fis, or GoFundMes, and probably do it on the go, too.

@bhtooefr @drwho
What I mean is: if this is an overall better mobile device, and it's used by people who also have home computers, discouraging impulse purchases on the go & providing no mechanism for advertising and in-app purchases are probably features.

Purchasing things on a phone is often an accident. Looking at prices can be distinct anyhow. If somebody does their window shopping on their phone and then makes the decisions at home, that's probably good for a lot of people.

@bhtooefr @drwho
And on the other hand, if this is a single app that simply does 90% of what we want to do with 10% of the bloat, people will still be able to switch out of it when necessary.

@enkiv2 @drwho I agree, but that still requires a web browser, ultimately, and it's a *huge* use case of smartphones (also the research case, which is something that the web legitimately does well).

Basically, the /ultimate/ point of this thread was, "how can we kill the web browser on the phone, to enable much lower-end phones".

I think in practice, we can't. We can certainly reduce its usage, and I think we can reduce its performance requirements (apply the Opera Mini approach to Firefox).

@bhtooefr @drwho
There's also the possibility of applying the man-in-the-middle principle to a greater extent and have the 'browser' be a thin client, where the actual browser is running on the person's personal desktop at home...

@enkiv2 @drwho That's exactly the Opera Mini approach (except it runs on Opera's servers)

Opera Mini's servers render the end state of the DOM after the JavaScript has done its thing to "Opera Binary Markup Language", a prechewed format for the Opera Mini client that requires minimal processing. (The servers are aware of things like the screen dimensions and how the device's fonts will render, as well, for positioning elements.)

@enkiv2 @drwho Basically, my idea is... adapt Firefox to do this, and see where it goes. (I feel like Browsh is the beginnings of this, but Browsh is trying to do different things - it's rendering to a fixed-width console, and it's willing to update the console at will, you can fully interact with JavaScript and even "watch" videos through it.)

@enkiv2 @drwho (OK, it's not just my idea, some other people on the Fediverse have suggested it.)

This could take advantage of the fact that it's not rendering to an Xterm - things like animated GIFs and videos could actually be sent to the device and handled on-device. But, it would also need to not change the DOM at will, without a round trip (so all JavaScript stops until there's an interaction with something that needs it).

@enkiv2 @drwho (You could probably, for round trips like that, diff the markup, though, so that less traffic is sent - AFAIK, Opera Mini does not attempt this.)

@bhtooefr @drwho
Yeah, I was thinking along the lines of something like:

* Server sends static images only when they change (possibly in terms of a diff from the current image), and only checks for changes when the browser indicates the page is fully loaded (by the same mechanism as the reload button is animated)

* Client sends only events to be emulated (clicks, scroll wheel manipulation, keys)

@bhtooefr @drwho
In other words: both extremely light and extremely thin, on both sides.

@enkiv2 @drwho Yeah, that's basically what Opera Mini does (except it doesn't send scrolling or keys).

Lazy loading is a nasty one for this, although you could probably detect it and have a trigger for a round trip (and have the server lazy load ahead of the client). And, finally, there's simply having an option to force a round trip at a certain point on the page (maybe "update page" in addition to "refresh").

Sign in to participate in the conversation

Server run by the main developers of the project 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!