I was fortunate enough to get to attend and speak at Web Directions this week, so thought I’d put together a summary of my key learnings for those who weren’t there.
Learning #1: don’t use Google Slides for high stakes presentations
I had a pretty significant technical hiccup at the start of my talk: despite having no issues during the run-through two hours before I spoke, when I got up at 2:50pm, half my slides decided not to load and instead showed “Content could not be displayed”. I had backups ready but discovered that both the PDF and .pptx versions were corrupted and clean forgot to use the Google Slides offline backup:(
Fortunately I knew my material well enough that I could power through anyway (and quite a few people came up to me afterwards and said “That was deliberate wasn’t it?”) but it’s not really the kind of stress I need in the moments before giving a high stakes presentation! It wasn’t entirely Google Slides fault: there was an issue with the WiFi that caused the proximate issue. Nonetheless, it was frustrating that the PDF backups got corrupted and this is the second time I’ve had similar issues with Google Slides (in the warmup event, my browser froze immediately after I clicked ‘Start Presentation’). Overall, it just doesn’t seem worth it.
I’m gonna go Keynote from now on.
*If you want to see my slides in their uncorrupted glory, go here.
Learning #2: break out of silos
Cap Watkins from BuzzFeed gave the keynote speech and dropped many a gem of wisdom as well as some awesome (and sometimes disturbing) animated GIFs. Key takeaway for me was avoiding “it’s not my job-ism”. Cap spoke about how he changed the culture at BuzzFeed away from a “designers do the PSDs and throw them over the wall” to “designers code and developers play with photoshop”. I really like this idea. Cross skilling helps everyone improve and gives the team more resilience + lower lottery factor (key designer wins the lottery and leaves the job, destroying company cos they can’t find a replacement).
Learning #3: deploy often and cautiously
Something I heard from both Cap and Tom Loosemore from Gov.uk was the importance of continuous deployment. Whilst at Etsy, Cap’s team would deploy up to 40 times per day. Tom’s team routinely deploys 10 times per day (and this is in government!). I was really impressed and intrigued by this because Learnosity generally only deploys once every 3 weeks.
Cap was gracious enough to come over for a chat at the speaker dinner and expanded a bit more upon this philosophy of continuous deployment. His argument is that the more frequent deployment is, the less likely any individual deployment is to break the product. As well as this, deploying often means the team knows how to quickly fix things if something does break whereas if deployments are infrequent, it’s easy to get a bit rusty.
Nonetheless, super frequent deployment feels a bit risky. Surely QA won’t have a chance to check everything thoroughly if new releases are getting fired off tens of times per day. Some solutions to this I heard were:
- using feature toggles so you can turn off features if they break without needing to redeploy (and we’re not just talking entire new features: a feature toggle could apply to a bug fix or a small enhancement to an existing feature)
- lathering the product with automated tests including perceptual diff tests so that your CI will pick up bugs before they go out into the wild
Learning #4: CSS Modules
Glen Maddern and Mark Dalgleish (both from Melbourne) gave us a cool intro into the world of CSS modules. My understanding of CSS modules is that it allows you to write web components with entirely isolated CSS so you avoid unwanted cascading and naming collisions. Chatting to some attendees afterwards, some people felt it was overcomplicating things and solving a problem that didn’t really exist, but I see a lot of value in this approach.
Rather than having to do crazy nesting like:
You could just do:
because someGenericClassNameThatWillProbablyBeUsedElsewhere will be automatically given a unique suffix/prefix by CSS modules. This would allow us to write highly semantic CSS because the CSS will be locally scoped by default instead of globally scoped.
Plus with CSS Modules, you can replace all your class names with Emojis like Glen did:D
I’m excited at the idea of using CSS Modules or Polymer (Google’s web component polypill) for new parts of the Learnosity APIs.
Learning #5 automated site speed testing
Maciej Ceglowski gave a hilarious and hard hitting keynote on the rising problem of web bloat. His argument is that no single web page should take up more space than a piece of classic Russian fiction like Crime and Punishment (2.3MB of text content). This is something for us at Learnosity to reflect on because as a 3rd party JS API provider, if we’re not careful, we can cause web bloat for our clients. The bar is substantially higher for us. We can probably only afford to take up 1/6th of Crime and Punishment because the host page is going to have images and other content as well as our scripts.
How can we ensure that we don’t exceed this limit? Kitt Hodsden has a few ideas. She gave a talk about using various grunt plugins to monitor load time as part of the build process. The end result is a private mirror of WebPageTest.org that allows you to check load times on the CI server and block any releases that breach your performance budget.
Learning #6: learn JS properly
- avoid super() calls like the plague
- don’t use classical inheritance unless you have a REALLY good reason to (otherwise you can end up with the gorilla-banana problem plus brittle class hierarchies that can cause domino effect bugs all down the inheritance chain)
- favour composition over inheritance
Talking to attendees afterwards, a lot of people found the talk over-opinionated but I didn’t hear anyone seriously argue with him.
I was personally curious about whether composition could also lead to brittle hierarchies. For example, what happens if Object A is composed by Object B and C and Object B is composed by Objects D and E? Is that not another case of a hierarchy which could cause flow through bugs down the chain? I spotted Eric after the talk and asked him about this. As it turns out, he’d already written an article answering this question. TL;DR: you’d be unlikely to have a whole bunch of child classes composing from the same parent because you’d probably create several variants of the parent to cater for different use cases. Makes sense to me. I guess good code review can prevent many of these issues but composition does seem less likely to cause issues than inheritance.
Learning #7: be patient
In Cap’s keynote, he mentioned the hypocrisy of change management in tech: we’re happy for incremental change with our products, but we often expect radical change from our teams and companies. This struck home for me because I’ve been trying to ram checklist driven development down my team’s throat and it hasn’t really been working. Cap suggests being patient and looking out for the little wins rather than being disappointed that people still aren’t ticking off the checklists with each ticket.
Learning #8: use pre-mortems
Julia Clavien gave a great talk on cognitive bias in software development. One of the antidotes she proposed was the pre-mortem, in which teams dream up everything that could possibly go wrong before a sprint starts. This thought process can help to make estimates more realistic and surface hidden dependencies. As a lover of apocalyptic fiction, I really like this idea and am going to float it with my team :)
Learning #9: get a distraction chair
I tuned in to a few of the talks from the design track as well. Denise Jacobs gave a terrific talk on unlocking creativity. According to Denise, one of the central problems that prevents creativity is distractions. Certainly rings true for me. She had a whole bunch of suggestions (e.g. use the pomodoro technique, use an app like Anti Social to block distracting websites, meditate, use powerful body language to restore energy and confidence) that I’d heard before (but still good to be reminded because I wasn’t necessarily practising them!) as well as one I hadn’t: the distraction chair.
The idea is that when you want to do something distract-y, you go and sit in another chair so that your work space doesn’t get polluted with cat videos and articles from The Onion. I’m definitely going to try this!
Learning #10: accessibility can be relatively easy to implement
One of my cognitive biases is to assume that everyone uses computers the same way as me, so it was good to be reminded that this is rubbish. Numerous speakers spoke about how we can’t assume that everyone has a lightning fast Macbook Pro with a fibre connection so we should design for limited or fully offline conditions. (Patrick Hamann’s talk was apparently amazing. Definitely going to grab the video for this.)
Isabel Brison also gave an excellent talk about improving keyboard accessibility. Lots for me to learn here but I am inspired by Isabel’s demonstration that accessibility can be relatively easy to implement (if you know what you’re doing).
I also picked up a handy demo of an automated accessibility test from Chris Giffard. Keen to give this a go.
Learning #11: flex-box fixes everything
Overall, I really enjoyed Web Directions. Was great to hang out with the other attendees and speakers, fun going on the rides at Luna Park and a big relief to have made it through my talk despite the technical difficulties.
Big thankyou to John, Rosemary, Bronte, Fiona and the rest of the WD team for doing such a stellar job!
*There are lots of talks I didn’t get to (definitely in favour of single track for 2016) so I might write part two after I watch the videos for the other talks.