Four things from Front End North

I just got back from Front End North, a weirdly affordable (but still very good!) front-end conference.

It’s rare for me to get a chance to do something career-related in Sheffield when I’m so used to travelling back and forth to London, so with the time I saved, here’s some things I learned or found interesting.

There’s lots of ways to test

From Mike Smith’s talk

Front-end developers are often scared of them and so am I.

I know the theory of unit integration and end-to-end tests and the testing pyramid that defines how many of each you should do, but this orthodoxy tends to lend itself best to traditional software engineering projects. It doesn’t always transfer well to a front-end made up of react components, for example.

Snapshot and visual regression tests can be valuable additions to that testing pyramid in those situations, and it’s even possible to test the efficacy and sense of your tests themselves through mutation testing. 🤓

I’ll probably be integrating Paypal’s Automated Accessibity Testing Tool into the continuous integration pipeline of the design system I’m working on right now.

Having good intentions isn’t enough

From Florence Okoye’s talk

While I’m lucky enough to work for a place that takes holistic change seriously, transforming teams, organisations and processes rather than just focusing on digital tools, this isn’t true for the majority of our sector.

Often we reduce the idea of “user experience” down to a shell of what it once aspired to be, figuring out how we can maximise conversion rates without much thought given to the wider social context and issues our products influence and are influenced by.

Having good intentions isn’t enough. Society’s systems of oppression will always pollute our designs unless we actively fight them by becoming true advocates for all our users, not just the ones who are most like us.

Alexa is more expressive than we know

From Léonie Watson’s talk

Although Amazon tries their darndest to make Alexa sound human, her normal affect sounds pretty flat. However, we can use speech synthesis markup language (SSML) to make our conversations with her much more expressive.

It’s possible to:

  • affect her pronounciation
  • give different voices and accents
  • add different kinds of emphasis and stress different parts of speech

All with a surprisingly familiar HTML-esque syntax!

I also learned that we were making machines that spoke in 1939, which seems absurdly early.

This honestly feels so ahead of its time that it might be a glitch in the timeline.

The code editor is a design tool

From Laura Gonzalez’s talk

I’m in the fortunate position of having a job that’s perfectly poised between design and web development (though it has the unfortunate consequence of my job title having a slash in it).

These few roles aside, there’s often a disconnect between designers and developers akin to the one that once existed between developers and ops staff before the devops movement started.

That’s a shame, because Sketch, Figma, Zeppelin, XD and all the other design tools are all well and good, but at at the end of the day the only one that matters is the code editor. That’s where we make what the user sees. They’ll never see our perfect mockups or our design system.

Developers are smart enough to figure out CSS, we’re smart enough to be let into the design process.

DesDevOps maybe?

Strategic designer & technologist. Why use three short words when one long weird one will do?