How much can you actually learn in two days of #RenderConf?
The short answer is: a lot. But there’s so much more to say about an event full of talented people. Buckle up!
It’s been a full week since this year’s Render Conf ended but the rush hasn’t subsided. Not even a little bit.
Let me just start by saying those two late-March days spent in Oxford held within them one of the best conferences I’ve ever attended. In terms of content and its relevancy to what a designer or front-end developer does, you couldn’t ask for more. Meet me below this picture and I’ll explain why.
To keep things short (and interesting) I’ve written about my six favourite talks, three from each day, to give you a true sense of what it was like to be present in such an amazing atmosphere. Here’s what I’m going to cover:
- Jeremy Keith — Evaluating technology
- Ben Ilegbodu — Isomorphic React sans Node??
- Seb Lee — Hack to the future
- Mina Markham — Styling Hillary
- Rachel Andrew — Starting Using CSS Grid Layouts Today
- Sally Jenkinson — Websites are a Symptom, Not the Cause
Okay, let’s get started!
Jeremy Keith — Evaluating technology
I think that it’s an absolute must for any conference to start with a great speaker like Jeremy because it really helps set the tone of the entire conference. Which in this case meant beginning with a quick, “how did we get here?” recap of technology that started with greats like Grace Hopper or Benjamin Franklin, and traced its evolution as a series of advancements built on top of pervious advances.
Backwards compatibility makes adoption easier/faster
As the relation between humans and the hardware (from tools to devices) has changed with the introduction of the software, it’s important that innovators make the effort to keep backwards compatibility in what they do so the adoption of that specific technology is easier, and faster.
Some good examples are Tim Berners-Lee’s creation of HTML based in SGML, which was the markup language used at the time, so the transition to WWW made sense and was natural to most people. More recently we’ve seen this with SCSS where all you need to do is change the .css file extension to .scss and you’ll automatically have a valid file that you can use to start adding the extra features that SCSS provides.
Even something as simple as the right choice of words can have a huge impact in the future of a technology.
Like the use of the term Progressive Web Apps. People that don’t actually have an app could be instantly put off by that term, or just assume it doesn’t apply to them, since they’re mainly focused on their website.
That struck me as a significant takeaway and definitely something that we all need to be aware as we develop new things. Reducing the friction of adopting new technologies might actually be the single most important aspect that governs what tech will “survive” in the future.
How well does it fail?
We’re often concerned about how well things work, but Jeremy put forth an interesting counter-line of inquiry: how well do things fail?
Or in other words, through failure what flaws in compatibility with existing technologies are exposed? And how do those revelations help us build something that integrates those insights born of past failures?
Take Service Workers (SW) for example. If you look at the Can I Use compatibility chart it doesn’t look that good, with just over 60% of partial support by current browsers. But they actually fail great! You can just use SW as an enhancement to your website right now without worrying about support. As browser vendors start adding support it will improve the user’s experience without having to change anything.
Not everything works in the same way though. We still need to be careful with things like Web Components because whether or not they are backwards compatible really depends on the implementation. Jeremy has put together a much more detailed post about this subject which you should definitely give a read if you’re interested.
Principles, assumptions and biases
Jeremy has been gathering a great collection of design principles on his website throughout the years and one of his favourites is the Priority of Constituencies, which basically says that the user’s needs should come before anyone else’s (which include authors, developers, etc).
However, when we look at most of the tools around us, they often ship with implicit principles and assumptions, leaving a lot of room for interpretation. That’s why for every group of people that love a new technology, there’s a group that hate it remorselessly. Like avant guard art, maybe. The polarization of opinion can’t be whittled down to any one group being “right or wrong”; it’s linked back to their philosophies.
Even the single fact of having a default configuration reflects assumptions and biases from the designers and developers that worked on it. It’s really hard (perhaps impossible?) to make completely agnostic software.
What’s concerning about this is that those default settings can actually become constraints to future innovation. When you consider historical examples like Bell thinking his telephone would be used to listen to concerts or Edison thinking the function of his gramophone was to record conversations (quite a turn of events right?), we start to understand how these constraints can affect the future use of a technology, and how careful we need to be when setting what we think are good defaults.
The third revolution
This all leads into the last segment of the talk, the rising of the technological singularity. According to Jeremy, humanity lived through three revolutions back-to-back-to-back: agricultural, industrial, technological. We’re still not through that third one.
The great thing about these revolutions is that they don’t aim to erase the past and replace it with an unknown, they take what’s there and actually improve on it. Even in agriculture, arguably one of the longest running human activities, there are still evident traces of the past even in modern practice.
Ben Ilegbodu — Isomorphic React sans Node??
One of my favourite talks of the day was by Ben from Eventbrite, who talked about how to render React components on the server running a Django application. This really resonated with me as it’s basically the same stack we currently have for the marketing website at EDITED.
The main reasons for doing server-side rendering of React components are SEO and Open Graph (social share). Some people might argue that it also improves performance, but nowadays there are many solutions with code-splitting and prefetching that can actually be better suited.
In the same note, most modern search engines will process a pure JS website so SEO isn’t really affected. Although in some situations it’s still useful to have some specific tags rendered server-side to avoid any issues.
The biggest reason for server-side rendering is the Open Graph tags that are used by social networks like Facebook or Twitter to generate the previews when someone shares the URL of your website.
This is where we’ve also had some issues and where Eventbrite’s solution might come handy. I won’t go into much detail, but basically they currently have an independent stateless NodeJS server that uniquely functions as a way of getting a request for a specific component and returning the rendered string to be injected into the Django template.
It’s indeed a very clever solution and you can also implement a similar solution with python-react and react-render libraries. Definitely something we’ll probably need to test in our current setup!
For detailed coding example please have a look at the presentation slides.
Seb Lee-Delisle — Hack to the future
Asteroids and lasers, what else do I need to say? Seb brought a snippet of his amazing projects to Render, and it was nothing short of spectacular.
Seb started by showing some of his previous work, which you should definitely check-out, before addressing the elephant in the room: the actual laser he had sitting on the stage with him. Using that laser we played a very new and interactive version of the arcade classic Asteroids as well as a laser-powered version of Flappy Bird, where the bird’s altitude was controlled entirely by crowd noise.
He finished his talk by showing us a recent project involving a hacked NES Zapper built to play (obviously) a laser version of Duck Hunt. So. much. fun.
Mina Markham — Styling Hillary
After two years spent working for Hillary Clinton’s campaign, Mina stepped into the spotlight for creating the famous Pantsuit UI pattern library.
This was a really interesting talk. Since we’re so used style guides or UI libraries applied to products or publications that don’t really change that much, it felt fresh and new to hear from someone who has applied one to an ultra fast-paced medium, like a presidential campaign.
It also helps highlighting the benefits of using a centralised source of design that can be used by any team working in the campaign.
This makes the message more consistent and creates an identity that people can relate to and actually recognise.
I won’t go into much detail about Pantsuit; Mina has already done an excellent write-up. But I do want to focus on a few key aspects of Mina’s presentation that we can also apply to our own work.
The first of them is the fact that Pantsuit was completely opt-in, meaning that each team would choose what to use and, more importantly, which version they would use. Every release was published in a Slack channel and each team decided if they’d use it based on the changelog. I really like this idea of opt-in styleguide because it facilitates the adoption of the guide by each team at their own pace and with their own objectives in mind.
Second is the importance of documentation in design. “A design system is only as good as its documentation,” is how she put it, and I totally agree. A good documentation is what makes the adoption easier and faster to everyone else and it’s definitely something that teams should have in mind right from the start. Luckily there are plenty of libraries that make this process much easier, in Hillary’s campaign they ended up using kss-node in combination with assembler and nunjucks. If you’re interested in a similar solution for React, my favourite is react-styleguidist.
The last thing I want to point is that by using their own product, they were able to spot some edge cases and it also helped keep things updated as they would remove or add new features depending on their usage. This is something that we can all apply to our own work and will lead to better products and more relevant features.
Rachel Andrew — Starting Using CSS Grid Layouts Today
I have to confess that I was a CSS Grid sceptic before Rachel’s talk. Today I’m not only a supporter, but also going to actively work to help others use the benefits of CSS grids for layouts (More on that soon at the edited.tech page.) Unsurprisingly, those two things are not unrelated.
You should definitely check the presentation slides for a more detailed explanation and links to interactive examples that you can play with and get to know the specificities of the CSS Grid syntax.
For me, the biggest selling point for starting to use CSS Grid today is that it can just work as an enhancement. This is very in line with what Jeremy Keith said initially about facilitating the early adoption of new technologies.
The fact that you can just use flexbox or the more traditional float grid as you normally do, but also start using CSS Grid layouts for specific sections of the page, or even as a better version of your current grid, means that we don’t need to wait for mass browser adoption (although it’s looking much better) to start using it right now.
The key thing is the combination with the new CSS Feature Query that allows us to just target browsers that support CSS Grid so we always have a safe way of using this new feature. Like this:
@supports (display: grid) {
.grid > div {
width: auto;
}
}Rachel has also an extensive list of fallbacks and overrides when using CSS Grid, so have a look if you’re planing to start adding grid layouts to your pages.
It’s definitely something that will take some time to master, but I’m now sure it will be the way of building layouts from now on. A good starting point is this blog post full of simple examples.
Sally Jenkinson — Websites are a Symptom, Not the Cause
What really got my attention in Sally’s talk was the positive message about empowering designers and developers to go back to work and make the world a better place.
In a world of constant challenge where bad things take a lot more of our attention than the good things, it’s up to all of us to use that attention to point in a more positive direction.
It’s important that we’re able to identify the issues in our work, a big failure can draw a lot of negative focus (remember the massive backlash when Obama’s healthcare.gov was released to the public?) so identifying the issues soon in the process is extremely important for any project, no matter what size it is.
On the same note, finding the root cause of the issues is probably more important than just pointing them out. Often what is considered a “tech problem” initially might actually be a communication issue and have a completely different solution for it. This is where techniques like “The 5 whys” and the “Fishbone diagram” come handy and help understand the root causes for a given problem.
This is where web thinking can be applied to improve other aspects of our lives. Sally gave the example of the time when she applied her experience in doing this kind of analysis on websites to improve the processes of a Formula 1 team. The principles that we apply every day in our work can actually benefit a much wider range of businesses and people, and that’s a really powerful tool that we shouldn’t be afraid of using.
Sally ends her talk by motivating everyone to go out and talk to people, talk to our bosses and start conversations around the topics that we care about. We all need to look around us and see what we can do to make the world a better place.
I couldn’t think of a better way to end this conference, this was truly a very inspiring couple of days and I’m sure I’m not alone. This was just a small overview of my favourite talks, but have a look at the rest of the slides and I’ll link to the videos once they’re available too.
Bernardo Raposo is a designer and developer from sunny Portugal. If you’d like to work with him on exciting new technologies, let us know using hello@edited.com or applying at https://edited.com/jobs/.
