Open RandomEtc opened 12 years ago
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:
discard
button, is hardly immediate and only applied confidently for those who find no use for local storage.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:
/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./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:
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.
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?