- A good writer is a good thinker
- Getting personal the why and how of designing for people
- Give them what they need not what they want
- Responsive images
- Rethinking publishing
- Beyond the browser with hybrid apps
- Is Blink the new IE6?
- Mystery speaker: Christian Heilmann
- Enhancing responsiveness with flexbox
- Debugging HTTP
- Making a silky smooth web (rendering performance)
- Crafting for World Domination
- User research for designers and engineers
- Modern progressive enhancement (incl. ServiceWorker)
- Panel
Christopher Murphey @fehler, lecturer at University of Belfast
Used to write as one half of The Standardistas
First talk of the first day. He's Irish, it was 17th March: drinking Guinness on stage at 09:20.
Open up the appeture: Read widely, learn to get different perspectives. Shit in, shit out.
4 levels of reading:
- Elementary: basic primary school stuff
- Inspectional: systematic skimming of title, ToC, index, back page summary
- Analytical: classifying a book, defining problem author is trying to solve, taking notes as you read
- Syntopical: Many books, multiple angles, prose disparities, form your own informed opinion
When you read a book, don't stop to look up stuff you don't understand, that way lies rabbit holes and you'll break the flow. Keep going, if the book is good you'll come back to it anyway and the next time you read it you'll have much more context.
As Charlie Monger, use ideas from many disciplines, understand as much as possible, bind ideas together to solve hard problems. (Helps you avoid the man with a hammer syndrome: the mentality of "I have a hammer, therefore a hammer is the best tool to use to solve this problem.")
You get the Lalapalooza effect: synergistic effect of combining all this knowledge.
For example you could look at psychology, anthropology, economics, heuristics, maths, pricing, accounting... for a richer mind.
"I write to clarify my thoughts."
All the ideas and knowledge accumulate, and sharing helps.
Abandon fear. Your writing is a playground, it's play, nothing can reallly go that wrong.
Can think of blog posts as facets of a diamond of your development.
Challenge yourself through what you read, and how you write. Use the socratic method within yourself, then you can write yourself into existance.
Evan Sempler said: once you have a blog you notice more. Sharing shapes you, people react to what you say, you react to that... you have a feedback loop.
The trick to good ideas is to get as much on the table as you can, then you can stitch things together.
"Real knowledge is knowing the extent of one's ignorance."
- How to read a book
- The myths of innovation
- Managing oneself by Peter F Druker
- A technique for producing ideas
- A note on reading by Mortimer Addler(?)
- his writing the The Pastry Box and 24 Ways
Meagan Fisher @owltastic, many things at Sprout Video
How can design take a fanstastic idea to the next level? With empathy: understanding feelings and needs of users. This understanding comes from exposure to users. With this understanding, we can design effective solutions
What determines the success or failure of a design? At the beginning, recognise as many of the contstraints as you can, see Charles Eames. Simply: success is made by answering these 2 questions:
- What are the business goals?
- What will look best?
New Coke failed because they didn't ask their customers "Do you want a new Coke?" Crystal Pepsi failed because they didn't check that it actually tasted good. Neither case addressed "What do people really want?" Real human needs are the most valuable constraint we have. Why do designers frequently resist getting this data?
- "it's someone else's job"
- don't know where to begin
- may raise inconvenient quesitons
- thought to be too expensive and time consuming
- they think they already know their users
BUT:
Anyone can do it, it's cheap! Cultivate a desire to be proven wrong as quickly as possible, as cheaply as possible.
In Jared Spool's team, everyone spends 2 hours every 6 weeks watching users use either their products or their competitors products.
- Ask questions for context
- Listen for unmet needs and goals
- Observe frustrations and successes
- Dispel your mistaken assumptions
Get as close to a user as you can, watch them using your product. Record them using e.g. Silverback (records audio, video and screencap). Take notes and share them with your team later.
If you don't have direct access to real users, interview people you know who are closest to your target audience.
Hits all 4 goals.
If you can't interview in person, you can run remote user tests, e.g. usertesting.com charges $50/video.
Hits goals 2, 3 and, but you're not face to face.
Using tools such as fullstory.com and inspectlet.com, you see what your users are doing in your product. Enables you to dispel bad assumptions.
Hits goals 3 and 4.
Tells you what, not why. Hits goal 4 only.
Now you have:
- useful contraints
- meaningful context
They will give you:
- better critiques
- iterative changes
(Other ways to underdtand users: read support emails for 15 minutes over your morning coffee; let a sales rep let you sit in (possibly silently), on a call, weekly).
Richard Rutter, co-founder of Clearleft, inventer of the 62.5% font size technique @clagnut
Redesign website of Royal Borough of Kensingto and Chelsea.
Started with a pilot for the planning section of the website. Was thought to be the most complex, was hoped that a successful pilot here would be an exemplar for the rest of the site.
They were told 3 things:
- Visitors do and seek
- Most pages arrived at via Google and homepage search
- They try to keep things simple, but are often over-ridden by regulatory need
Content audit: 86% content related to planning applications. These tell you what people are doing, not why
Residents' panel: "wealthy, educated and used to getting their own way". Thougth the council was deliberately hiding stuff!
Ran exercises to uncover users' mental models of content:
- card sort with the residents' panel using the top 30 pages in the content audit
- 1:1 stateholder interviews with staff - what did they think residents needed the site for?
- repeated card sort with staff
- also did online card sorts with optimal sort (got results as dendrogram).
Customer services are your best friend for user research. Also search logs, including failed searches. Can then normalise terms and understand language your users are using, so you can echo this to them in the site's terminology. Note what's not in the search logs, too.
As majority of users came from Google, each page had to be considered a landing page, and must be able to stand on its own.
Regulatory documents must be on hand, but shouldn't get in the way.
As users did indeed exhibit seeking and doing behaviour, they're not coming t oreceive broadcasts from the council, the the site is not the place for the council to broadcast information.
New "Check if you need planning permission" page is focused, short. There's no sidebar nav, as the page addresses the task without it. To perform unconnected tasks (which are usually what's available from this menu), users tended t oreorientate by going back to the home page anyway.
Defined a set of design principles for the people adding the content. Simliar to GDS ones, but not GDS ones, these were specifically for RBKC.
There were a lot of PDFs. The rule was t ocorrectly tag a PDF for accessibility, and if it can't be tagged, publish it in an accessible format, ideally HTML.
One deliverable they gave the council was a pattern portfolio.
Yoav Wiess, Committer to Blink and Webkit, now working at Akamai on making the web faster @yoavwiess
Yoav implemented srcset and <picture> in Blink, and is doing the same for Webkit
Use cases for responsive images: http://usecases.responsiveimages.org/
srcset is simliar to imgset in CSS, it's used like this:
<img src="[fallback/default resource]" srcset="[resource] [descriptor], [resource] [descriptor]..." />
where resource is the path to the image, and descriptor is the description of that image. The description can be the width of the resource (e.g. 640w), or the dpr of the resource (e.g. 2x).
srcset provides hints to the browser to help it decide which image to load. Note that as this is a hint, it is not mandatory, this enables the browser to take other things (e.g. network quality), into account while deciding which resource to load.
sizes specifies the size the image should occupy in the viewport, based on mediaqueries. This becomes powerful when used with srcset:
<img src="default.png"
srcset="narrow.png 100w, medium.png 200w"
sizes="(min-width: 36em) 33.3vw,
100vw"
/>
This says that if the viewport is at least 36em wide, the image should occupy 1/3 of it, otherwise the image should occupy its full width. Note that if using sizes, you must use the width descriptor, not the dpr descriptor, in srcset. Like srcset on its own, this provides hints to the browser, rather than mandatory instructions. This allows the browser to make the best decision in its current conditions, which the code author cannot know at write-time. Consider sizes and optimisation, if it's missing you still get the benefits of srcset.
Note that the the first media query to match in sizes wins.
There is concern about the separation of concerns with this approach, having media queries in the markup. It's there because the browser needs to know this stuff to work out which image to download before it's calculatated the page layout. The media query syntax is the same as that specified for custom media queries in the upcoming media queries spec. When that happens, they can be named, allowing for update-once-permeate-everywhere. The media queries used in sizes are a preview of what breakpoints your page is using, so must be identical to your page's breakpoints.
- Chrome 38
- Opera 25
- Will be in FF 38
- IE: stated they will support srcset x descriptor, and look favourably on the rest
- Safari: srcset x descriptor in 8, sizes in nightly.
srcset and sizes are used to provide equivalent images for different client conditions. This is why they can be treated as hints to the browser: if something doesn't work, and another image loads instead, then the only price is a missed optimisation. Sometimes images loading under different conditions are not equivalent (the 'art direction' use case). In this case, use <picture>. The media attributes on the its child <source> elements provide instructions to the browser that it must follow, rather than just a hint that it may follow.
<picture>
<source media="(min-width:55em)"
srcset="..."
sizes="..." />
<source media="(min-width:36em)"
srcset="..."
sizes="..." />
<img src="fallback.png" alt="something relavent"/>
</picture>
The media queries on the <source> elements within <picture> are again first-one-wins.
The <img> element is doing the heavy lifting, the <picture> element is a wrapper around it that the browser uses to determine which resource to load into <img>. Style the <img> element with css, not <picture>.
For feature detection, can use HTMLPictureElement, and HTMLImageElement.currentSrc and HTMLImageElement.sizes
To layer in responsive images:
- start with
srcsetwith x or w descriptors - optimise using
sizes - if you need to force art direction, then introduce
<picture>
For simple cases, just rely on the built-in fallback of src. For complex cases can use Picturefill.
Next steps: client hints.
Peter Bi'lak publishes Works that Work @peterbilak
Typically, 54% of a magazine's content is advertising, so is the magazine made for the reader or the advertiser? The advertiser is the client of the magazine, the reader is the commodity.
Bemnjamin Day came up with the advertiser-subsidised publication for The Sun (New York?) [19th C]
[publn?] abandoned print end of 2012 still with 2million paying subscribers, but advertising revenue had declined 84%. The subscriber was paying 34¢/issue, which doesn't even cover delivery!
Monacle uses 'advertorial' approach where the line gets blurry between content and advertising. Readers don't seem to mind at the moment, but the person who invented the banner ad says this is gambling with the readers' trust.
NYT have only just started making more money from subs than advertising.
Works That Work has cap of 5% of content to be advertising (although it's not gone above 3% yet). Got started using crowd funding. Asked funders what format they wanted and what they're willing to pay. They wanted print as well as digital, showing there still is appetite for print: print per se is not a problem that can be solved by online - there's still an appetie for print.
How to maintain identity of magazine where there's so much variation in the platform? Main tool is typography to bind it together: they started by designing their typeface.
Offered a slider tool to allow readers to select their price, and explaining what they get for it. They also make subscribing and unsubscribing as easy as possible.
[Creativity and design in unexpected places.]
The key to sucess. Traditional distributors take 80% of cover price. WTW uses 'social distribution' to avoid them, as advertising cap would make them a non-viable choice anyway. Tried getting readers to get local bookstores to stock it, but the bookshops weren't interested. Readers themselves can chhose to be part of the distribution network: if they buy 10 copies, you get a 50% discount and you can sell to friends.
Even so, shipping costs are high. Readers offer spare luggage space to take the magazine abroad.
Natalie Yadrentseva. Works for targetprocess
Despite its interesting title, this talk was impossible to comprehend. Rapid fire examples with no context, and no narrative arc to the talk. Incomprehensible.
Tom Gianatassio @atassi Works for macaw.co
Uses web technologies to build desktop apps. Web stack gives you the layers
- app
- browser
- os
Hybrid apps make the browser 'browser-ish': one main difference is that you can talk to the OS directly.
- well definied environment: webkit
- can be packaged and distributed to different OS, and even deployed to the web (although might need some changes & many browser checks first).
Node Webkit (nw.js)
npm install nw- create an index.html page, and point the
package.jsonfile at it nodewebkit build
In package.json, add the window object with whatever properties you want (e.g. toolbar: false), then build up the interface.
Because node is running in the background, you can use any node module you want in your app. You can use responsive techniques in your app too, like responsive typography etc!
Some challenges in their image editor around taking a change an applying it to all windows that need it. Created an empty window at the top of the screen to hold all the main JavaScript. They used this as the hub for a hub and spoke, the visible windows being the spokes.
Used virtual DOM to manage history.
CSSOM is available from document.styleSheets. They also used a virtual CSSOM to abstract away the wrinkles involved with manipulating the CSSOM directly.
Bruce Lawson, Opera Developer Relations @brucel
Always entertaining while making very good points, was looking forward to this.
Opera is the 3rd biggest committer to Blink after Google and Samsung. They are interested in making it work better on low end phones.
Native apps work offline a bit, web ones don't. Serviceworker! Forces you to have URLs and it's offline by default.
People love to have an icon on the home screen. Coupling a manifest with Serviceworker enables this.
We need to be the web, but better. Stop emulating failure!
- iPhone
- vendor prefixes
Both cases, lazy/short-sighted devs risked breaking the web/forcing an monopoly by only implementing for one platform/browser etc.
Blink is not currently a monopoly:
Browsers now not implementing vendor prefixes, but rather hiding the functionality behind a browser flag means that devs can test stuff, but it can't deployed until stable. Stops lazy devs implementing only -webkit-blah. Helps stops de-facto monopoly arising.
- Blink doesn't want to be a monopoly (recognise benefits of healthy eco system)
- even if they did want to be, couldn't be because of the competition
- devs could still make it a monopoly if they're lazy or short-sighted. DO NOT DO THIS!
-
don't fight other people's knowledge, use it!
-
the web is a burden to people who want to make a quick buck out of software
-
we need to stop gorging on technology and build sites for people who are not us
-
Github stars, retweets etc are equivalent to the leaf currency adopted by the Golgafrinchans
-
Minimum loveable product
-
bet on interop
-
wpdev.uservoice.com
-
status.modern.ie
Zoe Mickey Gillenwater, works at booking.com, Amsterdam @zomigi
This built on last year's talk, with more emphasis on solving responsive design problems.
Opera Mini now supports Flexbox!
Remember: setting display:flex on parent doesn't stop you setting e.g. display: inline-block on an element that then becomes a flex item.
Modernizr is good for detecting flexbox support, and legacy flexbox!
The old syntax is slow. If you're using flexbox as a progressive enhancement, you could ignore the old syntax entitrely and make the old-syntax-parsing get the fallback. N.B. You can't exclude old syntax generation from autoprefixer.
Flexbox overrides:
- floats
- table-cell
- inline-block
Flexbox doesn't override
- absolute positioning
Lorna Mitchell Seen her PHP courses online @lornajane
Seeing the problem is generally harder than fixing it.
Useful in devtools network tab:
- resend XHR
- copy as curl (so can alter request before resending)
Useful curl switches:
-xverb-HHeader-dbody data-ssilent (useful if piping)-cwhere to store cookies for reuse (filename)-bcookies to send (filename)-vshow headers for request and response
Curl wrappers if you don't wan tto use the command line:
- postman
- rest client
- Paw (Mac specific)
ngrok.com publishes what's running locally out onto the internet (uses a tunnel). Really useful for previewing etc. [Hope it's secure!]
Charles is more web literate than Wireshark, and is a real proxy. Can use the 'Publish Gist' option is working remotely to share your findings. Can throttle the connection to check performance.
Can use Charles as a proxy, & if proxy phone through charles on local network, Charles can capture the traffic for inspection. (Can map Charles to local instance (??))
- http://placekitten.com
- use 'realtive urls' plugin if you're using Wordpress to avoid nightmare of hardcoded domain name.
Paul Lewis, Advocate on the Chrome developer relations @aerotwist
Page load is king, but that's not all. We're in the business of shipping frames to the screen. One frame is a page, more than that is an animation.
When the browser calculates style:
- create the render tree
- calculate layout (the geometric part of the process)
- paint (filling in the picture)
- composite
Changing an element's width will hit all the steps, so relatively slow.
Changing an element's colour enters the flow from the paint step
You want the changes you make to only hit the compositing step if you can. Look at http://csstriggers.com/ to see how updates to different css properties hit different parts of the rendering path.
Use requestAnimationFrame rather than setTimeout. Note jQuery's animate function uses setTimeout.
Can use a worker with a callback.
But you could have lots of long-running scripts e.g. ads: uh-oh.
Workers don't have DOM access, but they could use virtual DOM and send the patch back into the main thread.
Classic memory profile of scripts using garbage collection. GC occurs as the peak drops, but while GC is running, nothing else can. Can set up object pools to counter this, but it's complicated. See Addy Osami's memory masterclass.
_
_| |
_| |
_| |
_| |
_| |...[repeated]...
Selector matching
- Did I limit scope for style change to only affect minimal number of elements?
- Are selectors fast? (CSS class selectors are fast, so BEM is good for selector performance.
If you set a style on an element, then read the style on that element, this causes a 'forced synchronous layout', which is bad. If this happens in a loop then it's very bad, and is called layout thrashing. To avoid this, read the style first, then set it.
Often the most expensive, and hardest to avoid.
- Can I reduce the paint area? Use
will-changeCSS property to tell the browser which properties are likely to change: the browser can then make a new compositing layer to help reduce render time. (New version of the now deprecated translateZ(3d) trick). Don't overdo this though, as each composite layer requires memory and management.
Transformations and opacity changes don't need layout or paint. The element in question will need to be on its own composite layer (so use will-change as necessary). Aim for a compositing time of 5ms.
Native touch handlers handle scrolling event on the compositor thread. Custom onscroll/touchmove/touchstart causes scroll to be sent to the main thread, so slower. Grab the values you need from the handler, then get out of the way. Use the values later when you need them.
The Chrome team think in terms of RAIL:
- Response
- Animation
- Idle
- Load
The time you have to respond to user input (100ms)
When aiming for 60 frames per second, you might think you have 16ms to play with (1000/60), but actually it's more like 10ms because of browser overhead.
Here you can do non-essential stuff that you've put off. Do it in 50ms chunks (appears non-blocking), and stop when the user interacts.
3000 - 1000ms. Aim for 1000 if you can. Trying to do everything up front will never get this fast.
- Performance is more than page load
- Serviceworker changes everything
- Tools not rules, so profile first then optimise
- Performance is not a unit test(?)
- Prioritise user needs
They are pretty equivalent, it more depends on what you're asking to to happen, and why. Sometimes CSS animation can continue when the main thread is busy (so it's better then), but what causes that to happen was not covered in this talk.
Polle de Maagt Works for KLM @polledemaagt
People got frustrated by reaching out to KLM on Facebook and Twitter, and not know how long it would take to get a reply: they felt ignored. In response, they calculated the current response time, and added that to their background pic in Twitter, and the equivalent in Facebook. Much happier customers.
Enabled people to be able to pay for flights/upgrades etc via social media. After agreeing a transaction, they DM'd a link to a form tailored to tha transaciton that lets them pay immediately. For an outlay of €3500, they're seeing €80000/month revenue from this feature.
If you say of your users "They don't get it", you don't get it.
Rachel Ilan UX Designer on Chrome @rilan
What will we build?
"Swiffer" mop designed after observing people cleaning the floor.
Why research doesn't happen?
- easier to throw it over the wall
- it happens a world away from the day to day
- "talking to users is scary!"
Why should you research your users?
- identify new oppotunities
- build the right thing in the right way
- can fail early and fail often
Simplistic product development lifecycle:
- discovery
- ideate
- design and test
- evaluate
Should research at every stage.
Tips:
- doing is better than asking
- don't interpret at this stage, just observe
- ask open ended questions
- followup with probing questions
- dont sell your product
- don't tell them how to use your product
- don't make them say of they like it
Literature review - good if you have time but no money! Pull out key themes; gets you congtext on existing work and shows unanswered questions.
Card sorting - used to determine IA by grouping into themes
Cultural probes - get information about people: they provide it in the context of photos, worksheets etc over a ferw weeks.
Codesign - meet with your users to e.g. "design the perfect cell phone for you". Great at uncovering user needs.
Pop App: Paper prototyping app; early stage; lo-fi. No good for usablity feedback.
Keynotopia: downloadable templates; fast & easy to use; paid for; detail & usability feedback; harder than wireframes; harder to get concept feedback.
Walk user through product to make sure they undefstand what it is.
When people visit a new site, they ask the following questions:
- what is this? They'll leave very quickly if they can't understand
- do I trust you? Often use visual indicators - what does this site remind me of?
- what are you offering me? if it resonates with users, you have a conversation
- how do I get it? Clear call to action
Book recomended: Rocket Surgery by Steve Krugg
3 users, 45 mins with each user + 15 mins debrief after each. Then working lunch to discuss. Ask users questions in order to answer the 4 questions above.
"Immediate debriefings are magic" Take detailed notes. Then you don't have lots of notes to write up later!
Share your findings!
- include others in the study
- document visually
- write a report and present it!
User research will change what you make and how you make it.
Jake Archibald Chrome dev rel @jaffathecake
BBC News cutting the mustard approach: if browser doesn't cut the mustard, don't give it any JavaScript. As long as the site works without JavaScript, not giving it any is fine.
Don't use JavaScript to duplicate browser stuff.
Good to throttle to 3G speeds in devtools for 'realistic' emulation. Do test on minified code!
This decade's web apps are making the same mistakes as last decade's native apps: stuff loads slow.
Have content in your markup. A splash screen is not an acceptable first load experience - it's an admission of failure.
So:
- unblock scripts
- put content in markup
- don't depend on webfonts in critical render. Some deliberately block in order to get stats (e.g. typography.com).
- loading CSS async is not straightforward: use Filament Group's loadCSS to load CSS out of the critical render. If used for fonts, that's not initial content. [use
<noscript>to allow css load when no js].
Ember fastboot and reactjs have a good approach to first render.
If you have 2 js scripts with 2 different functions, load separately async & test for when the functionality is available (this approach is HTTP2 friendly, too).
Render time can get worse if a full cache, as resources already available so processed immediately and blocks render.
If put loading script inside requestAnimationFrame, stops their render-blocking. This increases overall load time by ~ 100ms, but first render is faster, so that's okay.
Sits between page and network.
When you update your service worker, change the name of the cache, so they can exist independently.
Available in Chrome now. See caniuse.com and isserviceworkerready
(Some enthusiasm around ServiceWorker and client hints together than I didn't catch.)
ServiceWorker is https only; http2 spec doesn't mandate https, but all implementations do.
(Beware defer behaviour in IE9 & below: if you have 2 deferred scripts, and the first one touches the DOM, at that point it stops, and the second one runs).
There was a surprise panel at the end of the second day, with some great questions. I've grabbed random soundbites below:
Jake Archibald: era is long over when a front-end dev could know it all.
Christian Heilmann: What can you take away? Reactjs has lost separation of concerns, this is bad
CH: Don't write code examples that teach bad practices as a side effect, because you're trying to make them concise. Be mindful of what others infer from your code examples.
Val Head: took 3 days to repair failing Grunt tasks before being able to edit 4 lines of CSS. I understand why it's this way, but if it's this complicated, maybe we're doing it wrong.
Bruce Lawson: Ian Hickson doesn't understand the full web stack, so what hope is there for the rest of us?
CH: Idea for a talk series "Here's what was shit in the past that we thought was really cool at the time." There are a lot of self-proclaimed "full stack developers" around at the moment. More like "full Stackoverflow developers"
Christopher Murphey: How do we teach people to be self-sustaining?
CH: Permission requests on the web don't scale: you can only have so many of these before the page becomes unuseable. We need good UX people to help us.