(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.
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.
Television-shaped objects (video series, podcasts) are RSS-like in that they have an order and periodic updates but their size makes them a little harder to handle -- and they're pre-compressed non-text.
Video games are a different problem but I don't think it's common to play MMOs seriously on portable systems with unreliable connections.
@enkiv2 Eh, there's various MMO architectures designed around those limitations - Pokémon Go comes to mind.
And I hear the kiddies are playing MMOFPSes lately on their phones...
Right, but I was interpreting your idea as offline-first, like SSB or Avant-Go -- i.e., content gets updated on the mobile device only during user-controlled periodic syncs.
This makes sense for store-and-forward and for subscriptions, but online games with high interactivity are going to have problems with day-long pings.
@enkiv2 I'm thinking always syncing when a connection's available, but keep working with whatever's been obtained when disconnected, and have the expectation of a low-end device that can't handle the modern internet and needs server assistance to pre-chew content for it. (Think... less performance than a Raspberry Pi 1.)
Basically, apply the ideas from the once-daily-sync era to a device with modern connectivity. So, you don't have to wait for sync time, but it still works like those devices.
Makes sense. The goal is to ensure that even in fairly extreme cases the user still basically has what they want though, right? So it doesn't make a lot of sense to imply that, say, an online button-mashing fighting game is possible.
MMOs are more complicated in how they deal with this kind of thing, so maybe they're actually better suited.
Like, an MMO is almost a wiki-style syncing problem to begin with: multiple users have copies of an initial state, which is processed locally, and they make changes that are merged on the other side in a way that ideally can be synced back without people noticing unexpected glitches -- and the longer the lag the more obvious the glitches. Since it's mostly noncompetitive the glitches are merely annoying.
Counterstrike would be very different.
@enkiv2 I don't think this exactly aligns with my goal - I think it's OK to say "sorry, you can't connect right now" to something that actually requires real-time connectivity.
The goal is really more to make the functionality that actually matters for smartphones possible on a far simpler, cheaper, and longer-lasting (both in terms of device longevity and in terms of battery life) platform.
If you want to play a game on it that requires being constantly connected, be my guest.
@enkiv2 But, fundamentally, the focus is... enable the communications that people do with their phones, with as little on-phone resources as practical
Some of that's inherently realtime - I mean, making a phone call, the supposed core functionality of a smartphone, is realtime - and some isn't.
@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.)
@enkiv2 So, essentially, you take content from all over, and a server under your control (or an account on a server you're paying for) gives you the sequences however they came, reformats things to be usable without a web browser, and also resequences them for you based on what it thinks you want (I adored Gmail's Priority Inbox when I used it, I want more of that tbh, but not controlled by Google, controlled by me. Make it work for RSS, too!)
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.)
Yeah, just preprocessing to remove embedded markup will help considerably, since all parsing goes away.
@enkiv2 I think about how much more hardware we have nowadays, to do the same things we did in the past with phones.
Fundamentally, I'm reading articles, IRCing and IMing, e-mailing, watching the odd video, and doing things in between those tasks.
I was doing the exact same things on a 312 MHz XScale 10 years ago, as I am on a quad-core multi-GHz Qualcomm ARM chip today.
Granted, it didn't work as well back then, but a fair amount of that was just bad implementation, the hardware could do it.
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.
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.)
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.
(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.
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.
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 @enkiv2 @drwho I've done a lot of international travel recently, and found that using standard web search for 'where's the nearest coffee shop with vegan cake' type inquiries are not nearly as useful as I expected. More specialized tools for common types of queries would be great. Problem: device can only handle so many apps (for both storage and UI reasons), and if it's on the web I need to a) know where, and b) remember that when I need it. This is why effective sites become legend
So, another use case for phones that is quite common is... I'm going to call it mapping, although that's a really broad, multi-layered category.
You have the problem case of, "I want to get from point A to point B", that navigation apps solve.
You have the problem of "where is point B?", that many navigation apps also solve.
But then... "what is point B?" is another question that's commonly asked.
That's... clearly reference material, not threaded streams. Myself, I end up using sites and apps like Yelp (I know, I know) for this. Google also tries to push into this space quite hard.
I'm wondering how this translates into a rigid model, really, because it's such a hyperspecialized use case, but it's such a common one, too.
It's pretty suitable to pre-loading though.
Maybe what we're missing is a second mechanism of access. We have threading, but what we need is search (wherein search produces a new pseudo-thread based on available material -- either already downloaded or filled in as necessary)
Search constructing new streams is... actually that's something that was half-floating around in my mind too, so that might be it.
And, then, it's just a stream/thread of places (each with their own discussions (reviews)), and some metadata (menus and such can be presented as attachments).
@enkiv2 @strypey @drwho Mind you, I feel like this isn't a communications task, so even if it uses the same standard threading UI widgets (although with adaptations to the different dataset - rating, price, and distance are things that are irrelevant to the communications application, but highly relevant to this), it shouldn't be in the communications application itself, but rather inside of a navigation application.
@bhtooefr @enkiv2 @drwho yup, we ended up using goOgle maps far more than I would have liked. #OpenStreetMap is fine when you're in a country that speaks a language you speak, otherwise it's less than helpful. Also it can't handles 'where is the nearest coffee shop' type inquiries, and even struggles with 'where is the nearest Starbucks'.
@strypey @enkiv2 @drwho I feel like this is a huge shortcoming of legacy mapping solutions - at best they can give you whole categories of things, sorted purely by distance, and with no ability to filter beyond "is this a restaurant"?
OpenStreetMap seems to spend way too much time copying legacy Garmin/TomTom-style mapping, resulting in Google Maps providing a vastly superior experience...
@bhtooefr @enkiv2 I've done it with a bot that renders HTML into text and shoves it into an Etherpad page (https://github.com/virtadpt/exocortex-halo/tree/master/paywall_breaker) but the problem there is you lose all text formatting. Problematic to skim through at best, requires re-editing later for legibility. I've since migrated to Wallabag (https://github.com/wallabag/wallabag), which is much more friendly.
@enkiv2 @bhtooefr Honestly? For that use case I use e-mail. For lower priority stuff (like news precis) the data gets e-mailed to the account my mobile is hooked to, and I scan through it when I have time (or dump it if I'm out of gift a shit).
For higher priority stuff I use XMPP, and for crash-priority stuff I use Pushover or speech synthesized phone calls.
@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.
Have you ever read this paper, which lays out how you could build a social network client on top of email protocols?
Also Ward Cunningham's smallest federated wiki is much more like a series of email-shaped objects that most wiki systems:
Une instance se voulant accueillante pour les personnes queers, féministes et anarchistes ainsi que pour leurs sympathisant·e·s. Nous sommes principalement francophones, mais vous êtes les bienvenu·e·s quelle que soit votre langue.
A welcoming instance for queer, feminist and anarchist people as well as their sympathizers. We are mainly French-speaking people, but you are welcome whatever your language might be.