Better discoverability for plugins

Posted on
Thu Sep 28, 2017 1:11 pm
jh71283 offline
Posts: 127
Joined: Jun 16, 2014

Better discoverability for plugins

This is more a request for the website than the software.

After a few frustrations with Indigo, I decided I would look at the other options that are available. In my opinion, the alternatives simply are not mature enough, and are pretty user-hostile. (Home assistant as an example - who want to spend all of their time editing yaml files? Not me.)

So I decided to figure out what it was about Indigo that was pushing me away, and a major one I thought was the ability to discover what platforms and technologies are currently covered by plugins.

The current way of discovering is reliant on browsing the forums, and to a large extent you need to know who wrote the plugin before you know what plugins are available, because they are all grouped by author.

That is one area where home assistant wins hands down, see https://home-assistant.io/components/

Is there anything that we as a community could do to to challenge this problem? I appreciate that Jay and Matt are neck deep in feature requests that the rest of us can't help with, but I think this might be one where we can help.

Posted on
Thu Sep 28, 2017 1:45 pm
Different Computers offline
User avatar
Posts: 2533
Joined: Jan 02, 2016
Location: East Coast

Re: Better discoverability for plugins

This strikes me as a bit of a formatting question.

If you look at the page you linked, and then compare it to viewforum.php?f=137 , they are kind of the same: A list of types, then the results.

I'll grant that the HASS page is prettier. The same functionality is there though.

SmartThings refugee, so happy to be on Indigo. Monterey on a base M1 Mini w/Harmony Hub, Hue, DomoPad, Dynamic URL, Device Extensions, HomeKitLink, Grafana, Plex, uniFAP, Fantastic Weather, Nanoleaf, LED Simple Effects, Bond Home, Camect.

Posted on
Thu Sep 28, 2017 2:36 pm
jh71283 offline
Posts: 127
Joined: Jun 16, 2014

Re: Better discoverability for plugins

Maybe it is about the formatting.

One thing that neither the indigo nor HASS page is good for is finding new plugins that you may be interested in.

Unfortunately all the entries on the indigo page show 2014 as their date, which is when they were created not edited.

Posted on
Fri Sep 29, 2017 12:12 pm
jay (support) offline
Site Admin
User avatar
Posts: 18200
Joined: Mar 19, 2008
Location: Austin, Texas

Re: Better discoverability for plugins

Yes, we know that plugin management (finding, installing, updating) needs quite a bit of work. It's been on my list for a long time but other things have taken priority. But I think we may be able to make some progress once we get 7.1 and subscription payments out the door.

Jay (Indigo Support)
Twitter | Facebook | LinkedIn

Posted on
Fri Sep 29, 2017 12:33 pm
dduff617 offline
Posts: 659
Joined: Jul 05, 2006
Location: Massachusetts, USA

Re: Better discoverability for plugins

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?

Posted on
Fri Sep 29, 2017 1:24 pm
jay (support) offline
Site Admin
User avatar
Posts: 18200
Joined: Mar 19, 2008
Location: Austin, Texas

Re: Better discoverability for plugins

Thanks for the feedback. Many of your thoughts are already on our list but there are some good ideas in there.

dduff617 wrote:
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.


I should point out that the custom config dialog that the plugin provides for the device, event, or action already does this - there's the help question mark at the lower left and the developer can customize where those buttons link to (besides just the plugin's general help url).

It is an interesting thought to make the one on the standard dialogs (Device, Trigger, Schedules, Action Groups) go somewhere special, but remember that (specifically the last 3) have to apply to the entire dialog - which includes the Conditions and Actions tab which can contain multiple actions - so the help in those cases has to contain enough general information (how do you add a condition, how do you add/manage multiple actions, etc) to help the user. Nothing impossible to change of course, it's just not necessarily as straight-forward as you might guess.

Jay (Indigo Support)
Twitter | Facebook | LinkedIn

Page 1 of 1

Who is online

Users browsing this forum: No registered users and 2 guests