Live editing of narrative files

[jameshadfield]

This PR introduces a prototype of live editing of narrative files. It's not ready for merge into master [1] but it is usable and I want to surface it now to solicit comments from those currently writing a lot of narratives, cc @emmahodcroft, @cassiawag & @sidneymbell.

Currently it can be run locally (see the readme for instructions) or via https://auspice-dev.herokuapp.com/ (which is currently very slow, see [2]).

It allows you to drag & drop a markdown narrative onto the browser and then edit content in place while seeing the rendered narrative update. This is best explained via a screen-grab:

This is a prototype. Please see the readme for a list of items which still need implementing (I'm hoping others can help here). This PR starts us on the journey described in #957.

[1] For one, it overwrites the heroku behavior so review apps won't work. See commit message of f1f2ed1 for more details.
[2] Mainly because everything's running in dev mode, so nothing's compressed and fetching large amounts of JSON + JS is slow.

[cassiawag]

@jameshadfield -- this is so cool!! Very nice work on it. I am excited for using this with translations.

Most of the valuable functionality I see is already covered in your to-do list in the readme. In order for this to be really useful for translations, I think integration with GitHub repos is key. Ideally, I could go to the app online, translate a narrative, and then have the GitHub repo automatically update with my translation. Translators vary in tech savvy-ness. Some solely edit on GitHub; some clone the repo and modify locally. Those who know how to use GitHub could copy and paste from their local repo to the online app, but this will be a barrier to uptake for others. Plus, moving the file to a new system is an extra step in the translations workflow. Some might prefer to just edit the markdown file locally and push up to GitHub for preview after as they currently do.

Obviously, if not GitHub integrated, this will still be very useful for writing narratives. While writing, it's easier to screw up syntax, and live preview has more value.

[eharkins]

@jameshadfield this is sweet! Happy to take on some of the to-do items, let's chat about it whenever works best for you.

One risk associated with editing in the client (also exists of course when editing on the github UI) is that you can lose your work by leaving the page or refreshing (you also lose your work on one slide when changing to another without first clicking Update). Not sure there are many ways around this, other than implementing some autosave feature (sounds complicated) or just warning users to save their work often.

[tsibley]

@cassiawag One big risk with saving back to GitHub directly is blowing away other edits that happen in the intervening time between one person opening it and saving it. If that situation isn't handled, it's a fairly substantial usability hurdle. If it is handled, it's a fairly substantial technical hurdle.

[emmahodcroft]

This is so cool James!!

My guess would be barring a big technical solution, we might just need to tell translators to stop and copy/paste slides into Github (or their local repo) whenever they finish a slide - to ensure their work is saved. For some, they might want to do a 'first pass' just translating, then they can drag and drop into this to ensure it all looks the way it should - if copying every slide back is too tedious?

But Cassia definitely better to comment on how the translations work!

[cassiawag]

That's a good concern @trs. I think that's currently a concern with editing translations on GitHub, which groups that do edit on GitHub have mostly worked around by lots of communication about who's working on what when. It's definitely a cumbersome solution though.

[sidneymbell]

This is really fantastic, thanks so much for working on this @jameshadfield!!

Most of my comments are in the to-do list already.

• I'd echo the autosave issue -- easy to lose work. As a first pass, could we perhaps prompt the user for a local file path at the beginning, and automatically dump updates to that file at some regular interval?

• Worth noting that any bugs that 'break' narratives in core auspice will become bigger issues in this context with non-technical users (e.g., links at line endings, map zooming, etc).

• [Semantic] While I like the meaning, the naming may hurt discoverability of this awesome new feature.

[tsibley]

I'd echo the autosave issue -- easy to lose work. As a first pass, could we perhaps prompt the user for a local file path at the beginning, and automatically dump updates to that file at some regular interval?

Not really possible to save directly to a local file path from a web app without user interaction.

As an alternative, though, the editor could save contents to localStorage and load it from there if present/resuming a session.

[trvrb]

What about continually saving to a GitHub repo ala https://prose.io/? Or could continually save to S3 via Nextstrain Groups. Idyll uses it's own Idyll.pub API to solve a similar issue.

[sidneymbell]

Continually saving to github would work well for users who are editing public narratives, but not for those who need to work with private narratives (e.g., DPHs)

…

On Wed, Sep 16, 2020 at 9:33 PM Trevor Bedford ***@***.***> wrote: What about continually saving to a GitHub repo ala https://prose.io/? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1117 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADAIYX7IHKGD6FGMEFFNWF3SGGGRNANCNFSM4M4S4LKA> .

[jameshadfield]

Thanks for all the comments :)

I've cleaned up the code a bit (it's still very much a prototype) and converted it to a stand-alone app which imports auspice as a dependency. I've improved bits and pieces of the functionality, and fleshed out the to-do list which hopefully I (and other contributors) can tackle piece-by-piece.

You can find the code & future development at https://github.com/nextstrain/auctor.