WizardNav Plugin: Initial Release

[Scott_Sauyet]

@linonetwo

Hi, you can use GitHub - tiddly-gittly/Tiddlywiki-WikiText-Plugin-Template: Simple plugin template, with Github Pages demo site. to get better dev experience, and will auto create .json plugin file in the github release, so it is easier to add plugin to the CPL, and easier for new user to install. (though I think this plugin is more like to be for experienced plugin authors?)

Thanks. I will take a look. This is my first serious attempt at creating a plugin, and while it’s working reasonably well, there are three pain points. I’m wondering if this would fix them?

1. (minor) When I change the version, I need to keep it in sync between package.json and plugin.info. I’m sure I could script this easily enough.

2. (medium) I haven’t yet got a working GitHub Action, so I have to build, then push. I’d rather just push and have the build run on the GH side. This is not huge, but is a minor annoyance. I’m not particularly experienced with GH Actions, so while I was able to do this easily at work with Gitlab, my first two attempts here failed and I put it aside for the moment.

3. (major) Before I build, I need to manually move any changed plugin files from /tiddlers to plugins/myplugin. This is not difficult to do, and if I keep with this solution, I will find a way to automate it in my build. But it feels very wrong.

There is also one feature I really love in this workflow: I build not just the main demo but also a copy in a version-specific folder. So while this plugin is simply hosted on GH Pages, I also have older versions kept handy. I need to do nothing more to create this new version than update the version number in package.json (but see #1 above!) While this does not make GH releases, I don’t know whether I really care, as I expect the main distribution for a TW plugin to be an actual wiki, as in my demo.

Does this tool do something similar, that is, hosting older versions in demo pages?

[Scott_Sauyet]

@Watt

Can I change the sort order on the ‘next’ and ‘previous’ titles? At the moment they’re sorted alphabetically by title. I’d like to be able to step through by date created or any other field.

I added the sort order configuration in 0.5.0.

…and I already have the idea for a better solution. Stat tuned.

[Watt]

Thanks @Scott_Sauyet it works!

I wasn’t sure at first but realised it’s an either/or between list field or custom sort field - e.g you need to delete the list field from the Tutorial tidd if you want to sort it on a custom field set in config.

Looking forward to seeing how you develop this plugin, it provides a nice way to step through tids on mobile.

Zoomin view with zero animation works for me but you end up with a lot of tiddlers open in the background so closing ‘current’ on click of ‘next’ or ‘previous’ could be another option for the future.

Thanks again Scott.

[Scott_Sauyet]

@Watt

Zoomin view with zero animation works for me but you end up with a lot of tiddlers open in the background so closing ‘current’ on click of ‘next’ or ‘previous’ could be another option for the future.

I don’t know how to do it. I’m sure I can find out, but if you have ideas how, please let me know. I wouldn’t make it the default, but it would make sense as something to opt into.

[Watt]

I think it might be doable - maybe saving the <currentNavStep> value to a ‘store tiddler’ and using that value with a tm-close-tiddler message on each ‘next’/‘previous’ button click? That would mean adding invisible buttons in there somewhere though. In the meantime it’s not so difficult closing the tidds manually so don’t knock yourself out Scott.

I’m pretty confident others will have much better suggestions. @Mohammad might have some prior examples.

[etardiff]

If you’re currently using links for “previous” and “next”, you’ll need to replace them with buttons (though you can still style them as links). You can then use tm-close-tiddler.

[Watt]

This button in place of the template’s ‘previous/next’ links seems to work (you’ll need to change the chevron for next) but might need some testing with multiple pathways. I kept the ‘small’ for my mobile.

<$button class="tc-btn-invisible" message="tm-close-tiddler" param=<<currentNavStep>> to=<<currentTiddler>>>« <small>{{!!title}}</small></$button>

Looking at multiple pathways with a single custom sort field means the list field has to be deleted from both Wizard tagged tids (if that makes sense ). Maybe that could be coded in somewhere?

The crossroads between those multiple pathways looks interesting, it’s a nice way to navigate on mobile.

[EricShulman]

I’ve updated my previous “TOCNav” post (see Navigating complex tiddler relationships, a discussion for the enthusiast - #2 by EricShulman) so the toc-nav() macro (which displays the previous/next links) now includes a tm-close-tiddler message. As a result, the current tiddler is automatically closed when navigating to the previous/next tiddler.

I’ve also added a <<tag>> display into toc-nav(), so that if the current tiddler is a tag, the navigation includes a tag dropdown for all “child” tiddlers. This makes it easy to “drill down” directly to any given child tiddler as an alternative to the linear previous/next navigation.

Here’s the complete updated “TOCNav” code:

\define toc-nav()
<$list filter="[enlist<all>before<currentTiddler>]" variable="prev">
   <$button class="tc-btn-invisible" style="float:left;" to=<<prev>>>
      {{$:/core/images/chevron-left}} <$tiddler tiddler=<<prev>>><<toc-caption>></$tiddler>
      <$action-sendmessage $message=tm-close-tiddler />
   </$button>
</$list>
<$list filter="[enlist<all>after<currentTiddler>]" variable="next">
   <$button class="tc-btn-invisible" style="float:right;" to=<<next>>>
      <$tiddler tiddler=<<next>>><<toc-caption>></$tiddler> {{$:/core/images/chevron-right}}
      <$action-sendmessage $message=tm-close-tiddler />
   </$button>
</$list>
<$list filter="[<currentTiddler>is[tag]]">
   <center><span style="text-align:left;"><<tag>></span></center>
</$list>
<div style="clear:both;"/>
\end

\define toc-list(here,max,exclude,level:"1")
<$list filter="""[tag[$here$]] $exclude$ -[[$here$]]""">
   <$text text="[["/><<currentTiddler>><$text text="]]"/><br>
   <$reveal default="$level$" type="nomatch" text="$max$">
      <$macrocall $name="toc-list" here=<<currentTiddler>> max="$max$"
         exclude="""$exclude$ -[[$here$]]""" level={{{ [[$level$]add[1]] }}}/>
   </$reveal>
</$list>
\end

<$wikify name="all"
   text="""<$macrocall $name="toc-list" here="TableOfContents" max=3/>""">
<<toc-nav>>
</$wikify>

[Watt]

Nice one @EricShulman
Scott’s approach wins for me though because of the ability to custom sort on the nav ‘steps’. I can click through the tagged set chronologically for example. His ‘multipath’ display on tag intersections looks interesting too, hope you get a chance to develop that Scott. Will stay tuned.

[Misterel85]

Hi @EricShulman, just for beginners’s sake, the first define lacks an introductory slash. Thanks for correcting.

[EricShulman]

oops! That was a copy-paste glitch. Fixed. Thanks.

-e

[Scott_Sauyet]

Fixed a glitch in where the Tag Tiddler footer links weren’t sorting by the list field. Released as 0.5.1.

[hiddengarden]

What a brilliant plugin! This little piece of linearity can help me navigate my research and keep the structure of the books intact.

I am currently running TiddlyWiki 5.2.2 on NodeJS

Thank you a thousand times for this plugin!!! If it helps, my NodeJS frowns upon plugin folder names containing uppercase characters. Once I renamed it to lowercase, it got recognized by my wiki, and I am now a happy little user.

To your questions if it can become any better - No! Perfect as it is.

Naturally, with me being a mythology geek, I renamed the Wizard tag to “Ariadne”.
This way, I call upon her name to help me keep the thread uninterrupted.

@Scott_Sauyet Many Thanks for this!!!

[Scott_Sauyet]

@hiddengarden

This little piece of linearity can help me navigate my research and keep the structure of the books intact.

I’m very glad it helps! On a daily basis, I use several wikis that include this, but I don’t think about it much anymore; it’s just part of the background.

@hiddengarden

If it helps, my NodeJS frowns upon plugin folder names containing uppercase characters.

Hmm, I haven’t noticed. What version of Node are you using? And how are you installing the plugin?

@hiddengarden

Naturally, with me being a mythology geek, I renamed the Wizard tag to “Ariadne”.

[TW_Tones]

@Scott_Sauyet because of this thread being touched by others, I returned to look at your solution and consider it very useful, quite an elegant solution. I must thank you for your kind acknowledgement, glad I could help.

One small idea I had was when the user clicks a next or previous, we know the “tag to which it relates” I thought if, on click we set a temp value to the “current route tag”. We would always know the route we were following, thus place its prev/next at the top and perhaps the “divergent paths” below a <hr> line. Thus one would have to make a conscious effort to jump onto another path. We could also set a “current tiddler” in the “current route”, because it could facilitate the following.

• If you do try and take a divergent route, eg pathway when following Tutorial, we have saved the current route and tiddler and provide a button to return to the original position in the Tutorial.

There are even more opportunities available to build on your work.

[Scott_Sauyet]

@TW_Tones

One small idea I had was when the user clicks a next or previous, we know the “tag to which it relates” I thought if, on click we set a temp value to the “current route tag”. We would always know the route we were following, thus place its prev/next at the top and perhaps the “divergent paths” below a <hr> line.

This is an idea I considered when I first wrote this, but I was quite new on my TW journey and it sounded rather difficult. Now it sounds like something I could accomplish. I will put it on the list of things to try when I do get back to this. (Not before September, I’m afraid; the next two weeks are vacation, and I’ve already committed my “tinker time” for the following few.)

There are some complexities. Instead of a single “current route” we might want a brief history of them. With routes like these:

W: A -> B -> P -> K -> O
X: C -> D -> K -> F -> R
Y: E -> S -> T -> U -> I -> O -> M -> L -> R -> N
Z: H -> J -> B -> D 

If the user opens a few tiddlers, sometimes following paths, sometime through other means, we maintain a list of most-recently visited paths, like this:

              [ ]       -- starts empty
B -> P (W)    [W]       -- clicked on P from the W path, add W to the front
P -> K (W)    [W]       -- clicked on K still on W path, no change
K -> F (X)    [X, W]    -- clicked on F from the X path, add X to the front
G             [X, W]    -- opened a random tiddler, no change 
I             [X, W]    -- opened a random tiddler, no change
U <- I (Y)    [Y, X, W] -- clicked on O from the Y path, add Y to the front
K <- O (W)    [W, Y, X] -- clicked on K from the W path, move W to the front
R             [W, Y, X] -- opened a random tiddler, no change

Now the user has R open. The paths X and Y both contain R. But this history says that Y is more recent than X, so Y becomes the default path displayed.

This would be only marginally more difficult than having a single current route value, and I think it would be more useful.

@TW_Tones

If you do try and take a divergent route, eg pathway when following Tutorial, we have saved the current route and tiddler and provide a button to return to the original position in the Tutorial.

There are definitely times when that would be useful. But it’s difficult to come up with a generic UI for that. First of all, some users would likely not want it, so it’s something we have to be able to turn off. How and where to place it becomes a question. I have two entirely different notions:

• This shows on the sidebar as the name of the most recent path, with a drop-down to select alternate paths, and a button that brings back up the most recently visited tiddler along that path.

• A box appears as you hover over near the top of the screen, dropping down to offer the recent paths you’ve visited, linking to the path tiddler and the most recently visited tiddler on that path. This strikes me as elegant, but doesn’t offer easy affordances for mobile usage. (I also have no idea yet how to implement it!)

Thank you for some very interesting ideas!

[TW_Tones]

@Scott_Sauyet

There are definitely times when that would be useful. But it’s difficult to come up with a generic UI for that. First of all, some users would likely not want it, so it’s something we have to be able to turn off. How and where to place it becomes a question.

I still need to work through your full reply but just raise I have some simpler and minimalist approach to divergent paths.

[vilc]

@Scott_Sauyet Great Plugin, thank you!

I’ve been playing around with it in my showcase wilk-tweaks.tiddlyhost.com. The tweak info tiddlers that display the plugin’s menu are not meant to be viewed in order, but the plugin helps in browsing through the collection anyway. I think it will prove useful in my other wikis.

I have two small styling ideas. These are totally preferential and relatively easy to customize by the user, so it’s perfectly good to leave as is.

Separator color

The top table border is currently set to <<colour muted-foreground>>. IMO <<colour table-border>> usually looks better. In many core palettes these two colors are identical anyway. If they’re different, muted-foreground usually has more contrast to tiddler-background. I like the more subtle table-border.

<hr> separator

The current separator is a colored top table border (and the rest of the table is invisible). I think it would make sense both semantically and stylistically to use an <hr> element before the table, and hide all table borders.

• (+) If one uses some custom styling of the <hr> (e.g. tzk does that), this style will also be applied to the WizardNav separator, and keep the looks consistent.
• (+) It matches the semantical meaning of the separator.
• (+) Actually requires less code in the plugin, as the top border and margin definitions can be removed from the table style.
• (+/-) It adds more vertical spacing between the separator and table contents, without additional measures.
• (-) If one doesn’t use any custom styling of the <hr>, it actually looks worse, because the default unstyled <hr> is not really appealing. I use a simple custom style that makes it much better.

The last point is probably a very good reason to leave it as it is, I guess.

[hiddengarden]

Sorry for taking so long to reply!

Apparently I have gone down the manual route with my NodeJS as I have little or no understanding how to install the plugins. As embarrassing as it is, I put the plugin folder in the server folder and edit the .info file for the wikis required to have access to the plugin.

I think the uppercase folder name didn’t “sound right” to my server instance, but that’s what you get if you try to go around learning curves to save time.

If it’s any worth, this plugin has been a life saver for me. I tend to create thousands of tiddlers and organising becomes critical. It’s so simple and elegant! It blends with my tiddlers so well and can be easily taken for granted. However, I assure you it is extremely valuable to me.

One example I can give is how it helped me create a weekly calendar based on Interstitial Journals. Years and Weeks of Journal entries were organised with strategic placement of a single tag. Again, Many thanks!

[Scott_Sauyet]

@vilc

The top table border is currently set to <<colour muted-foreground>>. IMO <<colour table-border>> usually looks better. In many core palettes these two colors are identical anyway. If they’re different, muted-foreground usually has more contrast to tiddler-background. I like the more subtle table-border.

(Sorry for the slow response. Just back from vacation.)

This makes sense. When I next work on this – and it may be a while – I will make that configurable, and switch the default as you suggest.

@vilc

The current separator is a colored top table border (and the rest of the table is invisible). I think it would make sense both semantically and stylistically to use an <hr> element before the table, and hide all table borders.

As you point out in your subsequent points, this probably has other problems. I would really like to get back to this plugin and take another swing at allowing the user to customize the entire UI; I have more TW skills that when I last worked on it, and perhaps could do this now. If so, I will probably have at least two built-in options, the default current table-based one and one that has an <HR> and simpler prev/next markup, as well as the option for users to write their own.