Several weeks ago now, I noticed a sideways mention to a new book on Mashup Patterns by Michael Ogrinz on some blog or other, and through the magic of Twitter managed to get a hold of a review copy, with no obligation to review it etc etc (so count that as some sort of disclaimer and s**w you, Mike Arrington, s**w you;-)
Mashup patterns are actually something I’ve been thinking about for quite some time now, most notably when it comes round to preparing (or not) for a mashup workshop I’m supposed to be running. (So for example, in my diary at the moment are a workshop at IWMW with Mike Ellis and a session at Mash Oop North.)
So what are “mashup patterns”? Following Ogrinz’s lead, I’m not really into the idea of coming up with an academically robust definition of what mashup patterns are, or aren’t. Where Ogrinz talks of “reusable solutions”, I am equally likely to talk about recipes (or instances of a particular recipe type). This reflects, in part, the way I cook! So for example, of the dozens of pasta sauces I have, on occasion, tried to make, they’re all pretty much one of two types: the red one (tomato based) or the white one (white sauce based).
Ogrinz identifies various catgories of pattern, and organises the book accordingly:
– harvest patterns (“Mine one or more resources for unique data”) identify how to get data out of the silos and into the mashup space in an appropriate format (for example data scraping from WIkipedia);
– enhance patterns (“extend the capabilities of existing resources”) show how to improve what you’ve already got (for example, feed annotation streams and progressive enhancement);
– assemble patterns (“remix existing data and interfaces to serve new purposes”), such as content aggregation and filtering;
– manage patterns (“leverage the investmnt in existing assets more effectively”) such as widget enablers and dashboards (like the OUseful dashboard);
– testing patterns (“verify the performance and reliability of applications”), such as load testing and regression testing; and
– anti-patterns: that is, how not to do it…
Each of the patterns is described (in brief) on the Mashup Patterns website.
Each pattern is then given a memorable name, tagged with the “core activities” associated with the pattern and described in terms of a problem statement and an appropriate solution (the solution describes the pattern, the problem statement the context within which the pattern might be applied), along with a diagrammatic representation of the pattern. One or more examples of how (at a high level) the pattern might be applied in a real world context (or contrived real world context!) are then described. Value is also added to each pattern in the form of ‘links’ to other related patterns, and a fragility rating that describes how brittle the pattern is likely to be.
Whilst I’m sympathetic to Ogrinz’s decision to avoid writing code or UML diagrams in favour of specifying mashup patterns in more generic terms, I do often prefer to illustrate the mashups I produce as working examples. (Ogrinz uses an attractive abstracted visual language to describe the elements involved in each pattern), So as regular readers of OUseful.info will know, Yahoo Pipes are one of my preferred ways of doing this…
As well as the idea of mashup patterns, I’m also very partial to the idea of lenses, ways of thinking or asking questions about a particular problem from a particular perspective. The Art of Game Design: A Book of Lenses provides a fine example of using lenses to think about the design of computer games (in fact, many of the lenses are appropriate for thinking about many areas of design). If you’ve heard of de Bono’s Thinking Hats, lenses provide a similar device for taking “different perspectives” on a particular issue, or asking particvular sorts of questions about it.
So to finish off, I wonder: if I was to start a “practical mashups” uncourse blog, would: a) anyone follow it; b) be prepared to buy Mashup Patterns (and maybe also The Art of Game Design: A Book of Lenses), as uncourse ‘set books’?