In 1979, two books shaped my formative years • Supernatural Detective’s Field Guide
This is such a great project from Jon—a mashup of two books from his childhood!
Put that RSS feed in your feed reader.
This is such a great project from Jon—a mashup of two books from his childhood!
Put that RSS feed in your feed reader.
Yahoo PIpes was ahead of its time. Here’s a nostalgic retrospective by Glenn Fleishman.
I think it was Jason who once told me that if you want to make someone’s life a misery, teach them about typography. After that they’ll be doomed to notice all the terrible type choices and kerning out there in the world. They won’t be able to unsee it. It’s like trying to unsee the arrow in the FedEx logo.
I think that Stewart Brand’s pace layers model is a similar kind of mind virus, albeit milder. Once you’ve been exposed to it, you start seeing in it in all kinds of systems.
Each layer is functionally different from the others and operates somewhat independently, but each layer influences and responds to the layers closest to it in a way that makes the whole system resilient.
Last month I sent out an edition of the Clearleft newsletter that was all about pace layers. I gathered together examples of people who have been infected with the pace-layer mindworm who were applying the same layered thinking to other areas:
My own little mash-up is applying pace layers to the World Wide Web. Tom even brought it to life as an animation.
See the Pen Web Layers Of Pace by Tom (@webrocker) on CodePen.
Recently I had another flare-up of the pace-layer pattern-matching infection.
I was talking to some visiting Austrian students on the weekend about design principles. I explained my mild obsession with design principles stemming from the fact that they sit between “purpose” (or values) and “patterns” (the actual outputs):
Purpose » Principles » Patterns
Your purpose is “why?”
That then influences your principles, “how?”
Those principles inform your patterns, “what?”
Hey, wait a minute! If you put that list in reverse order it looks an awful lot like the pace-layers model with the slowest moving layer at the bottom and the fastest moving layer at the top. Perhaps there’s even room for an additional layer when patterns go into production:
Your purpose should rarely—if ever—change. Your principles can change, but not too frequently. Your patterns need to change quite often. And what you’re actually putting out into production should be constantly updated.
As you travel from the most abstract layer—“purpose”—to the most concrete layer—“production”—the pace of change increases.
I can’t tell if I’m onto something here or if I’m just being apopheniac. Again.
I like this mashup of two diagrams: Stewart Brand’s pace layers and Stephanie DiRusso’s typology of design thinking.
Such an elegant idea!
Bookfeed.io is a simple tool that allows you to specify a list of authors, and generates an RSS feed with each author’s most recently released book.
Small pieces, loosely joined.
Well, this is a rather wonderful mashup made with data from thesession.org:
The distribution of Irish traditional tunes which reference place names in Ireland
On Monday, I linked to Tom’s latest video. It uses a clever trick whereby the title of the video is updated to match the number of views the video has had. But there’s a lot more to the video than that. Stick around and you’ll be treated to a meditation on the changing nature of APIs, from a shared open lake to a closed commercial drybed.
It reminds me of (other) Tom’s post from a couple of year’s ago called Pouring one out for the Boxmakers, wherein he talks about Twitter’s crackdown on fun bots:
Web 2.0 really, truly, is over. The public APIs, feeds to be consumed in a platform of your choice, services that had value beyond their own walls, mashups that merged content and services into new things… have all been replaced with heavyweight websites to ensure a consistent, single experience, no out-of-context content, and maximising the views of advertising. That’s it: back to single-serving websites for single-serving use cases.
A shame. A thing I had always loved about the internet was its juxtapositions, the way it supported so many use-cases all at once. At its heart, a fundamental one: it was a medium which you could both read and write to. From that flow others: it’s not only work and play that coexisted on it, but the real and the fictional; the useful and the useless; the human and the machine.
Both Toms echo the sentiment in Anil’s The Web We Lost, written back in 2012:
Five years ago, if you wanted to show content from one site or app on your own site or app, you could use a simple, documented format to do so, without requiring a business-development deal or contractual agreement between the sites. Thus, user experiences weren’t subject to the vagaries of the political battles between different companies, but instead were consistently based on the extensible architecture of the web itself.
I know, I know. We’re a bunch of old men shouting at The Cloud. But really, Anil is right:
This isn’t our web today. We’ve lost key features that we used to rely on, and worse, we’ve abandoned core values that used to be fundamental to the web world. To the credit of today’s social networks, they’ve brought in hundreds of millions of new participants to these networks, and they’ve certainly made a small number of people rich.
But they haven’t shown the web itself the respect and care it deserves, as a medium which has enabled them to succeed. And they’ve now narrowed the possibilites of the web for an entire generation of users who don’t realize how much more innovative and meaningful their experience could be.
In his video, Tom mentions Yahoo Pipes as an example of a service that has been shut down for commercial and idealogical reasons. In many ways, it was the epitome of what Anil was talking about—a sort of meta-API that allowed you to connect different services together. Kinda like IFTTT but with a visual interface that made it as empowering as something like the Scratch programming language.
There are services today that provide some of that functionality, but they’re more developer-focused. Trys pointed me to Pipedream, which looks good but you need to know how to write Node.js code and import npm packages. I’m sure it’s great if you’re into serverless Jamstack lambda thingamybobs but I don’t think it’s going to unlock the potential for non-coders to create cool stuff.
On the more visual pipes-esque Scratchy side, Cassie pointed me to Cables:
Cables is a tool for creating beautiful interactive content.
It isn’t about making mashups, but it does look something that non-coders could potentially use to make something that looks cool. It reminds me a bit of Bret Victor and his classic talk on Inventing On Principle—always worth revisting!
Tom’s videos are so good! Did you see his excellent in-depth piece on copyright?
This one is all about APIs and the golden age of Web 2.0 when we were free to create mashups.
It pairs nicely with a piece by another Tom from a couple of years back on the joy of Twitterbots.
Jigsaw puzzle companies tend to use the same cut patterns for multiple puzzles. This makes the pieces interchangeable, and I sometimes find that I can combine portions from two or more puzzles to make a surreal picture that the publisher never imagined. I take great pleasure in “discovering” such bizarre images lying latent, sometimes for decades, within the pieces of ordinary mass-produced puzzles.
Refresh for a new design challenge.
This is nifty—a map of all the Irish music sessions and events happening around the world, using the data from TheSession.org.
If you’re interested in using data from The Session, there’s a read-only API and regularly-updated data dumps.
Absolute genius! I’ll never hear Sgt. Pepper’s quite the same way again.
I giggled at quite of few of these mashups.
The thesis: any film is improved by playing Walk Of Life by Dire Straits over the ending.
The proof: this website.
(this is absorbing and brilliant)
Back at the first San Francisco Science Hack Day I wanted to do some kind of mashup involving the speed of light and the distance of stars:
I wanted to build a visualisation based on Matt’s brilliant light cone idea, but I found it far too daunting to try to find data in a usable format and come up with a way of drawing a customisable geocentric starmap of our corner of the galaxy. So I put that idea on the back burner…
At this year’s San Francisco Science Hack Day, I came back to that idea. I wanted some kind of mashup that demonstrated the connection between the time that light has travelled from distant stars, and the events that would have been happening on this planet at that moment. So, for example, a star would be labelled with “the battle of Hastings” or “the sack of Rome” or “Columbus’s voyage to America”. To do that, I’d need two datasets; the distance of stars, and the dates of historical events (leaving aside any Gregorian/Julian fuzziness).
For wont of a better hack, Chloe agreed to help me out. We set to work finding a good dataset of stellar objects. It turned out that a lot of the best datasets from NASA were either about our local solar neighbourhood, or else really distant galaxies and stars that are emitting prehistoric light.
The best dataset we could find was the Near Star Catalogue from Uranometria but the most distant star in that collection was only 70 or 80 light years away. That meant that we could only mash it up with historical events from the twentieth century. We figured we could maybe choose important scientific dates from the past 70 or 80 years, but to be honest, we really weren’t feeling it.
We had reached this impasse when it was time for the Science Hack Day planetarium show. It was terrific: we were treated to a panoramic tour of space, beginning with low Earth orbit and expanding all the way out to the cosmic microwave background radiation. At one point, the presenter outlined the reach of Earth’s radiosphere. That’s the distance that ionosphere-penetrating radio and television signals from Earth, travelling at the speed of light, have reached. “It extends about 70 light years out”, said the presenter.
This was perfect! That was exactly the dataset of stars that we had. It was a time for a pivot. Instead of the lofty goal of mapping historical events to the night sky, what if we tried to do something more trivial and fun? We could demonstrate how far classic television shows have travelled. Has Star Trek reached Altair? Is Sirius receiving I Love Lucy yet?
No, not TV shows …music! Now we were onto something. We would show how far the songs of planet Earth had travelled through space and which stars were currently receiving which hits.
Chloe remembered there being an API from Billboard, who have collected data on chart-topping songs since the 1940s. But that API appears to be gone, and the Echonest API doesn’t have chart dates. So instead, Chloe set to work screen-scraping Wikipedia for number one hits of the 40s, 50s, 60s, 70s …you get the picture. It was a lot of finding and replacing, but in the end we had a JSON file with every number one for the past 70 years.
Meanwhile, I was putting together the logic. Our list of stars had the distances in parsecs. So I needed to convert the date of a number one hit song into the number of parsecs that song had travelled, and then find the last star that it has passed.
We were tempted—for developer convenience—to just write all the logic in JavaScript, especially as our data was in JSON. But even though it was just a hack, I couldn’t bring myself to write something that relied on JavaScript to render the content. So I wrote some really crappy PHP instead.
By the end of the first day, the functionality was in place: you could enter a date, and find out what was number one on that date, and which star is just now receiving that song.
After the sleepover (more like a wakeover) in the aquarium, we started to style the interface. I say “we” …Chloe wrote the CSS while I made unhelpful remarks.
For the icing on the cake, Chloe used her previous experience with the Rdio API to add playback of short snippets of each song (when it’s available).
Here’s the (more or less) finished hack:
Basically, it’s a simple mashup of music and space …which is why I spent the whole time thinking “What would Matt do?”
Just keep hitting that button to hear a hit from planet Earth and see which lucky star is currently receiving the signal.*
Science!
*I know, I know: the inverse-square law means it’s practically impossible that the signal would be in any state to be received, but hey, it’s a hack.
A superb piece by Marco Arment prompted by the closing of Google Reader. He nails the power of RSS:
RSS represents the antithesis of this new world: it’s completely open, decentralized, and owned by nobody, just like the web itself. It allows anyone, large or small, to build something new and disrupt anyone else they’d like because nobody has to fly six salespeople out first to work out a partnership with anyone else’s salespeople.
And he’s absolutely on the money when he describes what changed:
RSS, semantic markup, microformats, and open APIs all enable interoperability, but the big players don’t want that — they want to lock you in, shut out competitors, and make a service so proprietary that even if you could get your data out, it would be either useless (no alternatives to import into) or cripplingly lonely (empty social networks).
I share his anger.
Well, fuck them, and fuck that.
This is a really nice and simple idea: view photos from a specific place taken at a specific time. Voyeuristic fun.
A nifty little mashup from Music Hack Day London 2012.
Steven Johnson describes the beautifully chaotic way that ideas collide and coalesce. Oh, and this bit…
Listening to Cerf talk about the origins of the Internet — and thinking about the book project — made me wonder who had actually come up with the original idea for a decentralized network. So that day, I tweeted out that question, and instantly got several replies. One of those Twitter replies pointed to a Wired interview from a decade ago with Paul Baran, the RAND researcher who was partially responsible for the decentralized design.
I never expected to see a cross between responsive design and AR, but here ya go:
A silly mashup of HTML5 technologies: We use the canvas to capture the contents of a video element. The canvas then identifies the blue markers and overlays an iframe on top of it. The iframe contains our website (upperdog.se) which has a responsive design.