Schedule

The process of building a pattern library or any kind of modular design system requires a different approach to delivering a set of finished pages. Even when the final deliverable is a pattern library, we often still have to design pages for approval. When everyone is so used to working with pages, it can be difficult to adopt a new way of thinking—particularly for those who are not designers and developers.

This talk will look at how we can help everyone in the team adopt pattern thinking. This includes anyone with a decision to make—not just designers and developers. Everyone in the team can start building a shared vocabulary and attempt to make the challenge of naming things a little easier.

If you've read the Twitters or checked out a JavaScript conference lineup lately — or, goodness help you, if you've reviewed a batch of conference proposals — you might think JavaScript these days is all about React and Flux and Redux and immutably isomorphic Babel-ified ES6, with maybe some web audio, offline, SVG, and an npm script or twelve thrown in for good measure. (I mean, gulp talks are sooooo 2014, amirite?) There's so much to learn about JavaScript that there are whole Medium posts about how there's so much to learn about JavaScript, and whole conferences to remind you how much you don't know.

Here's the thing: maybe you're lucky enough to live in this magical world where everything you build is shiny and new, but there are an awful lot of people working on client-side apps that came into being back when yayQuery was a thing and Backbone wasn't. They're building software that serves hundreds of millions of actual users, software that makes actual money, software whose underlying architecture is such that there's rarely such a thing as a "small change," even as the demand for new features never subsides.

If you're one of these developers and you're starting to feel like modern JavaScript has left you behind, this talk is for you. I'll share the story of how I started a new job this year by paying a visit to JavaScript circa 2009, back when Ryan Dahl was getting ready to announce Node and Facebook was still four years away from being mocked for the apparent heresy of JSX. I'll explain how I modernized and best-practice-ified a project that didn't even have a package.json, smoothing the development process, eliminating common sources of bugs, paving the way for bigger improvements, and never once uttering the words "we oughta just start from scratch."

From native apps to closed platforms to messenger bots, there are many threats to the influence and long-term health of the web. But perhaps its not time to give up on the browser just yet: the web could be sufficiently flexible to find new roles and new opportunities in the technology landscape of today and the near future.

Did you know the inspiration for the computer came from a mechanical textile loom? Back in the day, producing textiles was a field which employed state of the art technology.

Making textiles is quite arithmetical just as computer programming is. From a textile loom to a desktop computer; the stitches in your garment and the letters on your screen are both the result of operations executed based on data input.

In this talk, we will look at computer programming from creator's perspective. You will be surprised how much doing craft projects can teach you about front-end development!

Origami aspires to create a unified style and experience for FT websites, and make web development at the FT faster.

This talk will be a walk through Origami, with its key parts described in contrast with other similar components systems and pattern libraries created elsewhere. An alternative talk title could be "Things Origami could learn from other design systems"

I'll look at the methodologies for deciding what gets to be a component, and compare this to more pattern-library type approaches (such as atomic-design). I'll look at how various teams have approached documentation and talk about why Origami does this badly and how we can improve it. I'll compare how Origami handles delivery of its components to browsers, and contrast it to how other places such as GDS and Lonely Planet have approached this.

By the end of the talk, the listener should understand a bit about how large companies like the FT deal with Front-End development at scale, and they will hopefully have some ideas about Front-End architectures to take back to their own worlds.

You've heard it before: "It works on my machine" and you know the punchline "so your problem isn't real". Sometimes a bug just won't appear on your system: computers are fickle beasts full of subtlety. Humans too, but more so: we have habits, preferences, biases, our background, opportunities vary wildly. And even the technology industry itself is a perfect example of legacy spaghetti code (without unit tests), and this makes it very hard to debug for a better future.

In this talk we will look at the many facets that affect our decision making and interactions in general, and work out how we can change for the better. Together, we will take a look at the effects that our software has on the daily lives of the thousands of people who are using it. We’ll examine how unconscious actions affect our work, and what part emotions and power dynamics play in it. You’ll learn what you can do as an individual to support change into a positive direction, and how you can help debug this system and make a difference in the tech industry – and why being better at bug handling means being better at working with humans. You’ll leave knowing about practical things you can do in your daily life to make tech a better, more inclusive and diverse environment that is a better place for everyone – including you.