Could the browserstorage help avoid users loosing data

,
#1

Hello.
I am using TiddlyWiki in eduducational and assymmetrical scenario:
We use the wiki to write a play. The students cannot edit the entire wiki but they can comment, rewrite scenes and invent scenes and post them to my server.
This setting sometimes causes the loss of data because the students sometimes do not understand that closing the wiki, reloading or tapping the back-button will reload the wiki without their changes.
Noteself or BrowserStorage-Plugin seemed to present an escape to this but in addition to the problems mentioned in the plugin’s description for me (as the admin who has to control the base version of the wiki) the confusion it causes when working from different machines make it problematic to use it.

So for me, it would be the best of two worlds to have an optional browser-storage on demand for users. This would allow users to edit without the imminent risk of using all input, and it would help me to edit the wiki on the server without ghost-tiddlers reappearing after being deleted etc.

  • It would be great if the plugin could ask right after loading whether the Tiddlers/Data stored in the browser (if there are any) should be loaded from there.
  • If there are no stored data is found, it should ask whether the browser-storage shall be used on this computer. This could also help with the privacy issues which are mentioned.

What do you think of this idea?
Is it possible to realize this?

2 Likes
You know yunohost as server for hosting for TW?
#2

JanJo,

I have spent some time exploring use of the browser storage plugin and related options. I have done testing and Proof of concept wikis with a view to “saving user changes”. I must admit I do not follow your specific requirements above, but I will point out solutions in this space are of three types;

  • Using existing Browser storage, save and export tools
  • Building a logical layer on top of tiddlywiki
    • eg exports of changes to tiddlers prefixed with the current user and an import mechanism to merge content.
    • A lot can be done buy the designer of wikis to control content in a way it can be combined either automatically or guided by an editor.
  • Developing Server, Macro plugin solutions to support multi-user contributions.

This subject, the possible requirement’s and the possible solutions are broad and complex, here I touch on some of the issues to progress this discussion, but it is not complete.

Responding more directly to your request for comments;

  • If the browser storage plugin is pre-installed in a wiki it can be turned on/off on demand
  • By default the browser storage plugin loads the previously saved content immediately if it is stored
  • You can detect if anything was loaded from local storage or not.
  • You can hide the normal save mechanism when browser storage is active or make use of it to save local changes
  • An alternate save changes or export mechanism can be given to users to capture there changes to the underlying wiki.
  • I have never lost local storage content but others insist this is possible especially on low memory browser/devices.

My feeling is we all need to get better from an architectural view of tiddlywiki solution’s and the mechanism’s to use for each. Here is how I imagine the architecture you may be looking for;

A single “master” wiki that many users have access to, on top of which they can make changes but not save back to the “Master” but retain their own modified copy.

Provide tools to guarantee the safety on individuals modified copy such as backup and restore their changes.

Allow users to submit their changes to their own copy for inclusion in the master copy

  • Provide the changes to an editor who decides which to import/apply to the master
  • Import all changes into the master but isolate them under a prefix, in a JSON or plugin.
    • Allow subsequent merging by the editor.
#3

Hi Tony,
what you describe in your first list is exactly what I want!

In the second list it is not entirely clear to me whether you say this is already possible or whether you add this to my desiderata. I would say partly this can be done in pure wikitext like

Whereas these would require reworking the plugin:

or even the core:

So far only this is true,

And it is not so easy to avoid importing the browserstorage so that it is likely to run into confusions by importing deprecated versions and deleted tiddlers.

So it would be great if the plugin was reworked to make better use of the fascinating possibilities browser-storage could offer while eliminating the risks.

1 Like
#4

All of which I spoke of can be achived now by designing some buttons and a proceedure the user is compeled to use.

In a way its inverting the save process. Dont save the wiki to file but to local storage and backup only changes to a json file.

Backups need only to save changes otherwise stored in local storage and only restored if the local storage is lost. There is a few areas of concern but they are “edge cases” such as the user on initiation of a backup must complete the save process or do it again. Idealy they would remember where they saved it in the event they have to restore.

I have proof of concepts of even better methods such as storing a restore tool and the backup location, in a bookmarklet. Then before backup or restore copy, the full local path and filename to the clipboard for use in the save/backup or open/restore dialogues.

So far I have found it difficult recruiting collaborators and I need to find an income. It takes time to build test and document a solution on ones own.

1 Like
#5

I’m supportive of doing more with Browser Storage. It could be used with other savers to persist longer term and sync between machines.

@JanJo do you want to lead fundraising efforts for this?

#6

Hi @boris I think this is worth it and could be a big step to improve the user-experience - especially for the first-time-users and for those seeking more for interactivity.
But I have no experience in fundraising, I would rather participate than initiate this.

#7

If you have ideas to these three topics I would be delighted to cooperate and turn this into something that can be publicly used.

1 Like
#8

Totally understand. I want to provide an environment where people can be successful and be supported by the entire community in meeting fundraising goals. It will require people to lead initiatives they are passionate about getting done. If someone leads work on browserstorage, I’m personally interesting in donating to it.

This is still very new to the TW community, which basically just hopes that Jeremy or Saq or a very limited number of folks who do plugins will just build what they want.

The #projects:opencollective is ideally the basis of people banding together to get this done. Hopefully this also then attracts more developers with more skills, and this will be self reinforcing.

@saqimtiaz did a really great write up about Commons plugins and his thoughts on this Feature request: File Uploads via Timimi - #2 by saqimtiaz

We’ll ideally have a community call in a couple of weeks that hopefully you can join to discuss this further.

1 Like
#9

Hi Boris,
I am in… I think open collective is a great way to support and motivate open source development…additional to the good karma, the good humor, the gain of knowledge and the friendly pats on the back…
(One thought: It would be good if it was easier to find the supported projects` websites there )

So the task (apart from donating) is to describe the precise feature-request and its benefits?

#10

Anything you can do to help explain as an end user what you’d like to see, yes.

This then needs refinement by whatever developer ends up taking this on.

Feel free to draft something up in the OC category to start.

#11

Boris,

Please keep in mind not all solutions need developers, the word I tend to use that can encapsulate both is a designer. For example in this thread I did suggest I already know how to do this without any development.

I may post on the problem of being a user and not a developer.

1 Like
#12

@JanJo my comments after each of the Quoting of me, in your reply

This is a trivial download filter nothing more, import to restore. Some clever design will help make it easier for naive users.

Just install the plugin in a wiki, save and reload, then go to the plugin settings and uncheck Use Browser Storage. This sets $:/config/BrowserStorage/Enabled to no. Now along with ensuring this tiddler is saved in local storage the wiki can be hosted on a readonly site and have the browser storage activated on demand.

At one point I argued this should be what we do on tiddlywiki.com, so users can keep notes along side the documentation. I think it was done, previously on one of the pre-releases.

At wiki load or reload simply test if;

The tiddler $:/temp/BrowserStorage/Log contains a log of the tiddlers that were loaded from local storage at startup:

Since local storage is immediate you can reload the current wiki (without loss) to cause the tiddlers to be loaded from local storage and thus populate this list. See $:/config/BrowserStorage/SaveFilter for what is saved in local storage.

This is simply a matter of changing some config tiddlers (designed for customisation) to alter what triggers the dirty indicator and what gets saved. See $:/core/save/all for the save filter and add a $(publishFilter)$

[Edited addition] https://tiddlywiki.com/#SavingMechanism

The saver mechanism uses the filter defined in $:/config/SaverFilter to specify which modified tiddlers trigger the dirty state for the wiki. (The dirty state is reflected in the red colouring of the “save changes” button in the sidebar).

#13

Further to this, if you can save files to the host, one method is to turn on local-storage but turn off autosave. Then you need only save when prompted if you try and navigate away from the tab or in an on demand manner. Because of local storage if the browser fails and you return to the same address, changes between saves will still be there.

If your saves are slow this can also help.

SO Yes

Browser storage [CAN] help avoid users loosing data!

[Edited: Addition]
For you the key wiki owner you could click a bookmarklet to change the save to autosave so when you come at it from a new device it should load the last copy and from file, and commt ever change to file, thus no local storage has being unsaved.

1 Like
#14

Well, of course know that button in the config … but in the exsting plugin getting rid of unwanted changes and deprecated tiddlers is not as easy as that.
If you have the browserstorage turned on in the masterwiki - which should be active in constellations where unexperienced users shall not loose data - the stored tiddlers are automatically loaded.
Thus you have to

  • Open the wiki
  • Navigate to the tab in the configuration
  • Delete the storage (all this without saving!)
  • reload the wiki
    …and then there is a high probability that you have allready imported and saved without even realizing.

This is not really what I would call usable.
Not to speak about the about avoiding the unsaved warning for users who cannot save to the server and other features which could/should be done in the done in the same draft to smoothen userexperience.

So if this shall become more usable, it is a good idea to fund someone who does this.

#15

@JanJo are you saying this is on node or something else because I have done all this and it works, without a plugin or any other core changes.

I support funding collectives and developers, but I am suggesting its not necessary to reach your goals as far as I can see with the information you gave. Sure raise and fund it but please don’t ignore a solution already presented, and consider that perhaps I can already give you the solution.

I do not see the problems you see, based on my knowledge and experience. It is easy to make such things usable with a startup action or a well placed button. We can make it very usable.

So tell me more if there is something I do not yet know about your requirements as I addressed above.

#16

It would be nice to show a demo of your well-placed-button and startup-action.

1 Like
#17

Just to be clear which button are you looking for?

If a user arrives at the master wiki they don’t have save or local storage active. A button could activate local storage just for their browser.

If you wanted you could have the wiki activate the storage plugin for every one, you just handle saves differently for the Master wiki only.

Users do have to “send” there changes to the master wiki owner. There are a few approaches for this available, and more on the horizon.

I am happy to collaborate on this we just need work together to focus in on the objective.

#18

I am talking about first time users or customers who do not understand the way TW works and mistake it for some serverbased interaction.
And if they activate the plugin just for their browser and reload, they reload a wiki with the plugin switched off…
Refute me if I am wrong in this.

#19

If the plugin is installed in the hosted wiki and active, it will immediately start using local storage, if it is installed but disabled they need only click a checkbox or a button that does the same to enable/disable, specifically $:/config/BrowserStorage/Enabled

If the owner can save then the changes will be committed to file and local storage emptied.

For the dirty indicator, save and local storage you may need to taylor the filters use to get the result you are after for the different users, or what you want to achieve.

#20

I made a simple test to see wheter what Tony says is true:
Testo…testing the behaviour of browserstorage.
So we can check this out.

It seems that the official plugin and danielo’s noteself behave differently here.
Noteself even reloads when offline :dizzy: - so what Tony assumes is more likely to work there.
It seems also that danielo was able to replace the annoying dependency on IBM’s couch-cloud ( cloudant.com) for online backups by installing his own server. Am I right? If so …chapeau