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/7c6a4cec-8f53-45d6-91d9-fa5edda20134n%40googlegroups.com.
