Front-Trends 2017 highlights

Things I was excited about during this conference

Published on

I love being at conferences. Since I’m writing articles, I want to share more and more knowledge. So here are my highlights of Front-Trends 2017.

Covering every presentation is difficult. I picked some talks which had some good learnings I want to share. Still, there was too much information to cover, so I chose the talks I was happily surprised with.

Field-tested interfaces for the next billion

The next billion is referred as the big wave of people who will be connected. Connected in this context means having access to and using internet. Some figures were shown about connected people.

Important take away is “Empathy shouldn’t replace research”. Later on, Ally concluded with “Be curious, do have empathy. But do the research”.

Lessons learned about users:

Lessons learned in UX:

The first meaningful paint

Our metrics for performance have changed over time. Currently, we need to focus on SpeedIndex, First meaningful paint, Time to interactivity and custom metrics. Performance metrics need to be specific, user centred, according to context.

Time to first meaningful paint isn’t exposed in a JS API, but Lighthouse helps us to retrieve this metric.

Patrick Hamann showed us a real life case (we need more of those in talks) of the Financial Times website. He worked before on The parts were as following:

  1. Critical CSS
  2. Preload
  3. Server push
  4. Server push async

Critical CSS

We have created a single point of failure (SPOF) with CSS. Inlining the critical CSS is a good solution.


What you need to ask yourself is “what are my critical resources?”. Luckily, Lighthouse will answer that question for you.

Server push and async

When HTTP2 is supported. Server push needs some configuration, as it can have a negative effect. Slide of this presentation, showing the results after the four steps taken.

A graph of the first meaningful paint of a webpage, after implementing the four aforementioned measures
Slide of this presentation, showing the results after the four steps taken.

Patrick also told us to look at the PRPL pattern, by Google.

Motion in design systems

This talk started with the statement “our deliverables are failing us”. At Mirabeau we’re also struggling from time to time with designing animations. If a designer delivers two static designs, it leaves room for interpretation.

There are several types of deliverables that can help us:

  1. Storyboards & sketches. This quick technique solves next questions:
  1. Motion comps (also called mockups). They can be made with several tools. Solves other questions:
  1. Interactive prototypes. Can be made in tools like Principle or Codepen. In order to discuss details, you can slow down animation speed in your DevTools.
  2. Define & document. This saves time and effort later on.

But how do the animations comply with your brand? Usually brand guidelines have a defined tone of voice. This can help you determine how you use easing and speed/timing.

Want more? View the slides of this presentation. And by the way, I’ve bought Val Head’s book Designing Interface Animation to learn more about this subject.

Changing the layout game

This talk started with a recap of techniques used for layout. From tables to flexbox and all the hacks we used to achieve certain layouts. Some of them are good, others are bad. Usually the ‘good’ hacks will eventually return as a standard. For example the fluid image hack became object-fit in the standards.

“Hacking or experimenting, we create our own path” Chris Wright

A while ago, Chris counted the media queries of roughly 50 websites. On average these websites used 264 media queries. It seems outrageous, but it’s a sign there’s a need for other techniques. Media queries are mainly limited to viewports and media types. But we as designers and developers think of design systems, modularity and context.

The constraint for components is available space. I’ve seen quite some articles and talks about element/container queries. As Chris points out, the problem with that concept is infinite loops and the way the CSS parsing works.

A screenshot of a component in two sizes
Slide from “Changing the layout game”, showing an example of component based imagery

There’s another thing: what about component based imagery? You don’t want to serve images that are too big to the user. The picture element only cares about viewport. But there’s a hack for that. SVG has its own document context. By using the tag <foreignObject> we can use <picture> in SVG and serve the right image. Awesome!

A lot of examples of grid were quickly shown. Chris wrote about css grid layout before, it’s worth a read.

Brilliant hacks are creative use of features. Chris encourages us developers to experiment and share our ideas. This way we can move forward with standards.

Microservices - The FAAS and the Furious

Static sites are limited. But the ceiling is far higher than you think. With these sentences Phil kicked off his presentation and told us about doing cool stuff with (boring) static websites. For me this talk was quite interesting, because the very site you read this article on is also a generated static site.

The current stack of publishing and maintaining a site is quite complex. Right now, ‘everything’ happens in the cloud. A website needs to have routing, load balancing, etcetera.

We don’t need that complexity. If we cut out the backend code and code needed by servers. What we’re actually doing here is working with the JAM stack (JavaScript, APIs, and Markup). Phil referred to a good presentation about the mentioned JAM stack.

“Complexity can be a barrier. Simplicity can be an enabler.” Phil Hawksworth

Given a simple use case (displaying a Twitter feed) we looked into our options on how to place this:

  1. Client side Twitter widget. This means dependency on a 3rd party JavaScript, which can mean unnecessary code and maintenance.
  2. Client side self made script. This is also depends on JavaScript and external requests (for every page view)
  3. Backend side content. But how do we fix that with a static website?

With services like IFTTT we can put things into motion. If Phil tweets a webhook goes off. Then, pages get generated and deployed online. This way we won’t need JavaScript on the client side. By using services that’ll execute just one simple script, you’ll make it yourself easier. We don’t need all that backend knowledge. Also, less maintenance and more automation. Sounds awesome, right?

We can do all kinds of things on different services. More tooling is coming, but for now we can look into the following: