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.
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.
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.
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.
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?
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.
@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)$
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.
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.
@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.
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.
It seems that the official plugin and danielo’s noteself behave differently here.
Noteself even reloads when offline - 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.