Forums

Hey!

I've been thinking about the Gallery for a while and how hard it is to get people to use Gallery modules. To improve this I'd like to discuss a few technical and community actions.

From a technical point of view there are a couple of features that would really help:

Versions

Right now users can only chose one Gallery build and they get all the modules from that build. If a user wants to get a newer release of a certain module he ends up getting a newer version of all modules, which could fail to work. This is possible mostly because some modules are updated more slowly than others and the ones that update quickly usually make them compatible with the latest version of YUI. If YUI changed its API (which is common between releases) the user might end up with a module for 3.3.0 and another for 3.5.1. It'd be good to have more granularity in the choice of versions for gallery modules.

Having more control over versions should also allow us to require certain Gallery modules from other Gallery modules from a specific build. That way if the author of one Gallery module changes its API, the other one won't break.

Testing

Having access to the YUI team's testing tools would be awesome. The same way the Travis Bot runs on pull requests, having a bot run tests in Gallery modules before pushing to CDN would be great. Also, having a badge in the module page showing how many tests passed would be a lot of help and increase trust in the module and its author.

Personally I can say that I don't have access to all the hardware Dav has in his garage to test YUI on. If I could get my Gallery modules tested there through Yeti... That'd be really really cool.

Analytics

If as authors we could know if people are using our modules from the CDN and how many times they got downloaded, it'd really motivate us to keep them up to date. Any level of depth of analytics would be really nice.

------------

Apart from the technical tools, there are some things that we could do as a community to improve the Gallery. Since the YUI team has decided to focus on making the building blocks for an application and its widgets instead of making a big number of different prebuilt widgets (which makes a lot of sense), it's a little up to the rest of us to fill in the gaps.

Most of the times what hits the Gallery is what we built for ourselves and we thought would be useful to others. That's fine, but the problem is that we can end up with what we have for Accordion for example: four different versions of it.

To improve this, Satyam once suggested to me that we could organice IRC meetings from time to time to discuss specific Gallery components and focus on one as a group to make it better, add better docs and examples, etc.

What do you think?

Hi,

Me too. (One of) the great things about the gallery is that gallery components get on the CDN right next to the YUI core, use()able really easily. It'd be even better if components are (or have the possibility to be) first class members of YUI in other ways. So to add to your thoughts:

- it'd be great if documentation could be generated from gallery components that are there, and hosted with the gallery. Obviously if gallery contributors don't document the code it can't generate the documentation, but if they do, that's another really helpful signal of trustworthiness for users. And having the API docs there alongside the core docs is just going to make it all a lot easier to use.

This might extend to examples - would it be possible to write examples using the YUI system (I watched Luke's video...) for gallery modules and have them hosted alongside too?

- retirement. I think part of the solution to the 'four accordians' problem is having a way for authors to explicitly 'retire' modules. It'd only be a flag really - you'd still want it available on the CDN for people who are using it and are happy - but retired components should be less visible in the gallery, and with a big warning that says 'this isn't going to get much tlc, and there's another version in the core/gallery that you'd be better off using'. So for example, I did a resize early on, but it's been superseded by other, better versions, so it ought to get retired.

- discoverability. I think it's quite hard to find components in the gallery. I mean, if you're looking for a particular something, you've just got to look through the list of all of them, and hope they've been well named. Some tagging and sorting (and perhaps this should extend from core to the gallery, so you see it all together) would be helpful (to me, anyway).

Matt

Hey Matt,

Gallery modules already have a "deprecated" tag. So that's covered.


About documentation, we could start by building the docs for all modules by ourselves and publishing them somewhere. That will give as an idea of the current state of documentation of all modules. It's likely many of them will have a lot of holes. Like Satyam says, we need to know on which to focus to complete them. And yes, I agree, we should start writing examples and user guides the same way the YUI team does.

I'm not really worried about discoverability yet. It's still far from npm and its 10378 packages.

My recommendation would be to follow our build steps and make your modules as close to ours as possible. Put your examples in your `docs` dir and use Selleck. Make sure that you have YUIDoc properly parsing your modules.

Then when I start this process I have something to work with