Fronteers 2014 - part 2

Oct. 23, 2014, 8:41 p.m. in Web Design


Hello! Welcome to the second part of my blog posts about Fronteers 2014 - a front-end web development conference held in Amsterdam at the start of October.

My last entry focused on some of the user experience and user consideration talks that really resonated with me. For this entry I want to talk about some of the other cool stuff I learnt at Fronteers, with an emphasis on web animation, and I want to begin with one very awesome lady!

me and rachel nabors
Rachel and I in Rotterdam! I'm the slightly shorter nerd. XD

If there's anyone in the web development world I've always been a bit of a fangirl of, it's Rachel Nabors, an awesome lady who started her career as a comic book artist, before becoming a front-end web developer. I find it's somewhat more common these days to find front-end web developers who come from a programming led background, or are heavily interested in Javascript as their main "thing", but less common to find those of us who maybe come from more visual/designery/arty backgrounds. Even though there is so much new and awesome Javascript stuff (uhh, "stuff" is a technical term :P), MVC frameworks and whatnot these days, I still personally believe that there's a lot of room in front-end development for the more visual-led of us.

As doodling is one of my favourite hobbies, I love when I can find ways to incorporate art or cute character designs into web development. With my affinity to visual media on the web, I've always been a fan of the idea of CSS animation - not least because I love how lightweight, maintainable, and device-agnostic it is, but also because of how it's a lovely way to combine art and code, and a new way to provide more visual goodness to our websites and applications.

Anyway, I was super happy that as well as getting the chance to meet and hang out with Rachel during my Amsterdam trip, I also got to attend her CSS animation workshop, and hear her speak at Fronteers. As I say - I have always been a fan of CSS animation, and this little codepen - Mr. CSS lion - is so far one of the few things I've played around with that combines my drawing style with CSS (worth mentioning because Rachel's work heavily inspired this!).

That was a while ago, and there haven't been too many animation challenges for me at work recently, even though we do get the opportunity when working on interactive ipad edetails to use animation to liven up an otherwise static presentation. Rachel's talk reignited my hope that some more of those challenges come along in the future! These are a couple of my favourite things that she talked about to help us with CSS animation:

  • Steps! - Even though I've done CSS animation quite a bit, I didn't know about these for some reason. Steps are a cool way to split up stages of an animation without having to add loads of extra points to your keyframes. One super cool use for this, is if you have a sprite of various images that may make up an animation (eg a walking animation or maybe a logo animation or whatnot), you can use steps to tell the animation how many states to have without manually setting all of those states. Say you have 5 sprite images in a file, you could set the starting background position, and the end background position and tell the animation via steps, how many in between states there are. Rachel demonstrates this better than I can explain here. But anyway, I wasn't aware of this previously and would have previously added more percentage values for different states, so this seems like a really handy way to handle certain animations, especially if you want to animate sprites.
  • animationend - and other handy javascript events that get fired through CSS animation (there is also animationstart and animationiteration). These events give us a nice way to control and also link our CSS animations to each other, for example firing one when another has finished. We could also trigger the animationstart event when hovering over a logo for example. One of my main issues with CSS animation in the past has been controlling a large number of them and keeping them maintainable and not too dependant on every other part of the animation. I've often tended to string delays together (for example the first part starts at 0.5s, the second animation starts at 1.5s), but this means that making changes somewhere in the middle of the chain can really confuse things. I like the idea of combining these animation events, along with some simple jQuery, perhaps manipulating classes too, to make animations more modular and able to be amended at different points more easily.

Anyway, my attempt to explain the coolness of CSS animation in text may not make a huge amount of sense, but make sure to check out some of Rachel's codepens for more examples - this walking cat one combines steps and animation events and is a simple but cool example of some of the possibilities we have with CSS animation now.

Is this useful for my client?

Obviously animating drawings is cool and fun, but does CSS animation have a place in our day-to-day jobs and client work in various industries? I think it absolutely does, and Rachel actually drew a lot of attention to the benefits of CSS animation when it comes to improving how users interact with our interfaces. I liked this quote below that she included, alongside an example of a typical dropdown menu, and how the shift in states, whilst obvious to some of us (the younger or more tech-savvy), it can be harder for other users to make that connection, and small animations and transitions can really help with that.

“By offloading interpretation of changes to the perceptual system, animation allows the user to continue thinking about the task domain, with no need to shift contexts to the interface domain. By eliminating sudden visual changes, animation lessens the chance that the user is surprised.” E. Hudson and John T. Stasko (1993)

I know that Rachel sees the web as much more than static documents - as a canvas with so many possibilities! I think CSS animation and transitions can be used subtly to bring static things to life, or can be used to guide our users around certain bits of our interface and help them see what's going on. And even if some of our users are on old versions of Internet Explorer - we can make these animations more of an enhancement for the users with modern browsers, and degrade gracefully for others.

Rachel rightfully pointed out that CSS animation and transitions shouldn't be something we attempt to tack on at the end of a project, as an afterthought, but rather that we should think about how we design our sites with these possibilities in mind. I definitely would like to see interaction design making more use of CSS animation because I think it gives us some great new options for interface design.

The Google Material Design documentation has some great responsive interaction examples of how animation can help our users.

SMIL-e... more animation! :)

Going nicely hand in hand with Rachel's workshop and talk, Sara Soueidan gave a wonderfully information-packed talk on animating SVGs using CSS and SMIL (Synchronized Multimedia Integration Language if you want to know!). SVG animation gives us a few extra nice options for more advanced animation with SVG shapes, for example if we want to animate more advanced graphics, have them scalable and still be able to use CSS on them. One thing that's cool alone is that:

"Basically, any transformation or transition animation that can be applied to an HTML element can also be applied to an SVG element." Sara Soueidan

But not only that, SVG animation gives us even more options than CSS animation in some cases! Using the <animate> element within an SVG, we can tell it things like how to animate, and even how to start animating (e.g. "begin = click"). I especially like that you can do things like "begin=click + 1s" to start an animation a certain time after an element is clicked.

Another really nice thing is that you can chain animations by doing things like setting one element to start animating a certain amount of time after another has started (or stopped). SMIL has many more properties that let us do some really cool animation functions without much code, and I think the possibilities for these on scalable graphics is awesome. Animations along SVG paths are another cool thing. There are so many cool things to know about these, and Sara is an incredible font of knowledge, which her talk showed! I recommend reading her guide on CSS Tricks to learn more, and there are some great examples in her fronteers slides also.

As for support, SMIL is widely supported - well... with the exception of all Internet Explorer browsers. :P But since we could use modernizr to check for SMIL support and provide fallbacks, or have this as an enhancement for all the other browsers that DO support it, it still seems like a pretty good time to think about trying some of this stuff out!

Infrastructure FTW

I realise I've written quite a lot about animation alone.. you can probably tell that it's one of my favourite areas of front-end development! I'm going to more briefly mention the other talks purely because this entry could go on forever.. (you can have a cookie if you're still reading :)

Daniel Espeset talked about the role of frontend infrastructure at Etsy, with a focus on the importance of having continuous deployment and letting "anybody touch anything", which I liked. At Incuna we generally have front-end as well as back-end developers being able to deploy sites to staging after they've worked on them and it's super useful I think to have all developers being able to do that. Daniel talked about tools like "Ranger" and "Builda" that Etsy built themselves for tracking deploys and code, and also discussed how the team had moved to using Scss for more maintainable CSS. At Incuna we use Sass and I would never go back now - the usefulness of CSS preprocessors such as these is amazing. Read Daniel's slides.

Nicolas Gallagher from Twitter gave a somewhat similar talk, about Twitter UI infrastructure. I liked that his talk focused on making the infrastructure as reusable as possible, allowing people to "spend time on creative things" instead of having to spend a lot of time on infrastructure everytime they work on a new project. This is something we've worked on a lot in the past couple of years at Incuna (and I have to give Perry Roper a mention for initiating a lot of those changes such as incuna-sass). We factored all of the CSS that we kept reusing in projects into our own Sass component library so that we can use it on projects every time and not spend time rewriting things. It's super useful!

Some of the other advice I found useful from Nicolas:

  • Have a shared language between design and engineering teams.
    I think this is something we can get better at!
  • Design for adaptability, not perfection.
    Use components to help people work on different parts of a larger app without effecting others.
  • Consistency is the best option.
    Make it so that anybody in a team can pick something up and work on it.
  • Make skilful use of what is at hand.
  • Documentation and ownership over institutional knowledge.
  • Hide complexity of infrastructure from developers
    and allow the infrastructure code to be changeable without effecting the dev's existing work. (This is another thing we're doing quite successfully with an edetail library that we use as a base for interactive ipad edetails)
  • Create habits among engineering teams

A round up of the rest

Dave Olsen gave a great talk on optimising web performance. He pointed out some of the perils of responsive web design that only considers layout - where we end up downloading too many elements on mobile by over-using "display: none". He recommended some useful tools, such as:

and of course if you're not already using chrome dev tools, the network and timeline are always super useful!

I also like that Dave Olsen discussed how you would get performance measuring into a client's budget or into your project workflow. He recommended having a "performance budget" and aiming to beat a baseline - for example, decide that your page speed score will be 25 percent lower than your nearest competitor. I think this was an interesting way to try and justify why it's worth spending time on webpage performance and also have something to aim for rather than a hard to measure goal like "make it perform better".

Fronteers featured some cool mini sessions on gaming in the browser. Being a massive videogame fan I always think I should try and make a game and never get round to it. Phaser sounds like a very interesting framework for HTML5 games.. if i can ever get round to stop playing them to make one! ;)

Forgive me if I've not mentioned all of the Fronteers speakers in my blogs, I've focused on those that are most relatable to my personal interests and role in front-end development. There were some talks on WebRTC, but they were a bit more technical and went over my head a little. XD (or was it that big lunch...? ^_^) I'm sure they were very useful for some other attendees! Anyway, here are all the slides from the conference if you would like to catch up more on anything I've mentioned or some of the other talks!

Collection of Fronteers slides

All in all, Fronteers was a wonderful conference to attend (not least because I love the city of Amsterdam!) - it reignited my enthusiasm for CSS animation (and grew it for SVGs!), it reminded me that Incuna are on a pretty good track with our increasingly modular and consistent codebase, and it also made me see the areas we can improve on when it comes to user needs and really merging our design and front-end practises more which is something I really hope we might be able to do more in future.

A more fluid, dynamic web

I've written before about how closely I see the link between web design and development, and how the canvas should be the browser, and I think it's true more than ever these days. With the different devices we are working with, and the animation and interface possibilities - the pure fluidity and changeability of the web, design isn't the static thing it may have once been. Some of us still have fairly waterfall processes in our companies, but I really hope we can all try and combine our design and front-end development processes much more closely because I really think that we are working towards the same important goal - what the user sees, uses, and interacts with, and making that a more useful, easy, and pleasurable experience.

Thanks for reading! :)