v7 Plugin Manager Suggestions

[cncb]

Originally Posted by Brent

Require a website link and screenshot for ALL plugins.

Change "require" to "highly encourage" and I think most won't have a problem with it .

[GKusnick]

Originally Posted by Brent

I think you are coming from the "why make more rules" side of things and thinking it's fine - it's all there the user just has to figure it out on their own.

I certainly didn't mean to imply that users should have to figure things out on their own. I'm all in favor of plugins devs documenting their plugins. I just don't think that more rules is a good way to get them to do it. All that does is force them to put up something cheesy just to get past the requirement.

Originally Posted by cncb

As a developer of plugins that don't get downloaded much I agree with the jist of your sentiment but I don't think there is harm in allowing "popularity" as a sort type. Frankly, I can't imagine using this as a criteria for downloading a plugin but that's just me. This would be one of many sort types to use and the same could be said of sorting by "Recently changed" (plugin might often have updates because it is buggy, etc.).

I think the difference is that users are much more inclined to equate popular with good. I mean there must be some reason why all those people downloaded it, right? But that equation doesn't really hold up, and that kind of thinking is not (in my opinion) something Sage should encourage. If we want a measure of plugin goodness, then a rating system where users can give feedback on the plugins they've downloaded would be a better option than a simple download count.

(That said, I grant that there may be value to plugin devs in knowing how many users they have. But they have other ways to get that info.)

[darcilicious]

Originally Posted by GKusnick

I think the difference is that users are much more inclined to equate popular with good. I mean there must be some reason why all those people downloaded it, right? But that equation doesn't really hold up, and that kind of thinking is not (in my opinion) something Sage should encourage.

"Most popular files" available here http://forums.sagetv.com/forums/downloads.php now so in one sense, that horse is already out of the barn

[stuckless]

Originally Posted by Brent

This is fine if we want this HTPC thing to be just for programmers but me being a non-programmer.....

Are you telling me, that the HTPC thing is not just for programmers

Originally Posted by GKusnick

(That said, I grant that there may be value to plugin devs in knowing how many users they have. But they have other ways to get that info.)

That's why I host my plugins on my google code site... I get download stats for each version that is released.

[Fuzzy]

I don't think a download count is all that important... though I wouldn't be opposed to Sage collecting anonymous stats on what plugins people have installed, and give an agregated '### users use this plugin'. Would alleviate the whole upgrades create counts issue, and provide a REAL feedback on what is being used, and help new users find what are truly the most popular plugins.

[Brent]

Here's a few more observations:

We'll start with the release date field being populated for plugins:

• Some plugins have NO release date at all - all of these are by Slugger & are dependancy-type plugins
• Some of the release dates are formatted this way: 2009-07-03 while others like this: 2010.06.1 and others like this: 2010.06.01. This makes sorting by date not work properly and honestly it bothers me since I'm kind of in to table fields being uniform.
• When viewing the plugin description in the UI you don't see all of the description. Worse, many times that description doesn't get pithy enough and the more important verbage is beyond the 85 or so characters that fit on that screen. Yes you can get to the complete description by selecting "view plugin details", but why not have a "short description" field that forces the developer to make that description count and then a "long description" for the plugin details screen.

[GKusnick]

Originally Posted by Brent

When viewing the plugin description in the UI you don't see all of the description. Worse, many times that description doesn't get pithy enough and the more important verbage is beyond the 85 or so characters that fit on that screen. Yes you can get to the complete description by selecting "view plugin details", but why not have a "short description" field that forces the developer to make that description count and then a "long description" for the plugin details screen.

You don't need a separate field for that. You just need for plugin devs to put the brief description up front in the existing field, as prescribed by the plugin developer's guide. If some plugin devs aren't adhering to that, drop them a note in their support threads.

[evilpenguin]

Originally Posted by GKusnick

You don't need a separate field for that. You just need for plugin devs to put the brief description up front in the existing field, as prescribed by the plugin developer's guide. If some plugin devs aren't adhering to that, drop them a note in their support threads.

In a two pane view this wouldn't be an issue as the detail pane would have plenty of room for longer descriptions

[sleonard]

Take, for example, the heading 'Library'. There are only a handful of useful plugins in a massive list of "dependancy only", "no need to download directly", DO NOT DOWNLOAD DIRECTLY - ...", etc., etc.. It's nearly impossible to find the useful ones. It also looks like most of the useful ones are listed under the 'General' heading so there doesn't look like there is much use for the entire category.

The heading of 'Images' could be aware of any zip code the user has entered in the weather applet, for example, and only show logo paks near the user. As logo paks become available for more and more locations this list could get too large to browse and the non-logo paks would also get lost.

'Themes' could really use a thumbnail view or better yet a two-pane with more room for a nice graphic.

'UI Mod' - Hmmm, I know what this category is but my family? Can anyone think of a better heading title? 'Plugins', 'Add-ons', ?

'Full UI' - Ditto

'General' - I can't think of any way to change this one for the better.

S

[sleonard]

Sage 7 is now RC and not taking any more feature requests. Brent were you able to get any of these ideas to Sage in time?

S

[Brent]

Originally Posted by sleonard

Sage 7 is now RC and not taking any more feature requests. Brent were you able to get any of these ideas to Sage in time?

S

I'm not sure. They could describe changes to the plugin manager as "fixes" but my guess is any noticeable changes to the plugin manager are likely not happening until 7.1 Not ideal but not the end of the world either. I'm sure they (SageTV) have other nice surprises for us down the road though

[shadeblue.com]

Ok .. seems like a good place to add my wish list for Plugin Manager and Plugins in STV7.

1.) Add a second "experimental" plugin repository where plugins can be published that are in a BETA state. The GUI should provide some discrete option to switch between BETA and RELEASE plugin repositories. This way users who are not into beta testing are not pulling down plugins that are not mature and ready for general release.

2.) Add "tags" and search to help users find targeted plugins.

3.) Add User Ratings & Reviews for plugins. This may help new users discover which plugins are popular and participate in reviewing plugins and providing developers feedback. ( I agree that download counts are not enough.)

4.) "Plugin Showcase" provide a GUI to show off different plugins on a monthly? basis. Maybe editorial reviews from SageTV or other content producers like Brent :-) I think plugin discovery is a big challenge, there are just too many plugins with too little detail to try and discover via the Plugin Manager.

5.) Provide a web management portal allowing developers to stage, deploy, manage and edit their plugins. The existing simple HTML submission of XML is fine for a first release, but somewhat lacking for long term management.

6.) Provide a means for automating the publication of plugins up to SageTV plugin repository via ANT or MAVEN or some build other automated build tool.

7.) Allow users to HIDE/UNHIDE plugins listed in the Plugin Manager.

[GKusnick]

Originally Posted by shadeblue.com

1.) Add a second "experimental" plugin repository where plugins can be published that are in a BETA state. The GUI should provide some discrete option to switch between BETA and RELEASE plugin repositories. This way users who are not into beta testing are not pulling down plugins that are not mature and ready for general release.

Plugin devs already have the ability to flag plugins as Beta, and users have the ability to exclude Beta plugins from the Available Plugins list.

Originally Posted by shadeblue.com

4.) "Plugin Showcase" provide a GUI to show off different plugins on a monthly? basis. Maybe editorial reviews from SageTV or other content producers like Brent :-) I think plugin discovery is a big challenge, there are just too many plugins with too little detail to try and discover via the Plugin Manager.

Brent is free to editorialize about specific plugins on his own site. I'm not sure it's appropriate for the SageTV devs to single out particular plugins for endorsement or featured placement in the plugin UI.

Originally Posted by shadeblue.com

5.) Provide a web management portal allowing developers to stage, deploy, manage and edit their plugins. The existing simple HTML submission of XML is fine for a first release, but somewhat lacking for long term management.

I'm not clear on what you're asking for here. What exactly would you like to do with your plugin that the current web form can't do?

Originally Posted by shadeblue.com

6.) Provide a means for automating the publication of plugins up to SageTV plugin repository via ANT or MAVEN or some build other automated build tool.

As a total Ant novice I didn't find it too hard to put together some scripts for automating my plugin build and upload process. This seems like the kind of thing we could easily develop and share among ourselves; I'm not sure what more you need from the Sage devs to make this possible (or how this differs from wish #5).

[shadeblue.com]

Originally Posted by GKusnick

Plugin devs already have the ability to flag plugins as Beta, and users have the ability to exclude Beta plugins from the Available Plugins list.

Cool, I guess I overlooked this in the plugin developer's guide. I see it now :-)

Originally Posted by GKusnick

Brent is free to editorialize about specific plugins on his own site. I'm not sure it's appropriate for the SageTV devs to single out particular plugins for endorsement or featured placement in the plugin UI.

I understand your point, I was just looking for a helpful way to expose and educate end users to the various plugins. (in the SageTV GUI) I have been working with SageTV for a few years now and I certainly can't keep up with all the various development efforts. Discovery is what I was after, maybe there are better ways to accomplish this.

Originally Posted by GKusnick

I'm not clear on what you're asking for here. What exactly would you like to do with your plugin that the current web form can't do?

The existing web page is certainly workable, I'm not attacking the brilliant efforts of SageTV in adding this new plugin management system; however, copying and submitting XML in a web form can be error prone and a bit odd. A web based user interface that lists all the plugins a developer has published and allowing the developer to modify descriptions, release notes, upload the artifacts (rather than the ftp site), add screenshot image files, etc. Again, this is a wish list :-)

Originally Posted by GKusnick

As a total Ant novice I didn't find it too hard to put together some scripts for automating my plugin build and upload process. This seems like the kind of thing we could easily develop and share among ourselves; I'm not sure what more you need from the Sage devs to make this possible (or how this differs from wish #5).

Do your ant scripts submit the plugin XML via the existing webpage using a form submit / post? I guess this would not be too difficult and you are right, we could probably manage this. I was thinking more of a web service API approach to provide a guaranteed interface to programmaticly submit updates. This wist list item may be somewhat in conflict with #5, this is an automated scripting approach, whereas #5 was a GUI driven approach. As long as I am wishing, both would be nice :-)

[GKusnick]

Originally Posted by shadeblue.com

Do your ant scripts submit the plugin XML via the existing webpage using a form submit / post? I guess this would not be too difficult and you are right, we could probably manage this.

My script brings up the web form in a browser window and pastes in the generated manifest without actually submitting it. This gives me a chance to eyeball it for correctness before manually clicking Submit. Call me old-fashioned, but I prefer to take personal responsibility for the final submission rather than trusting it to a script (even one I wrote myself).

However it would certainly be possible to automate that last step as well. I believe Slugger has a script that does that.