Since the creation of Webmaker.org and the MakeAPI, the recommended strategy for creating and curating galleries of makes was to use tagging.
For example, one can tag ten makes with gallery and surface that collection of makes using a tag search. If there was a need for order in the data, a second unique tag must be given to each make as an indication of its order in the set. For example: gallery-1 all the way to gallery-10, then they must be sorted manually after fetching the set.
The downsides of this for the regular user are numerous:
- If someone else uses the same tag on an unrelated make, it will "pollute" the gallery
- The logic required to order the gallery is needlessly complex.
- It's a pain in the ass to apply tags to a set of existing makes
- It's a pain in the ass to update a gallery without screwing something up horribly (i.e. duplicate ordering tags)
Galleries and collections are a heavily used feature across the Webmaker universe, and the horrible system we force people to use to build these galleries is a crime.
In order to rectify this crime against the world, I identified some goals that would have to be met in order for this to be considered fixed.
- A gallery should not be defined by tags
- Gallery order should not be defined by tags, and should not require additional logic at the point of the consumer to sort the gallery data
- Fetching Make data from a gallery should be simple, and act as a drop in replacement old style of gallery searches.
- Every Webmaker User should be able to create and maintain their own galleries of Makes
Enter the Make List API. It is a collection of server endpoints that allow Webmaker apps to manage a newly defined data model built right into the Make API server.
Essentially, a Make List ("List") is a Mongoose model that stores an Array of Make ID's.
Goal 1 Completed!
Order in the array determines positioning wherever the List is to consumed.
When a List is fetched, The Make API will automatically fetch the Makes from ElasticSearch, sort them, and return the Make JSON to the client. The data is identical to the data returned by make searches.
Goal 2 and 3 Completed!
Lastly, every list is associated with a Webmaker account and only an owner of an List can modify it.
Goal 4 completed!
So the TL;DR; of this is that any user can create and curate any number of Lists (my favourites, top tens, best of makerparty, etc). These lists can be built into any number of places - The front page, the webmaker gallery, top webmaker teaching kits, webmaker profile, webmaker events, ALL THE THINGS!
If I had this running somewhere live I would link it, but I do not. For the time being, you can follow the development in Bug 997329 on Bugzilla.
Below is a Youtube Video of the Demo Application I built to show off the API:
If you have cool ideas about what this can be used for, or have questions about if it could be used for something, drop me a line!