Last modified: 2014-09-26 06:12:22 UTC
I'm not sure which behavior is more desirable. Currently, the book creator uses the jStorage api to save data into the browser's localstore as a collection is being created. Choosing the "Save and share your book" synchronizes to a new article in the "Book:" or "User/Book:" namespace. There is a corresponding "Open in book creator" action which repopulates local storage using the contents of these server-side articles. Problem 1) There is no UI text indicating that you are saving to local storage and not a server. If you connect using another browser or computer your work will have disappeared, possibly causing the work to be repeated. Problem 2) This makes it much more difficult to collaborate on a collection. It breaks any built-in edit conflict resolution. It is a totally different workflow than editing a wiki page, although the eventual storage is in fact a wiki page. Problem 3) Only one page can be in draft at any given time. The alternative I'm proposing is that the collection is stored as a Sandbox page (or a private page, if such a thing exists) until you choose to "Save and share". Book creator edits can be made through a new Extension:Collection api, which would simply add or remove the line from the book's wikitext source. Or, changes (eg, adding three pages) could be batched, previewed and diff'ed, then pushed to the server when the editor is satisfied.
I fully agree with the usability issues with the interface; most importantly users do not know they work might be lost if the browser local storage is purged. Those should be fixed. I feel, however, that local storage has lots of advantages - it is pretty fast and saves us constant round-tripping to the server and it does not create lots of edits on a wiki. It could be used as a form of internal bookmarking service as well; in that case user privacy should be considered.
bug 54183 is another consequence (not necessarily bad!) of client-side storage
(In reply to Marcin Cieślak from comment #2) > bug 54183 is another consequence (not necessarily bad!) of client-side > storage And #839 asked for a "built-in"/UI option for saved books for unregistered users. A local txt file sounds clunky, maybe localStorage would be a sensible option for that use case as well (considering most users don't clear it that often). Otherwise what long-term storage exists in browsers? Bookmarks? Maybe both could be done, collection staged in localStorage + stored server-side behind a hash and accessible with the hash at some (bookmarkable) URL.
