You never have to hit “Save” again

This week’s project has been the little task of never making you ever have to hit save again!

One of the most important things you asked for was constant saving so you don’t even have to think about it – it just does it. So that’s what we’re doing. First step: building the editor. We’ve not got to formatting yet but are just looking at how to build the editing bit, the bit we are calling the “paper”.

This is an important bit to get right (I have said this a lot throughout dev, I guess everything is important!) so we did a lot of research around what libraries (code) already exist, particularly markdown-ready ones and ones with simple interfaces. After exploring pen, tinyMCE and Hallo, we settled on an open source editor called Quill.js (for now at least). So what we have done is used the raw form of Quill to provide the foundation for the editor.

It’s currently a blank page on the Novlr product (no formatting – we’ll get to that in a couple of weeks). You can type on the page and the words are stored as part of the chapter in the database. This is progress. It still has a long way to go – the formatting, the usability of it, keyboard shortcuts and crucially what it is doing behind the scenes (to make it exportable to all of the formats you will need). However, this means that one thing that is working is the feature voted second most important by you (at time of writing :)) which is constant saving.

Constant saving: the nitty gritty

For saving we thought that there were essentially two ways to tackle it. Save at intervals or save when something’s happening. We drafted about five solutions:

  1. Save the whole novel every 5 seconds
  2. Save the chapter being edited every 5 seconds
  3. Save the chapter being edited every 5 seconds whenever you are typing
  4. Save the chapter every time there is a third of a second break in the typing (so “whenever something has changed”)
  5. As 4. but only save “the difference” rather than the whole chapter

I won’t go into all of the discussion around the options. I also acknowledge that on the face of it there might not seem much difference between these options, however when you are spending hours writing a novel, it is these little interactions that make a big difference.

We went with, *drumroll*, number four. Which we believe is the second best option there. The best being number 5 which I’ll get onto in a second. So number four works by detecting when keystrokes are being made. It then essentially gets ready to save but stores it up until there is a 0.3 second break in the keystrokes (this time period we can experiment with and adjust) and then saves. And then as soon as a keystroke is detected again, it starts storing up the save again! For those technically-leaned, this is utilising something called “de-bouncing” and comes packaged as part of a helper library called lo-dash.

So, what happens on that “save” event is: we take the whole chapter and update the database with this newer version. Like I said above, this is probably not the ideal solution, number five would be as it would save only the difference. This would be less “expensive” on the server (not as intense on the memory), however, this is technically a much greater task and something we hope to add in the future when we look at adding versioning (being able to track back through all the changes you’ve made). For beta, the number of people using Novlr at the same time should mean that this marginal difference in processing times shouldn’t have an impact of usability, however when it is scaled up and used by thousands (ney, millions) at once, we may need to rethink.

To have the constant-saving in place is a great step and I am now just excited to get on with the rest of it!

And that’s it. As I say, the editor requires a lot of work so will dominate our attention for the next couple of weeks but after that we will be looking at the export functions and the settings available to you.