The Mat stuffs are among the great resources in TW community!

I use 

   - TW version like Mat on the title
   - Single wiki per plugin
   - Rather good documentation and examples (the most tedious part always 
   ignored by developers)
   - Examples as much as possible
   - Try to keep them update with latest changes from Tiddlywiki
   - Use GitHub to keep track of issues, history, feature requests (I 
   absolutely do not recommend Tiddlyspot for this purpose)

Like Mat said, I believe your myMenu is very far from standrad (empty or and visitor confuses, keep it very close to empty edition!


On Wednesday, September 11, 2019 at 7:00:30 PM UTC+4:30, Mat wrote:
> I don't know if this is exactly what you're asking for but here are some 
> "rule of thumbs" and other thoughts that have evolved in my own work:
> Only show/serve what is relevant. This can definitely include a wide set 
> of examples etc but it would mean that one generally sticks to standard TW 
> behaviour such as default Theme, Palette, Storyview, tool buttons etc. 
> I do deviate a tad from this by e.g activating "titles as links" partly 
> because I think it is almost common courtesy to make it easy for people to 
> fetch whatever they want from my public wikis, *particularly* when 
> serving plugins. I've also disabled CamelCase linking because it is a 
> nuisance with dead links.
> Aslo I subtly, but noticeably, show what version the current TW has (above 
> the tiddler title). IMO the user should get a feeling for the context the 
> plugin was created in. ("Hm, this plugin seems to use some math stuff but 
> 5.1.17 is pretty old... must be before the core math was introduced")
> Continuing in this vein, I mostly avoid things that the visitor might 
> mistake to be the plugin when it is not. One exception is my SideEditor 
> which shows up as an arrow button in every tiddlers toolbar. I'm too lazy 
> to remove it because I'd have to reactivate it whenever I want to tweak 
> something. But other than this, typically no magic looking buttons or stuff 
> that are not part of what is actually offered.
> IMO, the very first tiddler meeting the visitor should, as a very first 
> thing, state what the plugin does *as succinctly* as possible. For 
> example: *"FooBar is a plugin that lets you ...."* or *"BarFoo is a 100% 
> CSS based stylesheet to get ...."* (I note this is missing in your 
> MyMenus plugin and hence a visitor can only guess, which probably minimizes 
> the chances him trying it out). 
> I typically name the wiki as the plugin (possible because I only serve one 
> plugin per wiki) and I try to make the name as self explanatory as 
> possible. The wiki subtitle is typically too short to allow for a 
> description so often I allow myself some artistic freedom with some stupid 
> joke or catch phrase for the plugin. 
> I typically try to only have one default tiddler. If it is a complex 
> plugin, I instead let this default tiddler have *tabs* such as "About", 
> "Demos", "Notes", "Installation", etc. Those are just examples - exact tabs 
> depend on the situation. It is fortunate if there can be a small enough 
> demo to make it on first tab (i.e About or Intro) so the user can quickly 
> decide if it is relevant at all. It is also nice if the 
> I personally think it is nice to give provide some context for the 
> creation such as clarifying its rationale and pointing out its possible 
> weaknesses. That would probably be under a "Notes" tab.
> Sometimes I include a list of the shadow or component tids with comments 
> on what they do.
> Sometimes I provide the plugin as a tag-pill, which is nice because it is 
> so visual but also because a tag pill can allow drag'n drop of anything 
> tagged so, not only the plugin components.
> <:-)

You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
To view this discussion on the web visit

Reply via email to