Nat Buckley
Video: https://www.youtube.com/watch?v=WU4vDTxLIdE
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?
- JavaScript - it's just not robust, JavaScript error most likely will stop your application running. There are many reasons why that might happen:
- ad blockers, browser extensions can modify/interfere with your JavaScript
- 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
Anna Debenham
Video: https://www.youtube.com/watch?v=AuRYK7iCVac
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.
Stefan Tilkov
Video: https://www.youtube.com/watch?v=y8UsGSFz8IQ
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.
CORBA, ws-*, SOAP. Even though Rest wasn't a new invention it took people a long time to get used to the idea and the "architecture of the web". Similarly, we shouldn't try and replicate the native applications using JavaScript and the browser. We can do better! We get back, forward, refresh out of the box, we can link pages and applications together which means we don't need to build monolithic apps. In fact, clients can be modularised as much micro services. Small frontend apps, loosely coupled and independently deployable.
That's what Resource Oriented Client Architecture (http://roca-style.org/) advocates. Don't reinvent the browser with JavaScript. Instead augment it to provide a better experience.
Forbes Lindesay
Video: https://www.youtube.com/watch?v=CBnd3EzIZCo
Some sort of mix between Meteor, GraphQL, Relay and React. ¯_(ツ)_/¯ http://www.bicyclejs.org/
Oliver Joseph Ash
Video: https://www.youtube.com/watch?v=dZU6_2xXeVk
This blog post is better than my notes: https://www.theguardian.com/info/developer-blog/2015/nov/04/building-an-offline-page-for-theguardiancom
Stu Cox
Video: https://www.youtube.com/watch?v=L_lVTKHJHNs
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 :(
https://twitter.com/jongold/status/694591217523363840
Adam Silver
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.
Jen Simmons
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
Robin Christopherson
Talk about accessibility and what it's like to use websites which are not accessible. No notes :(
Stephanie Morillo
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"
https://drive.google.com/file/d/0B9tuXpNb2iGHSW40TDZQWk8yMW8/view
Aaron Gustafson
This blog post is better than my notes :) https://www.aaron-gustafson.com/notebook/learn-from-the-past-enhance-for-the-future/