Journal tags: canvas

I remember when I first saw Paddy’s illustration for this year’s dConstruct site, I thought “Well, that’s a design direction, but there’s no way that Graham will be able to implement all of it.” There was a tight deadline for getting the site out, and let’s face it, there was so much going on in the design that we’d just have to prioritise.

I underestimated Graham’s sheer bloody-mindedness.

At the next front-end pow-wow at Clearleft, Graham showed the dConstruct site in all its glory …in Lynx.

I love that. Even with the focus on the gorgeous illustration and futuristic atmosphere of the design, Graham took the time to think about the absolute basics: marking up the content in a logical structured way. Everything after that—the imagery, the fonts, the skewed style—all of it was built on a solid foundation.

It would’ve been easy to go crazy with the fonts and images, but Graham made sure to optimise everything to within an inch of its life. The biggest bottleneck comes from a third party provider—the map tiles and associated JavaScript …so that’s loaded in after the initial content is loaded. It turns out that the site build was a matter of prioritisation after all.

There’s plenty of CSS trickery going on: transforms, transitions, and opacity. But for the icing on the cake, Graham reached for canvas and programmed space elevator traffic with randomly seeded velocity and size.

Oh, and of course it’s all responsive.

So, putting that all together…

The dConstruct 2015 site is gorgeous, semantic, responsive, and performant. Conventional wisdom dictates that you have to choose, but this little site—built on a really tight schedule—shows otherwise.

dConstruct 2014 has a new website. Huzzah!

When I announced the original website two months ago, I was very, very excited about the line-up, but I was less excited about the design of the site itself. To be honest, it was a somewhat rushed affair. It did the job but it didn’t have much pizzazz. I had some design direction—colour, typography, texture—courtesty of Mikey, but I didn’t push it to do anything very interesting.

So Mikey took some time to iterate and revise, and he came up with a gorgeous new design. I think this does a much better job of capturing the spirit of dConstruct.

As well as a revised colour palette and lusher textures, there was also opportunity to do something quite playful in the masthead. Making sites for our own projects always presents a nice opportunity to try out some whacky stuff that we might not get a chance to do on client work.

In this case, the plan was to play with the theme of this year’s dConstruct—Living With The Network—and use it as part of the visual design, literally networking up parts of the interface.

It was a nice chance for me to play around with canvas. But I didn’t dive into code straight away. I had a think about how I could add this an enhancement to the responsive layout.

My plan was to generate a canvas element under the existing elements in the header using z-index to keep them separated while maintaining the appearance of having everything connected up.

It worked out pretty well. But I wanted to push it further. How about making it an interactive element that responds to the user?

I know, I know. It’s very silly and frankly a bit wanky, but y’know, it felt like it would be nice and playful.

I had no idea how to do it though. At an internal code review here at Clearleft, I demoed what I had so far and asked for advice. The general consensus was that I should probably be using SVG rather than canvas for making interactive graphical elements. They’re probably right, but I distinctly remember learning about hit detection and mouse events in canvas during Seb’s excellent Creative JS workshop.

So I stuck with canvas and fiddled around with numbers until I got to something that felt lke it reacted nicely to hover events (or touch/clicks if hover isn’t available …or even if it is). requestAnimationFrame was a godsend when it came to getting smooth animations.

Have a play with it. It’s hard to miss. It’s not exactly a subtle easter egg.

The content of the site remains much the same. While I was disatisfied with the original visual design of the site, I’m still pretty chuffed with the copy.

One small change I made was to give the code of conduct its own page (and expand on it a bit). Previously it was included with terms and conditions but there was a good chance that it could’ve been overlooked there.

Anyway, I hope you like the new site. I think Mikey did a terrific job with the design and it was a lot of fun to put together …especially the silly wanky bit. The only slight disadvantage is that the page weight comes in slightly larger than the previous design. But I’ll keep optimising to see if I can shave off some bytes here and there.

Oh, and you might notice one significant change on the home page. In addition to the speakers that are currently listed, there’s an addendum that reads “…and more”. That’s because the line-up for this year’s dConstruct, awesome as it is, is not yet complete. It’s going to get even better.

If you don’t have your ticket to this year’s dConstruct yet, what are you waiting for?

See you on September 5th.

Brad has done a great job in documenting navigation patterns for responsive designs. More recently I came across Erick Arbé’s similar collection of patterns for responsive navigation. And, of course, at the Responsive Day Out, David gave a presentation on the subject.

As I mentioned in the chat after David’s talk, choosing a pattern doesn’t need to be an either/or decision. You can start with a simple solution and progressively enhance to a more complex navigation pattern.

Take the footer-anchor pattern, for example. I really, really like this pattern. It doesn’t require any JavaScript whatsoever; just a simple hyperlink from the top of the page that links to the fragment identifier of the navigation at the bottom of the page. It works on just about every device.

But you don’t have to stop there. Now that you’ve got a simple solution that works everywhere, you can enhance it for more capable browsers.

Take a look at this example that applies the off-canvas pattern for browsers capable of handling the JavaScript and CSS required.

You can see the two patterns in action by looking at the source in JS Bin. If you toggle the “Auto-run JS” checkbox, you can see both behaviours. Without JavaScript you get the footer-anchor pattern. With JavaScript (and a capable browser) you get the off-canvas pattern.

I haven’t applied any media queries in this instance, but it would be pretty straightforward to apply absolute positioning or the display: table hack to display the navigation by default at wider screen sizes. I’ll leave that as an exercise for the reader (bonus points: apply the off-canvas from the right of the viewport rather than the left).

Feel free to peruse the somewhat simplistic code. I’m doing a bit of feature detection—or cutting the mustard—to test for querySelector and addEventListener. If a browser passes the test, a class is applied to the document root and some JavaScript is executed on page load to toggle the off-canvas behaviour.

On a recent project, I found myself implementing a number of different navigation patterns: off-canvas, overlay, and progressive disclosure. But each one began as an instance of the simple footer-anchor pattern.

Progressive enhancement, baby. Still not dead, still important.

I like sparklines a lot. Tufte describes a sparkline as:

…a small intense, simple, word-sized graphic with typographic resolution.

Four years ago, I added sparklines to Huffduffer using Google’s chart API. That API comes in two flavours: a JavaScript API for client-side creation of graphs, and image charts for server-side rendering of charts as PNGs.

The image API is really useful: there’s no reliance on JavaScript, it works in every browser capable of displaying images, and it’s really flexible and customisable. Therefore it is, of course, being deprecated.

The death warrant for Google image charts sets the execution date for 2015. Time to start looking for an alternative.

I couldn’t find a direct equivalent to the functionality that Google provides i.e. generating the images dynamically on the server. There are, however, plenty of client-side alternatives, many of them using canvas.

Most of the implementations I found were a little heavy-handed for my taste: they either required jQuery or Processing or both. I just wanted a quick little script for generating sparklines from a dataset of numbers. So I wrote my own.

I’ve put my code up on Github as Canvas Sparkline.

Here’s the JavaScript. You create a canvas element with the dimensions you want for the sparkline, then pass the ID of that element (along with your dataset) into the sparkline function:

sparkline ('canvasID', [12, 18, 13, 12, 11, 15, 17, 20, 15, 12, 8, 7, 9, 11], true);

(that final Boolean value at the end just indicates whether you want a red dot at the end of the sparkline).

The script takes care of normalising the values, so it doesn’t matter how many numbers are in the dataset or whether the range of the numbers is in the tens, hundreds, thousands, or hundreds of thousands.

There’s plenty of room for improvement:

• The colour of the sparkline is hardcoded (50% transparent black) but it could be passed in as a value.
• All the values should probably be passed in as an array of options rather than individual parameters.

Feel free to fork, adapt, and improve.

The sparklines are working quite nicely, but I can’t help but feel that this isn’t the right tool for the job. Ideally, I’d like to keep using a server-side solution like Google’s image charts. But if I am going to use a client-side solution, I’m not sure that canvas is the right element. This should really be SVG: canvas is great for dynamic images and animations that need to update quite quickly, but sparklines are generally pretty static. If anyone fancies making a lightweight SVG solution for sparklines, that would be lovely.

In the meantime, you can see Canvas Sparkline in action on the member profiles at The Session, like here, here, here, or here.

Update: Ask and thou shalt receive. Check out this fantastic lightweight SVG solution from Stuart—bloody brilliant!