Making Autosave Smarter - Testing a New Implementation

#1

There has been some discussion in the past about how it would be helpful to control how often autosave runs, especially for users on platforms like TiddlyHost, where frequent autosaves can slow things down or interrupt editing.

I’ve been working on a new prospective implementation for the core and would welcome your feedback and testing.

I’ve packaged the changes into a temporary plugin so it’s easy to install in your own wiki and test. The settings UI and description that you will see are temporary to aid testing.

What’s New?

Instead of saving automatically after every change, this update gives you more control over when autosave happens. It introduces two optional behaviors you can enable via config tiddlers:

$:/config/AutoSave/DelayAfterEdit

Wait until you’re done editing.
When this is set to yes, autosave won’t happen immediately after a change. Instead, it will wait until you pause editing/making changes that trigger autosave again.

That pause time is controlled by:

$:/config/AutoSave/DelayAfterEditInterval

Sets the number of milliseconds TiddlyWiki should wait after your last change before autosaving.

Example:
Set it to 10000 to autosave 10 seconds after you stop editing.

This prevents autosave from interrupting you while you’re actively working.

$:/config/AutoSave/MaxDelay

Never go too long without saving.
Even if you keep editing nonstop, this setting ensures that autosave will still happen at least once within a certain time limit, like every 5 minutes.

If DelayAfterEdit is disabled, autosave will occur only once within that time limit. This would allow you to set your wiki to autosave only once every 5 minutes.

This time limit is set using:

$:/config/AutoSave/MaxDelayInterval

Sets how many milliseconds is the maximum time allowed before autosave must run.

Example:
Set it to 300000 to ensure a save happens at least once every 5 minutes.

What I Need Feedback On:

  • Is the mechanism too complex to easily understand?
  • Is this implementation helpful in your wiki? Especially if you use TiddlyHost or other platforms where autosave may slow things down.
  • Are the setting names clear and easy to understand? Please feel free to suggest more intuitive alternatives.
  • Should different defaults be used?
  • Would a visual indicator be helpful to show when autosave is pending? If so, what kind of indicator would you want to see?

Background:

  • An earlier implementation was simpler and simply delayed autosaving more than once in a given interval. However, the feedback I had from a few users was that while this was very helpful, autosave was still happening a little too frequently for their liking during times of heavy wiki editing such as creating and saving many tiddlers.
    • I have my doubts as to whether the greater control the new implementation offers is worth the additional complexity it entails.
  • These changes do not have any impact on what triggers an autosave in TiddlyWiki and what does not.
3 Likes
AutoSave would be useful if
AutoSave would be useful if
#2

Im looking forward to trying this soon when I’m back at home. I do a lot of batch editing in my wikis and this makes a lot of sense. I also noticed when playing with the resizer plugin that just came out that the underlying tiddler gets changed very quickly and with high volume, so this is timely.

As someone who uses the ‘$:/temp/volatile’ namespace often for similar reasons, this feels quite natural to me.

#3

Just keep in mind that not every change triggers an autosave, its usually just saving/deleting a tiddler after editing in the default editor that does so. Hence the question as to whether this implementation makes sense, or if the simpler original one is more appropriate for the majority of users.

#4

Wonderful idea. I have now done a brief test on a Tiddlyhost wiki of mine.

The intended functionality is easy to understand.

  • Is this implementation helpful in your wiki? Especially if you use TiddlyHost or other platforms where autosave may slow things down.

Just like for native Autosave, the plugin would be useful if it actually saved after changes were made - but Autosave (and your plugin) instead expects the Done button to be clicked, and only save thereafter. I often stay in edit mode for long times so I would need the saving there (and after clicking Done). The plugin would be more helpful if the countdown started from a change rather than from clicking Done. Considering how the save-wiki indicator turns red on any change, it seems to me that an autosave mechanism could do this.

  • Are the setting names clear and easy to understand? Please feel free to suggest more intuitive alternatives.

Yes, but under Ctrlpanel > Saving > General the friendlier caption is used rather than the system tiddler title. Captions for your plugin could perhaps be “AutoSaveDelay” and “AutoSaveMaxDelay”.

  • Should different defaults be used?

Duration wise I can’t tell (because I don’t use autosave for the above reason).
Unit wise, it think seconds make more sense for an end user than milliseconds.

  • Would a visual indicator be helpful to show when autosave is pending? If so, what kind of indicator would you want to see?

This ties back to my first point; IMO the red button already indicates that we have unsaved changes. I think that should be the indication that an autosave is pending.

…

One idea for the UI might be to use checkboxes instead of the circles (that I mistook for buttons) and the actual buttons.

Thank you for sharing.

#5

Aha. The links you give is to a PR draft. Are you saying that that PR does save as I outline above, i.e when the save-wiki indicator turns red? That plus a delay makes sense.

#6

@twMat Just to clarify: neither the plugin implementation nor the draft PR changes what triggers an autosave.

Assume we have configured autosave with a 30-second delay, are using the default editing UI, and autosave is enabled.

Draft PR behavior (fixed interval delay):

  • The user edits and saves a tiddler → autosave is triggered.
  • The wiki is autosaved immediately.
  • 10 seconds later, the user edits and saves another tiddler.
  • Autosave is now scheduled to occur 30 seconds after the previous autosave (i.e., 20 seconds from now), regardless of any new edits made in the meantime (unless the wiki is manually saved).

Effect: At most one autosave occurs every 30 seconds, and each autosave happens at most 30 seconds after the previous one was completed.

Test plugin behavior (idle delay):

  • The user edits and saves a tiddler → autosave is scheduled for 30 seconds later.
  • If the user edits and saves another tiddler within those 30 seconds, the autosave is rescheduled for 30 seconds after the most recent change.

Effect: Still at most one autosave every 30 seconds, but the autosave is postponed until 30 seconds have passed without any autosave triggering activity. If the user keeps triggering autosave, the delay resets to 30 seconds from the trigger each time.

Since there are very limited triggers for autosave, hence the question whether this behaviour of the test plugin is actually useful to most users. The users in question that it was designed for had somewhat unique constraints that I doubt would apply to others.

#7

@twMat I understand what you mean and this is something has occurred to me as well. However this is a far broader conversation than configuring how often an autosave occurs. The core has a very strict definition of what entails an autosave and it would likely be problematic to extend that to every change in a tiddler. Even changing tabs in the sidebar would then trigger autosave.

Therefore I think it might be pragmatic to decouple the official definition of autosave from the need to save drafts as you work. I suggest you start a new thread to discuss potential ways to address these needs that you have outlined.

#8

Thank you for the clarifications. As you propose, I’ll start a new thread to discuss the outlined needs.

1 Like
#9

Thanks for the clarification. Using the “done” button or otherwise using the editor is probably less than 1% of my saves - I’m almost entirely using action-setfield in daily usage. I agree though that additional options on “triggers” would be helpful.

#10

I am in the same boat. However I suspect the majority of users rely on the default editor.

#11

For an autosaver based on a countdown timer, see

TiddlyTools/Time/AutoSaver

This TiddlyTools add-on also requires

  • TiddlyTools/Time/Ticker
    defines a startup tiddler that starts an interrupt-driven countdown “ticker” to trigger the autosaver function when a specified time runs out.
  • TiddlyTools/Time/action-timeout.js
    defines the underlying $action-timeout widget used to set up the interrupt-driven countdown ticker.

Note that this is NOT based on the TWCore’s “autosave” setting (which should typically be turned OFF when using TiddlyTools AutoSaver to avoid the “excessive saving” that TWCore setting can cause).

Instead, you set the TiddlyTools AutoSaver to countdown a specific amount of time (default is 30 minutes). When the countdown reaches zero, the standard TWCore “save changes” process is triggered. Thus, if you are using TiddlyHost it will save your TiddlyWiki to the server; or, if you are working locally, it will use whatever saver method you have set up to save a local file. If you haven’t set up a saver method, it will default to the “HTML5 Download Saver” that uses
the tm-download process to save your local file.

Note that, by default, you must manually start the initial countdown after loading your TiddlyWiki, but there is an option to automatically “begin countdown as startup”. Also, to guard against unwanted saves, it defaults to “ask before auto saving”. You can disable this setting so that autosaving is always performed when the countdown reaches zero without being asked for confirmation each time.

In addition to performing a standard “save changes” action, the TiddlyTools AutoSaver can trigger tm-download handling to automatically “export changes” (using the haschanged[] filter) to export all tiddlers that have changed during the current session . You can also choose “export tiddlers” to export a list of selected tiddlers based on a chosen filter and a $select list. These tm-download options can be used to create .json “checkpoint” files while you work, without saving your main TiddlyWiki.

enjoy,
-e

2 Likes
#12

I think the feedback you asked for is answered within the following comments, I am comfortable with your proposed names and settings.

I think what you propose is a good idea and quite clear. I think your solution and/or a hybrid with Erics should be ultimately included in the core. However below are some notes adjacent to this issue that should be taken into account;

  • Using the three additional editor buttons, $:/plugins/telmiger/EditButtons allows one to do a save “checkpoint” but allows a change to be saved that potentially starts the autosave clock, whilst not leaving the editing of a tiddler.
    • I wish we could stop loss of the cursor position in the editor
    • This is where your proposed autosave configurations would work nicely.
  • By installing the local storage plugin its ok to not autosave for extended periods and if the local computer powered off you often find it reopens without the loss of even the last character typed in the editor.
    • Local storage is then purged once autosave occurs, so there is not an over reliance on local storage OR autosave. They work together beautifully. Even better if one can configure longer autosave settings that would be possible with your solution.
  • Of course adjacent to this is the “Dirty indicator” used to trigger the default autosave, change the save icon color etc… In some scenarios where we configure an auto save, we may wish to change or hide it, since the user need not ever “save”.

I would love to be able to optionally issue a action trigger that starts your autosave timer. Let the designer also choose when it may be important to autosave. For example a wiki may use startup actions that make changes we want to autosave.

Special Notes;

  • If I am not mistaken there is no way to trigger/action an autosave, only a save which demands interaction. If your solution presents this we can trigger an autosave after a batch operation.
  • If a timer interrupt needs to be introduced, exposing this for other functionality, as in erics example, should be considered as it helps to leverage one interrupt rather than multiple, for performance reasons. Eg a general trigger at least ever n seconds or other methods.

Thanks for your work @saqimtiaz

#13

Other related asides

One thing is if we are never required to manually save, because autosave does it for you, we loose the opportunity to enforce a logout trigger if we want to introduce end actions (as opposed to startup actions).

  • It is also possible to trigger an action for autosave if one navigates to or away from a window or tab in many browsers.
  • This may be the opportunity to introduce logout logic.
#14

What triggers this? I.e, as I outline here, is it triggered from “any change” in the system, or does it require that the user e.g clicks the Done button?

#15

It is based on an interrupt-driven timer. It is not triggered in response to “any changes” in the system, or a user action like clicking the “done” button. Rather it is a simple countdown timer that uses the same interrupt-driven technique as TiddlyTools/Time/CountDown and is triggered when the countdown reaches zero, regardless of whether or not any changes have occurred in the TiddlyWiki.

As I noted in my previous post:

-e

1 Like
#16

As stated by @saqimtiaz in another thread, it is possible to trigger an autosave, with a tm-auto-save-wiki message.
I successfully used this technique on Android with tiddloid to save a wiki in reaction to some user inputs (button clicks for example).

Fred

#17

Thanks for pointing this out.

Although there is more to it from Memory, as the documentation says

The autosave wiki message is handled by the TiddlyWiki core SyncMechanism which invokes the current SaverModule. Not all SaverModules can handle autosaving.

  • I would need to test it in more detail than I have so far and have a recollection it is not so strait forward as one would imagin.

There may be a need to separate the actual save from the “request a save” in N seconds?