Best practices for plugin configuration UI

[Rob Hoelz]

Hi TiddlyWiki users and devs,

I've been working on improving my full-text search plugin, and I was wondering what the community standards for plugin-specific configuration are.  Here are some options I've thought up:

A separate tab in the control panel via $:/tags/ControlPanel (like full text search currently does)

The advantage to this approach is that it's easy to get to, and all options are bundled together under a single tab.  The disadvantage is that if enough plugins did this, the number of tabs in the control panel would get out of hand!

Under the "settings" tab in the ControlPanel via $:/tags/ControlPanel/Settings

The advantage here is that all settings are in one spot, but the disadvantage is that you may need to scroll down quite a bit to find a plugin's options.

A configuration tiddler in the plugin itself (displayed alongside "readme" and "history" in the plugin's tiddler)

I like this approach because it's very clear which plugin the options are for, and everything is bundled together; however, discoverability and getting to a plugin's options is a little harder this way.  But you could always mix this approach with the others if you wanted a particular plugin's options to be easy to access; you could just transclude the plugin's configuration tiddler in another tagged with $:/tags/ControlPanel, or $:/tags/ControlPanel/Settings, or both.  I'm thinking of converting full text search to use this approach.

Something else?

Also, where do you store your configuration data? I've been storing it in tiddlers prefixed with $:/plugins/hoelzro/full-text-search, but I've seen non-namespaced system tiddlers used in practice too.

If anyone could shed some light on what they do for their plugins, or what they've seen in the wild, I would really appreciate it!

Thanks,

Rob

[Jed Carty]

I haven't come up with a good solution for the placement. I have been using a separate tab in the $:/ControlPanel, but it gets crowded very quickly, particularly on small screens.

I think that perhaps we could make a convention where we make a Plugins Settings tab in the control panel and then add tabs under that for each plugin. It would also be crowded but that seems like less of a problem.

For many plugins there aren't a lot of configurations options so just having the settings in the plugin tiddler is good, but I think that a more consistent set of guidelines would be good.

And I think that we should always store configuration in tiddlers prefixed with something specific to the plugin. If it is persistent data I try to use a prefix like $:/data/OokTech/Bob/ and for settings I try to use a prefix like like $:/settings/OokTech/Bob/

So far in my experience I haven't had many wikis that have enough plugins to cause trouble just putting the configuration in a control panel tab so it hasn't been an urgent concern for me, but if enough people are interested in coming up with a consistent set of guidelines I will happily help develop and follow them.

[Rob Hoelz]

Thanks for your input, Jed!  I agree about not seeing too many plugins in practice (although my own wiki is my only experience), but I think a standard set of practices would be nice to rally around.  I think the idea of a "Plugin Settings" in the control panel would be a great way to unify various plugins' settings, although I admit I don't see *too* many plugins that actually have configuration!

-Rob

[TonyM]

Good Question Rob,

I am in no way an authority here, however I have being building numerous things I may publish in the future, many of which are macros and may be bundled in json files rather than plugins. 

As a result of this different approach I place most tiddler under my "own" name space "$:/PSaT" and then have a tiddler designed to display things in the side bar tab. In this tiddler is a link to the documentation in a name spaced tiddler but I also provide the ability to remove the side bar tag. In the Key system tiddler eg $:/PSaT/solutionname I include the code to toggle its display in one or more places. The use of captions allow he name to be descriptive but not write over other tiddlers.

What I am trying to to is make everything produced by me be consistent under my name space and if I use the info, controlPanel or other locations I try and keep all solutions under one tab for PSaT (Happens to be my trading name "People, Systems and Things"). The point is I may never ask for more than one info tab, or control panel tab for anything I produce. I also bundle some PSaT Reference info and Doco under a PSaT sidebar tab.

On a few occasions I have created temp tiddlers under $:/temp/PSaT/[solutionname] and config tiddlers under $:/config/PSaT/[solutionname]

I also look to systematising view template tiddlers such that they contain list widgets that will only display items with a $:/PSaT/tag/tagname so that any solution of mine can use my tags to to be display something on say a PSaT Status line.

I think if the more prolific solutions generators coral their settings into one tab in each of these locations I doubt any one of them will get tool busy. I only have one Wiki that has a large number of installed services, otherwise I use independent wikis for specific functions so most do not use too many tabs anywhere.

Regards

Tony

[Jeremy Ruston]

It would be very useful to start to document these conventions.

In terms of the OP about plugin configuration UI, we've currently got a bit of tension between two or three different ways of doing it:

* Within the "config" tab of the plugin in the main listing on the control panel "Plugins" tab (e.g. Dynaview)

* As a separate tab within control panel (e.g. XLSX Utilities)

* As additional segments in the control panel "Settings" tab

* As a dedicated, entirely separate system tiddler (I don't think the core has an example, but it's basically the approach taken by core components like $:/TiddlerManager, $:/TagManager etc.

There's a lot to be said for the first technique in terms of consistency, but it tends to push settings off into the silo of individual plugins. The second technique is useful when you want to provide rapid, obvious access to the plugin within control panel. The third technique (and variations thereof) make sense when you want to merge (or replace) new settings associated with existing core settings. The fourth technique is useful if the functionality of the plugin is self contained and needs to be frequently referred to.

Thus, I think our conventions shouldn't be too prescriptive: they should provide guidance for choosing between competing options.

Best wishes

Jeremy

--

Jeremy Ruston

jer...@jermolene.com

https://jermolene.com

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/a6640bf0-524d-4ff0-b458-d42bb67b13c1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[@TiddlyTweeter]

Jeremy Ruston wrote:

It would be very useful to start to document these conventions.

...
 

Thus, I think our conventions shouldn't be too prescriptive: they should provide guidance for choosing between competing options.

 I agree. Different plugins do different things and need different types of interfacing. Some could need frequent ongoing interaction on settings (for instance, possibly, for Rob Hoelz's "Synonyms" in the plugin he is still developing). Tabbed under Control Panel is good in the sense that its the obvious place for frequently changing settings. Another example is the way Bob is integrated into the  Control Panel, where rich "settings" need to be maintained. Bob on the CP also includes documentation Tiddlers--which makes much sense for that application.

TWO things I do suggest is that ALL plugins follow is ...

1 - Those that use the  tagging method (adding "$:/tags/ControlPanel") to get them under Control Panel give a option to switch that behaviour OFF.

2 - The plugin ALWAYS have a Config Tiddler under a tab in the plugin itself if it has user interactive settings, whatever else its doing.

PMarios Bundler plugin is a case in point (just an example). I only need to configure it ONCE. 99% of the time I don't need to see its settings. But it appears under the control panel. And its config does not appear as a tab in the plugin interface at the moment.


From my point of view I want to switch OFF seeing things where settings are finished with, done. It starts getting too "noisy" having interfaces to things I don't use much persistent in the Control Panel.

Best wishes
Josiah