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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/tiddlywikidev/a86b92aa-5a63-4900-8919-ccaa905a16a6%40googlegroups.com.
