Designing for a hostile environment
tl;dr: think about what you're building and who you're building it for
Browser is a very hostile environment to program against because lots of things are outside of our control, the network connection, the browser/runtime environment, screen size, etc...
What does it mean then when we say "a site doesn't work"? It means you can't complete a task, the reason why you came to the website in the first place. There are multiple reasons why that could be:
- accessibility - creating websites which can be used with Assistive Technologies is hard (https://gdstechnology.blog.gov.uk/2014/08/14/improving-accessibility-on-gov-uk-search/)
- jargon, language and tone - your website can use terminology and language that is foreign to your visitors. Think about your target audience, whether English is their native tongue, the context in which they might be visiting your website (headache, dead relative, in the car). Avoid using exclusive (gendered) words.
- page size and load time - think about time to text, most of the time people come to your page to find out some information. They don't really care about fancy animations. Also, roaming costs!
- everyone has 4G - that might be unless you happen to live in an area where it doesn't work as advertised, e.g. Peckham. Also, wifi isn't always reliable, think hotel wifi or wifi at the edge of it's range. And not everyone has the latest MacBook Pro, do you want to turn their PC into a washing machine on the spin cycle?
- available memory and processing power might be insufficient which can be a problem on even the swankiest mobile phones if you happen to have multiple tabs open
- your CDN has incorrect content, is misconfigured / down etc
- the latest JS features are not supported
- according to GDS stats: 1.1% experience their site without JS out of which 0.9% had JS enabled but did not receive it for some reason or another
What can we learn from game consoles?
tl;dr: universal design is not about designing for one thing, that's software design.
When you design something with consideration for your edge cases it becomes more usable by everyone. Consider the hisotry of the OXO Easy Grip peeler as an example (http://www3.eng.cam.ac.uk/inclusivedesign/index.php?section=introduction&page=ex-oxo) and their universal design principles (http://www.oxouk.com/UniversalDesign.aspx).
Why is this important? Almost every device with a screen has a browser built in today, everything from exercise machines to water taps. And yet we keep thinking about the screen sizes in terms of very concrete silos: mobile, tablet, desktop. But what do these sizes mean? Is a touch enabled table a tablet? A desktop?
What about a game console? 14% of people in the UK use their game console to browse the internet, with the highest percentage of people in the age range 16-44.
We can't reliably tell if someone is using a console! XBox 360 (which uses IE9) has two user agents, mobile and desktop. That's because often it's easier to use the mobile version of the website on a large screen 10 feet away. Also, user agents lie!
Mobiles, tablets, consoles are just a fraction of different browsers out there today and in the near future. It will only get worse. Virtual reality is just around a corner (with VR CSS) which is extremely exciting because there are no legacy design or UX conventions.
To make things worse, there are hundreds of different interaction methods: touch, stylus, gamepads, voice...
There are lots of considerations when designing for TVs, for instance performance is critical because memory is very limited. Also, just because we have a bigger screen and more space, it doesn't mean that we can just add more columns! Google has a good design guidelines for designing for screens 10 feet away which mentions using a mobile screen as a substitute for a large screen (same size at larger distance) and the fact that users expect sound cues when using a TV interface.
Factoid: 80% of people (6m in the UK) who use subtitles on their TV are not deaf hard of hearing.
Progressive Enhancement for Software Architects
tl;dr: The web is more than a sum of its protocols, it has an opinion how things should be done so we should just embrace the constraints rather than fight them. Constraints are good, they simplify your choices.
Developers tend to be reluctant to learn new technologies and tend to reinvent the technology they already know using the latest thing, e.g.
Server side rendering using Bicycle.js
Some sort of mix between Meteor, GraphQL, Relay and React. ¯_(ツ)_/¯ http://www.bicyclejs.org/
Taking the Guardian offline
Oliver Joseph Ash
This blog post is better than my notes: https://www.theguardian.com/info/developer-blog/2015/nov/04/building-an-offline-page-for-theguardiancom
tl;dr: Let's be pragmatic about Progressive Enhancement and use tiered architecture. Basically restatement of "cutting the mustard" if you've read it (http://responsivenews.co.uk/post/18948466399/cutting-the-mustard).
Websites are complicated because there are multiple implicit user journeys (type of device, input methods, capabilities, etc). Progressive enhancement is all well and good but it makes things even worse and more difficult to test as the number of combinations increases exponentially. That's difficult to test. In order to simplify, let's split the features on a website into couple of tiers, e.g. low, mid and high end. Low end tier would contain features available to everyone whereas the high end would have all enhancements available. Depending on the capabilities of the device, the application would either receive no enhancements, some enhancements or all the bells and whistles. If one of the criteria of a given tier is not satisfied, rather than degrading one feature, all the features in that tier are switched off.
Stephen Waller and Phil Hawksworth
Good discussion between a designer who wants everything to be beautiful and "designy", and a developer who advocates using best practices. Also, why all pages look the same these days. Sadly, no notes :(
tl;dr: Make things as simple as possible, but not simpler.
Everyone makes mistakes, even highly skilled people. That's why both the airline industry and doctors have "preflight" checklists which help them prevent making stupid mistakes.
People have the tendency to be seduced by the complexity and forget the simple things. We were bored with building simple websites so we invented SPA to make our lives more interesting and make ourselves more "marketable". And yet, time and time again we see that simple solutions tend to be/perform/convert better than their complex counter parts. JustEat found that with their checkout process after they replaced a monolithic SPA with 4 pages, stripped to absolute basics. Their orders increased by 2 million that year.
What can we do with the basics? Quite a lot. There's text colour, font, size, length. We always knew that content is important but we've only started taking that advice seriously when mobile became a thing. So we started doing mobile first, small screen first, essential first and then essential only. At which point, it doesn't matter if your app is an SPA or not.
Progressing Our Layouts
tl;dr: CSS is extremely robust. If you use the latest features and they are not available, nothing happens. Literally. Learn CSS, stop using Bootstrap.
Slides are better than my notes: https://speakerdeck.com/jensimmons/progressing-our-layouts
Living on the Edge: Extreme computing and the Age of inclusive design
Talk about accessibility and what it's like to use websites which are not accessible. No notes :(
Copy Basics for Tech-Focused Individuals
tl;dr: There's more to copy than meets the eye.
- What is copy writing?
All text is copy. It's meant to make you do something e.g. "download an app", "share on Twitter", "choose username", etc. Obviously there are different copy types:
- long - blog articles, email, content on the website
- short - Social media, ads, UI microcopy
- "jargon copy" - legal and technical copy which are completely different and usually not written by copywriters
- What do copywriters do?
- research the domain and brand to understand it better
- write and proof read
- Guiding principles
- decide who your target audience / segment of the audience is
- choose the right tone of voice matching the brand
- be clear, concise and consistent. Don't be afraid to take things out
- Copy writing process
- front load the information - tell them what the purpose is, who this is for, medium it's going to appear in, how you going to measure the success, background information / similar examples
- draft and review - usually multiple people review each copy. It's best if one person is responsible for one aspect of the text (technical accuracy, general proofreading, final signoff). Otherwise, you end up with multiple "cooks"
Learn From the Past, Enhance for the Future
This blog post is better than my notes :) https://www.aaron-gustafson.com/notebook/learn-from-the-past-enhance-for-the-future/