Web Directions Respond is in its third year; but the first in a two-day format and in two cities. The ansarada crew rolled into the Sydney edition at the Maritime Museum; and @justosophy rolled out on the electric scooter Vision6 gave away ;)

Contents

Yes a jump nav is old school, but this is a BIG stonking post...

Disclaimer & photo credits

These notes were hammered out very quickly because doing so seems to help me remember them. However due to the haste, errors occur and you should always assume I'm paraphrasing - if you need an exact quote, please check the session recording later.

Photo credits:

  • Pando By J Zapell, Public Domain, https://commons.wikimedia.org/w/index.php?curid=27865175
  • Others as noted in embeds

Trends

  • Notable catch phrases: gonzo development, "css is a hack".
  • Recurrent slide theme: caniuse.com screenshots.

Ethan Marcotte – Laziness in the Time of Responsive Design

FallPando02.jpg

Reference: Pando forest – 40,000 stems from one tree.

Ethan's confession: “I am in incredibly… impossibly… lazy person.”

We're starting to see the web design forest for the trees. We're understanding the challenges underneath the familiar – going from grids and an attitude of control in Photoshop, to a time when we don't build pages. We build parts – modules, which we combine into networks of content that display on a range of devices.

We are moving away from thinking of the desktop experience… the mobile or tablet experience. We're building a single responsive experience.

But there is more complexity underneath than ever before – we have more operating systems to support, display density and colour depth. Saying “tablet” and “mobile” is too broad to be really useful talking about these challenges. Then consider 60% of the world's mobile connections are sub-3g (Ericsson report, 2013).

Ethan's reaction is laziness. An interesting quirk of language is we tend to assume lazy is bad. But maybe laziness is a good thing to introduce to visual practices? Perhaps laziness can be a virtue, or a saving grace?

My anxiety doesn't come from thinking about the future, but from wanting to control it. - Hugh Prather

How can we embrace laziness in responsive design? Three areas:

  • layout
  • navigation
  • animation

…

Layout

A little less code, a little lazier.

Better selectors allow simpler HTML – we don't need to pepper the DOM with classes for presentation. Nth-child allows you to select all even- or odd-numbered cell; or every third cell (nth-child:3n) then the cell that follows (nth-child:3n+1).

The baseline – most sites are being built mobile-first. The simplest layout is the default. Adding extras at higher baseline is very powerful just with the simpler tools like nth-child. We don't need to wait for flexbox support across our users' browsers. We can build essentially limitless grid systems.

“The F Word…. Frameworks” Good for quick prototypes, good for large organisations, but the challenge with modern frameworks is they're conceptually heavy; and will their stock breakpoints and patterns be nimble enough to cope with the future?

But if you think about the content and avoid device-specific breakpoints, your design can be highly portable.

Early animation showed its time – it showed the limits of the tools available. Frames being re-used because it was so expensive to draw each frame.

Animation had been done before but stories were never told. - Marc Davis, early Disney animator

Disney's animations felt human to the audience. The design principle was that drawings should possess “a caricature of realism, an illusion of life”. This ended up being the title of a book The Illusion of Life, well worth reading. They didn't talk about production tips – they talked about the 12 basic principles of animation.

The 12 principles are a philosophical framework. This is what we need for responsive web design.

The Whitney “responsive W” is a great example of a simple formula to produce many iterations: put in the required content, divide the remaining space into four, then draw the W into that.

Gerstner's wordmark grid gave a system to produce text-based logos like intermobel.

“There is always a group of solutions, one of which will be right in the given circumstances.” - (rough wording) Gerstner

We need a design vocabulary to support your design. We need to avoid “rows” and “columns” which are page-centric terms that no longer make sense.

We are dealing with designs that are networks of small layout systems.

Making it fit is the baseline. How can we make them feel at home on different devices and sizes?

Navigation

A common pattern is off-canvas menus that are hidden until invoked. But the overall situation is we still rely on hamburger menus a lot…

☰

Maybe we have a hamburger problem in the industry?

Part of the problem is the hamburger symbol has a meaning – it's the Chinese trigram for “sky”. Is it ok to appropriate that? Things do change over time, perhaps it's ok that a particular symbol takes on a new meaning in context.

But a lot of hamburger menus are introduced with lots of help text and tips – which is a bad sign.

Also while the hamburger menu's icon is simple and clear, the flyout menu can be massive – because we can conceal it, people are often putting too much in there. It's closing the door on the messy cupboard.

Don't avoid the hard stuff – look for opportunities to improve the experience for everyone.

Alternative patterns:

  • progressive reveal – eg. horizontal nav with a “more” to reveal the options that didn't fit in the first load; or a scrollable nav bar
  • adaptive layout – eg. never hide the menu, just move or reformat it appropriately for the current viewport

These layouts can actually be pretty easy to implement without a lot of code… they're an opportunity to be a little lazy.

Animation

Example: a four-dot layout that transitioned between the options and the actions that can be applied to an option. This isn't driven by the animations, this is driven by the content: four radio buttons with cancel and ok buttons.

The first step was to make round versions of the six elements which appear in two rows. With a has-animation check, transitions and layered layout were added. The associated javascript doesn't track or care about layout or position, it just handles the state of the elements.

...

So, wait, aren't we doing more work to be lazy? Maybe but in 2016 a responsive design has to be device agnostic. We have a lot of browsers, some “hostile” browsers that are really hard to work with compared with a desktop (a tiny round watch face..?).

The BBC dev team use a nice test they call “cutting the mustard” (does your browser cut the mustard?). A small amount of inline javascript tests the core features of the browser – and if the browser doesn't cut the mustard, it gets the baseline. It's a “lazy” approach but all browsers get something they can use.

In the beginner's mind there are many possibilities, in the expert's mind there are few. - Shunry Suzuki

Go forth and be lazy.

@beep / @rwd

Dina Gohil & Lucinda Burtt – How we learned to love iterative design at Fairfax

The Fairfax team has been working on a re-architect and re-design of the platform behind publications including the SMH (smh.com.au). SMH has long been a technical leader – one of the first papers to be online in 1995, one of the first major standards-based publications in 2004, in its market committed to the paywall model relatively early. But in the mobile game they were a bit behind the pace, despite this head start.

Major focus of the project: a consistent experience for the transitioning user. They use the SMH a range of ways at different times during the day – on mobile while commuting, desktop while at work, tablet on the couch in the evening.

Project:

  • clear goals
  • constant delivery and iterations
  • cross-functional team
  • make fast decisions together

The project ran for 18 months and the mantras remained in use all the way through:

  • screen agnostic
  • iterative process
  • reuse reuse reuse
  • made for sharing
  • data driven decisions

The team was also having to move away from the old “build multiple” approach of aussie media – that is, not building a new site for each device profile (m sites). The current state was a mobile site and a desktop site.

Those chose an adaptive approach (fits a set of sizes) rather than responsive (fluid, fits any size). Advertising was a key challenge – it's how the business makes money, so they had to accommodate a reasonable set of ad offerings that can be sold; and the ad sizes and shapes define the space left to design. They also needed to really optimise each profile for performance; and adaptive allows deeper optimisation.

Iterative design allowed the team to meet the business requirement of delivering high-value pieces first. This goes against common design approaches of holistic thinking and waterfall workflow (agile dev but waterfall ux and design).

Mandate 1: no wireframes. Instead did the “hour of power” - 60 minutes, 3 people, 1 room. UX + Visual design + dev. The outcome: something that can be tested.

Mandate 2: quick'n'dirty. Do things fast according to design principles (essential, purposeful, useful). Reduce, get out of the way, be useful to readers. Used “style tiles” - fast visual alternatives, low fidelity, fast to create. Almost like simple mood boards of yore.

Mandate 3: screen agnostic. Eventually settled on tablet-first design. Initially fell into the desktop-first trap, then flipped to mobile first… but realised it was tablet that really tested the responsiveness. It was easy to go up and down from tablet.

Mandate 4: feature parity. Solved with lean user testing. Testing with fewer users, more often, with results fed straight into the build. This kept things in harmony over time. Aim for a sense that the new site was “different not difficult”.

Reuse: codenamed “project lego”. The project was creating building blocks that could be used on other properties; and for other properties to add to. Created a UI library.

Users' sharing culture means the article is “the new homepage”. Users arrive on an article page, not the homepage.

Data: used both qual and quantative data; A/B testing; etc. Used data to test intuition and assumptions, validate qualitative insights with quantitative data. Do users really want what they ask for?

Lots of lessons learned – key learnings included belief there will be further iterations (smashing down “there is no phase two” attitude), ditching design perfection (make something that's “right for now” not “perfect”). Lots of cultural considerations inside the organisation and choosing the right battles. Iterate based on what the user needs, have a transparent backlog so nothing was ever hidden – that helped communications.

The iterative process is a collective process. There has to be collaboration, freedom and safety to fail, and doing what's right for the user and not what's right for individuals on the team.

Check it out at beta.smh.com.au

Simon Knox – Incremental responsive design at kogan

Kogan has been around for about ten years and were on “K3”, the third version of the site. They had a separate m-site, which both users and developers hated. Simon decided to have a go at K4...

Goals:

  • feature parity
  • responsive design
  • speeeeeeeeeeed (lots of Es since Simon was stuck on a tethered connection when he wrote it...)

Project codename “F5” - refresh! We're really creative with our naming...

K4 started with an utterly minimal implementation; using React, flexbox, etc. A few weeks in and they hadn't really got far. They basically still had an utterly minimal implementation and they were not set for feature parity. They were recreating a lot of business logic and that was not the point of the project. They also couldn't have a full time designer and dev on the project. The project wasn't going to work.

They decided to throw it out. Stepped back for a few weeks and thought of a new approach.

Next iteration of goals:

  • Responsive – just responsive. No design, no re-architecture, just make it responsive.
  • Consistent style
  • Don't break stuff – you're playing responsive Jenga

Incremental approach:

  • small – now
  • hacks – soon
  • components – later
  • Bonus: theming

Small

Start simple. Crack open dev tools and see what the page structure looks like… and kogan had a fixed width div. 1000px wide. That's not going to work… so fix that one thing.

Changed from

width:1000px

to

width:100%; max-width:1000px

Done! Certified responsive! Couldn't launch it yet, so added

min-width:1000px; //todo: delete when responsive

After this point, start thinking about breakpoints. Just pick something at first; and use smart SCSS to make it maintainable.

Next… add a feature flag to enable the responsive design. A url switch works nicely.

Up to this point Simon had just been doing these things more or less in secret; but now it needed to become something bigger, generally become more open.

Hacks and bad advice

(Simon notes this might not work for you, or for bigger teams… but this is what they found)

They were using float layouts. People say it's a hack… but it works, so they kept using it. Then they started using a bit of flexbox and ran into the flexbugs. Ultimately concluded that CSS itself is a series of hacks. So, use whatever you want. People might say it's a hack, but if it works it works.

Don't use a wrapper class for legacy OR the new code. It increases the specificity for everything and encourages bad code.

If you are desperate for an override, you can chain duplicate classes rather than making new classes or nesting:

.foo.foo.foo {}

This is nasty but it works as an interim solution.

CSS vars – start near the implementation and expand from there. Simon found few vars ever went up from the top of the file to sitewide variables. It also helped minimise the impact of presentationally named variables.

Use the checkbox hack to avoid unnecessary js: link multiple labels to the checkbox and show hide using :checked (test your accessibility works of course!).

Don't worry about big/ugly selectors at first. Get it working, you can optimise speed later.

Don't prevent zoom; but you can use the viewport meta tag as your feature flag.

Compartmentalise

Lock up the legacy:

do-not-add-to-this.css

Inverted nesting pattern:

<!-- HTML -->
div.sale
    div.product

// SASS
.product { 
    .sale & {}
}

You can put media queries inside nesting. Simon notes he's still testing whether this is a really great idea.

Build as much into the shared base as possible and just override the differences.

They have been using CSS Modules; some BEM. Just have a way to resolve CSS clashes.

Themes

They had a $red variable for their brand red. Then they acquired Dick Smith which is very yellow… used a “themify” mixin.

.product {
    @include themify(color,
        $kogan: $red,
        $des: $yellow
    )
}

// kogan.css
.product { color: $red; }

// dse.css
/product { color: $yellow; }

Keep your eyes out for a rethemed Dick Smith!

…

Epilogue: they have turned off their m-site now; and there hasn't been a drop in mobile sales.

@psimyn

Sara Soueidan – SVG + CSS: A Designer's Delight

SVG can be used to extend the capabilities of CSS – the “SVG features” in CSS are simply the primitives.

SVG structuring, grouping and referencing (reusing).

  • <g> groups elements.
  • <defs> defines elements that you want to reuse later. Elements inside defs are not rendered until instantiated.
  • <symbol> combines the benefits of G and DEFS; adding viewbox attribute.
  • <use> instantiates the templates defined in SYMBOL and DEFS.

You can use SVG images as backgrounds and sprites; but it misses some advantages you get when the SVG is used inline/directly.

  • You can use CSS to style SVG elements, noting there are inheritance rules between inline style attributes and external CSS.
  • You can use CSS variables like currentColor or custom properties --primary-color to style elements inside an SVG var(--primary-color)

Details – Styling SVG <use> Content with CSS | Codrops

So SVG for icons, rather than icon fonts…

  • SVG is great for multiple-colour icons, where icon fonts are limited to one colour (not counting some pretty awful layering hacks)
  • Fonts don't always look crisp – text aliasing may not be awesome
  • SVG has lots of extra properties like STROKE
  • Icon fonts have bad fallback issues – if the font doesn't load you get strange characters that don't make sense
  • (lots more arguments in favour of SVG)
  • You can use Grumpicon to generate SVG sprites with nice fallbacks for old IE versions – takes a lot of maintenance problems out of the picture.
  • You can use iconmoon to convert a font out to SVGs

Details – Inline SVG vs Icon Fonts [CAGEMATCH] | CSS-Tricks

There are lots of great CSS effects available:

  • filters
  • background-blend-mode
  • mix-blend-mode

...but what if you need more control?

  • SVG can do per-channel filters – feColorMatrix (see article on A List Apart “Finessing feColorMatrix”)
  • Content clipping. CSS has some basic shapes (circle, ellipse, etc) and clip-path which can accept an SVG clipping path (SVG uses <clipPath> for this, including the ability to clip to text). Some good articles on this including “Sketchy Avatars” on CSS Tricks; and some cool animation demos using SVG clipping.
  • Video clipping – common error is the video disappears when the path is applied. Poor browser support. There is a workaround – you can use SVG clipping inside an SVG which then loads the video in an iframe using foreignObject. It's buggy though – only actually works in IE and EDGE. Look up user “yoksel” on codepen for some great demos.
  • Text shadows – only so much you can do with CSS text-shadow. Not nearly as powerful as Photoshop's various options. There are some neat generators; or you can do what you want in Illustrator (specifically using SVG Filters menu) and export it.
  • Creative text effects like image-filled text (knockout text) – webkit has text-fill-color and background-clip to produce the effect. SVG has wider support; and can apply the effect to actual text. You can even have animated text backgrounds. See posts on codrops.
  • Type lockups – you can create this in Illustrator and export as SVG – remembering to export text as text and not as outlines. The only time you really want to use outlines is for logos.
  • SVGs can be responsive – there are some tips and tricks to embedding them correctly so they resize; need to look up some articles for this. Then you can hide elements of the SVG using media queries. The great thing is SVG media queries are element queries, so you can use breakpoints on the size of the SVG and not the viewport.

Making SVGs Responsive with CSS

@sarasoueidan

Jessica Claire Edwards – Farewell Photoshop: advanced CSS techniques

Jessica works as a Creative Developer – great title!

First off – why? Why use CSS? Well it's fun and it works really well for Jessica's workflow. It also keeps you in the tools that will be used to ship to customers.

CSS properties

  • linear-gradient() mostly takes the direction, angle and colours to produce a gradient. Nice and simple. If you need to tweak this during creative it's easy – just change the code or use a variable.
  • radial-gradient() is much the same, setting a shape and origin. However you can also layer these, eg. to put repeating dots above a background.
  • repeating-radial-gradient() is a little hard to find a real use case for, although it looks psychedelic
  • repeating-linear-gradient() is great for creating stripes; or layer them to create effects like wood panelling
  • blend-mode() example was polka dots over a pic of a cat
  • background-blend-mode: blend-mode
  • mix-blend-mode: blend-mode really great for having an element's background blend into the page background; and can even be used with videos.

Considerations:

  • Browser support for these properties varies a great deal
  • Consistency is not at all guaranteed across devices
  • Accessibility needs to be considered – very easy to lose contrast or make text unreadable
  • mix-blend-mode creates a new stacking context so be careful...

Filters

  • Lots of great options – blur, brightness, hue-rotate
  • Can be chained/combined
  • Has some performance problems, eg. opacity can really thrash rendering
  • drop-shadow() is nice as it can snap to transparent areas in an image
  • hue-rotate is useful because it rotates the colour wheel – so if you need to present a lot of differently-coloured items, you can use one and apply hue-rotate

Much the same considerations as properties – support, a11y, etc.

@jsscclr

Craig Sharkie – vw + vh === v.nice

Together vw, vh, vmin and vmax give us and effective set of viewport units… they are under-utilised. People have been talking about these for quite some time and support is surprisingly good.

If you just use vw and vh, support is 100%.

Contextomy – taking something out of context to change its meaning.

Great minds think alike.

Great minds think alike while fools never differ.

A common place where we do this is browers and browser market share. We often think we know what the market is doing instead of just looking it up. We under-estimate the share of Chrome; over-estimate the share of IE; and so on.

We also forget that IE gave us AJAX, which is the foundation of current development practices. It doesn't matter that there were variations of implementation, we still got good things.

We risk missing the great units we have at our disposal. There are about 30 size units in CSS when you take into account the common ones, relative units, keywords, etc.

Back to viewport.

vh – 1/100th of height of viewport

vw – 1/100th of width of viewport

Without a limit, viewport units will eventually render nothing when the screen reaches zero width or height – in reality things just get too big or small.

To make typography responsive now, we generally just change the px value based on media queries. To do something better, mix fixed and proportionate with calc()

calc(18px + 1vw)

There is a way to calculate this – look up Mike Reithmuller's blog Precise control over responsive typography · MadebyMike. Even better, use a mixin.

Demo: pure css connect-four, chess and responsive graphs.

@twalve

Rachel Simpson – Designing secure experiences

For digital security, the stakes have never been higher. We think of security attacks as being very technical, very sophisticated, but in reality human behaviour is often seen as the weak point.

The question: are users really the weakest link?

We're only human.

Non secure behaviour is not just the domain of less-savvy users or people who just take risks. Consider human factors: memory, attention, cognitive load, previous context.

Passwords – we know they don't work well for users. People struggle to remember their passwords, or re-use passwords. Why are they so hard? Add up the factors: you need to remember the username, the password, recent passwords you've used, policies applied to passwords. It's not just the password itself.

A recent study found American users had an average of 130 user accounts associated with each email address. 130 user accounts per person… that's a lot to remember.

We use passwords that are hard for humans to remember, but easy for computers to guess. - xkcd: Password Strength

While password managers are good, we can't control whether our users will actually make use of one.

Creating a password is challenging – people don't really know what makes a password secure or hard to guess. P@$$w0rd is a terrible password.

Attackers know they can try the common passwords which account for a large percentage of accounts; or breach one account and try that password with the same username or email on other systems.

So what can we do? You can piggyback existing authentication; you can use two-factor authentication; in some cases you can requires biometrics (eg. fingerprints).

Take away 1: Be more flexible – consider options for auth

Attention is focused on the task at hand – people don't really look at the security info in their browser's URL bar

Take away 2: Be timely and meaningful – information should appear when the user needs it; and explain clearly what the implications are (users don't know what SHA-1 is…)

You can alert users to errors but Chrome's huge, red, scary SSL interstitial had a low success rate. 63% of people would click through anyway; particularly as the messages were mixed and the first button was “proceed anyway”. So they redesigned – the only button is “back to safety” and you have to expand “advanced” to get to the clickthrough button. Only 38% of people continue through the new screen.

Take away 3: Offer an opinion. Give the user a clear course of action, particularly if they are not sure.

Phishing… this is a very old scam, but a modern version is the “Nigerian Prince email” scam and all its variants. Many are extremely obvious and it's hard to understand why people still respond; but in 2013 a study showed 23% of people opened the emails and 11% clicked through – which is quite high.

Users do not generally perceive the absence of a warning, they're focused on something else. A great demonstration is the monkey business illusion:

A more sophisticated phishing attack can sneak in under the defences of even the most savvy user - A sobering day | FT Labs.

So what can we do?

Phishing is very hard to counter. Nobody truly has an elegant solution yet. Hopefully someone is going to come up with it soon…

Last take away: know your audience. Try to anticipate what they know, what they are likely to do.

@rilan

Jen Simmons – Real Art Direction on the Web

What is Art Direction anyway? Clearly it's directing… the art… But is it about the brand? Is it about aesthetics? Jen's lightbulb moment was it's part of being in a conversation, with other people; or the world outside your project.

(Great demonstration of the impact of different type setting in Jen's slides – why choose Helvetica? Why not choose Helvetica? What is she trying to say with the slide deck and what suits that message?)

Why was the Apple Watch set in a particular way when that doesn't look like a tech logo? It was being positioned with fashion brands. Association with brands like Hermes, not tech brands.

Apple Watch logo compared with a huge range of fashion brands it is designed to match

A lot of web design still just parrots other things that seem successful – oh that worked for them, let's copy that! Or just thinking it's about making things look pretty.

A lot of design is about conveying an idea. Every choice in the way an article is presented in a magazine goes back to conveying the idea, supporting the story in the copy. But the same article on the web loses all that – it gets dropped into a common layout and it's just not as effective.

Call out: box-sizing:border-box and its impact on web layout (see * { box-sizing: border-box } FTW - Paul Irish)

The prevalence of libraries like Bootstrap has turned layout into a bit of a multiple-choice question – which leads to the parodies like All Websites Look The Same “every website ever! Here's where we talk about how unique we are!”

We need to separate tooling needs from the design process. “Don't learn a flexbox library, learn flexbox!” If you prototype with Bootstrap, you will tend to go with one of their default layouts – it directs you to a particular result.

We don't have to start from scratch – people have been studying layout for well over a century. Print has been experimenting with layout for a very long time now. In print there was an actual cost to whitespace – you had to buy the paper then not use it. But the web is not like that!

Lots of examples at labs.jensimmons.com

Lots of big and little pieces coming in CSS that will allow us to do things we couldn't do before.

  • Initial letter – we haven't been able to do good drop caps easily with decent support. Initial letter lets you specify how many lines of text to match. You can supply two numbers and do raised caps as well.
  • CSS Feature Query - @supports (initial-letter: 4) { // rule using initial-letter: 4 }
  • Viewport units – allows really robust whole-viewport headers (“It's like a splash page, with scrolling!”)
  • Object fit – allows resizing of photos within a size, maintaining aspect ratio. (Great example of reproducing a magazine layout with Grace Hopper's photo staying the same size without squishing the photo)
  • Clip path – everything on the web is a box, but clip path can let you do a non-rectangular shape without a whole lot of code.
  • CSS shapes – this is so common in print layout and we just don't think to do it on the web. Great tip – use Chrome dev tools' “shapes” extension to grab the shape quickly. (“CSS Shapes Editor” from Razvan Caliman)

Big pieces:

  • Flexbox - flexbox tends to think of everything as one big row or column
  • Grid layout – has similar capabilities to flexbox, but has more powerful layout features. It's still a work in progress.
  • Flexbox vs Grid – fundamental difference is that flexbox is still thinking of things flowing through a page; where grid is thinking of fitting content into a grid.
  • Circular screens – with the popularity of smart watches, there is movement to create a circular layout system… which means we can use circles everywhere, don't just think of tiny screens!

The question is what are we going to do with all this? Great example: jazz festival poster. Standard HTML source order can be moved around into a rich design with grid and a float fallback.

So, a process.

  1. organise content – what content are you working with?
  2. create HTML and set the source order – helps understand the content better
  3. sketch ideas for page layout – use whatever tool works to figure out your ideas… but don't get final approval at this phase!
  4. design a custom grid – do a live prototype at this point
  5. apply CSS – write your own layout. With these new tools it is much easier, you don't need to rely on a third party 960px grid!

Remember you don't have to use all the pieces. Use pieces that make sense.

Also don't think the choice is “use it | don't use it”. Use things that don't work in a browser – let things be different in different browsers. The people with old browsers don't know they're missing something nicer, so long as they get the content do they really care? People don't open content in two browsers side by side.

More details and links:

  • jensimmons.com – slides and resources
  • labs.jensimmons.com – examples are also on github
  • Jen's happy for people to get in touch talking about ideas, experiments, problems they're hitting trying to do new layouts

@jensimmons

Peter Wilson – Perfomance: HTTP2 in a 1.5 world

Looking at what the transition to HTTP2 really means for us.

Where are we now…

  • Currently sitting at an average page weight above 2.5megs on desktop and 1.2meg on mobile.
  • The average weight is 2.5 what it was just 2 years ago.
  • Average load time is 15.23 seconds (worse on mobile)

We have damaged the web.

(Amazing demonstration: Peter had us wait out 15.23 seconds “in awkward silence”)

This is not to say we used to have it better. We had bad habits in the past too!

But we know that users get frustrated and go to competitor websites; speed impacts conversion rate for websites that sell things directly. There are plenty of case studies backing this up (Walmart, Yahoo… Amazon would lose an estimated $1.6b by slowing their site down by 1 second).

So what to do: start by measuring your starting point.

  • Google PageSpeed is ok as a metric, but it doesn't have a huge level of insight.
  • WebPageTest gives far more depth of information.
    • Peter highlights three key metrics: start render, render complete, document loaded.
    • Timeline view is really useful as it illustrates the reality – what does it actually look like at certain points?
    • It does give a single-number metric as well

Single metrics tend to encourage clickbait communications – you need to dig deeper to really understand what's going on.

It's useful to understand the differences between HTTP1 and HTTP2.

Demonstration of HTTP1 via command line using telnet. Every asset has to initiate a connection, which is overhead. This creates blockers… 200ms of wasted time, or $30m/year if you're Amazon.

HTTP2 talks mostly scream “everything you know is wrong and all practices are anti-patterns that are considered harmful”! Peter feels those headlines are considered harmful right now...

The stats show about 40% of web traffic is using browsers that don't support HTTP2 yet; while 93% of servers don't support HTTP2 yet (93.4% HTTP1.1). We will get there but we are not there yet.

Demonstration of HTTP2 via command line with SSH, because HTTP2 requires a secure connection. The connection will fall back to HTTP1.1 if the browser can't support 2. The key difference for rendering performance is that multiple assets (CSS, images etc) can be downloaded immediately over one connection. This removes render blocking and other overheads.

Server Push will allow devs to manage this even further, letting the server push content over the persistent connection. (“Nag your system admins to install this.”)

The truth is that HTTP1's best practices can be harmful over HTTP2. Not automatically, not always, but can be. eg. techniques to improve performance in HTTP1 that doesn't help in HTTP2: inline critical path CSS in the <head>. It helps a lot in HTTP1 but it's just making your HTML bigger in HTTP2.

Server push lets you detect http2 and push CSS and JS. A trap here is that doing it via HTTP headers will push these files on every load even though they are now cached. Server push is unsophisticated. Your code cannot query actual cache detection; so we have to set a cookie on the first load so the server can ignore it from then on. There are server packages to manage this, like H20 CASPer (cache aware server push).

So what's a 1.5 or transitional approach? Detect both caching and http2 and serve content accordingly.

Web fonts – they look great but they've had a negative effect on performance. They block rendering and you are reliant on the performance of external font hosts. You get FOUT problems. A better approach for HTTP1 is “font events” (“CSS Font Loading” on caniuse.com).

HTTP2 will lower the chance of fonts slowing down loading time, but not eliminate it – you will still need to consider lazy loading fonts.

HTTP2 offers two great ways to break the web (again). First is to think performance is solved; second is to break everything for the 40% of people who can't use HTTP2.

The new rule is, sadly, “everything you know about performance is now twice as complicated”.

Web Directions Respond: Performance: HTTP2 in a 1.5 world // Speaker Deck

peterwilson.cc

@pwcc

Michael Mifsud – CSS variables: why you should care

Many people are familiar with variables from Sass; but we're also familiar with the limitations and pitfalls, eg. scope implications, they're not live (compile time).

CSS is different; the language has different primitives than Sass. CSS has access to the live DOM.

CSS has had a single variable currentColor for a while – it refers to the most recent value set in the cascade. 99Designs used this to enable a live colour scheme based on source colours picked from content.

As well as variables var(foo), CSS has custom properties --foo:. The double-dash is a namespace for author-custom properties (single-dash is for browsers).

Common pattern which is useful for APIs:

:root {
    --background-colour: #bad455;
}

element {
    background-color: var(--background-color);
}

.elementvariant {
    --background-colour: #fec0ff;
}

It's early days, unexplored territory. No real best practice has emerged. So things will probably get worse before they get better.

JavaScript can access CSS variables. Your CSS can set, say, a media query condition and pass that to JavaScript.

This is not a preprocessor killer – things like Sass have some really rich features that aren't in the spec.

What can you do right now? Read the css-variables spec, get creative, give feedback, vote for the feature in Edge.

@xzyfer

Kevin Yank – CSS Selectors Redux

We have so many options…

  • the core selectors
  • pseudo classes
  • pseudo elements
  • combinators

Lots of niggly issues like needing :blank not :empty, or :user-error not :invalid.

:not() is really powerful, cool trick is :not([class]) which finds any unmodified instance of an element. You can create mutually-exclusive rules that don't compete for specificity.

We under use ~ as well.

But what about really-new stuff?

  • i keyword for case-insensitivity
  • :matches() eg. a:matches(:link, :visited)
  • :placeholder-shown

But this still isn't truly exciting! Why don't we get new stuff? Developers aren't really asking. People are using BEM, frameworks, stuff with lots of classes. Even CSS Modules is just writing lots of classes. This is leading to people abandoning HTML semantics.

In “put a bird on it” from Portlandia, they know just one way to make things pretty so they do it to everything.

We are the “put a class on it” people.

Reference:: Effortless Style by heydon. Talks about prescriptive/axiomatic or unintelligent/intelligent styling.

The over-use of class selectors is impacting the future of CSS. CSS4 had cool stuff:

  • local link pseudo selector
  • Reference combinator /for/

...that just got removed due to “lack of interest”.

Stuff that is still in play:

:has() is a form of parent selector. element:has(.something) ...but there is a caveat – there is a new “profile” known as the static profile; which means you can only use it in JavaScript :(

So we are left to use the Macguyver approach.

This where we get the “lobotomised owl”. * + * {} which is a great base style. You can get the same result with :not()

What if we want to style a table based on their contents? Display table-cell ends up putting text over text.

Read: Quantity Queries for CSS · An A List Apart Article

So… play with the selectors we have; give feedback to CSSWG.

@sentience

Russ Weakley – accessible web components without tears

Starting with 4 painful questions:

  1. Ever navigated your site just with keyboard?
  2. Could you do every action?
  3. Could you always see which element was in focus?
  4. Did the tab order make sense?

The myth of full stack… over the past 5 years there has been a major change in the way frontenders work. A lot of “full stack” developers have forgotten some core principles of the web. Like basic understanding of HTML, CSS, accessibility and progressive enchancement.

Rise of the Stack Overflow Developer means there are people who don't know the why behind many pieces of code. People not knowing why a DIV can't go inside a SPAN.

Assistive technology (AT) is far more than screen readers; but we can cover a great deal more with a relatively small number of tricks.

  • Keyboard-only usage
  • ARIA – roles, state, purpose, properties (allows us to make HTML elements more meaningful for assistive tech)

Dynamic content.

Problem: the AT is not aware that the DOM has updated, so a simple thing like injecting a message is not announced to the user. Solution: aria-live. This also works on things like sortable tables, to announce the fact the table has changed.

aria-live has levels:

  • off: don't announce updates, but announce the change if the user focuses the element again after the update (doesn't mean the content is not announced)
  • polite: waits for the next logical pause in vocalisation, then announces the change
  • assertive: announces the update immediately, will interrupt any other activity. Use very very sparingly. Also – this is not supported very well. Polite is supported better so it's usually the right option.

aria-relevant:

  • gives a hint about what kind of change has occurred
  • additions: nodes added
  • removals: nodes removed
  • text: text added or removed
  • all: announce all (tends to be too verbose)

role=”alert”

  • Has implicit aria-live=”assertive” ...and is also poorly supported

Accessible areas

  • Screen readers have two modes: read (navigate the page as normal), forms (interacts with form elements). Readers switch automatically.
  • Catch – in forms mode, content not directly related to the control may not be announced. A paragraph next to a form input is not announced – you would have to manually switch to read mode to hear it. So many users will read a form twice, once in each mode, just to make sure they're not missing things.
  • Validation gotcha – form control errors aren't announced until after the input has lost focus; and if the error message is not programmatically linked, the user may never hear it. Plus the user may never know the entire form is invalid as focus may stay on the submit button – so nothing's being announced.

Solutions:

  • Programmatically link inputs with labels and errors (use label for to link labels and inputs; and aria-describedby to link inputs and errors)
  • Don't use colour alone to indicate invalid forms
  • Error message should have proximity to the input
  • Error should be informative
  • Send focus to the error-state input, so the user hears the information and can fix it
  • Global error messages should have jump links to error-state inputs (eg. put a list of errors at the top). Use role=alert aria-live=polite and aria-label to describe what's going on.
  • Know your tabindex: -1 means an element won't get focus; 0 means it can be focused without changing the natural tab order (don't use other values)

Modal problems

  • keyboard users can tab out of them while the modal is active and if they are also blind, they have no idea what's happening
  • AT not informed when the modal is triggered; nor what it's for (input information? Is it an error?)
  • Focus sent back to the top of the page when the modal is closed

Modal solutions

  • Ensure the modal is properly hidden when not in use – display:none and aria-hiden=”true”
  • Set initial focus to the actual modal, not the first form input; and set the modal to <div role=”dialog” aria-labelledby=”idofmodallabel”> … then <h2 id=”idofmodallabel”>
  • Prevent people tabbing out of the modal – cycle through the tabable elements
  • Don't intercept keys - allow people to shift-tab, use arrows, etc
  • Esc should close the modal
  • You can add extra description to the submit or cancel buttons to inform them what will happen next – where will they be taken, what happens to the data
  • Don't use “X” as the label of a close button.
  • When the modal closes – focus the relevant element (the trigger element if that is not confusing; or the element that has changed as a result of the modal's actions). Don't focus the top of the page; don't make the AT repeat the original instruction.

Tabs (in-page tabs)

  • No programmatic relationship between the tab control and the tab panel/content – sometimes it's not clear what the content relates to
    • See the code in the demo for the various roles – tab, tabpanel, aria-labelledby
    • See the code in the demo for the various states – aria-selected, aria-hidden, aria-expanded
    • tabindex should be managed as well to prevent people tabbing through the controls (should be arrow)
    • If the tab controls are inside a list, set the LI to role=”presentation” so spurious list information is not announced
  • non-semantic elements used as controls. A SPAN used with click events is not available to keyboard users – you can't focus the element
  • Use TAB&ARROW “straight through pass” pattern.. use tab to get to the tab set; and arrow keys to get to each tab (and immediately show the contents of that tab, so hitting tab takes you to the right content). This mirrors form elements and Operating System usability.
  • If you can't get 100% of this done in the first pass – start with basic keyboard accessibility

Some tips:

  • test keyboard-only navigation
  • check for visible focus
  • test with accessibility checking tools (see slides for links)
  • test with a screen reader – Voiceover on OSX, NVDA on Windows
  • note screen readers work (or don't) differently depending on the browser
  • get an accessibility audit

maxdesign.com.au/jobs/sample-accessibility

@russmaxdesign

Matthew Kairys – Picture Perfect: Designing with responsive images

Smashing Magazine twitter poll in Feb 2016 showed 58% of devs weren't using any responsive image solution.

There are many advantages – particularly in a world where our screens vary from massive desktops to tiny watches. We want to send smaller files to devices on expensive and slow connections. We can do better art direction to suit the experience.

<img> + srcset + sizes

Gives us fixed and fluid-width images.

  • Srcset: comma-separated list of images; the browser chooses which to display. You can also supply a pixel density.
    <img srcset=”filename.png 1.5x, filename2.png 2x” src=”fallback.png” …/>
  • sizes: has a media condition, display size and fallback size… lets you control the finer points of displaying the images (eg. full-bleed for mobile, but put a gutter around the image at higher sizes)

<picture> + <source> + <img>

  • <picture> Acts as a wrapper for specific images and sources, gives focused art direction
  • <source> each instance defines a source image and the appropriate media query to load it
  • <img> nested as a fallback
  • you can use different file types to determine what loads – if a browser can't use a format, it skips that <source> and tries the next. Very common way to load an SVG with a PNG fallback.
  • Browser support: all except IE and opera mini.
  • Alt text from the <img> is used

So what's the catch, other than IE?

  • The actual final code is verbose and complex
  • [aside: CMS support would be a challenge?]
  • Implementation is reasonably straightforward but design process will need to accommodate the extra images

Polyfills

  • Picturefill by Scott Jehl is the go-to polyfill

Good resource for responsive images: Responsive Issues Community Group

Chris Wright – In search of the element query

We understand the media query. It enabled us to adapt our content to lots of devices. But our understanding of the web was very page-oriented and the technology reflected that.

Then we moved on to content-driven breakpoints, trying to let the content drive the layout.

Things started getting really complex – Chris reviewed 50 highly-regarded responsive sites and discovered one with 905 media queries; and the average was over 200 [aside: I missed the exact number].

Now we are in the atomic design era. We think in terms of small units that are combined in many contexts… but we can only do queries about the entire viewport.

Enter the concept of the element query, imagined something like:

.foo:min-width(300px) { // conditional css }

But this creates a potential endless loop – in this example if your conditional CSS makes the element bigger than 300px it will no longer meet the query and won't be applied any more... at which point the query is met and the conditional CSS is reapplied...

So far, the circular dependency/endless loop problem has not been solved. So for now there is no standards-based option.

But people still want things like Molten Leading and adaptive layout. A form needs to be laid out according to the space available to it, not the space in the viewport.

Element Flow – properties which automatically control the way the element is displayed. This is using flexbox tricks.

Container sized source ordering – this can be done using media queries plus flexbox.

display:contents – collapse the element according to content.

Read: Flexbox & the keyboard navigation disconnect – Tink

Container-based responsive tables – see slides for links!

But there is still no real container query… what can we do?

Try experiments; get involved with working groups.

chriswrightdesign.com

@cwrightdesign

Karen McGrane – Adaptive content, context and controversy

The web is its own medium. Not print, not tv. It is defined by its fluidity, its accessibility. You can use all kinds of devices and connections… so long

This is encapsulated in the W3C's One Web philosophy – one documented displayed many ways and places. Responsive design is just the latest round in that story.

There is an opportunity to have one single code base, one team, one pipeline, delivering one responsive site… but so many organisations don't do that. People want “adaptive”, or one of dozens of other “moving beyond responsive...” ideas.

Three strategies come up:

  • responsive – flexible fluid site that reflows continuously at arbitrary sizes; the flexibility occurs in client-side code
  • adaptive – a bit of a catch-all term for “serving something different”; but typified by serving several fixed width layouts at different breakpoints
  • mdot – whole separate site usually served at m-dot-domain-dot-com

These can be compared in terms of URL, content and design:

  Responsive Adaptive M-dot
Same URL? Yes Yes No
Same design? Yes No No
Same content? Yes No No

Karen would like to fix it down and say adaptive is serving something different. The server detects the device and serves accordingly, opposed to responsive where the client differentiates the layout (the server does not).

Responsive is Google's recommended approach for mobile devices.

But there are lots of real-world scenarios where you need to serve a different version of a page – politics of the homepage, for example. Or maybe your A/B testing process can't cope with fully responsive sites.

Perhaps you don't need to serve whole different pages – maybe you just need to serve a different feature. eg. beatport needed to serve a different player. The rest of the site could be responsive but that one feature needed to be adaptive. Fidelity had problems serving large tables and had to serve two versions of the table.

Adjust layout fluidly on the client side. The server doesn't need to get involved.

Adjust content on the server side. display:none is not a content strategy.

COPE: create once, publish everywhere. Each display of the core asset can request a subset of the content. NPR used this for a while; but eventually went responsive.

Model your content more fully. Treat it as something that exists independently of its display. Work out the granularity of content.

Possible guidelines to decide how to serve different content:

  • Device: literally what the device is; and its capabilities (screen size, OS, etc)
  • Context: information gleaned from the device sensors to infer what's going on around the user (location, velocity, sound and temperature)
  • Person: knowing the user directly. Age, gender, life stage, etc.

Targeting devices can be sketchy – if you hide Android information on an iOS device, the iOS device owner can't look up support information for a friend having trouble on their Android.

However you could provide different terminology – eg. on a laptop say “click”, on touch say “tap”, in a car say “select”… a nice idea, but we don't have really reliable ways to detect input.

Ultimately you can't use device to predict what users want. There are too many assumptions and traps. Instead, peoples expectations across devices aren't really that different – generally they're trying to do the same task, just with whatever they have on hand.

Context: time, location, velocity, barometer, temperature… these things still can't tell you when someone's standing in line. They can detect broad context.

Karen's digital hearing aid links to her iphone; and when she's going faster than 10mph it decides she's in a car. It does not, however, know if she's actually riding a bike.

Location targeting can go wrong so easily – offering to translate to a language you don't speak, or serving ads in a language you don't read.

What people are doing is personalisation fan fic… “wouldn't it be cool if...”. Wouldn't it be cool if you knew if the user was pre-, during- or post-purchase in a particular store; and serve a different experience accordingly! ...but do users even want this, even if you can make it work? Do they actually need something different at those points?

Even if you can work out that people use different devices at different times of day, do they want a different experience on those devices?

Data suggests users want the opposite: they want a seamless experience across devices.

The publisher does not get to decide what the user chooses to go online with.

Why go to all the expense and risk of trying to guess what the user wants, when you can ask them? Netflix could do all kinds of time and location tailoring and still get it totally wrong; or the user could choose between two user profiles when you start the app.

Most of the time you're better off serving the same information to all.

Do a great responsive design, you'll get more value than tinkering around trying to guess what users want and serving different things. Even if you go there later, you should start with responsive. Adaptive and responsive solutions work together – they're not competitors. Responsive design will probably solve 95% of your problems; then adaptive might solve that last 5%.

bondartscience.com

@karenmcgrane

fin

With that, Respond was done and it was time to repair to a local establishment for libations and animated conversation. Shout out to the Web Directions crew for another great event; to the speakers for sharing their wisdom; and to the attendees who were such excellent company.

PS. you should grab a copy of Scroll - Web Directions (Re)introducing Scroll Magazine - Web Directions.