WizardNav Plugin: Initial Release

WizardNav

With help from many wonderful people here, I’ve created my first plugin.

It adds previous/next links to tiddlers whose tags themselves have the tag “Wizard” (name configurable.)

Demo and Code

Questions

This is my first plugin, and I’d like advice on a few things:

  • Core Version: I don’t know enough about how this is used. I probably shouldn’t advertise a version I can’t support, and I have no idea what features I’m using might be newer than the 5.1.0 I claimed. Do people do rigorous testing to find the first working version? Or do I simply put in the only one I’ve tested, 5.2.3? Something in between?

  • Plugin pages: I use readme, license, config, as well as the default content. I’ve seen a fairly wide variety of choices, but I don’t know if that has settled down into any rough consensus. Should I be using other pages?

  • Extra feature: I think I know the answer to this one, but let me ask anyway: While I wrote the code that lead to this, I found myself doing something extra in each of the tags that serve to define the wizards, ending them with the ordered list of items tagging them, so I moved it up into what became this plugin. I added a configuration option to turn it on, and left it off by default. But is that still a silly idea? I give no chance to configure it, offering no way to control the output. Should I give some way to override the default plain list-links output? Should I just get rid of it?

  • Markup: I used HTML to mark up my output, as it was simply easier for me at the moment. Is it more idiomatic to use wikitext? If so, is that important enough that I really should fix it, or is it it a minor thing?

  • Plugin: I know there are other ways of distributing this work. Is this in some way a poor use of a plugin?

  • What else?: This is my first plugin. What else did I do wrong? What is all right but less than optimal?

7 Likes

Can’t offer any insight to your questions but i like the plugin. Thanks for sharing.

1 Like

Hi, Nice plugin. …

It seems the plugin contains a PNG image which adds at least 125kByte to the plugin size. The rest of the plugin probably is just a few kBytes of text.

I think it’s OK if there are images in the demo edition, but they shouldn’t be part of the plugin, where they add weight to someone elses wiki.

If you publish a new plugin, you can start with the plugin version you developed with.

If you use an “older” versions you have to be sure and test them. So it does matter.

That’s OK. If you need more, you can add them. But to start with readme, license, config is OK. The content tab is created automaticlly by TW.


About the “Extra feature” … The list-links in the tags tiddlers. I think it’s OK to have that list there. It’s configurable, so IMO its OK.


That’s OK. It’s your plugin and you decide, how it should work. Looking at the code, I think a table is OK for the job.

That’s exactly a functionality what plugins are used for. So everything is fine.

I’ll have a closer look at the GH repo and I’ll probably create issues or a PR there… … There are some things I would have done differently, with the DOM structure created by the plugin. But overall I think it’s a nice function.

Great plugin! I gave a Gold star to it on GitHub

D’oh! You’re right. I will fix that this evening.

Of course that’s the case. I don’t know what I was really thinking. I guess what I didn’t want to do was bisect the versions until I found where it was supported. I’m curious, though. Is this a hard limit? Will TW not run a plug-in that has a too-new supported version? Or is it caveat emptor?

OK, thanks. I read in some thread here that if it doesn’t need JS modules and doesn’t need the “disable” feature, a plugin was unnecessary overhead; a JSON bundle was plenty. But I’m happy enough to leave it as a plugin.

Great! I look forward to seeing them.

Thank you for your feedback. It’s very helpful. And thanks too to @Ste_W and @Mohammad for the encouragement.

3 Likes

I’ve released another version of my WizardNav plugin:

I think I’ve covered the points discussed. Please let me know if I’ve missed anything.

I have a few more things I want to do before I reach 1.0.

(A quick meta question. Is this an appropriate way to post this? I’ve seen threads where the original post is amended for new versions, and others where a new topic is raised. Is one of those preferred, or is this middle ground of adding a new message to the discussion reasonable?)

1 Like

I did have a short look at the TW code. It doesn’t check the core-version at all.

If a thread gets too long I’d recommend to create a new thread. … But let’s say up to 20 posts or so it’s OK to post update info in an older (3-6 months) thread. IMO if it’s a year old just start a new one except if there is only 1 post in it :wink:

BUT you should create 1 thread for 1 plugin. It gives you better visibility and the discussion can focus on 1 plugin, so it’s less confusing for visitors.

1 Like

It should have a “name” field for the plugin. Thanks!

Ok, thanks. I wouldn’t know where to look yet. But I’m learning more and more.

I’m sorry, I seem to have lost the context. What should have a “name” field?

The plugin. Just like it has author, description, version, etc. fields

https://tiddlywiki.com/#PluginFolders

Thanks @Scott_Sauyet for a nice navigation plugin and the useful questions about plugin production too. Both will assist future navigators!

One request for a future iteration - a config option to choose whether to close the current tid when clicking on ‘previous’ or ‘next’. At the moment they all seem to remain open in the river.

1 Like

It’s ok Scott, I answered my own question by going to Control panel, Appearance, Story view, Zoomin. Allows only one tid at a time.

Turning the animation setting under the ‘info’ tab down to 0 also helped.

May still be a nice plugin config option for other views but it works well for me now, thanks!

[quote=“Mark_S, post:11, topic:5376”]

Oh, of course. I copied that info file from somewhere and either I accidentally deleted name or it wasn’t there. Added in the new version below.

Hmm, I don’t know how to do that yet. I could certainly look, but I thought that was basically controlled at the wiki level, with $:/view, configurable from Control Panel > Appearance > Story View. Is there another level of control?

Another new version adds the missing name property and changes the Tag footer from <ul> to <ol>:

3 Likes

Hi @Scott_Sauyet
Two more ‘config option’ questions for a future iteration, should you find time for refinements;

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.

Can I replace the title links displayed for ‘next’ and ‘previous’ with something else? E.g arrow icons or contents of another field. The link would remain the same. Same for the Wizard list, I’d like to sort it differently.

Both might already be possible by tweaking some filters but nice to have as config options too.

Thanks for the plugin Scott!

Oh, I’m still working on refinements. There’s a long thread where I’ve been asking about how I might achieve one refinement I would like to have. The consensus seems to be that if it’s even possible it’s extremely tricky, and beyond my current skills.

They’re currently sorted by the list field on the TagTiddler, if it has one, and by the natural alphabetic ordering otherwise. You can change the list field by clicking on a Tag Pill and dragging the fields around. You’re right that it might make sense to offer a way to override the sorting, but I’ll have to think about it. If you’re comfortable with GitHub, could you raise an issue for this?

At the moment you can simply override the ViewTemplate. That long issue was all about how to make this overridable in a more user-friendly way. I think that’s playing itself out now, but if it comes down to, “No, that can’t be done by a noob like you,” then I’ll look at how this might be configured. It doesn’t sound too hard.

I raised an issue on github about enabling ‘next’ and ‘previous’ to sort on a field other than title but I think I’ve answered my own question.

Adding sort[created] in 4 places in $:/plugins/ScottSauyet/WizardNav/ViewTemplate and reducing the font size a bit for mobile use seems to work.

Maybe the ‘created’ could be replaced with a variable that allows a different sort field to be set on the config page but the adjustment below works for me so far and I can see where to change the arrow icons/text too if I want. Thanks again Scott.

<$set name="currentNavStep" value={{!!title}}>

<table class="wizard-nav">
<$list filter="[is[current]tags[]tag{$:/plugins/ScottSauyet/WizardNav/config/TagName}sort[created]]">
  <tr>
    <td>
      <$list filter="[enlist{!!list}] :else[tag{!!title}sort[created]] +[before<currentNavStep>]">
        <$link to=<<currentTiddler>>>« <small>{{!!title}}</small></$link>
      </$list>
    </td>
    <td>{{||$:/core/ui/TagTemplate}}</td>
    <td>
      <$list filter="[enlist{!!list}] :else[tag{!!title}sort[created]] +[after<currentNavStep>]">
        <$link to=<<currentTiddler>>><small>{{!!title}}</small>  »</$link>
      </$list>
    </td>
  </tr>
</$list>
</table>


<$list filter="[[$:/plugins/ScottSauyet/WizardNav/config/AddLinksToTags]get[text]match[yes]]" variable="_"> 
<$list filter="[is[current]tag{$:/plugins/ScottSauyet/WizardNav/config/TagName}]">
  <<list-links filter:"[all[current]tagging[]sort[created]]" type:"ol">>
</$list>
</$list>

</$set>
1 Like

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?)

1 Like

Thank you. I will look at the issues this weekend and, I’m hoping, put out a new release.

Yes, that was what I was thinking for “created” - a tiddler that holds the name of the field, defaulting to “title”

I hadn’t even looked at mobile yet. My test case is not online except in a locked-down corporate network that won’t let you phone on it unless you surrender a lot of control over the phone. I don’t want GigantiCorp bricking my phone, thank you! I will check it out soon and see if the default font should change. (I don’t set it at all.)

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?