🤔 What the heck is an offline browser app?

[pathall]

@msatokotsubi’s mentioned her work with CMDI-Maker, which if you haven’t heard of it is an app for putting together archival metadata in the browser.

(Check out her cool overview video that explains how CMDI-Maker works.

I find CMDI-Maker interesting because it’s entirely browser-based. Except for delivering the app to the user in the first place, it doesn’t save anything to to a server. Such apps are sometimes called offline apps.

The idea is very powerful, since the whole panoply of web technologies that browsers support (without server-side involvement) can be brought to bear in the implementation of applications. But the concept is a little weird. I mean, wait, we’re doing a non-internet app in the browser? Once you try out something like CMDI-Maker the utility of the approach becomes more apparent (and in my opinion, rather inspirational), but it really is a bit of a head-bender to think about. A non-networked app which lives in an application called a browser which is supposed to be for browsing stuff on the network…

I personally am all in on this “offline app” business. I’m working on an approach to fieldwork software which is based on a bunch of modular offline apps — each one does a specific thing (helps add glosses, generates an output format, does time-aligned playback, etc), and the idea is that they can be sort of “pipelined” together. The output data from one module becomes the input data to another, eventually building up to some of the same things stuff like Flex and ELAN do, or else new things that such apps don’t do.

So I dunno, just bringing up the topic here. Is it familiar to you all? Are you a fan? A non-fan? A shrugger?

[lgessler]

For the right applications I think offline support can be really powerful. For any workflow, though, where you want multiple people to be involved, you’d need to decide how to coordinate changes they make, and that gets pretty hard. PouchDB is, I think, the leading solution to this problem, since it’s a more or less full-on database that can sit inside a client’s browser, but it forces you to use CouchDB in order to coordinate clients, and IMO CouchDB is kind of lacking in some basic database features which can make it hard to develop some kinds of full-featured apps.

That’s all really too bad, because I know that while things are changing rapidly these days I’ve heard from fieldworkers who haven’t had stable internet connections (or any at all) in the field. When I was at ICLDC6, though, I went to a talk from Nick Thieberger where he described how PARADISEC was distributing archival materials to community members without internet: they loaded up a Raspberry Pi (a very cheap, very small portable computer) with a web application that served archival materials, set it up in the middle of the village along with a wifi hotspot, and let people use their cell phones to connect to the wifi network and then to the Raspberry Pi server. There was no internet in the village, but often all we care about is not the entire internet but just a particular computer in it, and in this case, they decided it was good enough to just bring that computer to the village instead of the entire internet.

Ever since I went to that talk I’ve been a little less bullish about offline-first browser apps in the context of language documentation: the choice is between developing a webapp with somewhat inferior features in exchange for an offline-first experience, and developing a webapp with full features in exchange for requiring that field linguists bring a specially set up Raspberry Pi with them into the field when they expect they won’t have an internet connection. The latter seems like a better tradeoff to me.

[pathall]

Thanks for your thoughts! Been in a dry spell around here, I was so happy to see your posts!

@lgessler

For any workflow, though, where you want multiple people to be involved, you’d need to decide how to coordinate changes they make, and that gets pretty hard.

So true. For me, the collaboration problem is separate from the user interface design problem. I have tried (and failed miserably) at projects that required collaboration. I have had more success with problems that are more about a single linguist getting things done. But that’s just me: I like front end stuff, I like the HTML/CSS/JS world.

Language documentation, at least in the early stages, we are not usually with gigantic databases. In the early stages of fieldwork and documentation, after all, every morpheme is a project and pretty much every word is subject to revision. There is this period where big data techniques are just not relevant (NLP, computational linguistics, machine learning, etc), because the data isn’t that big!

In that smaller, earlier world, I think that browser apps are fine. You can use indexeddb (and its heinous API ), you could even use localStorage for certain tasks. They’re clunky and do not scale to very large projects, but sometimes you just want to a edit some interlinear texts and manage a 10K word lexicon (and that’s already pretty big for documentation).

I think an app which helps a linguist to put such a text together as a JSON file is a reasonable target. How to have two (or twelve!) linguists working on the same text, well, I can say from experience that managing files on Dropbox or some other shared folder kind of thing for work like that will be HELL.

Obviously what’s necessary is a server, and synchronization algorithms and (worst of all, IMHO) authetnication and all that jazz. Those are problems, but it seems to me that it’s not orthogonal to the “do some documentation in browser apps”, since if you have a folder full of structured interlinear texts as JSON files, well, that’s a pretty good start to populate a fancy server-based solution anyway.

With regard to Nick Thieberger’s work with Raspberry PI, it’s super cool. I think I saw him give a talk on that once too. Even there, however, I don’t see how using such a mechanism to create a local, accessible network is orthogonal to the problem of what content and applications will be sent from that local router to the cellphones. What is the Raspberry PI routing, exactly?

I admit that I am a guy with just one hammer , but couldn’t it just be some nice static HTML files with <audio> and <video> tags if necessary? I mean, maybe that is what Nick’s project was using anyway (will have to do some searching…), just thinking out loud.

Sorry, I’m rambling a bit, but yeah, PouchDB, Raspberry PI, Strawberry pie with whip cream, let’s try everything. I’m just putting all my cards in the web stack basket because it is, as far as I know, the only stack which is simultaneously a document dispersion platform and an application development platform.