- *Copy path to clipboard:* That's a good idea and should be possible when loaded as file://. UI design is a consideration here to make it clear to users when copying the path. - *Custom Target/tab: *Do you mean something like Open Links in a New Tab, Or Re-Use Already Existing Tab (usefulangle.com) <https://usefulangle.com/post/337/html-open-links-in-same-tab>? I think this only works when clicking on links from a common page. - *Local storage: *Not really all that safe since we can't guarantee that changes will be flushed to disk before the browser closes. If going with that kind of approach, I would rather just use a JS lock which can work with tabs in the same browser window. - *File Associations: *Might work, though that requires some platform specific code such as an installer to setup the associations. For Timimi, there is obviously the solution of disabling the saver via a setting, but that obviously sucks if you have multiple people using the wiki. It'd be nice if there was a way to specify a priority for savers, but I don't think there is one right now. I don't want to add a bunch of custom logic to this saver for other specific savers. I could add in some special field containing JS that can be modified for determining whether to enable this saver or not, but that seems like a lot of complexity for users.
On Thursday, March 24, 2022 at 8:04:16 PM UTC-7 TW Tones wrote: > Folks, > > I am watching this with "bated breath" ( *in a nervous and excited state > anticipating what will happen*) however as I do not understand the > technical part of the saver I am finding it hard to contribute. > > It seems to me this is approaching the "Nirvana" of savable wikis without > any additional installation of servers, savers or Browser addons. This will > transform how people can acquire, use and distribute wikis to naive users. > It just needs a little more work. > > What follows is some 'innovative' solutions I have developed that may be > able to smooth the path to a solution with the least "resistance" of not > almost transparent. > > - You may also find these tips and tricks powerful in their own right. > - 'Innovative because' "I see few if anyone using them" > > > I believe I can add a lot here but there remains a slight technical > barrier for me. What I want to see is to minimize user interaction > including between reloads, and when forced interaction is necessary, > improve and guide the user for minimum complexity. Here are a few > techniques that may help overcome the barriers. > > - *Copy path to clipboard*: If we want to save a tiddlywiki to an > existing location, as may be forced when reloading the wiki or browser, we > already have the full path and filename available in the browser, it just > needs to be available to the save as dialogue. > - I have created a save button with additional actions that copies the > contents of $:/info/url/full to the clipboard, where ctrl-V pastes > the full path and filename and I just click save. > - This would save the need to remember the full path and filename > and reduce the error of selecting the wrong file > - Remember also > - the full path tells you if the wiki is at a file location > which is a useful piece of information > - If we have a modal pop up as mentioned below in "Bait and > switch", this can be explained for the user, perhaps a variation for > the > detected OS. > - *Custom Target/tab:* If we want to protect against opening the > same wiki in a tab, one trick is after the first save (knowing the full > path and filename) we can construct a html link with an appropriate target > attribute, then navigate to that (if possible closing the original tab), > thus the wiki is now running in a tab with a named target. > - If we bookmark or pin the tab this remains the target. If clicked in > future it will open the very same tab, never another new tab. > - Warns if unsaved changes exist in the tab. > - This should help given the global file:// issues > - *Bookmarklet*: Perhaps extending the value of Custom Target/tab > and because there is value using it, we can consider the use of a > bookmarklet both with a target and a payload if necessary. An example may > be so if the user returned to the source site, published on the internet > the bookmarklette can recall you already have a local copy and with a > click. When saving from the source URL for the first time we could prompt > the user to use their saved bookmark if they want to access their local > copy, to not create a new one, or override and existing one. > - *Bait and switch: *Using the existing save button or a customized > copy which does more work than the default save button, on this occasion > opening a modal with an explanation rather than adding another tiddler and > set of instructions would be wise. One could also allow the full path top > be copied to the clipbord etc... > - However this modal would not be displayed if it can go ahead and > save automatically. > - *Local storage:* As long as one does not tax the local storage > much, it can act as a fairly safe space to store changes, and if when > closing the tab the dirty indicator triggered the Native file save, then > all tiddlers are saved to file and the local storage vacated. > - The point here is automated save is not necessary but can be > optional. The user should be able to choose when they invoke the file > saving. > - *File Associations: *Most browsers on opening a tiddlywiki file, > what ever its name, detect its html and opens it as expected. This allows > us to save tiddlywikis as for example a empty.tw file. Helping > distinguish it from all other html files. Then we can provide (yes > install) > a file association to force such files to be opened in a particular > browser, in this case the one with local storage for that wiki such as the > one containing the IndexDB. Perhaps a .twc (tiddlywiki chrome) or .twf > firefox or .twe tiddlywiki edge would be useful. > - Browsers also enable handlers for given extension/mime types to > be set, which may be another avenue to improve user interaction more eg > .tw* > - *Note:* For me, if my default browser, or all browsers have the > Timimi extension installed it does not matter in which browser I open the > wiki it can save to the local filename. > - Currently testing this solution I am using Edge as it is my only > browser without Timimi installed. Timimi once installed is almost > transparent at saving, its only problem is it requires both a local > install > and an addon for each browser. > - There would be value if it were possible to choose or avoid the > Native saver on file based wikis in browsers running Timimi. > > On Thursday, 24 February 2022 at 11:38:49 UTC+11 brian....@gmail.com > wrote: > >> Dyllon, >> >> On Tue, Feb 22, 2022 at 9:32 PM Dyllon Gagnier <dyllon...@gmail.com> >> wrote: >> [...] >> >>> In terms of stressing if you picked the right file, assuming you used >>> the modal button, you don't need to stress out too much since the >>> consistency check should catch that. >>> >> >> The stress I describe in steps 1-7 below is only about using the modal >> button. During the first save, the consistency check is not done, right? >> Therefore, that first save during each session is a potentially damaging >> operation. That's the source of the stress. >> >> >> >>> On Saturday, February 19, 2022 at 5:45:06 AM UTC-8 brian....@gmail.com >>> wrote: >>> >>>> On Fri, Feb 18, 2022 at 8:16 PM Frédéric Demers <fred....@gmail.com> >>>> wrote: >>>> >>>>> As inspiration, this seems to be a decent implementation of native >>>>> file storage API: https://bangle.io >>>>> >>>> >>>> This does look pretty good. Another example is >>>> https://app.diagrams.net/. >>>> >>>> These two apps have a webpage at a well-known url which holds the >>>> javascript functionality. The data files are loaded in separately. Compare >>>> this to tiddlywiki in which the functionality and the data is combined >>>> together into a single file. >>>> >>>> I think to implement the same workflow in tiddlywiki, you'd have to >>>> have a "launcher" instance of tiddlywiki which would read a tiddlywiki >>>> instance from disk as the "data file". >>>> >>>> I seem to recall https://tiddlywiki.fission.app/ implements such a >>>> launcher, but currently that page has an endlessly spinning "Authorizing >>>> with fission" message and the console has an "Uncaught (in promise) Error: >>>> Improperly formatted header value: skeleton" in webnative.js, so I >>>> couldn't >>>> confirm my memory. >>>> >>>> I think the workflow implemented by the above two apps is "safer" than >>>> what I saw in the TW chromium native file saver. With the TW native saver >>>> the workflow looks like this: >>>> >>>> 1. Load my native saver enabled TW using some url (possibly a >>>> file:// url) >>>> 2. Click the Save button in HTML Native File System Saver modal >>>> 3. From the file dialog select the same file I'm already editing >>>> 4. Dialog box "a file with this name already exists, do you want to >>>> replace it?" >>>> 5. Start sweating a little bit...if I've chosen the wrong file >>>> here, I might be overwriting something important >>>> 6. Sweat a little bit more especially if I've loaded it from a web >>>> url where it isn't as easy to tell that I've selected the matching file >>>> or >>>> not >>>> 7. Cross my fingers, click the "replace" button and hope for the >>>> best >>>> >>>> The bangle and diagrams.net applications don't have the same room for >>>> user error since you are prompted for what file to read and then it >>>> automatically saves back to that same file. I find that workflow to be >>>> less >>>> nerve-wracking. >>>> >>>> Maybe with tiddlywiki's unique structure there is an even better >>>> workflow to be had, I don't know. And maybe the TW nativesaver can already >>>> be used with a better workflow and I just missed it. >>>> >>> [...] >> > -- You received this message because you are subscribed to the Google Groups "TiddlyWiki" group. To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/b235f544-3c9c-49db-81c6-ab35694fc66cn%40googlegroups.com.
