# [![Enhance Conf 2016][2]][1]

​

- http://lanyrd.com/2016/enhanceconf/

- https://twitter.com/search?f=tweets&vertical=default&q=enhanceconf&src=typd

​

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

​

---

​

## Q&A

​

- What do emojis sound like? Turn on voice over, open the emoji keyboard... 

​

_"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][3] 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.

​

<blockquote class="twitter-tweet" data-lang="en"><p lang="en" dir="ltr">Options should mirror how people talk! Content is where experience begins! design <a href="https://twitter.com/hashtag/clarifynotprettify?src=hash">#clarifynotprettify</a> <a href="https://twitter.com/hashtag/enhanceconf?src=hash">#enhanceconf</a> <a href="https://t.co/fHaYieT7kF">pic.twitter.com/fHaYieT7kF</a></p>&mdash; Rainey (@RaineDe) <a href="https://twitter.com/RaineDe/status/705799275289190400">March 4, 2016</a></blockquote>

​

---

​

# 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...

​

- Who is our audience? (know the segements. You are not always your users.)

- brand / tone of voice?

​

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.

​

​

---

​

Q&A.

​

- I can't designer in the browser. If I could cut all you developers out of the design equation, I would. But a developer paring with a designer is a beautiful thing.

​

- Can you use the budget argument? If you looked only at the bottom line it could be argued that it's not viable to spend time on accesibility?

​

- IE support obsession... Look at your stats. If 0.4% use IE but 4% use screen readers, then something is wrong if you are focused on old IE.

​

---

​

# Progressing Our Layouts

​

**Jen Simmons**

​

Timeline of the evolution page layouts on the web.

​

- none

- table

- float

- puppies riding unicorns

​

_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.

​

<blockquote class="twitter-tweet" data-lang="en"><p lang="en" dir="ltr">which one of the two possible websites are you currently designing? <a href="https://t.co/ZD0uRGTqqm">pic.twitter.com/ZD0uRGTqqm</a></p>&mdash; ¸.•´¯`• GOLD •`¯´•.¸ (@jongold) <a href="https://twitter.com/jongold/status/694591217523363840">February 2, 2016</a></blockquote>

​

​

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**

​

```css

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

​

```css

@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.

​

So.

​

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.

​

<blockquote class="twitter-tweet" data-lang="en"><p lang="en" dir="ltr">&#39;Let go of the idea that you have to wait 5 years before you can use something new&#39; <a href="https://twitter.com/jensimmons">@jensimmons</a> at <a href="https://twitter.com/hashtag/enhanceconf?src=hash">#enhanceconf</a> <a href="https://t.co/N8BTbbFOD4">pic.twitter.com/N8BTbbFOD4</a></p>&mdash; Ines Teles (@iteles) <a href="https://twitter.com/iteles/status/705765463662395392">March 4, 2016</a></blockquote>

​

---

​

# 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.

​

So

​

> 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?

​

**Phil:**

​

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."

​

http://motherfuckingwebsite.com

​

vs

​

http://bettermotherfuckingwebsite.com

​

**Phil**

​

> The first bite is with the eyes.

​

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

​

**Stephen**:

​

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.

​

Consider:

​

> 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.

​

Hug.

​

​

> 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**

- Features are **core** and **enhancements**

- Capabilities are browser / device / human

​

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.

​

<blockquote class="twitter-tweet" data-cards="hidden" data-lang="en"><p lang="en" dir="ltr">Atomic enhancements: totally disabling an unsupported feature, not partially implementing it. <a href="https://twitter.com/hashtag/enhanceconf?src=hash">#enhanceconf</a> <a href="https://t.co/940AlGWoGd">pic.twitter.com/940AlGWoGd</a></p>&mdash; Siddharth Vadgama (@siddvee) <a href="https://twitter.com/siddvee/status/705728138483990529">March 4, 2016</a></blockquote>

​

​

---

​

## 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?

​

https://www.theguardian.com/info/developer-blog

​

**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:

- Chrome > dev tools > Resources > Service workers

- Firefox > about:debugging

​

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

​

**Problems**

​

- it's new, plenty browser bugs.

- CDN caching - differrent ttl on html and js can lead to your offline assets being out of sync. User ends up with new offline html file, before they get the service-worker.js logic. Consider using a manifest.

​

<blockquote class="twitter-tweet" data-cards="hidden" data-lang="en"><p lang="en" dir="ltr"><a href="https://twitter.com/OliverJAsh">@OliverJAsh</a> talking about progressive web apps with service worker <a href="https://twitter.com/hashtag/enhanceconf?src=hash">#enhanceconf</a> <a href="https://t.co/qvl8YI564o">pic.twitter.com/qvl8YI564o</a></p>&mdash; Sanne Veroude (@SanneVeroude) <a href="https://twitter.com/SanneVeroude/status/705719506585440256">March 4, 2016</a></blockquote>

​

​

---

​

## Forbes Lindesay

​

Why should you care about server-side rendering?

​

how to universal app?

​

- write two apps client/server

- write server only

- **write a client app and run it on the server**

​

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.

​

**Rendering**

​

`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.

​

BUT

- Search engines run JS

- Initial page is not interactive

- Running server-side uses centralised resources. Scale pains.

​

Escalation of an app..

​

- Will a simple serverside app do.

- Will a serverside app with JS as enhancement do?

- Can I ditch this feature for no js / serverside only users. (animations etc.)

​

​

<blockquote class="twitter-tweet" data-cards="hidden" data-lang="en"><p lang="en" dir="ltr">Semicolons ftw :) Finally understand how isomorphic apps work <a href="https://twitter.com/ForbesLindesay">@ForbesLindesay</a> <a href="https://twitter.com/hashtag/enhanceconf?src=hash">#enhanceconf</a> <a href="https://t.co/wE0h19Ln3d">pic.twitter.com/wE0h19Ln3d</a></p>&mdash; Anna Doubková (@lithinn) <a href="https://twitter.com/lithinn/status/705713544340369408">March 4, 2016</a></blockquote>

​

---

​

## 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.

​

<blockquote class="twitter-tweet" data-cards="hidden" data-lang="en"><p lang="en" dir="ltr">“The Web is more than the sum of its protocols” … “constraints are good” —<a href="https://twitter.com/stilkov">@stilkov</a> <a href="https://twitter.com/hashtag/enhanceconf?src=hash">#enhanceconf</a> <a href="https://t.co/u9DxGEGpJC">pic.twitter.com/u9DxGEGpJC</a></p>&mdash; Aaron Gustafson (@AaronGustafson) <a href="https://twitter.com/AaronGustafson/status/705697648557363202">March 4, 2016</a></blockquote>

​

​

---

​

# 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

- £0.22 to view the page in the UK

- £5+ when abroad.

​

Gov.uk tested for users without js.

- 1.1% had none.

- 0.9% had it but it failed to load.

​

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

​

- Know your purpose.

- Know your audience.

- Define your principles.

- **Stick to your principles.**

​

<blockquote class="twitter-tweet" data-lang="en"><p lang="en" dir="ltr">&#39;Nobody cares about your product the way you do, they just want to get to the content&#39; <a href="https://twitter.com/thatnatbuckley">@thatnatbuckley</a> <a href="https://twitter.com/hashtag/progressiveenhancement?src=hash">#progressiveenhancement</a> <a href="https://twitter.com/EnhanceConf">@EnhanceConf</a></p>&mdash; Ines Teles (@iteles) <a href="https://twitter.com/iteles/status/705690581104779264">March 4, 2016</a></blockquote>

​

---

​

Some notes, transcribed as it happend by [@olizilla](https://twitter.com/olizilla). All mistakes are genuine.

​

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

​

​

[1]: http://enhanceconf.com/

[2]: https://pbs.twimg.com/media/CcsQQ-SXIAAPPxR.jpg:large

[3]: https://en.wikipedia.org/wiki/Zork

​

​