Avoiding frustration for newbies

#1

Stimulating user growth to my mind, in the first place would mean trying to avoid the initial frustration when your work is not saved. I could witness that several times in my work as a teacher. Even after explaining and telling students three times “remember to save ath the end” there is many students who close without saving, reload - or simply click back and loose all the work. I can imagine we loose three potential new users of four with these problems a way to cure this could be:

  • Add a more intense warning, that as long no way of saving is organized the wiki has to be saved manually at the end.
  • Add a different naming mechanism for the download-saver. At the moment, even after adding data the file is called empty(2).hmtl when save with the download-saver (I would call the download to start “fresh” not “empty” anyway). But it would be best to automatically name downloads after the title of the wiki plus the datestamp.

The alternative to these changes would be to

  • Propose a hosting site like Tiddlyhost as the best way to start - or at least add a link to a service like that right next to the download empty button. TW could still mention, that all the data can be downloaded as a funktional wiki.
    or
  • to start with browserstorage enabled (and explain that this is not really safe either…)

Another thing would be:

  • to avoid the backbutton disaster, permalinks should be switched on by default when you start.
  • Perhaps the Edit button in the Tiddlercontrols should be hidden by default, if no username is set.
4 Likes
How to stimulate User Growth of TW?
Lost 4 hours of content and code because Tiddlywiki doesn't automatically save
Could we have a feature to deactivate error-screens under certain contitions?
How to stimulate User Growth of TW?
#2

If a new user goes through the steps ensuring save is possible it is at that point they should engage autosave, which is painful until then.

  • The saving mechanism should save backups by default.

Another trap for newbies is opening the same wiki in two tabs, and saving over changes, I have being developing some methods to help reduce this problem, but not yet sure how to weave them into the normal adoption process.

2 Likes
#3

Version control between device is an issue even for … me

#4

That’s interesting, since every action you describe here activates a browser dialogue, that tells users that changes may not be saved.

They actively have to click the “Leave Page” button.

That doesn’t avoid data loss, since the back-button does initiate a page refresh

I think a different naming scheme is possible, but it won’t save us from data loss if warning dialogues are ignored by users.

The only thing, that would prevent data loss is the local storage plugin enabled by default. … But I wouldn’t want to have that active at tiddlywiki-com, because it would create a new issue. … Don’t forget to delete your crap or sensitive data when you leave the page.

IMO this would be especially problematic on shared systems

Conclusion

I think for your students you need a custom setup, that is tailored to your usecase. IMO it should be relatively straight forward to create such a setup

2 Likes
#5

I have also done a lot of work on this to, and just cant afford the “unpaid” time to complete it.

  • Basically you can check out a tiddlywiki and set a local device name, and browser brand and save it in the wiki, so that unless you check in the document you can’t save it on the other device, this is easy between your mobile and desktop, but perhaps not if you fail to check out at work and want to edit at home.
    • There is the possibility to cache changes and apply them later with contention resolution, or mark tiddlers as owned by a particular user/device/browser.

Unfortunately these are “somewhat wicked issues”, all reduced by using a server such as tiddlyhost.

1 Like
#6

IMO, beginners must pay their due to have the honour of using TW. They should learn the hard way like the rest of us. Tough love. Only then can they become real tiddleurs.

OK, OK, just kidding. I’m not an a-hole.

Joking aside - and I’m sure someone has already mentioned it but I’m too lazy to read the above - did you see Controlpanel > Saving > General > Autosave ? I’m not sure what underlying system it takes to make it active but if you use Tiddlyhost it works fine.

6 Likes
#7

There’s also the old-fashioned lost-track-of-tab with eventual browser-crash problem (too many streaming tabs, etc.) in which an abandoned tab is lost with no dialogue.

Tiddlyhost for newbies, plus autosave as default, for the win. :slight_smile:

-Springer

2 Likes
#8

It seems a mechanisium to switch on autosave durring download would help.

#9

Hi @TW_Tones can you expand on that – are you suggesting that autosave should be enabled by default for all savers?

#10

Not quite that far yet, only that if a mechanism were available such that when a saver is available it would be possible to flip it into autosave.

  • For example I use Timimi on my browsers, if I were to download empty.html or saved by any other name, any changes are not saved by default as autosave is off in empty.html
  • Perhaps the download process and/or the wiki template could switch autoasave on. True if there is only the default save available this will be annoying but at least it asks them to save.

There are possibly smarter approaches such as a prominent button after download.

  • This presents other possible improvements to the new user experience I will not detail here unless asked, but I touch on them above in this thread.
#11

This would be problematic for me as localStorage is slow and has a max size limit that I’m sure most TiddlyWikis likely exceed. Mucking with some cache in a service worker would be good as service workers only work on pages loaded from a web server. We need local functionality (hence the empty.html). We maybe get away with some kind of compression but again since localStorage is strings only I can’t imagine a compression converted to a string being much of an advantage.

To address the issue IMHO. If you use the single HTML version it is expected that you must abide by the rules and restrictions of the browsers. This means no auto saving as that is a manual step by design for security by the browsers. If you want auto saving use the Node version. That is how I run my daily TODO / GTD system. I use Node to serve an always running instance of TW. It auto saves every time. I even have a crontab that backs it up to another disk once a day.

There is also a third option which is to use a browser extension like Timmi which does exactly what you want. auto saves a single page TW that runs in your browser.

I find this works well for me and I very much appreciate that TW is flexible enough to accommodate multiple ways to use it and that I can continue to use it in multiple ways.

1 Like
#12

You are right. I did look it up. It seems to be between 10MB and 2GByte.

#13

Well, this threat is about easing the start - and there the wiki will be small. Browser storage has its flaws, but it could help to avoid loosing your first hour of work.

I often taught pupils writing stories in TW (like in Twine which is in fact a TW under the hood), and they thought that their work was saved when clicking the checkbutton of the first edited Tiddler.

It is the questiion whether we want to treat the many cloudnatives, who carelessly log in to every website with their google/apple-id and do not care what is happening in the back, as burnt flesh for a real understanding of computers which TW could provide if they would stick to it.

#14

So what if there was a plugin created that, when the Check button on edit tiddler is clicked, also saved the tiddlywiki being worked on?

I’m not capable of making something like that, but from my POV, that seems like a good middleground?

2 Likes
#15

Yeah! Let us describe the features it should have!

#16

What? Is there a magic setting? When I tried it, I seemed to hit the ceiling at around 5 megs. 2Gbyte would be amazing.

Edit: TW’s own docs suggest 5 to 10 MB: https://tiddlywiki.com/#BrowserStorage%20Plugin

Or are we talking about something else?

#17

Well, another feature that could help with that could be a timestamp -like mechanism?

Something I used to do was instead of setting an actual subtitle, I would have the modification date of the last updated tiddler inserted.

It would look something like “Justin’s TiddlyWiki – Last Updated: (YY/MM/DD@24HHMM of last modded tiddler)” in the browser address bar. Doesn’t prevent overwriting per say, but helped keep track of whichever was more up to date. I’m sure TiddlyHost has a mechanism in place to help with prevention of accidental overwriting, though I’m not certain of that.

I’m not sure if I still have that tidbit, sadly. Scratch that! TiddlyWiki has docs of something arguably better I think.

You can find it Here!

#18

This has not being tested thoroughly or for a long time (if ever). There are other factors as well. This deserves some research.

Do you mean last saved timestamp ? like here [IDEA] Last saved timestamp and what it may enable · Issue #6684 · Jermolene/TiddlyWiki5 · GitHub

Technical Discussion: JavaScript access to document and window information
#19

I haven’t seen this before, I’ll give it a quick read and let you know, but it sounds interesting.

I linked to a banner modification in tiddlywiki.com that had the behavior I had attempted to make way back when.

Edit: So, I’m not 100% I’ve read this all correctly but the premise of “Two identical tiddlywikis opened in two different tabs, without any modifications to either, how do you tell them apart” has me interested.

I would imagine the method of differentiating them is to use the time at which they were open, since in HH:MM:SS.mmm, there should be no way a user can open them both at the same exact milisecond.

Not sure how relevant that is to this specific discussion but a fun idea to play with!

#20

TiddlyTools/Time/LastModified.js defines a macro <<lastmodified>> which returns the document.lastModified value and also supports a format parameter to apply TW Date Formatting codes to the macro output.

  • <<lastmodified>>
    returns the browser-formatted document.lastModified value (e.g. “01/12/2023 18:21:18”)
  • <<lastmodified "[UTC]YYYY0MM0DD0hh0mm0ss0XXX">>
    returns a 17-digit TWCore system UTC datetime stamp (e.g., “20230113022118000”). Note that document.lastModified typically does NOT include milliseconds, which defaults to “000” in the output.
  • <<lastmodified "DDD, MMM DDth YYYY at 0hh12:0mm:0ssam">>
    returns a formatted datetime (e.g., “Thursday, January 12th 2023 at 06:21:18pm”)

Thus, rather than relying upon the timestamp of the last tiddler modified, you can use the above macro to report the actual datetime at which the file was saved or uploaded.

And, if the macro is not installed, you can use something like:

<$let modified={{{ [<lastmodified "[UTC]YYYY0MM0DD0hh0mm0ss0XXX">]
~[all[tiddlers]sort[modified]last[]get[modified]] }}}>

as fallback handling to get the modified timestamp value from the last tiddler that was modified, and then:

<$text text={{{ [<modified>format:date[DDD, MMM DDth YYYY at 0hh12:0mm:0ssam]] }}}/>

to format that timestamp value for display purposes.

enjoy,
-e

3 Likes
Technical Discussion: JavaScript access to document and window information