Using the indieweb easily from my phone has been hobby horse of mine for a while now. A few of us brainstormed the indieweb’s next big thing over the weekend, and one idea that caught my eye was an “offline first” mobile client that’s fully functional without connectivity and syncs to your site when it is connected. This is a small but growing pattern among modern mobile apps, and it’s great.
We could build this as a native mobile app or library, maybe using an existing mobile offline sync platform, but the indieweb community prefers the mobile web to native apps. So, let’s consider it a challenge!
Here’s a hand-wavy straw man design for a self-contained, browser-based mobile micropub client on top of HTML5 and localStorage, which all modern mobile browsers support:
- You load it in your phone’s browser, then save it so it’s usable offline.
- When you’re connected, it fetches your site, crawls your feeds, and stores your posts locally. Maybe all of them, maybe just the most recent or another heuristic. Could use Web Workers (well supported) and/or Service Workers (less supported).
- You can compose new posts and edit existing posts offline, using only localStorage.
- When you’re connected, it publishes your updates via micropub.
Note that due to the
same origin policy, your site
will need to set CORS headers (e.g.
Access-Control-Allow-Origin) to allow the client to download its data and post
to it via micropub.
Bonus features:
- Easily post pictures, videos, links, and other content by sharing/sending them to the editor via deep linking (aka intents aka app links).
- Download your site’s nicknames-cache, venue database, syndication targets, and other data to provide a better posting UX.
- Register for web actions so you can use it to easily indie reply, like, etc.
- Download your moderation queue, ie pending webmentions and native comments, and let you approve or reject them. (We don’t yet have a standard for this.)
There are plenty of example apps with good UXes for managing posts offline and updating when connected: WordPress, Tumblr, SimpleNote, Quip, and most email and messaging clients, just to name a few. They’re worth studying for UI ideas and techniques.
This isn’t an itch for me personally, since my site already has a great mobile app, so I’m probably not the right person to build it. I’d love to see it happen, though. Who’s interested?
Pingback: Ryan Barrett
Pingback: Ryan Barrett
cool. Still not enough! I’ll write a post on my flight. Just boarded, so it’ll be a bit :)
looking forward to reading more of your thoughts on the topic.
it’s not the final piece of the puzzle but I’m hoping that eddiehinkle.com/indigenous can help fill some of the gap.
So putting away my embarrassment that my last two project ideas were your ideas first…
I’ve been trying to gather information about offline frameworks and such. I got excited about hood.ie and the way the frontend communicates with the backend only via CouchDB sync. You’d write a post, save it to the local db. Then when you want to publish, stick a publish task in the db, and when that task makes it to the server (whether now or the next time you’re online) it would go ahead and send the micropub request, and update the model with the URL of the published post. But when I started looking into the bits of server-side logic it’d need, I was pretty overwhelmed. Extending the server-side seems relatively unexplored (by people outside the core team).
Back to the drawing board a bit. I might still try to use PouchDB/CouchDB with a simple Flask app on the server and vanilla javascript on the client, or I could manipulate localStorage directly and handle “syncing” (pretty trivial in my case) manually, using Offline.js to detect connected/disconnected. Not sure I could get anything interesting done in a day. Kiiinda wish we had a frontend dev who could hold my hand :)
Or I might back-burner this altogether and work on private posts instead, or just hope to be inspired on Thursday.
Once again I’m finding myself wishing I had time to work on Publ. I really need to get around to writing a MicroPub endpoint for it! (And all the related stuff necessary to make it actually work…)