Enhance Conf 2016

Talk notes are in reverse chronological order, last one first.


"Smiling pile of poo"

Learn from the past to enhance the future

Aaron Gustafson

Web design is cyclical, just like everything else

Things you learnt about optmising for dial up modems, are still true for hotel wifi and 3g connections.

GUI-less interaction. Voice control is happening.

How do we design a conversation? ZORK understood sentences which created the feeling of playing the game with a friend.

Every web page is a conversation. Homepage: we've just met, here is why I matter. Show people, rather than tell them. Sales copy puts people off.

In 2 days of photo uploads on FB over a holiday, they got more photos than the entire catalog of flickr.

There was also a dramatic uptick in mis-reported photos. They followed up and it turned out that the stock "reporting reasons" were not suitable.

they added :"How does this photo make you feel: Embarrassing, Upsetting, Saddening, Bad photo, Othere:"

Things got better, but many chose "other" and wrote It's embarrassing." They didn't identify with the copy "embarrasing", missing the implied "it's".

They updated the copy again, adding the "it's" and saw another uptick in correctly reported photos.

the purpose of design is not to make something pretty, it's to clarify.

Mobile first is to focus on the essential.

Write for people

Be clear, concise, honest, considereate, and write how you speak. Read it aloud; For a voice ui, that's beta testing.

We write in the service of our users, not ourselves. Be concise.

We show users respect by respecting their time. Remove unrequired fields. Via a voice interface, non-essential are tedious.

Use html5 input types. Avoid slicing fields. A voice user will have to give three seperate inputs.

With progressive enhancement, supporting the past is setting us up for succss in the future.

Options should mirror how people talk! Content is where experience begins! design #clarifynotprettify #enhanceconf pic.twitter.com/fHaYieT7kF

— Rainey (@RaineDe) March 4, 2016

Copy Basics for Tech-Focused Individuals

Stephanie Morillo

Resource list: https://drive.google.com/file/d/0B9tuXpNb2iGHSW40TDZQWk8yMW8/view

Copy != Content

Copy is not a marketing artefact.

Creating copy is oftern divided up amoungst many members of an org.

What is Copy Writing? The art & science of strategically delivering words that prompt action.

Guiding the user with words throught the user interface.

2 types. Long form copy (blog post), short form (sms alerts, help messages, form labels)

legal copy isn't a job for a copy writer. Tech docs similarly. (they'd probably benefit from it tho)

Interview stake holders to ensure the message is accurate. It is factually correct and is of a tone appropriate to the org.

They ask...

You can't write the same copy for different localities. US / UK cultural references and spellings, all matter.

Through understanding your organisations values you define your tone of voice.

Avoid salesy copy. No superflous words. If a word adds no value, and removing doesn't change the meaning, remove it.

Use techincal terms consistently. Is it Back end? backend? Back-end?

Your credibilitiy is harmed by errors in copy.

A copy writers craft a message, they don't invent the information content. You need to front-load them with the info, so they can work it up.

Keep in mind that I'm an artist and I'm sensititve about my shit

Pick a technical reviewer, an editor and a sign off. A pile of misc comments on the copy is crushing.

Use real copy as you build a site. Don't use Lorem Ipsum. You can edit the copy later, but you should be realistic about what space the copy needs, and you see the story for your self in-situ, in a holistic manner.

The purpose of copy is to inform and to promote action.

Living on the Edge: Extreme computing and the Age of inclusive design presented

Robin Christopherson

Make sure the default layout for small sreens isn't mean. No tiny fonts, no poor contrast. You help all users, the sighted on a sunny day as well as the partially sited.

A non-disabled person opeating a mobile one hand while walking is motor imparied. "the one handed juggle" That extreme useage scenario overlaps with the requirements with a disabled person.

Fat fingers. We don't all use oversize devices yet. Some of us have jumbo fingers. Consider the tap zones. When you do you also consider someone with limited motor control.

Consider a sat nav use case. You set it going, then the app mustn't require further manual interaction. Voice, gesture, and other interfaces are needed.

Many mobile users do have a disability. I love my smart phone.

See: http://www.w3.org/TR/mwabp/ - Mobile Web Application Best Practices

Set users free... offer them a choice of interfaces.

Preserve focus on dynamic web pages.

See: https://www.w3.org/WAI/intro/wcag

Test with VoiceOver on osx and use the Accessibility Insector.

CAPTCHA - it's a accessibilty disaster. It provides an audio option. No one in the room could decypher it.

Consider: TextCaptcha http://textcaptcha.com/

Augmented Reality. If you're buiding an AR app, think about how you'd create those layers of accesibility. We have new accessibility challenges ahead.

AbilityNet - https://www.abilitynet.org.uk/

Please think about everyone. Not just yourself. Thank you.


Progressing Our Layouts

Jen Simmons

Timeline of the evolution page layouts on the web.

I can't use that new puppies unicorn thing because IE*

but 96% of browsers support flexbox now.

yes because client ...blah... IE*

How important to you is that 4%?

For the dev, there is that risk... if I use it and it doesn't work, I get fired. The problem is the binary thinking of either it works or it doesn't.

!! @jongold tweet makes it for the second time. such fame. what a beard.

which one of the two possible websites are you currently designing? pic.twitter.com/ZD0uRGTqqm

— ¸.•´¯• GOLD •¯´•.¸ (@jongold) February 2, 2016

So you can boil down your design to the standard bland layout out of fear...

or you can do some research. Look at the stats in caniuse.com. You can drill down to see the support by global usage percentage. Maybe your users don't use that browser, you can plumb in your google analytics and actually know the answer rather than worrying about it.

...and css degrades gracefully. So that browser doesn't support that css property. It just gets ignored. Border radius works and doesn't work both at the same time. Browser that support it will get them, browsers that don't , won't, and thats ok.

Even vertical alignment. See display: flex, height:100vh Nice full hight headers. If the browser doesn't support it, well the header collapses, and it sill looks good. Even if the client demands a tall header on browsers that don't support it, you can add height:500px; height: 100vh; and the browser that doesn't undestand it will get a 500px high header, as it ignores the second rule that it doesn't understand.

Design in the browser. Figure it out in sketch, sure, but then try it out in a browser. You don't have to draw screens for every possible combination.

CSS feature detect

p::first-letter {
  inital-letter: 4;

Where first-letter will pick the first char, and initial-letter will ensure the letter is the height of 4 lines.

It's badly supported. So what do we do

@supports(initial-letter:4) {
    // media query style, only applied if supported.

If the browser doesn't support @supports then the block is ignored. (Atomic enhancement style from earlier talk from Stu.)

Autoprefixer: is cool. use it.

See also Modernizr, but it depends on JS. CSS always beats JS, in the load time. If a problem can be solved just in CSS, it's better to do it there. Don't depend on a JS solution if you don't have to.

Conditional style sheets

IE only comments (old-school) and -ms- specifc media-queries.

It's totally ok to send the mobile site to the browser that doesn't support all the fancy features.


Drop layout frameworks & lean vanilla css.

Don't polyfill grid layouts.

Don't use JS for layouts.

Use feature queries to hide layouts that use flexbox / grid from browsers that don't support it.

If you do, you get a puppy riding a unicorn.

'Let go of the idea that you have to wait 5 years before you can use something new' @jensimmons at #enhanceconf pic.twitter.com/N8BTbbFOD4

— Ines Teles (@iteles) March 4, 2016

Embracing Simplicity

Adam Silver

Imagine your life with less. Less superfluous and unecessery complexity.

I have no icons on my desktop, I have no icons on my homescreen, I shut down apps I'm not using. I work better when there is no clutter. My computer works better too.

It's hard. Simple is complicated.

Medical failures are mostlt attributed to

Ignorance, Technology, Ineptitude.

Aviation uses checklists to fight ineptitude. When implmented in medical settings saved 47% of avoidable injury.

We are

Seduced by Complexity

We feel that we must put effort in to get value out.

Value has a value when it's value is valued

Repeatedly building new checkout flows for Boots then JustEat, when all the fancy was stripped out, and the flow reverted to very simple, full page per step, there was a huge increase in conversion.


What can we do with just the basics?

typography, color, copy, it's a long list.

Mobile first can be reformulated as "Essential only" which has been extremely useful for the industry.

iteration = momentum

Do the simple, test it. If it works, you've delivered early. If not, you've learnt something about the context the solution will exist in, and you can iterate and improve.

In this way, we get less attached to any one solution and we learn as a team.

Design smackdown

Stephen Waller (design) and Phil Hawksworth (dev) Rumble!

OOooOOH let'd do things carefully.

says the developer.

Phil: what

Stephen: BORED, where has the fun gone?

in the 00s the web was a gigantic playground and you could do what you wanted.

now the rise of UX (as if it never existed before). We are more structured and sensible in our approach.

Not much has really changed. "Does it work in IE" is now "does it work in Safari"

Responsive: we once designed for 1024x768. Now we have to have a more structured apporoach (grids, breakpoints) to deal with explosion of resolutions.

flat design is responsive designs co-joined twin.

"We don't need layout design now we have material design." I want to slap them.

Quotes @jongold!

Which one of the two possible websites are you currently using?


Material design is incredibly effective for google.

The tools and techinques are constantly improving. Developers are not runing your fun...

Stephen: Are you sure about that? Phil took delight in telling me that flash was dead.

There is always an argument against design (page weight, no scroll-jacking).

All you've left me with is parallax.

Phil: Not happy with the title: "All you've left me with is parallax."

We didn't take flash away from you. We explained the risks.

we are constantly learning, and we're not putting a moritorium on progress.

Stephen: the puritanical rhetoric of "what the web is" is dangerous.

What other creative industry actively discourages innovation

Web articles daily on "only use existing design patterns, what is a proper web page."





The first bite is with the eyes.

I'd never argue that design is not important. Point conceeded!


Design is not sugar coating. Content and presentation are mixed together.

Credibilty through design.

People are going to websites that are not the real ESTA (us travel visa) registration site, because the real one looks so bad that people assume it's not the right one.

Phil: This credible design looks like one of those "two availble website designs mentioned earlier!"

There are inappropriate useage of design see: http://www.milwaukeepolicenews.com/

Stephen: That is terrible, but consider the intention behind it. If its to give information, it's a failure. If it's to drum up excitement and support, then arguably it's a success.

When design is relgated to a frilly superfcial, optional thing, it betrays the lack of understanding of that design really means.


The value of emotion

We judge books by their colour. We ascribe ourselves to tribes.

Trends... people get board of things. No matter what the design, it will have to be changed, just because.

Phil: Broad agreement! We all need good design, and access.

I disagree that the rhetoric is dangerous, nor that creativity has been lost...

see particle physics demos, crowd sourced graphic novels.

But somethings have to be accessed by the widest array of people.

We need balance. We need Progressive Enhancement.

It's not wall or something to hide behind when asked to implement a design, it's the baseline.

Stephen: a reduced or degraded experience has to be designed. That's an overhead. The budget is constrained. Everthing is vastly more complicated. We start to repeat ourselves as we have to fall back on existing solutions.

It's a head and heart issue.

Phil: Agreed.


Innovate as a last resort. More horrors are done in the name of innovation than any other Ray Eames @adactio

Fighting Fragmentation

Stu Cox

Broadest possible support leads to fragmentation / code complexity. Nothing is simple; responsive layout, mobile inputs and input type support, image/video/media support.

multiplicity in design, code & test = more to go wrong.

Features depend on capabilities

Capabilities required by core features are hard requirements to experience the content.

atomic enhancements either fully applied or not at all. You don't want your non-essential 360° product viewer to fail because the browser lacks webgl, but to leave buttons on screen that refer to that feature. alienates users.

On finding a capability is missing, you can: drop the enhancement, ployfill, or re-build in simpler technologies.

Progressive Enhancement != "works without JS"

If your app needs JS, progressive enhancement is still valuable.

Conisder structuring your project in terms of core vs enhancements. Split core functions out from extras. This should make it possible to test how your app functions when enhancements are not available.

To ensure atomicity of enhancements, wrap entire feature in a feature detection, either modernizr test for js, or media-query for ui.

Group features fold related enhacements in together to reduce fragmentation. Consider strucuring your code around tiered, gold / silver / wooden spoon, impls of enhancements, based on groups of related capabilities that losely identify a grade of device we're dealing with.

Atomic enhancements: totally disabling an unsupported feature, not partially implementing it. #enhanceconf pic.twitter.com/940AlGWoGd

— Siddharth Vadgama (@siddvee) March 4, 2016

Taking the Guardian offline

Oliver Joseph

web vs native

The guardian app is built to deal with poor access / no access conditions. Last content is cached. App is useable.

The website is not. We can do better! What content can we serve when offline and how?


ServiceWorker can intercept and handle network requests. Is https only... guardian is moving across in stages to https at the moment.

Service Worker support is only FF and Chrome currently so always test for the feature before using.

See them in dev tools:

Guardian uses the install event to prepare things like updating a client local cache.

fetch event intercepts all page requests. You can choose to re-implment the default; go access the server, or pull responses from a cache / or rebuild from json & templating. As long as you end up with a string of html.

You get access to the headers so you can use the accept header to limit your hi-jacking to type: text/html

You can re-think your network access. offline-first! Hit the local cache first. If the resource is not in the cache, go to the network.

Now you have a caching problem. You can use servicework to background sync / update the cache when the user has network, for, say, updating an offline cross word to the latest.

See: https://www.theguardian.com/info/developer-blog/2015/nov/04/building-an-offline-page-for-theguardiancom


@OliverJAsh talking about progressive web apps with service worker #enhanceconf pic.twitter.com/qvl8YI564o

— Sanne Veroude (@SanneVeroude) March 4, 2016

Forbes Lindesay

Why should you care about server-side rendering?

how to universal app?

To write code that can work in both client and server we need to abstract away the diferences.

Routing: both client/server render at a given url and respond to navigation.

See https://github.com/reactjs/history

Using history we can abstract away the implementation details of url handling from the app. Server and client can implement it as required.


JSDom a JS impl of WHATWG DOM and HTML standards. This can be substituted in for the window on the severside.

React: built in support for serverside rendering. Every change is a complete re-render, then diffing keeps it fast.

Forbes is giving some super useful code examples, passing in the parts of the env that need to be abstracted to build an app that can run on both client and server, I'm not gonna be able to recreate that here, but will find the slides later... its worth it.

Data fetching Server calls db. Client calls apis. Server has to wait for all data before rendering. Client can deal with partial rendering.

You could render a minimal page layout server-side... just the public / common parts. Keeps server simple / static. Defer the user specific details to client side.

Or... Make data loading declarative, abstract the mechanism by which data is loaded.

Bicycle by Forbes is an example / prototype imple of this idea.

Bicycle is a caching layer and knows data requests that are in flight. App creates a subscription with a declataion of what data it needs. App can send updates back.

Bicycle is stateful, to figure out what data the client has already.

You crete a BicycleLoader which knows how to get data for the current environment (ajax/db)

Use container components in React that deal with the data requirements, and pass down state to simpler presentation components.

mixins are dead, long live composition.

Data Transmission: Form Posts... it works, but we can do better on the client. ABSTRACT

Bicyce makes an abstraction over forms...

Advanced Interactions

Is the user actually trying to navigate? Can it be a link tag.


Escalation of an app..

Semicolons ftw :) Finally understand how isomorphic apps work @ForbesLindesay #enhanceconf pic.twitter.com/wE0h19Ln3d

— Anna Doubková (@lithinn) March 4, 2016

Progessive Enhancement for Software Architects

Stefan Tilkov

The anatomy of a SOAP Web Service... It violates all the things that make the web great, no acccess to individual resources / uris. It happens to use http as a transport.

It's optimised for a particular use-case, but it's isoalted / inflexible / not playing to the strengths of the web.

we knew soap was a bad idea in 2001 but the industry insisted on proving it for the next few years.

hypermedia as the engine of application state ( HATEOAS! my personal favourite abbreviation in tech )

Nobody very few people do soap based interfaces anymore.

Whats the corollary in frontend? We've got multiple frontends...

web-apps should not be as bad as native apps! Build a native app if that is the best solution. Play to strengths of each. They exist in entirely seperate universes.

A bad webservice ignores the basic features of the web. A bad web app does the same. No support for the back button, no linking, a monolithic app, no second tab... this is the web app version of a terrible (SOAP like) web service.

See: http://roca-style.org - roca principles.

A web-native way of distributing logic - hypermedia style, where the server informs the client of what actions are available from where they are.

You render to an unknow client. Logic and state on the server. Client extensible on demand.

any sufficiently complicated JS client side application contains an ad-hoc, ill-specified, buggy impementation of half a web brower.

The web has an architectural style.

It's a testament to the web that you can do anything you want, but constraints are good! Work with it.

“The Web is more than the sum of its protocols” … “constraints are good” —@stilkov #enhanceconf pic.twitter.com/u9DxGEGpJC

— Aaron Gustafson (@AaronGustafson) March 4, 2016

Game console browsers

Anna Debenham

Designing for the broadest spectrum of users can improve the experience for each.

Anywhere you can stick a screen, eventually, there will be a browser.

Screen size / device type is a continuum.

games console a used as browsers. 26% of 16-24yr olds use console to browse.

lower income families are more likely to have a console than a pc.

Nintendo have a web-framework based on webkit and lets you build apps in html5 with gamepad support.

D-pad to browse!

in 1997 there was a web-browser in the game.com handheld.

xbox 360 scores 33% on html5 test and and 25% on css3 test.

You can flip a xbox user agent string to pretend to be a mobile. probably because it's typically easier to use. We need to re-think our desktop interfaces.

Consoles are being marketed as complete entertainment solutions. The browser is a feature. They are coming up with features to make the experience more interesting than desktop.

xbox one is rocking 77% on html5 and 33%(check) on css3

in esoteric devices, interaction is weird; but that's good.

CHECK OUT: http://console.maban.co.uk

Designing for hostile environments

Nat Buckley

You can't always know the ramifications of your design choices. Always test. Always test with voice over

Use clear language. Use a tone appropriate to your org. (gov.uk is formal, mailchimp is informal)

Language can exclude. Biased terms re-enforce existing inequality.

Page load time... If a Medium article is 1170Kb all in, it loads slowly on fast urban wifi. It's basically unusable elsewhere.

If you happen to not have unlimited mobile data that'd cost you

Gov.uk tested for users without js.

Ask yourself it it's ok for your site to depend on js.

'Nobody cares about your product the way you do, they just want to get to the content' @thatnatbuckley #progressiveenhancement @EnhanceConf

— Ines Teles (@iteles) March 4, 2016

Some notes, transcribed as it happend by @olizilla. All mistakes are genuine.

of note The @jongold quote was just beaten by the Doug crock quote 2 to 3.