Thanks Mat that is very helpful,
Can I take it then that you only produce a single wiki for both the demo,
documentation and plugin distribution?
Regards
Tony
On Thursday, September 12, 2019 at 12:30:30 AM UTC+10, 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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/tiddlywikidev/3cca7bd3-e35b-41ac-ae7c-593235886720%40googlegroups.com.
