|Page 1 of 1||[ 8 posts ]|
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:
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.
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.
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?
I second your thoughts.
I found the gallery build process a bit "artificial" related to the testing: I mean, the builder creates the final version of the module adding some glue and only then you can test it. Maybe we need something as selleck for the docs.
And I am tired of Ant: I have been waiting ybuild  for windows.
I would add a badge indicating if the module is compatible with the latest version.
I have a mobile network bandwidth and I second IRC meetings suggestion.
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).
I think that we need a new category of gallery-components, and for that we need Dav's help. The category would be something like: "peer-reviewed". We would announce a review of a component to take place over a month. We would explicitly invite the authors of those components beyond a general announcement.
For that process, we would first need to establish a series of guidelines on what is it we want on a component, so as to be able to rate each of the candidates based on these guidelines. We could suggest the authors to improve on those missing areas. This "guidelines" would be valuable on their own and we should publish them.
What happens with an author who is not able or is unwilling to tweak an otherwise promising component? That is easy: anyone can add to it. What is the difference with the current setup? Right now, we simply don't know which one to improve. For example, most components lack test suites. If there are four accordions, is anyone going to write tests for the four of them? Now, if we have a candidate for best accordion, then any such effort would not be wasted.
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.
This is a great thread guys, I have a ton of little notes on my vision for the Gallery:
* Doc generation with Selleck
* API Docs via YUIDoc
* Custom Loader builds with Gallery and Deps
* Improved Gallery build
* Switch to buildy
* Allow use of an external source repo (not required to fork yui3-gallery)
* Better meta-data (from Selleck's component.json)
* Remove most of the admin on the site and drive it all with JSON files
* If a module has docs and tests
* Fail the build if tests fail
* Have a build tester (Travis)
* Integrate them right next to the Core lib
I know what I want to do, but I need to have the time to build it all
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
I noticed your mention of Buildy. I created a similar project named gear that has a number of advantages over Buildy:
- Simple to write tasks. Tasks transform input to output without requiring the STRING(S)/FILES mechanism of working with input.
- Improved API syntax. Simply call the task name on the queue i.e. queue().load('file').jsminify().run()
- Modular loading system. Loads tasks from NPM.
- Improved forking support. Buildy forks are limited and can't rejoin on completion.
It's well tested and being used here within Yahoo on Mojito Shaker.
|Page 1 of 1||[ 8 posts ]|
|You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum