Tags: svg



Sonic sparklines

I’ve seen some lovely examples of the Web Audio API recently.

At the Material conference, Halldór Eldjárn demoed his Poco Apollo project. It generates music on the fly in the browser to match a random image from NASA’s Apollo archive on Flickr. Brian Eno, eat your heart out!

At Codebar Brighton a little while back, local developer Luke Twyman demoed some of his audio-visual work, including the gorgeous Solarbeat—an audio orrery.

The latest issue of the Clearleft newsletter has some links on sound design in interfaces:

I saw Ruth give a fantastic talk on the Web Audio API at CSS Day this year. It had just the right mixture of code and inspiration. I decided there and then that I’d have to find some opportunity to play around with web audio.

As ever, my own website is the perfect playground. I added an audio Easter egg to adactio.com a while back, and so far, no one has noticed. That’s good. It’s a very, very silly use of sound.

In her talk, Ruth emphasised that the Web Audio API is basically just about dealing with numbers. Lots of the examples of nice usage are the audio equivalent of data visualisation. Data sonification, if you will.

I’ve got little bits of dataviz on my website: sparklines. Each one is a self-contained SVG file. I added a script element to the SVG with a little bit of JavaScript that converts numbers into sound (I kind of wish that the script were scoped to the containing SVG but that’s not the way JavaScript in SVG works—it’s no different to putting a script element directly in the body). Clicking on the sparkline triggers the sound-playing function.

It sounds terrible. It’s like a theremin with hiccups.

Still, I kind of like it. I mean, I wish it sounded nicer (and I’m open to suggestions on how to achieve that—feel free to fork the code), but there’s something endearing about hearing a month’s worth of activity turned into a wobbling wave of sound. And it’s kind of fun to hear how a particular tag is used more frequently over time.

Anyway, it’s just a silly little thing, but anywhere you spot a sparkline on my site, you can tap it to hear it translated into sound.


I’ve noticed a few nice examples of motion design on the web lately.

The Cloud Four gang recently redesigned their site, including a nice little animation on the home page.

Malcolm Gladwell has a new podcast called Revisionist History. The website for the podcast is quite lovely. Each episode is illustrated with an animated image. Lovely!

If you want to see some swishy animations triggered by navigation, the waaark websites has them a-plenty. Personally I find the scroll-triggered animations on internal pages too much to take (I have yet to find an example of scrolljacking that doesn’t infuriate me). But the homepage illustrations have some lovely subtle movement.

When it comes to subtlety in animation, my favourite example comes from Charlotte. She recently refactored the homepage of the website for the Leading Design conference. It originally featured one big background image. Switching over to SVG saved a lot of bandwidth. But what I really love is that the shapes in the background are now moving …ever so gently.

It’s like gazing at a slow-motion lava lamp of geometry.


I was in Nuremberg last weekend for Indie Web Camp. It was great.

At some point I really should stop being surprised by just how much gets done in one weekend, but once again, I was blown away by the results.

On the first day we had very productive BarCamp-like discussion sessions, and on the second day it was heads-down hacking. But it was hacking with help. Being in the same room as other people who each have their own areas of expertise is so useful. It really turbo-charges the amount that you can get accomplished.

For example, I was helping Tom turn his website into a progressive web app with the addition of a service worker and a manifest file. Meanwhile Tom was helping somebody else get a Wordpress site up and running.

Actually, that was what really blew me away: two people began the second day of Indie Web Camp Nuremberg without websites and by the end of the day, they both had their own sites up and running. For me, that’s the real spirit of the indie web—I know we tend to go on about the technologies like h-card, h-entry, webmentions, micropub, and IndieAuth, but really it’s not about the technologies; it’s about having your own place on the web so that you have control over what you put out in the world.

For my part, I was mostly making some cosmetic changes to my site. There was a really good discussion on the first page about home pages. What’s the purpose of a home page? For some, it’s about conveying information about the person. For others, it’s a stream of activity.

My site used to have a splash-like homepage; just a brief bio and a link to the latest blog post. Then I changed it into a stream a few years ago. But that means that the home page of my site doesn’t feel that different from sections of the site like the journal or the link list.

During the discussion at Indie Web Camp, we started looking at how silos design their profile pages to see what we could learn from them. Looking at my Twitter profile, my Instagram profile, my Untappd profile, or just about any other profile, it’s a mixture of bio and stream, with the addition of stats showing activity on the site—signs of life.

I decided I’d add signs of life to my home page. Once again, I reached for my favourite little data visualisation helper: sparklines

A sparkline is a small intense, simple, word-sized graphic with typographic resolution.

I’ve already got sparklines on Huffduffer and on The Session so I suppose it was only a matter of time before they showed up here.

Small Screen Sparklines Large Screen Sparklines

I’ve been tweaking them ever since I got back from Germany. Now I’ve added in a little h-card bio as well.

Bio and sparklines Bio And Sparklines (large screen)

Initially I was using the fantastic little scripted SVG that Stuart made , the same one that I’m using on Huffduffer and The Session. But Kevin pointed out that a straightforward polyline would be more succinct. And in the case of my own site, there’s only four sparklines so it wouldn’t be a huge overhead to hard-code the values straight into the SVGs.

Yesterday was the first day of Render Conference in Oxford (I’ll be speaking later today). Sara gave a blisteringly great talk on (what else?) SVGs and I got so inspired I started refactoring my code right there and then. I’m pretty happy with how the sparklines are working now, although I’m sure I’ll continue to play around with them some more.

There’s another activity visualisation that I’m eager to play around with. I really like the calendar heatmap on my Github profile. I could imagine using something like that for an archive view on my own site.

Luckily for me, I’ll have a chance to play around with my website a bit more very soon. There’s going to be another Indie Web Camp in Germany very soon.

Indie Web Camp Düsseldorf will take place on May 7th and 8th, right before Beyond Tellerrand. Last year’s event was really inspiring. If there’s any chance you can make it, you should come along. You won’t regret it.


Jake gave a great talk at Responsive Day Out 3 all about nuanced progressive enhancement, with a look at service workers in particular (a technology designed with progressive enhancement at its heart).

To illustrate the performance gains, Jake used his SVGOMG site as an example—a really terrific resource for optimising SVGs.

SVGOMG requires JavaScript for its core functionality (optimising an SVG file). That was a deliberate choice. Jake could’ve made the barrier-to-entry as low as any browser that supports input type="file" but he decided that for this audience (developers) it was a safe assumption that JavaScript would be available.

Jake talked about this in an interview with Paul about the site:

I’m a strong believer in progressive enhancement, but also that each phase of the enhancement needs a user.

I agree completely with this approach. It makes sense to have a valid reason for adding any enhancement. But there’s something about this particular example that wasn’t sitting right with me. It took me a while to figure it out, but I now realise what it is.

Jake is talking about making it work on the server as an enhancement. But that’s not an enhancement, it’s a fallback.

Thinking in terms of fallbacks is more of a “graceful degradation” approach (i.e. for every “full” feature, thinking of a corresponding fallback). That’s not how I like to think of progressive enhancement. I like to think in terms of a baseline. And that baseline, in my mind, does not require a user to justify its existence. That’s because the baseline isn’t there to cover the use cases we can think of, it’s there to cover the use cases we can’t predict.

That might seem like a minor difference in wording to the graceful degradation approach but I think it’s actually a fundamentally different way of approaching the situation.

When I was on the progressive enhancement panel at Edge Conf, Lyza asked how low the baseline should be. I said “as low as possible.” Some of my fellow panelists took issue with this saying it varies from project to project, and that’s completely true, but I think I should’ve clarified that when I talk about a baseline, I’m not talking about browsers. I don’t think about a baseline in terms of “IE4 and above, Android 2.1 and above, etc.”—I think about a baseline in terms of “the minimum required technology to allow a user to accomplish the core task” (that qualification about core tasks is important—the baseline does not need to cover tasks that are nice-to-have; those can safely require more sophisticated technology).

That “minimum required technology” often turns out to be a combination of a web server, HTTP, and some HTML.

So to take SVGOMG as an example, I would begin with the baseline of “allowing a user to optimise an SVG file”. The minimum required technology is a web server running a programme that does the optimisation, and an HTML document that contains a form element with input type="file". Once that’s in place, then I can start applying Jake’s very sensible approach of thinking about enhancements in terms of specific user benefits. In this case, it’s pretty clear that 99.99% of the users would benefit from not having that round-trip to the server and have the SVG optimisation happen in the browser using JavaScript.

There’s an enhancement provided for the use case that I can imagine. But—and this is the subtle but important distinction—there’s a baseline for all the use cases that I can’t think of. I need to recognise that I won’t be able to predict all the possible use cases, and that’s okay—as long there’s a solid baseline in place, I’ve got an insurance policy for unforeseen circumstances. It’s still not perfect, but it lowers the risk somewhat by reducing the number of assumptions being built in at that baseline level.

Going back to Jake’s chat with Paul, he says:

I thought about making the site work without JS by doing the SVG work on the server, but this would be slow and a maintenance burden.

The maintenance burden is a very valid point. This is something that Stuart talked about a while back:

It is in theory possible to write a web app which does processing on the server and is entirely robust against its client-side scripting being broken or missing, and which does processing on the client so that it works when the server’s unavailable or uncontactable or expensive or slow. But let’s be honest here. That’s not an app. That’s two apps.

Leaving aside the promise of isomorphic/universal/whatever JavaScript, this issue of developer convenience is big issue. When I use the term “developer convenience” to label this problem, I am not belittling it in any way—developer convenience is incredibly important (hence the appeal of so many tools and frameworks that make life easier for developers). I still believe that developer convenience should be lower on the list of priorities than having a rock-solid baseline, but I can totally understand if someone doesn’t share that opinion. It’s a personal decision and if the pain involved in making a more universal baseline is greater than the perceived—and, let’s face it, somewhat abstract—benefit, I can totally understand that.

Anyway, that’s my little brain dump about progressive enhancement and baseline experiences. Something about treating the baseline experience as an enhancement was itching at my brain and now that I’ve managed to scratch it, I can see what was troubling me: thinking about the baseline experience in the same way as thinking about enhancements doesn’t work for me.

Personally, I’m going to strive to keep the baseline as low as possible. I’m also going to strive to apply Jake’s maxim about every enhancement requiring a user.