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.