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?
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.
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.
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?)
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
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.
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.
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>:
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.
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.
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?
(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.
(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.
(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?