- Posted on
Fri Sep 29, 2017 12:33 pm
-
dduff617
offline
-
- Posts: 662
- Joined: Jul 05, 2006
- Location: Massachusetts, USA
I definitely support the idea of "Better Discoverability".
my ideas for improvements fall into two areas:
1. better ways for people to browse and find plugins that are of interest.
The key here is that plugin authors need to remember that this info by definition will be accessed primarily by people who DON'T (yet) use the plugin. That is it needs to state clearly: WHAT the plugin does in simple terms understandable by someone who's not already familiar with the plugin and/or the specific technology or device that it relates to. Ideally, a set keywords would be provided to facilitate search and the Indigo authors should seed this set with standard terms to avoid duplication (#HVAC, #lighting, #audio, etc.).
It should also state WHAT the plugin requires or assumes that you already have in order for it to be of benefit (for example, if the plugin is an interface to a specific hardware device) or if it extends or improves some other existing functionality. If it is a plugin to control a receiver, it should state which models of receiver it covers. Ideally, this would be written to be understandable by someone who is interested in the functionality and might want to know what they need to buy to use it - as opposed to some existing plugins that seem to assume that one has all the gear already. For example, if I'm going to buy a new thermostat or AV receiver, I might browse to look at functionality provided by a plugin and then look to what specific models are covered so I know what to purchase.
Most plugins already provide the above, if you know where to look for it. What is needed is some kind of standard mapping onto Indigo support forums. For example: one forum for each plugin. It can be a sub-forum under the plugin author's parent forum or whatever - doesn't really matter. There is one or a small set of "sticky" posts, which cover topics mentioned above, specifically "What does it do?", "What does it require?" etc. (perhaps the subjects for these required sticky posts should be specified exactly). It would be great if these could be instantiated and updated automatically by a script or something that references the data in the plugin bundle.
A quick glance at the Home Assistant link provided suggests that existing "index" of existing plugins could be improved. My experience is that the current index is hugely valuable, but needs to be made more new-user friendly - i.e., easier to get to and navigate. (or just integrated into the "Manage Plugins -- see suggestion below).
To protect against accumulating cruft in the database, it should provide metadata such as the date the plugin was submitted, the date of last update, and range of Indigo versions known to be supported (or not). That way, you don't have poor Joe the newbie having to scroll through dozens of way-out-of-date and abandoned-experiment plugins looking to discover the plugin to support his new door lock.
To provide some "social" to the Indigo website, it would be nice to track things like the number of times a plugin has been downloaded and maybe give users an ability to give a "thumbs-up" or something to a plugin. This would provide a simple way for users who might not have time to scan in detail through the entire database to see "popular" or "highly rated" plugins. Other useful metadata might include some idea of the plugin's status {experimental, alpha, beta, released, deprecated, ...} to help set users expectations appropriately as to the level of stability/reliability.
2. Better plugin mechanics and integration with Indigo.app
Downloading a plugin should not require hunting around the forums looking for the link to the current version; unfortunately it sometimes does. I won't belabor this. Seems like a simple thing that just needs to be fixed. Forums start small and simple and then inevitably grow. Plugin authors initially start out with just one plugin, then often expand to additional ones. Important "readme" type data gets lost in the shuffle. The-key-thread-everyone-needs-to-read either gets buried and/or it grows to be 20+ pages long and contains dozens of no-longer-useful discussions of older versions and/or off-topic side conversations. Whereas the plugin author initially assumes that "it's obvious" where to find the download link for the plugin or tell which link is the current one, it's often not so, especially for a user who's browsing and maybe trying out the plugin or the first time. Indigodomo providing more "structure" here would be a big win.
It would be a big improvement for me if manipulating plugins in indigo were consistent across the mac client app and server. This would require some behind-the-scenes magic - for example, if indigo-client received an open request for a plugin URL, it would simply pass it to indigo-server. If indigo-client was actually pointed at a local file (plugin bundle), then maybe it copies it to the server and installs it there (?). I speculate that is a direction Indigo might want to go in the future anyway -- i.e., to allow for indigo-server running on a device like AppleTV , an off-the-shelf "indigo appliance" to compete with devices like "Insteon Hub" or Vera, indigo-in-the-cloud service, etc. Same argument as above applies for Indigo Touch client although Indigo Touch is still way further from feature-partity in many other areas, so I'm not holding my breath on this one.
The existing "Manage Plugins..." interface should be improved to show what plugins are installed and the installed version, which ones are in need of update (and possibly centralizing "update" options for each installed plugin - i.e. whether to do nothing, notify-only, or auto-install when a new version comes out), a simple one-click manual update for each each plug-in, and perhaps even an "update-all" button. The basic ideas for supporting this seem to have already included in Indigo since version 5 or maybe even earlier- just need more rigorous fleshing out of some standards, I think.
It would be somewhat ambitious but very cool if "Manage Plugins..." could include all the metadata for the plugins registry, not restricted to currently-installed plugins as it is currently. This would make exploring and trying (and rejecting/removing) plugins 10x easier. Of course this assumes that there is an official central "plugin registry"...
Something like "show dependencies" should work for plugins, showing (or at least providing optional columns in the tabular "manage plugins..." interface) the number of devices, triggers, action groups, and control pages that utilize any of the plugin-provided features.
Plugins should connect to the "hooks" in Indigo.app for users to get help/info. For example: when you select "New..." from the device window, and then select the type of the object, the little "help" icon (circlular icon with question mark) should take you to the specific page that defines and documents the selected object type (and "model" if specified), not a generic page. Ditto when defining a trigger or an action.
Can Indigo register a URL scheme so that URL's for plugins could be something like "indigo-plugin://chameleon/nest-home" and they'd get opened automatically by indigo when a user clicks on them in a browser?