Could the browserstorage help avoid users loosing data

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

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

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?

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.

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

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

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?

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.

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

@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).

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

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.

@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.

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

1 Like

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.

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.

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.

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

This are completely different systems. Noteself uses a library called pouchdb, which uses the browsers Indexed DB.

The local-storage plugin uses the browser local-storage, which is a different thing.


I think the problem with your test version is, that it looses the “Use browser local storage” config setting after a reload. You may try to delete $:/config/BrowserStorage/Enabled tiddler from your file prior to upload it to the server. So the setting can be saved into the local storage.

This is just a guess, since I didn’t play with the plugin for a long time.

1 Like

This is what I say: If I delete $:/config/BrowserStorage/Enabled browserstorage is active and can cause the confusion described above…