pages only visible in another browser; edits seem to be "lost"?

I think I've run into an issue (or misunderstanding) with the local storage functionality (possibly related to #93 or #122?).

I don't recall the exact sequence of events but I added some content to my wiki and when I later returned that content wasn't visible (the pages were yellow and empty). However the pages were visible in another browser, and they were visible when I logged in with the Google ID I had previously used to claim the wiki. I think this means that somehow I had blank versions of those pages in local storage, and they were being shown in preference to the ones in the database (I'm on Heroku with Cloudant)?

Having read around the issues/wiki a bit, I looked in /view/local-editing and sure enough there were pages listed there. Removing all of them solved the problem, so perhaps this issue is best closed and serves only as a :+1: to the proposed UI changes that will make the local storage functionality cleaner?

The current behavior starts by being confusing and then, with experience, becomes only annoying.

However, federated wiki assumes there is a writeable store and local storage remains the writable store of last resort.

We will find ourselves in a position of great flexibility when we overcome the confusion and annoyance without giving up on local storage. Things that I know will help:

• When an edit causes a page to be written to local storage (say because one failed to login) the local storage version should be identified in the journal as a fork of the original page. This will provide convenient access to the original instead of hiding it forever.
• When a page is unwanted, there should be means to immediately and confidently discard it. Currently, for local changes, the indirect method of conjuring up the local-editing page, just to push the indiscriminate discard button, is hardly immediate and only applied confidently for those who find no use for local storage.
• Federated wiki is quick to pull content closer. There should be some sync-like mechanism to push content to some further (but still writable) store.

Note also, that any situation that occurs with local storage will also occur with multiple writable sites. Good solutions here will aid those who keep local caches of public sites on their laptops or behind firewalls. These are the true functionality and usability challenges we face.

... and confusion fades to annoyance :) ...

Thanks for continuing to clarify the various things I'm stumbling into. Much appreciated!

If this issue is to be left open I would like it to be more actionable for you and other contributors, but I think there are several action items (the ones you outline above already warrant individual action items). I defer to you on whether you want to create separate issues for all these or not:

• as you say, saving a new version of page into local storage should add the "fork" action to the local version's journal, so that the original page can be found again
• when viewing content that's served from local storage, perhaps the URL should be different (/view/foo could be /local/foo). This /local/... URL could be made to work even when logged in (and server content could continue to take precedence at /view... URLs). When logged-in the /local version could offer ways to merge/copy/push the content back to the server, and the /view version could likewise offer ways to merge/copy/pull the content from local storage.
• if you're viewing a page from local storage (ie you're not logged in) the client UI should invite you to log in so you can save that page to the current wiki (something like "Edits to this page will be saved to your browser's local storage. If you're the owner of this wiki, log in to save edits on the server.")
• the client UI should indicate if edits will be saved to the browser's local storage (and invite you to log in) (this could perhaps go in the footer, or use similar yellow styling to the pages which are served from local storage)
• if you're logged in and there's a page in local storage that matches the current page, the client UI should give you a way to access that content, and a way to merge the content into the current page (even if the pages have diverged?)
• the client UI (perhaps the footer) should have a visible link to admin pages such as /view/local-editing (should such pages be locked to avoid newbie editing/clobbering?)

I confess at this point I am only really thinking through the divide between local storage and "my" wiki, and not whether the same terminology and UI makes sense when considering other federated sources. I also have only just come to understand the nature of claim/log-in, and have some suggestions on that front too:

• once a wiki is claimed, the "login" UI should be changed to only accept log-in from the the original claimant
• the "oops this is not your wiki" page should explain about federated wikis and offer links and guidance on how to get your own (this is shown if you claim a wiki with one OpenID and then logout and attempt to log in with a different one)

Is it core to your thinking on federated wikis that each wiki is run by a single author? Or are there ways to share a single wiki? (I'm aware of the farm terminology, and the general goal that it should be quick/easy to get a new federated wiki for yourself, but that's about it.)

(Sorry for long issues/comments on a Sunday, please let me know if you'd prefer another channel or means of discussion... I am pretty close to forking and implementing some of this but that may take a little longer!)

I am relying more on local storage in my current work. I see nothing wrong with any of the suggestions above and will see if I can't make progress on some.