decodeuri

Web typography workshop with Rich Rutter

Tue, 25 Sep 2018 00:00:00 +0000

Rich Rutter is a veteran web typography expert. Back in 2004 he proposed the 62.5% font sizing trick which quickly became an established technique to make it easier to reason about using ems when sizing fonts on the web. In 2018 he’s literally written the book on web typography. When I saw this guy was running a workshop at Generate London this year, I had to go! What follows is a lightly edited note-dump to help me remember what I learned.

Frequent references to Bringhurst, probably worth a re-read.

Firefox has the best font support, so for best understanding, try things out in Firefox Developer Edition.

Readability

Relies on the measure, line-height and font-size. If one changes, the other(s) may need to be adjusted to maintain readability.

Bringhurst says convention considers a readable measure to be between 45-75 characters. Assuming 1em is about the width of two characters, 75 characters comes in at about 38em.

Reminder: CSS line height is not leading: space imposed by line-height is distributed equally above and below the text.

For shorter line lengths, line height can be increased slightly, but it’s best to just pick one value that works well enough across the possible widths.

You may need to adjust line-height when using different fonts, test by eye.

Adjust the font size if required, different overall glyph heights and different x-heights will determine what’s required.

The “aspect value” is the ratio of x-height to font size. If two different typefaces are being displayed at such sizes that they have the same aspect value, they are likely to look the same size, even when they’re not. Tool for calculating aspect value: http://clagnut.com/sandbox/font-size-adjust-ex.html.

Will be able to use font-size-adjust for this in the future, but not enough browser support yet.

Reading distance

Different reading contexts often involve different reading distances. For example reading the news on your phone packed in like cattle on a standing-room-only commuter train, you’re likely not to be the same distance from the screen as when you’re reading that fancy online design magazine on yer massive 4k desktop monitor.

Arcminutes are units used to express perceived size: it’s a measure of angle which takes distance into account. As reading distance increases, the physical font size needs to be increased in order to maintain the same perceived size.

Sizecalc can help, it’s “a tool for calculating and visualizing the relationships between viewing distance, physical size, and perceived size”.

Using sizecalc, we can determine that someone reading a book set in 10pt type, holding it a comfortable 40cm from their eyes, perceives the size to be 30 arcminutes. This is about the same as someone reading on phone (apparently). Can’t always rely on devices reporting physical size though. For example the iPad and the iPad mini both report the same size via media queries, even though they are very different physical sizes. [Difference between device pixels and CSS pixels?]

Five arcminutes is about the smallest perceived size of text that we could read.

Can also use sizecalc to determine that the moon at its perigee (221,559 miles), would have to have writing 322 miles high in order to be read from the surface of the earth (even ignoring any atmospherics etc.) Typography in space FTW! :-D

Type size

Set text in rems.

Don’t neglect to set text at display sizes where appropriate, even on smaller screens.

Set type using a scale to ensure a consistent visual hierarchy.

Examples of scales:

ios scale: 32, 24, 19, 16, 13
classic: 36, 24, 18, 16, 14
16/9: 90, 51, 28, 16, 9

modularscale.com is great for exploring possible scales you might use.

Can use the same scale for different screen widths, but miss out some points in the scale on larger screens in order to get the exageration in scale that can work well when a lot of screen space to play with.

Or you can use different scales for different widths. Rich likes to do this so he can focus on the different purposes of the scales which the different widths impose.

Watch out for line height on headings: the large line height often applied to larger headings can often make one heading look like two headings when it wraps. To get around this, set a small line height for the heading, and organise the vertical space above and/or below it with margins.

You can size display text as you would an image, so you can use e.g. vw or vmin units to size the <h1>. Note that elements styled solely with viewport units aren’t zoomable, so use calc, e.g. font-size: calc(13px + 10vw).

Height-based media queries can be really useful: for example don’t necessarily set massive headings unless the height as well as the width is available

Vertical rhythm

Rich sets vertical rhythm using margins, using em units so it can scale appropriately.

Microtypography

use correct punctuation symbols
em dash/en dash
hair/thin/normal space
kerning (on by default these days, w000t!)
treat numbers as ‘letters’ in running text to prevent them standing out and distracting the reader

Numbers

Numerals are either ‘lining’, that are similar in treatment to uppercase letters, or ‘old style’ that reflect the style of lowercase letters. Both of these numerical styles may be set as either tabular (fixed width) or proportional (don’t line up).

Recommended to use lining numerals in headings, and when all caps, otherwise use old style.

Use tabular lining numerals in tables.

If the font supports it, can use font-variant-numeric CSS property to specify which numeric property/properties to use. The fallback for this is font-feature-settings, but this resets everything and really is a spedgehammer/nut situation, and not sure it’s worth it. Might be better to just use font-variant-numeric as a progressive enhancement.

Tables

they should be readable
they should support a sense of the data within so you “can understand it by its shape”.

Recommendations:

left align text
right align numbers
align the column headings to the data they’re heading up
if left/right alignment is not appropriate, align to a decimal point, or another appropriate character [except… this can only be reliably done using text-align: "character" center, but this is in CSS text module level 4, and as such has no browser support as yet].

Allow horizontal scrolling, with e.g.

.tablewrap {
    max-width: 100%
    overflow-x: auto;
}

You could wrap parts of cell heading labels within span which is hidden for very narrow screens (only). e.g.

/* css */
.u-hide-when-tiny {
  display: none;
}

@media screen and (min-width: 480px/*or whatever*/) {
  .u-hide-when-tiny {
  display: inline
  }
}

/* html */
<div>
  D<span class="u-hide-when-tiny">ou</span>bl<span class="u-hide-when-tiny">e</span>
</div>

but you have to be able to predict and control the heading labels in order to use this technique.

Font choice

is it suitable for the text?
does it contain the glyphs you’re likely to need?
does it offer the effects and features that you’re likely to need?
does it have enough weights and styles?
Is the spirit and character of the typeface consistent with its intended usage?

OpenType

One way to turn OpenType features on for a font is by specifying which font-feature-settings are desired. For example font-feature-settings: "swsh" 1; turns on swashes, if they are available in the font. Note that you should only set OpenType features using font-feature-settings if there’s not a supported longhand property associated with the feature you want to use. For example don’t use it to set small caps, to do this you should use font-variant-caps: all-small-caps; instead (see MDN).

To discover what OpenType features are available in a font, use https://wakamaifondue.com/. Incredibly useful resource.

Side note: some font files have embedded Python code to handle the more complex logic required to determine some glyph substitutions.

glyphhanger node module reports what unicode ranges are used on a website, and can provide some subsetting functionality.

Interesting post on creating a subset font with Python.

Variable fonts

Quite new. When I played with them six months ago, they weren’t ready, but now they seem like they’re nearly there.

Subsetting a variable font can cause problems, so don’t for now.

A variable font is a font file which makes many more versions of the same glyph available, for an entire typeface. For example a traditional typeface may offer a selection of weights over several individual font files. A variable font is capable of offering all weights between 1 and 999 in one font file. Weight is just one axis, or dimension, of variation. There are five registered axes:

weight
width
italics
slant
optical-size

controlled using the CSS properties font-weight, font-stretch, font-style and optical-sizing.

There have been calls for more registered axes, but the the registered axes are backed by the OpenType spec and so it depends what happens in that.

You can have non-registered axes in your variable font file.

You can have other axes that affect a subset of the 5 registered axes.

Each axis can be addressed by providing its 4-letter OpenType feature code to font-variation-settings. The convention is to address non-standard axes in uppercase.

In @font-face blocks, font-style, font-stretch and font-weight all default to normal, so you might need to set these explicitly. They take the following respective ranges:

oblique -90 to 90
50% to 200%
1 to 999

They will also take the auto keyword, but that’s not implemented yet.

Variable font spec says you can declare them within @font-face using format(woff2 supports variations), but that’s not implemented yet. The workaround is to include feature queries checking support for an appropriate value of font-variation-settings, and only load the variable font when support is available.

Can use (responsibly) in responsive design: for example could use font-stretch to introduce slight variations across breakpoints.

File compression is good. Can see soon we might be loading one variable font to provide all weights and styles rather than a handult of different font files. Overall performance will be interesting to track.

For more see Rich’s post on using variable fonts.

Font foundries aren’t sure yet how to price variable fonts, which is one reason their availability isn’t as widespread yet as we might have hoped.

Variable font resources:

v-fonts “A simple resource for finding and trying variable fonts”
AxisPraxis “for playing with OpenType Variable Fonts”

General resources:

https://wakamaifondue.com/ Explore which OpenType features are available in a font file
https://fontsinuse.com
https://www.whatfontis.com/
https://typ.io/
https://www.typewolf.com/
http://www.typeroom.eu/
https://www.parachutefonts.com/
https://abookapart.com/products/flexible-typesetting
https://abookapart.com/products/webfont-handbook
https://www.alibris.co.uk/Shaping-Text-Jan-Middendorp/book/25412024

SmashingConf London 2018

Tue, 13 Feb 2018 00:00:00 +0000

Preface

Immediately below are a few key points distilled from my raw notes. Following these is a writeup of my raw notes: they’re an extremely raw, totally unproofed write up of my notes from SmashingConf London 2018. There will be typos, incomplete sentences, fragmentary notes, repetitions, and possibly contradictions. Some of it might be even incomprehensible out of context, (but at least this way you don’t have to try to read my handwriting). I’ll tidy these up over the next few weeks, but most the important thing is to make them available soonest, so here you are.

We can do better.

And we will!

Soon…

Some key points

use Brotli compression
use HTTP/2
You can have impactful images with fewer bytes transferred by degrading the image quality but combining it with a background colour or gradient via mix-blend-mode or filter()
make sure you can remove A/B testing quickly if it causes performance problems
flatten the dependency tree with client hints
consider using font-display with preload client hint as a progressive enhancement to improve font loading UX (for this and alternatives see https://www.zachleat.com/web/comprehensive-webfonts/)
a little care how you construct and manipulate js arrays can take advantage of V8 optimisations
only load the js you need, and delay non-essential scripts
may improve jank by using will-change
use requestAnimationFrame
Chrome User Experience Report provides real user metrics at scale (for Chrome)
Case studies of business cases for demonstrating the impact of web performance optimisation on business metrics are at WPOStats
CSS grid is awesome

Vitaly: New Front-End Adventures in Responsive Design

Smashing: annual drop of 50% revenue; 66% users using ad blockers.

copy docs - method to build a site with a text-first approach.

Maslow for sites (bottom to top): speed > access > scale > style

JAM Stack: JavaScript, API & markup

Otto.de: German retailer uses vertical slicing of responsibilities: e.g. the breadcrumb team.

AirBnB: ‘air/shots’: search engine for style guide that works for both designers and developers. Now extended to use machine learning to recognise their UI patterns

Sketch to React tool: build mock-ups in React & then import into

html-sketch-app
nodeToSketchLayers SymbolMaster

Supernova Studio

define component root sizes in rem, but internal component sizes in em. Usual caution applies. [How might this blow up?]
plot font size against viewport width, and code the curve: for font-size see Mike Reithmueller. Could apply same principle to e.g. line-height

Grid

vw doesn’t take into account the width of the scrollbar.

-start and -end are magic suffixes to grid line names…

Can use for baseline grid - see https://codepen.io/rwdworkshop/pen/qVzyej

Watch out for Edge < 16 implementation: can use @supports (grid-gap: 0) to screen out Edge as it doesn’t support grid-gap

Grid bugs and their amelioration: https://github.com/rachelandrew/gridbugs

cssgridgarden.com

Text

zlib preset quality settings: slow compression, smaller size; faster compression, larger size
could use zopfli: improved gzip: good but slow, backwards compatible
brotli: better compression but slower (decompression speed on client is okay), and not backwards compatible: could use brotli with a gzip fallback. Requires HTTPS.
- speed could be an issue?
- check slides for details

Images

large image with drop shadow: embed jpeg of big image into svg container, that also has embedded withing it a png that contains the dropshadow.
contrast swap technique (but bad for saving image)
could have large, highly compressed image displayed at a small size: file size could be a lot smaller than an smaller image of higher quality (bad for memory)
could blur unimportant bits of an image to reduce file size
try modifying default scan level for progressive jpegs in order to ‘ship fast and show soon’
- mights try mozjpeg or adapt jpeg, or tinyJpeg, or Guetzli
letsenhance.io upscales images with machine learning

Webfonts

can use bulletproof@font-face syntax
can drop eot & opentype if don’t care about IE9 & old Androids

Fonts only downloaded when they’re references in css (after construction of DOM and CSSOM) Flash of invisible text with 3 s timeout in FF & Chrome before displaying fallback, but Safari has no timeout! Native browser API (web font loader)

“Comprehensive guide to font loading strategy”

Critical FOFT

Can store font in ServiceWorker cache.

font-display (optional could be a good bet).

Web fonts often drop out of the HTTP cache because they have a low priority: Facebook 2015 study: 40% of the time, users don’t have the assets in the cache you’d expect. That’s pretty unreliable, so use ServiceWorker cache instead.

Can use unicode-range in @font-face: good for internationalisation: only requests font if the page contains characters from that range. [Could this be automated?]

Variable fonts (see font-variation-settings: can only be targeted with media query and JavaScript (?as opposed to what?). Designers can add custom variable axes, in addition to the preregistered ones): not so much use for latin character sets, but in languages with large character sets, e.g. Japanese, it’s prohibitive to load the bold font weight as well as the regular one, so using variable fonts can help here. Poor browser support, but support is coming. Not many fonts support it yet, but type designers are on it now. font-variation-settings is low level (a la Houdini), and so can override other font settings, e.g. font-weight. Variable fonts are incompatible with parametric fonts. axis-praxis.org

3rd parties

generate request maps for what
requestmap.webperf.tools
WebpageTest black hole endpoint
could return an empty response from ServiceWorker if script doesn’t return in a set amount of time
sandbox property
SafeFrame?
IntersectionObserver: one of the family of Observer APIs. Could investigate ResizeObserver for element query prollyfill?
contain css property

CSS custom properties

@supports (--custom: property)

everything using a variable expression is recalculated when the value is changed
can be scoped: if you put it on the :root then it’s global
the old Intrinsic ratio for videos (2009) can be updated to use css custom properties

Performance

cheap Android phones running Chrome pass all mustard cutting checks but have limited memory & CPU capability.
could try for Device memory API, and fall back to mustard cutting if that doesn’t work
Google suggesting Moto G4 as an average reference phone.
script parsing time vary so much between devices it’s insane.
90% sites sending 1MB js which takes about 4s to even just parse on a Moto G4
(sites only use 40% of the js they’re sent)
takes 5s to get interactive on 3G network with 400ms round trip time with just 170k for everything on critical load path
scout approach to deploying on H/1.1, avoids having to re-download html when assets change
H/2 can have many small files
comparing H/1.1 with H/2: with no packet loss H/2 is (much?) faster, but what about packet loss with H/2? It can bork downloads (~20% US traffic affected by traffic loss).
server push: good for first load, but server will always push them even when they’re in the browser cache (solved by cache-digest: coming, but it’s not ready yet).
still important to package with H/2 in order from dictionary reuse in the compression: e.g. 5-10 bundles
browsers not optimised for this yet, so there can be browser runtime costs of sending many files over H/2.
with H/2, can load individual files instead of inlining critical css
resource hints: rel="prefetch", rel="preconnect", rel="dns-prefetch", rel="preload". preload enables you to set the right resource priority for preloading assets. for fonts you need to specify crossorigin. DO NOT USE the deprecated prerender
can fetch js with preload and then only execute it when you need it.

ServiceWorkers

they try to get html files from network first, then cache
for ‘files’ (assets, I assume), try cache first, then network
in both cases, show offline fallback page if both respective attempts fail.
Google’s ‘workbox’ (? https://developers.google.com/web/tools/workbox/ ?)
pragmatist guide to service worker https://github.com/lyzadanger/pragmatist-service-worker

Phil Hawsksworth: Making Platforms and Processes Promote Performance

Deployment:

version control deployments
Avoid human interventions
Make them atomic
could create a URL for every version ready for circulation stakeholders’ approval
decide when and what to version (= a deployment)
script them
automate them
make it real: actual production deployments, not just to a pseudo-identical staging environment
make it first: work out how you’re going to deploy early in the project process

Look more into

Book: Designing for performance: Laura Hogan
jamstack.org

Rachel Andrew: into the weeds of CSS layout

Mainly grids: not too many notes here as will be attending her workshop.

Grid level 2 Working Draft shipped 6th Feb: includes subgrids!

Sizing is often misunderstood in grid, a la flexbox: “how big is that box?”

Sizes can be fixed (px, % etc), intrinsic (auto, fit-content, min-content, max-content) or flexible (fr)

For grid track sizing:

auto: generally fits without overflow, intrinsically has effect of justify-content: stretch
min-content: uses all soft wraps without breaking out of its container
max-content: no soft wrapping, may overflow
fit-content(x): acts as max-content until it hits with x
fr uses available space

minmax() can set both min and max width for a grid track. 1fr track size is actually shorthand for minmax(auto, 1fr). This may not give equal track sizes if the width of the content under auto rules would be larger than 1fr. If you want to force equal track sizes, risking overflow, use minmax(0, 1fr)

Perf studies indicate that whatever you do with grid, it performs pretty much the same.

[UC Browser has ~30% market share in India.]

[Shapes is ready]

“I’m not here to build shiny things for rich people. I never have been.”

Grid gaps and tracks should be animatable (only implemented in FF atm)

Suggest don’t use progressive enhancement approach for building a grid:

build good document structure
build grid that you want
work out how to give non-implementing clients a good user experience Using this approach means you’re not constrained by the limits of only what was possible before grid

Una Kravets and Martin Splitt: Beyond the basics of image optimisation

@una; @g33konaught

WebP may be lossy or non-lossy (configuration).

Questions for us:

Are our WebPs lossy?

Various optimisers:

mozjpeg
Optipng
img loader for webpack

Lifecycle of an image load:

download image
read header (setup)
decode image
VRAM upload
Composite
Display

jpg compresses in 8x8 pixel blocks. Large areas of block colour compress better when using lossless compression

PNG header: first 4 bytes identifies a png file to the browser

compositing is running shaders with all layers as input (Martin coding shaders in GLS language)

Techniques:

“blur up”: load tiny, scaled up image first to give an impression of the image while the main image loads.
manipulate the colour histogram e.g. make the image greyscale. Put it over a background colour or a gradient background (either of its own element, or of a (pseudo, maybe) element positioned behind it) then apply css filters/mix blend modes etc to the image element so it interacts with the background colour in funky ways to give coloured effects.
When SVG is used as a background image, you can’t affect it directly, but you can affect it with CSS filters.
“contrast swap”: reduce image contrast using linear transform function in an image editor to reduce the image file size, serve image, in CSS apply contrast filter to make up for the contrast removal. Downside is downloading the image gives you the low contrast image version
never use gifs: send video instead

Blend modes are either on or off, but filters are animatable. Blend modes’ hue, saturation, luminosity and colour use the Munsell colour system.

Look into client hints to try to work out what quality image to send.

Andy Davies: “A/B testing, ads and other third party tags”

slideshare.net/andydavies

3rd party: something you have on your page whose infrastructure and code is controlled by someone else.

150 3rd parties in 2011; 5000+ in 2017.

Chrome and Safari decode images on the main thread, so blocking js will block image display.

Retailer removed Bazaar Voice from their site, gained a 4s speed reduction in Android, resulting in 26% increased revenue from that platform

Safari double keys its cache for privacy reasons, which means loading a 3rd party library from a URL on site A means that its cache entry can’t be reused on site B.

Optimizely blocks the critical render path for 2s. So:

only have the experiments that you actually want to run
strip out jQuery if it’s already on the page
use separate tags for staging and production

long task API is coming, but it’s not here yet: https://www.w3.org/TR/longtasks/

Make sure tests are testing the same things in the wild, e.g. if A/B testing images, make sure the images have a comparable file size.

Do A/B testing on the CDN, not on the client. Fastly recognise this.

Make sure you can always turn off A/B testing quickly in an emergency. Recounted one client who was A/B testing login buttons. A/B testing caused a massive slow down, but they couldn’t turn it off without removing the login button from their site entirely. Some 3rd parties (ad providers tealeaf & Oracle were the examples), add a beforeUnload handler: they want to finalise data or whatever before the next page load (they use this event because there’s no guarantee that the unload event will ever fire). This can introduce a 1-2s delay when leaving a page with these ads on.

Double check DevTools waterfall in WebPageTest, as it can be hard to see what’s going on. Example of game.co.uk: during page load, the browser had initiated 61 image requests before requesting the actual page [wtf?]. Couldn’t tell in DevTools, but waterfall chart in webpagetest made it clear.

Average number of network requests sent by one ad is 56! One video ad can use 3s CPU render time.

He’s tried CSP and sub resource integrity to try to control rogue ads, but not had much success.

RUM: Real user metrics rather than lab metrics (New Relic vs WebPageTest).

Tag managers:

too easy to add new tags
but it is easy to remove them, too (technically, if not politically)

Removing tags often political. Best scenarios when all parts of the business are aligned. Have an audit trail for what gets added, devs have permission to remove tags if they’re causing a performance problem. Tag managers can help in controlling load order

For each 3rd party you add, establish the value, and understand the cost.

Zach Leatherman: Web font performance

slate.com accidentally announced that Mitt Romney was running for president when the actual story was that he’d decided not to run for president: this happened because an oblique webfont for the word “not” hadn’t loaded (FOIT).

Browsers often hide content when loading web fonts (FOIT).

Alternative is FOUT: the text appearing in its fallback font until the webfont loads. Much less serious than the old FOUC that we used to get while waiting for CSS to download & be processed.

Over the years, browsers have flipflopped between FOUT and FOIT (now with a 3s timeout at least).

Play with the behaviour at https://www.zachleat.com/foitfout/

FOIT repaints more than FOUT (although you can force a grouped repaint, but it’s not clear from /foitfout what the tradeoffs are here with this)

Don’t use bullet proof font face syntax any more

Only need to use woff and woff2 formats these days

Each webfont has its own independent loading cycle, which means independent FOITs.

Whether and how FOIT / FOUT can be managed using font-display as a progressive enhancement (only Chrome & FF atm): https://developer.mozilla.org/en-US/docs/Web/CSS/@font-face/font-display Note this only changes how things display while loading, it doesn’t affect the load itself.

Browsers use font-synthesis (fake bold/italic), when the real font version is not available. Useful for when fonts are loading, but don’t use this technique once font loading cycle has finished.

faux-pas bookmarklet can identify occurrences of font-synthesis on a page

The browser initiates a web font load when:

CSS has been parsed and @font-face found
a node has been found in the document:
- that has an exact match on font-family
- has content
- if using the @font-face’s unicode-range, content on the node matches

Because it takes inspection of the CSS to determine font(s) to download, the CSSOM can be completed, and render has got far enough along that the “paint text” step has happened before the webfont is available. This is why and when the FOUT/FOIT occurs.

Can use preload with web fonts to reduce the elapsed time to font available; extra powerful when coupled with display-font.

CSS Font Loading module (Editor’s Draft atm) may help in the future, Bram Stein tried to polyfill but it needs access to browser internals that just aren’t available, so he’s instead concentrated on Font Face Observer. It has no FOIT, forces one grouped repaint, and works with third party font hosts.

postcss-foft-classes uses css classes to control font loading. Potentially powerful, but you need to be careful because once the appropriate css class is applied, the font is loaded whether there is any node using it or not.

Checklist:

No invisible text:

use FOUT and font-synthesis
font-display
CSS font loading API

Reflow as little as possible, as soon as possible

group repaints so fewer overall (CSS font loading API; variable fonts)
make font files smaller (woff2, subsets)
trigger downloads sooner (preload)

A comprehensive guide to font loading strategies

Patrick Meenhan: How fast is it?

Runs WebPageTest from his basement!

There are more metrics than we know what to do with, so when selecting one, make sure it’s something that can be used to improve the user experience.

onload is easily gamed: think Twitter’s old client-side rendering.

Metric recommendations

Synthetic: - First (contentful) paint - Speed index - First interactive

Real user measurement: - First (contentful) paint - First interactive

User timing

Pick some representative ‘profiles’:

“My site isn’t that slow”
Chrome User Experience Report (CrUX) effective connection type
GA and RUM connection info
Slow users underrepresented: they do less on your site because your site is slow for them
Median & 99th percentile

Socket connection time is a good proxy for user connection latency

CrUX

https://developers.google.com/web/tools/chrome-user-experience-report/

Real user performance data from Chrome users
Aggregated per origin
Histogram of several metrics:
- First paint
- First contentful paint
- DOM Content Loaded
- Onload
Split by:
- Country
- Effective connection type (2g, 3g, 4g…): describes how good the user’s connection actually is, not what it nominally is
- Device type (phone, tablet, desktop)

[does HTTP/2 use the look ahead pre-parser? Not sure.]

3rd parties break the HTTP/2 prioritisation strategy.

TTFB: if this is long, nothing else matters.

Server response time should measure if the server flushes early, so then can measure total time to deliver both header and full content

onload and fullyloaded events aren’t very useful.

Look into Paint Timing API.

When lazy loading images using IntersectionObserver, delay until first paint, but then load the images in order, don’t wait until the container comes into view: phone networks will otherwise load the images too slowly & the user will notice it’s missing.

[could be clever, loading the next one as its container gets close to the viewport, but is far enough away to allow time for the load to complete on a mobile network?…]

Interactive metrics: first interactive vs consistently interactive. Showing lots before first interactive can be frustrating: you’re showing the user lots of lovely toys they can’t play with yet. Kind of a victim of own success in getting the time to first meaningful paint down so successfully

iPhones have maintained lightening fast rendering: e.g. all JS & CSS [for what site?] downloaded at 3s desktop, 5s iPhone, low end 20s Android.

user timing performance.mark()

Measure real user performance; evaluate that to develop improvements against it, testing using synthetic metrics (e.g. WebPageTest); deploy it and measure how (if) it’s improved real user metrics (RUM).

[WebPageTest: ‘custom metrics’ takes arbitrary js that runs once the page has loaded; ‘inject script’ runs the injected script while the page is loading]

WPO Stats “Case studies and experiments demonstrating the impact of web performance optimization (WPO) on user experience and business metrics.” Can submit to them as well as use their data.

When emulating a less performant client (e.g. phone), make sure you throttle the CPU as well as the connection & using the viewport emulation.

Re memory: you can test on a low-end 512Mb device to make sure things don’t blow up, but apart from that, let memory be the browser’s problem: don’t need to emulate memory.

Speed Index (WebPageTest) vs Perceptual Speed Index (Lighthouse): perceptual speed index penalises when content moves around during loading (think ads, but also cookie popups).

HTTP/2: don’t domain shard any more, serve everything from a single origin.

Umaar Hansa: DevTools

Performance panel: capture screenshots
local overrides: Override tab -> ‘enable local overrides’ -> add local override folder -> network tab (not panel): right click on resource: ‘Save for overrides’. Notice a small purple dot now appears in the tab next to the filename indicating this file now overrides the file from the server. #everythingisawesome!

Render performance

console popup tab (not main tab), ‘…’ -> performance monitor console popup tab (not main tab), ‘…’ -> Rendering provides FPS metre, paint flashing, layer borders and scrolling performance issue indicators console -> enable verbose logging will show best practice violations. audits -> performance audit -> all_the_things!

https://developers.google.com/web/tools/lighthouse/ has lots of best practice info.

Paint indicators

performance.getEntriesByType('paint) gives access to first-paint and first-contentful-paint in Chrome (FF returns empty array).

console popup tab (not main tab), ‘…’ -> Coverage provides real time reports of unused CSS.

Can programmatically access dev tools, so can script API via Puppeteer for automated tests

Best way to know what’s happening in DevTools: read the codebase!

Ilya Grigorik: Mystery speaker

Book: High performance browser networking

How to measure UX on the web?

As per a previous talk: there are many metrics out there, but which ones can you use to meaningfully measure the UX?

Local lab/synthetic metrics can be got from WebPageTest/Lighthouse. Small scale Real User Metrics can be gained from RUM tool used by the site.

Large scale lab/synthetic metrics can be gained from HTTPArchive.

Large scale RUM: Chrome User Experience Report (CrUX): provides UX metrics for how real world chrome users* experience the web

*users who are syncing their browser history without a passphrase.

Processing the data:

anonymize
filter out non-public URLs
filter out low traffic URLs (so users can’t be identified by visits to these)
geocode by country and then by IP address

Two ways of accessing the data:

Big Query: can query per domain
PageSpeed Insights: can query per URL (whether it’s your URL or not)

Network Information API

Ilya’s netinfo-monitor reports network quality, as reported by the Network Information API.

Paint Timing API

Can use CrUX for competitor analysis, vertical benchmarking, monitor macro UX trends.

Can use to calibrate lab tests with real world UX: used in PageSpeed.

[Look into Airdroid]

Chrome user selected data saver routes things via Google proxy to save on bandwidth. Uses HTTP header Save-Data.

WebPageTest vs CrUX Emulated moto 4G Hundreds of different device types 3G throttling Full mix of Ethernet, WiFi, 4G, 3G, 2G… Clean cache (HTTP, memory, network) cache Index page only All pages Deep traces & ‘00’s of metrics Small set of diagnostic metrics

Calibrate your lab against the RUM data for your site.

CrUX:

page load time: 3.4s
1st contentful paint: 1.4s

Looks better than lab metrics (HTTPArchive).

Mathias Bynens: JavaScript Engine internals

Element kinds in V8

The internal type of the things held within an array.

The more specific the elements kinds type, the more efficient the array operations.

As the variation in the types of items held in an array becomes more heterogeneous, the elements kinds type of the array changes. It always changes in the direction specific -> generic, never in the other direction.

For example: if an array has only small integer values, the array has a very specific elements kinds; once floating point numbers are added, the elements kinds becomes more generic, and if you add in some strings, the elements kinds becomes very generic. If the strings and floating point numbers are removed from the array, and only small integers remain, the elements kinds type remains very generic, because these values can never get more specific.

A sparse array is always more generic than its equivalent packed array. This is because when trying to identify the type of an undefined element in a sparse array, JavaScript has to look all the way up the prototype chain before it can be sure it’s undefined, and prototype chain lookup is expensive.

The same lookup happens when addressing an array element that’s out of bounds, whether in a packed or a sparse array, so don’t do that!

Try to avoid transitioning elements kinds. This has an effect on the array methods (except find and findIndex, that are more expensive anyway [why?]).

Use for of: this works with NodeLists as well as arrays, huzzah!

Try to avoid having arrays containing -0, NaN and Infinity [also -Infinity?], because they cause elements kinds to transition downwards (more generic).

Use (...args) rest syntax for getting args into a proper array rather than the old arguments array-like structure.

d8 is a REPL for v8. See https://www.dropbox.com/s/h24711w7q5z5vfn/2018-02-08%2010.53.01.jpg?dl=0 for slide of how to run it (Note %-prefixed items are not valid js names and so are deliberately used for V8 internals so they don’t accidentally get exposed.)

Array constructor preallocated space, which might be more efficient when dealing with e.g. 9000+ elements, but the array it creates is sparse, so bear in mind what happens when trying to read from an unpopulated index. Alternatively, create the array using a primitive, and push to it. Good for allocating 16 elements at a time, but may be slower than using the array constructor for large arrays.

Basically you’re either optimising array creation, or future array operations: you pays your money, you takes your choice.

Arrays use Copy On Wrote (COW): if you have 10 copies of the same array, it’s only stored once, and all 10 references point to the same thing initially. Only when one of the 10 is modified is the array then copied and changed accordingly and the reference to the modified array is updated to point to the new (modified) copy. It’s a memory optimisation thing.

Coming in ES2018: big ints, regex improvements.

Katie Hempenious: Improving page performance in modern web apps

Hardware and networks constrain performance: “you can’t escape physics”.

Hardware constrains computationally expensive tasks, e.g. a radial gradient compared to solid colour.

JavaScript code volume has a large impact on performance: parse/compile/execute, so remove unnecessary JavaScript.

Strategies:

remove unnecessary js
delay loading non-critical js
use another tool/context

Remove unnecessary js

Only use transpiled code where necessary (80% of browsers support ES2015).

Use minifiers and optimisers. This can have tradeoffs: better compression may require more CPU/upfront work/possible side effects. Can reserve more aggressive optimisations for static resources that can be cached. Find the sweet spot between compression size and time.

Tree-shaking (webpack, rollup etc.), made possible because ES2015 modules are static rather than dynamic. This is why exports are always top level.

Webpack: typically used for frameworks: “static module bundler for modern JavaScript applications”. Features tree shaking; code splitting; hot module replacement and import of static assets.

Rollup: typically used for libraries (e.g. used by React, Vue, Ember, D3, etc…). Features tree shaking only i.e. generates a smaller bundle, but lacks many of Webpack’s features.

Tree shaking removes only unused exports, only supports 2015 modules; it may include more code than necessary (it defaults to safe i.e. includes the code if it’s not sure). Remove unused code yourself, because it’s hard to do automatically via static analysis because JavaScript is loosely typed.

Delay js load

Defer non-essential scripts: prefer defer over async: defer executes when the parser finishes parsing the document [ordering vs async?].

Use code-splitting and lazy-loading: it reduces js that needs to be parsed at startup, and reduces load of irrelevant code.

Code splitting:

1 application, 1 script: good compression, poor caching, poor granularity
1 module, 1 script: poor compression, good caching, good granularity
Goldilocks: bundles. The trick is to identify the level of granularity that works for you

Use another tool or context

Netflix reduced the Time To Interactive on their login page by 50% when they replaced React with vanilla js. The remainder of the app loads in the background while the user logs in.

Moving things from the client to the server gives you less variation of metrics, and the server’s completely under your control.

Bandwidth vs latency

Increasing bandwidth has diminishing returns, bandwidth is sufficient in many markets. Average bandwidths by country (with corresponding bandwidth-only theoretical minimum load time of average sized 3.5Mbps web page, ignoring all latency):

UK: 26Mbps (0.13s)
Japan: 22Mbps (0.16s)
USA: 12Mbps (0.21s)
Brazil, Russia: 9Mbps (0.39s)
Indonesia: 5Mbps (0.70s)
India, Pakistan, Nigeria: 4Mbps (0.88s)

But latency is strongly correlated with performance:

5G (spec): <= 4ms
4G: <100ms
3G: 100-500ms
2G: 300-1000ms

Sending more data is usually less expensive than setting up another connection [didn’t mention HTTP/2]. Fewer requests is better when latency is high, smaller file size is better when bandwidth is constrained.

With HTTP/1.1 it takes 1-3 server round trips to download a tiny resource. TCP slow start limits the amount of data that can be sent at the beginning of a connection.

Use caching: ideally determining freshness should not require a network request: use content-addressed URIs (e.g. logo[hash].jpg, not logo.jpg), in conjunction with max-age: [very large number]. Facebook quoted as saying this technique saved them 60% of requests.

When BBC switched to ServiceWorkers they saw a 40% speed increase for high latency networks, and a 0-2% decrease in speed on high latency networks. It’s speculated that the performance drop on a low latency network was to do with the TLS handshake as HTTP/2 forces TLS.

Resource prioritisation

Browsers prioritise loading of assets depending on whether they’re likely to be useful, and whether they’re render blocking:

Very high: Main resource (HTML); CSS (applicable media type)
High: JavaScript (synchronous)
Medium: JavaScript (synchronous); Images (in-viewport)
Low: JavaScript (async; deferred); Images (out-of-viewport)
Very low: CSS (non-applicable media type)

dns-prefetch

preconnect

preload for current navigation (has priority of the resource type being fetched) (very recent browser versions)

prefetch for next navigation (has the lowest possible priority) (not Safari)

Consider a progressive enhancement (support not universal)

(prerender and rel=”subresource” are deprecated).

Ideal candidates for HTTP/2 push: critical resources that are used immediately, and that previously would have been inlined. It’s the quickest way to get resources to the browser, but weigh against that the lack of caching, pushing on subsequent page loads, and that it’s new tech (so may experience some wrinkles when using in anger). [Yoav talks more about this.]

Use brotli for compression. Compared to gzip, you get a better compression ratio, so larger files will see a proportionally better improvement; faster decompression; range of compression speeds (but note that when selecting high compression it can be slower than gzip, use different levels of compression, and so speed of compression, depending on whether the item compressed is a static asset or dynamically generated at page request time).

LinkedIn observed 20-30% reduction in file size vs gzip; Dropbox saw 20%.

Implementing: enable it on server/CDN; no client config required: clients include br in “Accept-Encoding” header if they can handle it; needs TLS; no issue if client doesn’t support it; supported in all major browsers.

Yoav Weiss: Resource loading: past, present and future

time != bytes/bandwidth because of latency. Connection to server is inherently latency-bound.

Six areas that affect performance:

handshake
TCP slow start
resource discovery
head of line problem
contention
bloat

TCP slow start: initial response is 10 packets which is equivalent to 14kb, response rate scales up exponentially from there when no packet loss. Try to get as much critical render stuff in the first 14k. [Does TCP slow start still apply with HTTP/2? Presumably, but can’t get resource on it].

Browser ideal would be a flat dependency tree, but humans write deep, creating a deep dependency tree.

HTTP/1.1 tries to avoid contention issues by delaying requests for low priority resources.

HTTP/2

HTTP/2 helps sending the request, but can’t help with the server response: now download is bandwidth-bound, not latency bound.

HTTP/2 server’s job is to send resources in correct prioritisation order, and is not very responsive to priority changes.

HTTP/2 packet loss effectively reintroduces HTTP/1.1’s head of line problem, as the stream will stall until the missing TCP packet is resent.

Critical rendering path: resource loading

The network imposes latency-, bandwidth-, and 3g/4g architecture constraints. Once things have begun to load it goes like this:

dl html, discover css asap with look ahead pre-parser.
HTML -> DOM; CSS -> CSSOM; dl JavaScript
combine DOM/CSSOM/results of JavaScript execution into the render tree
layout
paint
composite

Priority: HTML > CSS > JavaScript > Fonts > Images

Cross resource compression (crossing the advantages of more bytes for greater compression with that of independent resources).

“Web packaging” treats each file in a bundle separately, but they can be cached together.

HTTP/2 compression dictionaries look promising, but there are security concerns.

QUIC stack replaces TCP/TLS layer with the new QUIC protocol implemented in user space https://www.chromium.org/quic

QUIC handles packet loss differently: rather than stalling all streams, it only stalls the stream that’s lost the packet.

QUIC is released in 6-week cycles and has not stabilised, the IETF are involved, but it’s not ready for prime time yet (hopefully end of 2018).

Early flushing isn’t always a good thing: for example, what happens if a database call fails, and you need to send a separate page, but you’ve already flushed the header of the page you were expecting to load before the db call failed? Its’ tricky.

HTTP/2 push: server doesn’t know what’s currently in the browser cache. Can lead to a lot of unnecessary pushing. Could be solved by new proposals e.g. cache-digests.

Can flatten the dependency tree with preload: the resource priority depends on the value of the as attribute. But as is coarse, for example can’t specify async or defer. Currently working on priority hints.

preconnect hints for non-navigation requests to set up the connection early.

connection coalescing: TCP fast open + TLS 1.3 QUIC & IETF QUIC Alt-Svc over DNS [?]

To reduce the effect of TCP slow start and contention, reduce the number of connections, and unshard your domains.

“secondary certificates”: load only what you need.

Brotli.

Coming: compression API for browsers: compress data before sending it to the server. Respectful of the user, useful for RUM data & much more.

Summary:

HTTP/2
push, preload, preconnect
unshard domains, coalesce
load only what you need
Brotli
Future!

Future: device memory client hint + JavaScript API to try to identify low spec devices in order to send less code & smaller images.

He’s writing a book on resource loading.

Emily Hayman: Hitting 60 fps every time

@eehayman Works at Algolia (search company)

“Performant page load is just the prologue.”

60 fps means one frame every 16.7ms.

Beware of more frames: more frames means more processing which could lead to dropped frames and jank.

Page render steps:

calculate layout: happens on the CPU; calculates the page geometry; highly interdependent; recalculating layout is expensive
paint: happens on the CPU; calculation of visual styles; repaints only occur once per frame; repaints are expensive
composite: happens on the GPU; separates out compositor layers; allows for non-destructive changes i.e. no recalculation of layout nor repainting required.

Ideally, only change properties that trigger recompositing: transformations and opacity and that’s it!

Can manually promote elements to their own compositing layer using the CSS property will-change. Do this for things that are paint-expensive, fixed position and overflow scroll.

will-change values:

auto: behave as normal, don’t do anything special
scroll-position: element expected to animate or change its scroll position in the near future.
contents: elements contents expected to animate or change in the near future.
[css-property name]: indicates the property with the provided name is expected to change in the near future
[directions]:

https://developer.mozilla.org/en-US/docs/Web/CSS/will-change

[MDN says not to Use will-change to fix performance problems, not to prematurely optimise.]

Too much of this gets resource intensive, so only use it when you need to.

CSS animations: browser knows the end point of an animation so it can be optimised. CSS animations happen off the main thread so tend to generally be performant.

Also see Web Animations API.

JavaScript animations are more finely tuned, and are capable of being made more responsive to the user; it runs on the main thread so risks dropping frames. If need to use JavaScript animation, use RequestAnimationFrame.

To help prevent scroll jank, use passive event listeners where appropriate: https://developers.google.com/web/updates/2016/06/passive-event-listeners

IntersectionObserver.

Avoid layout thrashing: read from the DOM and then write to the DOM, don’t try to do both at once.

CSS containment: indicates an element subtree is independent from the rest of the document, it tells the browser it’s safe to optimise the element.

test in DevTools: more tools -> rendering -> performance -> timeline.

Allison McKnight: “Building performance for the long term”

Was on Etsy’s performance team with Lara Hogan.

WebPageTest

WPOStats

Bring performance RUM into daily understanding.

Consider factoring in performance data tracking into A/B testing. Etsy build ‘Sonic’ to report on how deployments change performance, using RUM with A/B testing.

Internal Chrome extension for developers to run WebPageTest. Nice!

Always evolve your metrics gathering and analysis: start with the most meaningful and take it from there. Iterate on how you integrate performance into workflows. Maintain expertise in performance. Celebrate performance!

Use histograms and percentiles rather than averages.

Jake Archibald: “In the loop”

requestAnimationFrame (rAF) happens before calculating style and performing layout and paint in Chrome & FF. Edge & Safari make rAF happen after layout and paint, but this is a bug.

Compositor thread runs composition.

MutationObserver (& other Observers) creates microtasks. Microtasks run when JavaScript finishes executing something. Promises also result in microtasks, so the promise callback will be at the bottom of the js callstack. Once the microtask queue begins to empty, it empties before any other JavaScript runs. Microtasks only run when the JavaScript stack is empty.

Same domain iframes are on the same event loop as the main window.

Cross domain iframes can’t be on the same event loop.

When opening a page with target=”_blank” on the same domain, the new window has access to the parent window via window.opener. Use rel="noopener" on all external links.

CSS layouts: Rachel Andrew

Original examples which I’ve then gone on to fork are at https://cssgrid.me/smashinglondon2018

multicol

multi-column layout reasonable fallback for grid in some cases.

but multicol fragmentation: e.g. cards can break between image and following text

break-before, break-inside can be used to mitigate. E.g. can force no breaks after a heading.

fragmentation a particular problem with printing layouts involving multi-col, grid & flexbox: use something else in a print stylesheet!

e.g. use case: long sets of checkboxes

use vertical media queries and use multicol within, in order to stop scrolling being required in a multicol environment

gap property in grid and multicol is the same (coming to flexbox later, too)

A lot of users of multicol are publishers: ebooks. CSS WG for multi-col is ~50% publishers using CSS to print books

Flexbox

Flexbox or grid? If you’re putting widths on your flex items, you should probably be using grid.

flexbox’s not wrapping by default is in sympathy with its single-dimensional nature.

alignment started in flexbox level 1 (current level); later all alignment stuff (and gaps) put into box-alignment spec - look here for now on for flexbox alignment (updates to box-alignment won’t be ported back into flexbox); grid uses box-alignment and gaps from box-alignment spec.

align items sets as a group each flex item’s align-self property.

auto never means default. Often ‘interesting’, and often not the initial value (that you might think). Make sure you know what it does.

MDN docs often updated by spec authors and browser engineers.

justify-content, not justify-items because you can’t justify one item, you have to justify a group ie the content of the flex container space-evenly (new? support?), gives an even measure on the 2 outsides, whereas space-around gives a half measure on the outsides.

Grid probably fewer bugs in supporting browsers than flexbox, because grid happened all at once.

[No one uses things between browser flags, Chrome origin trials: can opt your site into trialing new tech. Experiment to get devs using stuff safely, early & so to provide feedback.

Browser vendors don’t want to look bad, so they’re all keen to solve interoperability problems.]

align-content acts on the group of flex items as a whole (a la justify-content) when you have wrapping items and there is space in the flex container. This is not the same as align-items, which works on individual items within the container.

Bear in mind not just order, but also direction imposes a visual-only change in order wrt the DOM. Don’t do this with things that have logical order. Probably okay with other stuff. This also changes the order in which items are painted, which may or may not be desirable.

flex-basis: auto - if width on an item, it’ll use that as the flex-basis: careful, this can catch you out! : content - the width of the content of the item(?) [less browser support] : 0 will mean all pixels will be distributed per grow/shrink factors

can play with flex-basis to build components that don’t need media queries.

flex-grow/shrink: factor affecting distribution of available space.

A high flex-shrink value will make it get smaller, faster, than those with a larger number, but the browser won’t let the element disappear altogether, even if mathematically it should.

Shorthand: flex-flow: [direction] [wrapping]

flex: initial - default - can shrink but they don’t grow == flex: 0 1 auto

flex: auto == flex 1 1 auto

flex: none == flex 0 0 auto

flex: 1 == flex 1 1 0

flex: 2 == flex 2 1 0

Remember auto margins can be used to split items within a justified content block. An auto margin (everywhere, not just flexbox), use all available space it has access to, so putting it on one side forces it to the other side.

Once things grow they will take up all available space so wont be able to use e.g. justify content, so if you want space between items, either apply a margin to the items, or constrain the widths (but if you’re constraining widths, should you be using grid instead?… (see above)).

flexbugs

Grid layout

https://www.w3.org/TR/css-grid-1/ https://www.w3.org/TR/css-grid-2/

Spec from IE team (IE10 & 11, can be used as a fallback. It’s very solid. ). Been around for ages but didn’t get very far for ages (b/c perf?).

Bloomberg paid for the implementation for Blink and Webkit(?), implemented by a third party. Then FF did it, and Edge have moved from old MS grid to current W3C grid.

Stable in current browsers (more so than flexbox).

No subgrids yet.

display: grid;
grid-template-columns: 150px 150px 300px;

auto fills the tracks with content

grid-gap is shorthand for grid-row-gap & grid-column-gap. Will be transitioning to names row-gap and column-gap for better reuse. But mapping to new names from old will occur so won’t break.

explicit grid: you define the grid template implicit grid: content just slots it, you don’t specify all rows/columns for each piece of content rows/columns autosize

grid-auto-rows/columns sets the size of the row/column. auto works the same as flex-basis.

% & length units work the same in grid/fb

fr unit shares out the available space, not all the space (so not %).

with grid, you apply things to the grid container, whereas with flexbox, the individual items broadly determine the spacing

grid-template-columns etc define a ‘track listing’. Can use e.g. repeat(3, 1fr);

minmax()-assigned row/column sizing prevents overflow if more contents than expected.

grid-template-columns: repeat(auto-fill, minmax(200px, 1fr)); auto-fill leaves spaces for missing tracks at the end auto-fit takes up all available space

Unless you position things, grid will put content in the next available place on the grid

No way to add rules, or colour cells in the grid spec per se. You need to do this via HTML. It may come via pseudoelements, but not yet.

FF devtools good for layout (Chrome DevTools for performance).

grid-auto-flow: dense; backfills and may move things out of order. Do not use if the grid contains things with a logical order (but if just, say, a wall of images, then that’s okay). Looks a bit like masonry, but it’s not (masonry is awful for performance).

placement: grids are 1-indexed. can specify order with negative numbers for explicit but not implicit grid. default is 1

grid-column: 1 / 3 is short for:

grid-column-start: 1
grid-column-end: 3

Placement targets the lines, not the tracks themselves, remember, e.g. a 3 track grid has 4 lines (see dev tools).

Can name lines on the grid with strings in square brackets.

lines can be named anything

lines can have multiple names

you can use any of a line’s names to address it.

If you want to line up grid components to line up with older %-based-laid-out components you can use %, probably the only good reason to though.

Grid template areas: create a template and place things into it. Need to define a name for things on the grid with grid-area populated via grid-template-areas overall shape of area needs to be rectangular. Each of the areas will yield line names e.g. ‘sidebar’ area will yield lines named ‘sidebar-start’ and ‘sidebar-end’. A line may have several names, derived from the area names.

grid areas are assigned without quotes, but references from grid-area-template within quotes. grid-template-area has one string per ‘row’

You could overdo it tho’.

Looks like this could be v useful in small ways, but need to take a lot of care reordering things so that they’re not inaccessible.

Remember 1fr distributes available space, so doesn’t guarantee equal sizes. If you need equal sizes, use minmax(0, 1fr)

“I’ve seen some people who don’t understand how float based grid systems work because they’ve learned their css from Bootstrap” :-O

Some browsers have clamped the max grid size to 1000 tracks, but there doesn’t seem to be a performance reason to do this, so they remove that restriction. The spec leaves this as an implementation detail.

Use grid for small, component use cases: doesn’t need to just be at page-level.

Sizing, e.g. minmax() CSS intrinsic (the size its content makes it) & extrinsic (developer-specified size) sizing specification spec. For intrinsic track sizing, browser uses these to calculate sizes, they are also available to developers to use directly: - min-content: track gets as small as it can, with softwrap & no oveflow (largest thing in the track sets the minimum size) - max-content: may cause overflow - fit-content([width]): acts like max content until it gets to [width] Very useful - auto: by default it stretches (so if you don’t want it to stretch, need to set justify-items to start, for example.)

Should get these sizing keywords into flex-basis at some point.

box alignment: start/end rather than flex-start/-end for both justify-content, align-content everything stretches with stretch, except if things have an intrinsic aspect ratio like images, videos and form elements(!). FF grid inspector is really useful for grokking what’s going on here. Try it out and play. align-self and justify-self (like flexbox).

vertical % on gaps and on padding/margin of flexbox and grid: spec allows for ambiguity: different browsers implement it in different ways; spec will be changed, but for now don’t use % on vertical spacing and gaps, will probably give you 0 in FF.

Browser support Not supported by:

UC browser (based on old version of Chrome)
other non-western mobile browsers i.e. some current browsers, it’s not just old browsers

IE10-11 has -ms-prefixed old IE style grid. No new vendor prefixes.

Spec includes what happens to old css when turned into flex items/grid items which helps us tweak code for fallbacks, but without having to build 2 separate layouts.

[Can use autoprefixer on CodePen.]

float/clear applied to an element that also becomes a grid item is ignored (like in flexbox).

could use display: inline-block as a fallback. Can use vertical-align. Both are ignored when it’s a grid item.

spec says things are “blockified” before becoming grid items (i.e. no longer inline).

fallback display: table-cell Can use vertical-align. Both are ignored when it’s a grid item. When it becomes a grid item, also throws away the anonymous boxes associated with table-cell.

fallback to multicol: multicol stuff is ignored when element becomes a grid item.

So for fallbacks, this mainly leaves widths and whitespace: can use feature queries.

can have multiple clauses in a feature query:

@supports ( (display: flex) and (display: grid) ) {
  ...
}

Beware checking for lack of support, otherwise may not get the result you expect as feature queries not supported in any IE.

Can reset width in a feature query for a grid item (or anything else), with width: auto

Can set <table> as a grid and make it more responsive. Will probably need subgrids to be really effective, but that could be great for us! (Level 2 is mainly subgrids.)

Coming in later levels of the grid spec: aspect ratio stuff: now there are 2 dimensions, these things start to matter.

display: contents removes everything to do with box generation for its element, replacing it with those of its children. Still exists, just some properties are removed. Useful when semantically important but graphically null elements are used: e.g. a <ul> or <fieldset>. This gets over some of the problems with flexbox and grid only acting on immediate children: you can effectively remove elements wrt style to make a grandchild part of a grid or flex layout.

A block formatting context (BFC) contains floats, and can be thought of as a mini-layout. Can generate it with overflow: auto or hidden in order to force creation of a BFC. But should you? Probably not. Instead, new: display: flow-root: all this does is create a new block formatting context.

CSS Exclusions. Removed from CSS shapes. Implemented in IE and Edge: -ms-wrap-flow: both. It allows text to span across an image:

word1 word2 ---- word3 word4
word5 word6 | I |word7 word8

Building a pattern library for scholarly publishing

Fri, 17 Nov 2017 10:00:00 +0000

Describes building a pattern library implementing a design system for an open access science journal. The approach taken makes both the design system and the pattern library codebase highly flexible and maintainable. Part 1 of probably 2.

Introduction
Deciding on an approach
Deciding on a process
Build
Where is it tho’?
Lessons learned
In conclusion

Introduction

I recently had the privilege of being involved in the ground-up rebuild of an online science journal. The whole stack was rebuilt from scratch using a microservices approach. The journal is building a reputation for innovation in science publishing, and it was a great opportunity to get involved in a green field project to build best web practice into this arena. In this post I’ll be focusing on how we built the front end. A companion post is planned about how we integrated the pattern library into the site.

Note that the code examples have been simplified for clarity.

Deciding on an approach

Design systems and Atomic Design

During the design phase, I had many constructive conversations with the designer, including prototyping some ideas to help decide on an overall approach to various things. He decided we needed a design system in order to retain both flexibility and design coherence not only for the initial build, but for what we might want to create in the future.

Building a design system requires a modular, hierarchical approach, and this approach is well supported by using a pattern library. Brad Frost’s Atomic Design principles are a natural fit with the designer’s concept for the design system, and so we chose Atomic Design as the mental model for our new site design.

Atomic Design considers reusable, composable design patterns in a hierarchy described in terms of atoms, molecules, and organisms. An atom is the smallest unit of the design system, for example a button or a link. A more complex molecule pattern may be composed by assembling a collection of atom-level patterns, for example a teaser within a listing. An organism is more complex again and may comprise a number of included atoms and molecules. We discovered that it’s not really worth trying to impose a strict hierarchy to distinguish molecules from organisms. Whilst trying generally to maintain the distinction that organisms are a higher-order pattern than molecules, it’s okay for molecules to contain other molecules as well as atoms, and for organisms to contain organisms as well as lower-order patterns. With only 3 hierarchy levels to play with, we found we got most benefit from a pragmatic interpretation of the Atomic Design hierarchy.

PatternLab

Having decided on Atomic Design, we chose Brad Frost’s PatternLab as the natural tool to deliver it. PatternLab uses mustache templating and provides a web interface to display the patterns next to the markup that defines them, along with any optional annotations you may wish to supply. Since we started the project, other pattern library candidates have appeared that may have served just as well, for example Fractal, but they weren’t available then; PatternLab was the the best available tool at the time, and it has served us well.

Useful abilities of PatternLab include:

Can view the template code and the compiled HTML next to its pattern.
Can annotate a pattern with style-guide level information.
Pattern search.
Option to view any PatternLab page without the PatternLab UI in case it’s getting in the way.
Can break down Atomic Design levels to group patterns of a particular type within a level. This can make it easier to track down a pattern on the file system; for example, the molecules patterns might be grouped like this:

molecules
├── general
│   ├── ...
│   └── ... 
├── navigation
│   ├── ...
│   └── ... 
└── teasers
    ├── ...
    └── ...  

The display can be restricted to show any level of pattern grouping, and only that level e.g. just the atoms or just the navigation molecules (see above diagram). This is useful when trying to see how different patterns within a group behave at breakpoints, to iron out inconsistencies.
Set the effective viewport width in px or ems to see how patterns behave in that situation.
More general one-click buttons to set a general viewport width.
DISCO MODE! i.e. constant automatic changing of the viewport to random widths to see what breaks (music not included).

It also has template- and page-level composition. This enables you to build up sample pages, illustrating how the patterns might work together. From a technical perspective this is very useful for checking things such as a baseline grid, that can’t be properly set on a pattern in isolation without observing it in a higher-level context. It’s also great for stakeholders’ engagement too! It can sometimes be difficult to communicate the value of a modular build approach to people who are used to thinking of the web in terms of pages not patterns. Being able to mock up a page with real patterns in can help with this.

Principles

Before starting work, we agreed a set of principles that would guide our approach to decision-making along the way.

Don’t lock out the readers

Progressively enhance: a reader could be on any platform anywhere in the world. It’s vital that the content (mainly results of scientific research) and core functionality be available to everyone, regardless of platform, so we couldn’t mandate a high technological baseline in order to read the journal. For this reason, and to be a good web citizen generally, we would use a progessive enhancement approach to ensure that JavaScript is not required to use the site: you get an enhanced experience if it’s available, but content and core functionality does not require it.
Make it responsive: it should be a given these days, but it’s worth mentioning anyway that the website should be responsive, so it will display appropriately, whatever the size of the users’ screens.
Make it performant: no one likes waiting for a web page to load and, if it takes too long, users will bail. If a user is on a narrow bandwidth or a high-latency connection, then any performance problems are exacerbated. Data costs vary across the world, and we don’t want it to cost more in data charges than necessary to read our content. Performance was considered throughout the build, using ideas of a performance budget, techniques such as responsive images, allowing for the HTTP/2 serving of smaller resources, and not using a library unless we needed it.
Make it accessible: it’s vital that our site content is accessible to all to read and use.

Maintain the value of the pattern library

One of the aims of a pattern library is to be the canonical source of truth for the design and front end implementation of the design patterns. This is the case at launch, but it’s common for the value of a pattern library to drop dramatically over time if it’s not easy to update, or it’s difficult to do so in a way that maintains the value of the underlying design system.

After launch, pattern libraries are often susceptible to ‘pattern rot’, when for whatever reason the patterns used on the live website are updated, but the pattern library is not. This usually occurs when there is some kind of copy/paste step necessary in order to apply an update from a pattern library pattern to its version on the live site. This step needs to be short-circuited only once by the update being applied only to the live site, for the pattern library and the live site to diverge. Once this happens, the pattern library is no longer the canonical source of truth, so you can no longer have complete confidence that what you see in the pattern library is what you get on the site. Much of the work that went into building the pattern library becomes lost.

In summary, for a pattern library to retain its value, it must:

Be built in such a way as to reflect the intent of the design system.
Be easy to maintain.
Be as easy as possible to integrate into the website it’s defining the patterns for (avoid ‘pattern rot’).

Integration is the hardest problem to solve and has been the holy grail for pattern libraries for years. We managed to crack this, but you’ll have to wait for the companion post to find out how!

Aims

Before we started writing code, we documented our lower-level aims, based on the principles we’d already decided upon. Our priority of concerns, in decreasing order, were:

Access.
Maintainability.
Performance.
Taking advantage of browser capabilities.
Visual appeal.

With the assumption that maintainability won’t negatively impact performance.

We also documented some of the techniques we’d use:

Progressive enhancement.
min-width media queries.
Small-screen first responsive images.
Only add libraries as needed.

Identifying and naming the patterns

Before we could build any patterns, we needed to identify what things we were building and decide how to talk about them: without a common vocabulary, things could fall apart very quickly. So, embarking on building a brand new look for an online-only journal, we took a large slice of irony pie and started by printing off wireframes of all the patterns.

Having cut out each pattern, we took up most of the floor of the room we were in, laying them out to take stock of what we had. We grouped similar patterns together, enabling us to distinguish those that were essentially duplicates from those we could treat as variants of the same underlying pattern, and to confirm which were actually distinct patterns.

Once distinct patterns were identified, we opened up the room to anyone who wanted to help us agree names for each pattern. Fresh minds at this point helped us get better names.

We thought the whole process would take a couple of hours, but it took most of a day to complete. The benefits were well worth the time: it was a great way to expose many hidden assumptions, identify gaps in thinking, and discover inconsistencies that had crept in during the design process. If we hadn’t done the exercise, all those problems would still exist, but they’d have only manifested later when they’d be more expensive in time and effort to fix.

Deciding on a process

With two front end developers liaising closely with the product team (the designer and the product owner), and facilitated by our tireless scrum master, we decided on 2 week scrum sprints, managing the scrum board in Trello.

Tickets

The fact that we were using progressive enhancement affected the tickets we created: each pattern had a first pass ticket for building its markup and CSS. We used a checklist to manage the work for each ticket:

Semantic html is built.
CSS is applied correctly
Core content and functionality is available without JavaScript or CSS.
Accessibility testing performed.
Browser testing performed.

If a pattern had some behaviour, then a second pass ticket was created for building its JavaScript. Each second pass ticket had the checklist:

JavaScript tests written.
JavaScript behaviour written.
JavaScript tests pass.

For patterns that had variants, the one ticket described building all the variants. They would all have to be considered at the same time in order to build them in a way that works for all of the variants anyway, so it didn’t make sense to split them up.

Individual tickets had additional, pattern-specific checklist items as necessary.

Board

The Trello board was initially created with the columns:

Backlog (all tickets start here).
Aprint items (committed to in the current sprint).
In progress (in active development).
In testing (in browser/accessibility testing).
In review (being reviewed).
Done (finished).

We discovered in the first retrospective that the product team were not feeling sufficiently involved in the review process for a pattern, resulting in patterns sometimes being classed as done when they weren’t. This was quickly addressed in two ways:

the addition of two more columns to separate out the product review from the technical review. The board columns were then:
- Backlog (to be done).
- Sprint items (committed to in the current sprint).
- In progress (in active development).
- For feeback (ready for product review).
- Feedback provided (reviewed by product).
- In testing (in browser/accessibility testing).
- In review (in technical review).
- Done (finished).
The addition of an approval checklist, with each product team member having a dedicated box to check to indicate sign off.

With the revised board, once the pattern is built and ready for product approval it’s moved from ‘in progress’ to ‘for feedback’. The product team members then either specify any changes to be made, or check their name off the checklist if happy with the pattern as it is. They then move it to ‘feedback provided’. Tickets may go round the ‘for feedback’ -> ‘feedback provided’ -> ‘for feedback’… loop a number of times until the pattern’s right. Once a ticket arrives in ‘feedback provided’ with all product team members’ approval boxes checked, the pattern’s ready for testing.

Code management

Pull requests on GitHub from feature branches into the master branch.

Build

Currently the pattern library defines just under 100 patterns. Each pattern comprises:

Exactly one .scss file.
Exactly one .mustache file.
One or more .json files, one per pattern variant.
Zero or one .js files, built in the second pass.
Exactly one .yaml file to define the data structure. This is helpful when integrating the patterns into the site and will be expanded on in the forthcoming companion post.

Each pattern’s accessibility was tested using Khan Academy’s tota11y for accessibility testing in the browser.

We used Browserstack for browser/device testing.

Basic build pipeline

Although PatternLab can compile SCSS, we elected not to do this as we wanted to control the SCSS compilation with the build pipeline. We started off with a minimal build pipeline, originally in Grunt (we switched to Gulp when we introduced JavaScript, see below), knowing that we could add to it when we needed to. Initially it was only for linting and compiling SCSS, and moving asset files where they needed to be for the PatternLab server to display them correctly.

SCSS

Style

We agreed a few simple rules with the aim of keeping the SCSS maintainable in the longer term:

One SCSS file per pattern.
Use Harry Robert’s flavour of BEM (Block, Element, Modifier) for CSS class naming. This works well with a pattern-based approach, as the root of each pattern can define a BEM block. Coupled with the decision to have one SCSS file per pattern, this namespacing kept the separation of the styles for individial patterns nice and clean.
Keep selector specificity as low as possible, and with a maximum selector nesting of 3 (not including pseudo elements). As selectors need only to start from the root of a pattern (or deeper), this seemed a pragmatic maximum. We agreed that we’d increase it if we really, really needed to, but up to now we haven’t had to.
Don’t use & as partial completion for a class name, as it makes searching/refactoring across a code base more error-prone.
Avoid @extends; use mixins instead for greater flexibility.
Only mixins that are completely pattern-specific may live in a pattern’s SCSS file, other mixins must live in higher-level files (see Architecture).
List property names alphabetically.

We implemented style linting with stylelint.

Architecture

Meaningful values for the design system: colours, font sizes, quantities for spacing and element sizing, media query breakpoints and transition parameters etc are defined in the variables partial.
For a sensible reset starting point we included Nicholas Gallagher’s normalise CSS stylesheet as an SCSS partial.
Our own base styles, and any necessary overrides to normalise are defined in the normalise-overrides partial.
The typography component of the design system is defined in the typographic-hierarchy partial: this contains numerous mixins responsible for enforcing a consistent typographic style across the site.
The grid partial contains all SCSS and mixins required for both the horizontal and baseline grid systems.
The mixins partial contains all other mixins.

These are imported along with the pattern-specific SCSS files to create the main build CSS file like this:

build.scss
├── base.scss
│   ├── _definitions
│   │   ├── _variables
│   │   ├── _mixins
│   │   └── _typographic-hierarchy
│   ├── reset
│   │   ├── _normalize
│   │   ├── _normalize-overrides
│   └── _grid
├── pattern-1.scss
├── pattern-2.scss
├── pattern-3.scss
├── ...
└── pattern-n.scss

Each individual [pattern].scss file also imports the definitions partial so it has access to all the necessary shared knowledge of the design system as distilled into the variables and various mixins.

With an eye on delivery over HTTP/2, we ensured that we could produce individual pattern-level CSS files as well as one main stylesheet for traditional HTTP/1.1 delivery.

Organising the typography

The designer documented the typographical part of the design system as a hierarchy of definitions. The lowest level is used to set relevent variables in variables, and set the base styles in normalise-overrides.

Example of base styles for design system typography
Style name	Default narrow screen	Media query
Body	PT Serif 16px/1.5 space after 24px	None
H1	Avenir Next Demi Bold 24px/1.3	Font-size 36px
H2	Avenir Next Demi Bold 21px/1.3 space after 5px	None
...

The media query column specifies what (if any) change occurs when the viewport is wider than the relevant site breakpoint. Note that the breakpoints themselves are not specified here, to keep things loosely coupled.

These base styles are then used as part of the specification for the next level up:

Example of title styles, extending base styles
Style name	Default narrow screen	Media query
Title-lg	PT Serif 16px/1.5 space after 24px	None
Title-md	h1 font-size 42px	Font-size 54px
Title-sm	h1 font-size 30px	Font-size 44px
Title-xs	h1	Font-size 36px
...

These all specify different title sizes (which one gets applied depends on how long the title is).

Typographical styles are defined for all aspects of the design, like this tiny fraction of the set:

Example of more typographical styles
Style name	Default narrow screen	Media query
CONTENT LABEL [grey]	Avenir Next Demi Bold, 11px/1	None
SUBJECT LABEL [blue]	Avenir Next Demi Bold, 11px/1	None
Article title (main list)	h2	None
Article title (side list)	PT Serif Bold 16px	None
...

All these definitions are captured in mixins within typographical-hierarchy. For example, for the two labels, we abstract out the common aspects:

 // All typographical style mixin names include 'typeg' for clarity
 // when viewed out of context. 
 @mixin _label-typeg() {
   font-family: $font-secondary;
   font-weight: normal;
   @include font-size-and-vertical-height(11);
   letter-spacing: 0.5px;
   text-transform: uppercase;
 }

and then create a mixin for each label type, based on it:

 @mixin label-content-typeg() {
   @include _label-typeg();
   color: $color-text-secondary; // grey
 }

 @mixin label-subject-typeg() {
   @include _label-typeg();
   color: $color-primary; // blue
 }

In the design system specification, all the patterns have their typography defined in terms of these typographical style names. Often a particular style name is used for more than one pattern. With this approach, we can easily apply the correct typographical style to the pattern’s CSS via the mixins and, at the same time, keep the design system highly maintainable. If a particular named style is updated, then a simple update to one typeg mixin will permeate to all parts of the system that use it.

(N.B. These examples are taken from an early draft of the spec and the final values used on the site may have changed, although the system defining them hasn’t, indicating that it’s working well!)

Markup

Compilation of the mustache templates with their json data files is handled by PatternLab, producing a user-friendly, to-some-extent-configurable, web view of the patterns.

A basic pattern with no variants has exactly one mustache template and one corresponding json data file.

Pattern variants

For a more complex pattern that has variants, an example of each variant can be produced by supplying a separate json file for each. For example the teaser pattern has 13 variants (an extreme case, most variant patterns have fewer than a handful). It has only one mustache file, but 13 associated json files:

.
├── teaser.mustache
├── teaser~05-main.json
├── teaser~10-main-small-image.json
├── teaser~15-main-big-image.json
├── teaser~20-secondary.json
├── teaser~25-secondary-small-image.json
├── teaser~30-secondary-big-image.json
├── teaser~35-related-item.json
├── teaser~40-basic.json
├── teaser~45-main-event.json
├── teaser~50-secondary-event.json
├── teaser~55-grid-style--labs.json
├── teaser~60-grid-style--podcast.json
└── teaser~65-main--with-list.json

PatternLab uses the ~ in a filename to identify a variant. The numerals in the filenames control the ordering of the presentation of the variants.

Sometimes when coming to build a pattern with variants, we discovered that one or more variants required a significant change to the markup of the main pattern, which suggested a new pattern rather than just a variant. In this case we’d create the ticket(s) for it and put them into the backlog, moving the appropriate spec from the old to the new ticket.

Images

The scholarly content contains a lot of figures, mainly in the form of images. We use responsive images techniques (<picture>, srcset and sometimes sizes) to stop the browser downloading more image data than it needs. For example, the compiled HTML from the captioned-asset pattern’s mustache template looks like this:

 <figure class="captioned-asset">
 
   <picture class="captioned-asset__picture">
     <source 
       srcset="
         /path-to-1076-px-wide-image 1076w, 
         /path-to-538-px-wide-image 538w" 
       type="image/jpeg" />
     <img 
       src="/path-to-538-px-wide-image" 
       alt=""
       class="captioned-asset__image" />
   </picture>         

   <figcaption class="captioned-asset__caption">          
     <h6 class="caption-text__heading">Title of the figure caption</h6>
     <div class="caption-text__body">The figure caption</div>
     <span class="doi doi--asset">The DOI link</span>
   </figcaption>

 </figure>

Note the empty alt attribute: as the image is within a <figure>, the <figcaption> provides the description.

To handle the large amount of image variants that can be required when implementing responsive images, we used the International Image Interoperability Framework (IIIF) to serve most of our images.

Extended build pipeline

When we came to build the patterns’ behaviours, we needed to add JavaScript linting, transpiling and test running to the build pipeline. It quickly became apparent that Gulp was much more flexible than Grunt for this, so we switched from a wild boar to a huge caffeinated beverage (and the caffeine would come in handy).

We author in ES6, and use Babel to transpile down to ES2015, because when we started this project at the beginning of 2016, ES2015 was the generally recommended target. Nearly 2 years later, the JavaScript/Browser landscape has changed considerably, and we’ll be reviewing this fairly soon.

Linting is performed with a mixture of jshint and jscs, although there is a pending upgrade to eslint.

Pattern behaviour with JavaScript

A pattern’s JavaScript behaviour is defined in a discrete component with the same name as the pattern. This JavaScript component is referenced from the root element of the pattern’s mustache template by the attribute data-behaviour="ComponentName".

For example, the content-header pattern has its associated behaviour defined in the ContentHeader class, which is found in the ContentHeader.js file. The content-header.mustache template starts with:

<div... data-behaviour="ContentHeader">...

This causes this HTML element to be passed as an argument to the class constructor in ContentHeader.js when the page’s JavaScript loads and runs:

 // 1. Load the components
 const Components = {};
 Components.ContentHeader = require('./components/ContentHeader');
 // ... load more components ...

 // 4. This bit does the actual initialising
 function initialiseComponent($component) {
   const handler = $component.getAttribute('data-behaviour');
   if (!!Components[handler] && typeof Components[handler] === 'function') {
     new Components[handler]($component, window, window.document);
   }
      
   $component.dataset.behaviourInitialised = true;
 }
    
 // 2. Find all patterns in the document that have declared  a js component
 const components = document.querySelectorAll('[data-behaviour]');
    
 // 3. Initialise each component with the HTMLElement that declared it
 if (components) {
   [].forEach.call(components, (el) => initialiseComponent(el));  
 }

This applies the pattern’s JavaScript behaviour to each instance of the pattern on the page.

Notice we’re additionally passing in the window and document objects to the component’s constructor. This dependency injection enables us to mock these objects, enabling us to write better tests.

Future improvements

It’d be great to improve the loader so that only the components on a particular page are loaded, and then initialisation can occur after these loads have completed.

Because we have a 1:1 relationship between JavaScript component and pattern, we should be able to support HTTP/2 delivery of individual JavaScript assets, only providing what is required to the client (once we’ve upgraded our CDN).

JavaScript testing

We test in the browser using the tripod of the mocha test framework, the chai assertion library, and with sinon for providing spies, mocks and stubs. At the moment we’re using phantomjs as the test environment, but now that’s not currently under active maintenance we’re looking to switch to using puppeteer with headless Chrome.

For each pattern under test there are two files: the spec file and the fixture file. The spec file contains the tests. The fixture file contains the HTML of the pattern whose component is under test. This is obtained by finding the pattern’s compiled HTML generated by PatternLab, and manually copying across the relevant code.

By way of example, this is the guts of the fixture file for the ToggleableCaption component:

 <!-- Results of test run end up here -->
 <div id="mocha"></div>
 
 <!-- This is the test fixture --> 
 <div data-behaviour="ToggleableCaption" data-selector=".caption-text__body">
 
   <div class="caption-text__body">
 
     <p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. In interdum, metus quis sodales pharetra, odio justo
       blandit mi, at porta augue felis sit amet metus. Aliquam porta, justo dapibus vulputate aliquet, arcu quam tempor
       metus, et aliquam nisi nunc in est. Cras vitae leo pretium, tincidunt nisi ac, varius neque. Donec nec posuere
       sem. Integer felis risus, sagittis et pulvinar pretium, rutrum sit amet odio. Proin erat purus, sodales a gravida
       vitae, malesuada non sem. Integer semper enim ante. Donec odio ipsum, ultrices vel quam at, condimentum eleifend
       augue. Pellentesque id ipsum nec dui dictum commodo. Donec quis sagittis ex, sit amet tempus nisi. Nulla eu tortor
       vitae felis porta faucibus in eu leo. Donec ultrices vehicula enim, quis maximus nulla rhoncus sed. Vestibulum
       elementum ligula quis mi aliquet, tincidunt finibus mi hendrerit.</p>
 
   </div>
 
 </div>
 
 <!-- Load the test frameworks -->
 <script src="../node_modules/mocha/mocha.js"></script>
 <script src="../node_modules/chai/chai.js"></script>
 <script src="../node_modules/sinon/pkg/sinon.js"></script>
 
 <!-- Initialise the test suite -->
 <script>mocha.setup('bdd')</script>
 
 <!-- Load the spec file -->
 <script src="build/toggleablecaption.spec.js"></script>
 
 <!-- Run the tests -->
 <script>
   mocha.run();
 </script>

We’ve found that keeping the test fixtures up to date can be difficult, because it takes a developer to remember to re-copy and paste the HTML from the compiled mustache pattern template every time a pattern’s source or source-generating JavaScript is updated.

The tests are run under Gulp using gulp-mocha-phantomjs.

Where is it tho’?

The website using the patterns is https://elifesciences.org/.

All the code for the pattern library is available on GitHub under the MIT licence at https://github.com/elifesciences/pattern-library.

The PatternLab pattern library generated by this code is at https://ui-patterns.elifesciences.org/

Lessons learned

Take the time to agree your principles and build aims up front. Set the expectations that derive from these in the wider team, so no one’s surprised when you start challenging demands for moarLibrareez, etc.
When following Atomic Design principles, don’t worry too much about strict molecule/organism hierarchy: get it as good as you can, but a slighly fuzzy, useable system is better than a system that’s strictly correct but horrible to use.
Implementing a design system requires excellent communication between designers and front end devs. A designer who understands front end code, and developers with a design eye, both really help with this: the more shared context, the better the mutual understanding.
Regularly review your process: if we hadn’t had the retrospective that uncovered the frustrations of the product team over sign off, work quality could have been reduced and relationships strained.
Don’t be afraid to iterate on the patterns, and set the expectation early that this is a good thing. More complex patterns, and/or patterns that have multiple variants may need a few shots at them to make them work. Remember that if you’re implementing a design system, the patterns don’t only have to work individually, but they have to be easily maintainable along with the design system. It’s worth spending more time to iterate to get it right at this stage, because fundamental changes later are bound to be more expensive in time, effort and complexity.
Concentrating the design system typography in one place made thinking about it, talking about it, and subsequently, maintaining it, a lot easier than it might otherwise have been.
TDD FTW! The few times we didn’t use test-driven development for the JavaScript, it was always painful to fill in the gaps afterwards.
Grunt is good to get up and running quickly for simple build pipelines, but if you’re trying to do more complicated things, it’s probably easier to use Gulp: Gulp build files are written in JavaScript, which is more versatile and less confusing than trying to wrangle a Grunt config JavaScript object for a complex build pipeline.

In conclusion

This is one of the most rewarding projects I’ve worked on: a truly honourable combination of open source code enabling open access science publishing. There’s loads more I could say, but this post is already long enough. Be sure to check back soon for the companion post about how we solved pattern rot through enabling use of the patterns we built in PatternLab directly in the website.

Detecting keystrokes in the browser

Thu, 08 Sep 2016 00:30:00 +0000

KeyboardEvent key reporting

All verification performed using this test form:

and referring to this ACSII reference.

(The test form is also available separately.)

Desktop and iOS

The modern desktop environment on Mac and PC (Linux not tested), along with iOS seems to behave fairly consistently.

KeyboardEvents from printable characters and the return key (at least), supply one or both of keyCode and charCode (depending on the browser, see below), for each of keyup, keydown and keypress events.

Lower case alphabetic characters have their lowercase ASCII value reported for a keypress event, but keyup and keydown events report the ASCII value of the corresponding uppercase character.

Typing uppercase characters does not exhibit surprising behaviour, but you need to remember to take into account the modifer keys (shift or capslock).

When an uppercase character is typed by holding down the shift key:

when the shift key is initially depressed, the keydown event reports that as the value for ‘Data line escape’ (16)
all three events register the ASCII value for the upper case character when that is keyed.
When the shift key is released, ‘Data line escape’ (16) is reported for the keyup event.

When an uppercase character is typed using capslock:

when capslock is turned on, the keydown event reports that as the value for ‘Device control 4’ (20)
all three events register the ASCII value for the upper case character when that is keyed. This continues as long as capslock is on
when capslock is turned off, ‘Device control 4’ (20) is reported for the keyup event.

When shift/caps lock key is keyed on a phone’s soft keyboard, it generates neither a code 16 nor a code 20 for the shift/caps lock key.

Events from arrow keys provide keyCode values for keyup and keydown, but not for keypress. Not tested on mobile (generally no arrow keys on the soft keyboards, I’ve not tested using external hardware).

When listening to events on input fields, those from the tab key provide a keyCode value only for keydown, not for the keyup nor keypress events. (This may be because the tab key moves focus away from the element where the keydown event was triggered, meaning that the keyup and keypress events will be never be fired for that specific keying of the tab key, but I’m not sure).

Android

This is where things get funky. I’ve not carried out an exhaustive test because there are hundreds of types of Android devices. However, playing on my venerable OnePlusOne, and also running the test page on a number of Android setups on Browserstack showed consistent behaviour, as far as it goes. It’s this, and it’s a doozy:

no matter what character you key in, keypress says nothing, and both keyup and keydown report a keyCode value for ‘Latin small letter a with ring above’ (229).

So every character you type is being reported as å.

Which is just very slightly wrong.

What to do?

when responding to keyup or keydown events, check keyCode for the ASCII value of the uppercase version of the character keyed.
when responding to the keypress event, check charCode for the ASCII value of the actual character keyed (some browsers will also report in keyCode, but not all, so charCode’s your best bet).

I’m assuming Android’s flakiness is not so critical when detecting tab and arrow keys as they are less likely to be used on a touch screen’s soft keyboard (but there may be people using external keyboards):

if you’re looking for the tab key, you need to listen for it on the keydown event to be most sure of getting it. Note that you should not generally try to do things with the tab key as you may break keyboard navigation.
if you’re looking for an arrow key, you may choose to listen for it on either the keyup or keydown events.

Other things that seem to apply most places but Android:

if you’re looking for an alphabetic character but don’t care in what case, listen for it using the keyup or keydown events.
if you’re looking for an alphabetic character, and the case in which it was typed matters, listen for it using the keypress event.

You’ll need a fallback strategy for Android. In some situations it might be enough to detect that there’s been a keyup or keydown event and use that to trigger an inspection of something on the page that might have been changed by it (the value of a form field with focus, for example).

OSX El Capitan

Chrome

keyup

says keyCode not charCode

Reports value of upper case version of the character where appropriate.

keydown

says keyCode not charCode

Reports value of upper case version of the character where appropriate.

keypress

both keyCode and charCode

Reports value of the character that was actually generated (upper- or lowercase).

Firefox

keyup

says keyCode not charCode

Reports value of upper case version of the character where appropriate.

keydown

says keyCode not charCode

Reports value of upper case version of the character where appropriate.

keypress

not keyCode but charCode

Reports value of the character that was actually generated (upper- or lowercase).

Safari

Appears to be the same as Chrome.

IE

Edge and IE 9 and up exhibit behaviour similiar to Chrome. (IE 8 hasn’t been tested because the test page uses addEventListener that isn’t supported by IE8.)

Smashingconf 2016: day 2

Fri, 18 Mar 2016 15:40:00 +0000

Design systems in difficult places
Taking layout to the next level
Designing the future of content
Devtools, an animated journey
Overthinking design and embracing minutiae
Living Design Systems
Modern workflow and tooling
Improving screen legibibilty

(Find out what happened on day 1.)

Design systems in difficult places

(Mark Boulton @markboulton)

By “Difficult”, he means distributed (across multiple locations), devloved (local decision making) and degrading (customers are exposed to a degredation of the design).

Grew up in Manchester. Factory records fly stickers all over the city. Got used to seeing them in the environment, absorbed into the zeitgeist. (Was taught by Peter Saville!).

Benefits of marginal gains: Sky cycling team manager looked at everything in the lives of his cyclists to attempt many microoptimisations in the hope that accruing enough of them to add up to siginificant improvements in overall performance.

Corollary is the dangers of marginal degredation: this is where a design system can help.

Often came across ‘Problem escalation’: design a website turned into change how your team contributes content turned into your whole business process needs an overhaul. As an agency, had no authority to lead on that, all they had were persuation. Not a comfortable position if the sucess of your project depends on being able to persuade.

Seeing how people work around the awkwardness in a CMS to do their jobs can be great research to feed into the requirements for what replaces it.

Al Jazeera website redesign

Editorial values very important to them. Where CNN sanitise’s footage from a war zone, they dont.

Readers consumed content very differently from how the journalists thought that they did: readers read more than one source; they scan by topic; they evaluated the contents based on the level of trust that they had in the brand, but the journalists were undermining that trust in the way they were presenting their stories.

CERN

Flat hierarchy, independent-minded constituents. They had no mandate, again were operating on persuation.

Design system must adapt to serve the communicating of high wonder to the general public, and low wonder for scientists.

Monotype

Stu Robson built ‘monotype core’, an npm-built setup that creates a local version of the site with all the correct brand assets, GA code, & other required boilerplate.

Central policing of brand never works, be where the person is and make it easier for them to do what they want - prevents gradual degredation.

Everyone wants to be creative. A design system gives people the canvas to do just that, while delineating the constraints, the edges of what they can effect.

Every system devolves into chaos, every garden needs tending.

Draw straight lines between design and KPIs:

research -> design -> outcomes -> KPI

He’s come to realise that meetings are the work. “Am I okay with that? I am at the moment, but maybe ask me again in a year.”

Establish a mandate if you can, otherwise you need to do lots of convincing and need a lot of good will.

How do you know when you’re successful?

there’s a shared vocabulary in use, e.g. “wonder” at CERN.
the system becomes self policing, that means people care.
design health. This can be a leading indicator, the canary in the gold mine.

Taking layout to the next level

(Christopher Wright @cwrightdesign)

Works at Campaign Monitor in Sydney [knows John Allsopp] He’s done Flexbox Adventures & Using flexbox today (look these up). Advocates learing in the open, writing about things as you learn, not after you’ve learnt, so you can document the small things that make it work, but that you mauy forget afterwards: better to help others learn.

EXPERIMENT! Fail early, learn faster.

Simplicity

Rise of complexity, try to manage it with things like SASS or Bootstrap.

Pattern approach good, helps avoid progressive degredation (see Marks Bolton’s talk), but things aren’t that simple

CSS gave us abstracted layouts, where a component is controlled by its ancestors, i.e. the grid.

Content-based breakpoints are good, but you can end up with very, very many media queries. Most frameworks addressed this by focusing on devices, e.g. Bootstrap or Foundation. Booooo. The problem is forcing the component to respond to screen size.

Component should respond to the amount of available pixels in its immediate container, not the overall viewport: this is component flow. For example flex-row-wrap [should this be flex-wrap?], flex-grow, flex-shrink. Can combine this with CSS columns for powerful effect.

Using flex-basis: auto can get around many flexbox bugs (but check that its appropriate for your use case!).

Can use flexbox-based pagination for carousel effect.

Flexbox reversing can be used for timelines.

Use order for presentational content only. Don’t confuse the user!

New: display: contents replaces the element’s box with a pseudobox, and with the boxes of its childern. This means you can use it on a flex item that is itself a container for child items, and those child items become part of teh set of flex items in the grandparent flexbox container. (Experimental: https://developer.mozilla.org/en-US/docs/Web/CSS/display)

To stop IE using flexbox, and force even those versions that support it (buggily), to ignore it, include the within a feature query:

@supports (display: flexbox) {
  display: flexbox;
}

CSS grid: have a play.

Can use new unit that comes with CSS grid module, fr, to implement a peekaboo pattern.

Designing the future of content

(Hannah Donovon @Han) Worked at LastFM, This is my Jam, currently at Drip

She designs for desires, not needs.

Conent is not meaningful when to the user when it lacks context, connection or perspective. Future money will be in the thing around the content.

Whether I know what I want, or whether I want something that I can’t define, I still need context, cononection and perspective. Knowing what I want is hard enough, so offering someone else a suggestion of what they might want is a lot harder.

Humans connect with us in ways that commputers can’t, e.g. taste. Computers connect with us in ways that human’s can’t, e.g. providing global reach.

Context

Makes content meaningful.

“Content is dumb until some smart designer grabs it and puts it somewhere with some context.” Paraphrasing Mark Bolton.

You can use time and place to set context.

At this is my jam, they scraped users’ YouTube avatar images (typically small and low res), cleaned them up, and applied some filters to make them look a bit funky, and applied them to a users’ (list/jam/profile/something), and so gave it some context.

Connection

“The quality of connections is the key to quality per se” - Ray / Charles Eames.

Familiarity can provide a connection, as can time and place.

The best music recommendations come from friends.

Perspective

Gives content feeling.

Gives the ablility to give a damn. Computers can’t give a damn.

The story can provide perspective, as can ethos.

“Designers solve problems, but so do many other occupations. What designers actually do is create culture” - paraphrasing Jack Schultz.

Unfortunatley at the moment it can feel like everything looks the same. See Design machines, and the parody HEY LOOK, IT’S EVERY BOOTSTRAP WEBSITE EVER. As designers we can do better!

Devtools, an animated journey

(Umar Hansa @umaar)

Member of the Google Developer Expert Programme.

Produces weekly newsletter of devtool tips in animated gif form.

Has written posts on SCSS source maps.

Resources

Google’s Devtools reference, doesn’t include everything experimental as moving so fast.
If you want to track devtools bugs or contribute, checkout the contributing page.
discover-devtools.codeschool.com

His examples need experimental devtools features activated in Chrome Canary chrome://flags, and the appropriate experiment enabled within devtools preferences.

If you want to make every new tab / window open with a devtools window ready-attached, start Chrome from the command line with the flag auto-open-devtools-for-tabs.

Elements panel

toggle class
layout editor (still work in progress). To activate it, within devtools preferences, press <shift> 6 times to expose the WIP features, then check “Layout editor”, and restart).
Hitting <esc> to bring up the console gives not just console tab, but also a promises tab and animation inspector. It has some Web animations API integration (I missed what), and keyframe editing.

Network panel

Request blocking, can e.g. block css load to see how your site behaves if the css load borks.
connection throttling
filmstrip of page load
may search network requests with the domain: or mixed-content prefixes. V useful, especially if you’re migrating to TLS and want to catch any http-loaded assets.

Sources pane

Click on DOM element then go to Event Listeners pane to see what listeners are registered to this element.
can live edit js. (This is an achievement!)
can blackbox scripts so they’re not listed nor exposed when debugging (they still run as usual).
supports js source maps
can use devtools for persistent authoring using workspaces
can inspect service workers and see what’s in their cached storage

Timeline

cpu throttling!

Accessibility

Accessibility tools for Chrome are currently provided by a plugin, but natve a11y tooling is on its way.

Overthinking design and embracing minutiae

(Jon Setzen @jonsetzen)

Works at MediaTemple.

US ecomomy is 84% service economy
organisations generally spend 20x more on marketing than they do on ‘experience’
customers who’ve had a good experience buy 140% more than those that haven’t
defines good service as useable / efficient / desireable
We tend to only think about service when it’s bad
where in your user experience do you start to think about your users’ experience (think airline).
[talked about Uber Eats]
MediaTemple Wordpress provisioning can take a while, have developed a game you can play while you’re waiting.
A bad experience degrades trust (see Mark Bolton’s point on gradual degredation).
unhappy users are expensive
Book: This is Service Design Thinking

Living Design Systems

(Jina Bolton @jina)

Works at Salesforce UX. As much as they can they open source: github.com/salesforce-ux

They build tools that other business will use to build things.
They design for configuration.
A fractured process leads to a fractured user experience
A great design system is useable by the entire team
design system is a product, not a project
drive design decisions with prioritised design principles

Their design goals are:

clarity
efficiency
consistency
beauty

Their first step: a UI Inventory - take a lot of notes! Document as much as you can: states, responsiveness, a11y, and also record open questions so you can come back to them later.

Make a list of people involved and their responsibilities.

[Sounds like a more design-focused version of our kickoff: project canvas + tech kickoff.]

BIG QUESTION: How to maintain consistency over a large organisation?

Store your assets in a repo. Once they’re updated, automatically update into styleguide and website
They use the concept of design tokens for e.g. font-size, colour etc. Abstraction of CSS properties into a token system that can deliver that configuration to not only the website and the pattern library, but the Android app team, the iOS app team, etc. All the different technical systems get the result of the design token in the appropriate format for them: e.g. hex for web, 8-character hex rgba value for Android, etc etc. Think SASS vriables, but cross-technology. Nothing is now hardcoded, the design tokens are framework agnostic and enable one central change to cascade to each of the technology stacks that need it.
they open sourced the tool they use to generate the configuration from the design tokens: theo.
Clarity beats brevity: they use BEM naming.
Additionally they namespace their blocknames to ensure to avoid potential clashes with a Salesforce client’s code, e.g. slds-button, rather than just button.
They also wrap their components in a div with a namespace class to provide namespace isolation to any css that they write to make sure they don’t accidentally stomp on client’s stying, for example they’ll use the CSS rule .slds .slds-form to address:

<div class="slds">
  <form class="slds-form"...>
    ...
  </form>
</div>

A styleguide should show all states of a component, otherwise those states will get overlooked.

Typography system: they created text utility classes decoupled from components (also see Alla’s talk).

Only show the code in the styleguide that the people need to see, and don’t build it until you need it!

Using this system leads to better communication and better prototypes - no more proliferation of onconsistent styles.

They have design ofice hours, and CSS office hours where anyone can drop in to consult with them on design or CSS.

Recommends Nathan Curtis, he’s has written & spoken a lot about design systems:

Difference between a styleguide and a design system: “A style guide is an artifact of design process. A design system is a living, funded product with a roadmap & backlog, serving an ecosystem.” - Nathan Curtis (https://twitter.com/nathanacurtis/status/656829204235972608)
on medium
podcast with Jared Spool
styleguides.io podcast
compare Team Models for Scaling a Design System with The Salesforce Team Model for Scaling a Design System.
blog.capwatkins.com/the-sliding-scale-of-giving-a-fuck

Modern workflow and tooling

(Wes Bos @wesbos)

reactforbeginners.com sublimetextbook.com commandlinepoweruser.com flexbox.io

There’s a fine line between tooling for its own sake and gettign stuff done.

Build tools

47% use Gulp. 20% said they used no build tools.
can use for many things, e.g.: critical CSS, removing unused CSS (purify), minifying images, uglifying code… you name it…
npm scripts are great for the simple things, but can get nasty when the complexity increases only a little.

Webpack: “Gulp meets Browserify”. Powerful but have to learn API.

Dependency management (Modules! :-))

To get code authored as modules working in the browser, you can use browserify, webpack or jspm. When authoring, try to use ES6 module syntax if you can, because that’s what it will be eventually anyway.

There are 2 main registries for modules: bower and npm (jspm sits on top of npm). npm has nested dependencies, whereas Bower has a flat hierarchy. Prefer npm over Bower if you can.

Ecosystems is coming soon to npm to enable non-hierarchical grouping.

Babel transpiles to ES5 for the browser.

CSSNext is like Babel for CSS Level 4 modules (and is part of the PostCSS ecosystem).

browsersync comes with built in certificate so can check things that need TLS on localhost. Can also proxy existing apps/servers.

sourcemaps are treasuremaps for bugs.

Improving screen legibibilty

(Tobias Frere-Jones @frerejones)

Sub-pixel rendering is handled differently by different browsers.
Helvetica subpixel rendering is generally poor, parallel lines blend into each othe.
Upper and lower case look similar
lower case “o” and lower case “c” look very similar
typefaces drawn specifically for the web are better, and generally have generaous spacing between letters, and wide appetures.

Hinting - distorts the outline to create a more pleasing shape, e.g helps with separating the dot of tyhe ‘i’ from its stem.

CBS in 1967 noticed terrible rendering of fonts on the TV screen e.g. on map labels: there was a lot of blur and bloom. They fixed some of the problem, but in the process, moved away from the previous News Gothic, more towards Helvetica so they didn’t solve all of the problems. (Helvetica was really poopular at the time: this choice sounds like a stylistic rule - see Alla’s talk.

Metal type faces are slightly different at different sizes because they can be (being physical blocks of metal). Because of this, 6pt running copy in century-old newspapers still reads fine.

“Screen text can be treated as an optical size” - he tried this with his new face: Mallory, that came out last year: it’s got “Standard” and “Microplus” versions, the latter being for the web and tiny print.

Fonts can and should be equally relavent everywhere, not just on screen, not just on printed material.

A prerequisite for good design is clear intention.

(Find out what happened on day 1.)

Smashingconf 2016: day 1

Fri, 18 Mar 2016 15:35:00 +0000

Building great design teams
Building a pattern language for the web
SVG in motion
HTTP/2
Understanding people
Dirty front end tricks
Look, no media queries!
Join the dots
Addendum

(Find out what happened on day 2.)

Building great design teams

(Aarron Walter @aarron)

Until recently design lead at MailChimp, now freelance.

Often lose details when handing over between research, design and development, as handover can be clunky. Having integrated research / design / development teams increases empathy which helps with handover, but also makes handover less waterfall.

Difference between art and design: design is about service. Need to research the context for the service delivery of your design. It’s hard to see the future of your product, but if you can talk to users and find where they’re working around your product to get what they need done, that can give you an idea of what your product is missing.

Successful product companies perform onstant quality improvements to existing products, as well as developing new things.

On site research will give you more context, e.g. age of tech, level of distraction, quality of lighting etc etc, all have a potential effect on how youe user interacts with your product. If you can video your users and play back to colleagues, more people in your company can appreciate your users’ contexts.

Before MailChimp was cross-device, he made a video (resourced in-house), of a future user who integrates multi device access into her use of MailChimp. More effective at communicating the story of a user of a future version of their product than expecting everyone to read and digest a 30 page report on future product direction.

Agile, used blindly, can lead to painful forcing of process as waterfall did. Reasrch, design and development naturally work at different cadences, development is generally very suitable for scrum, but design works on a longer iteration cycle, and research longer still. Also, research should generally have a head start over design, and design likewise over development.

Deadlines provide powerful focus.

Small, integrated interdisciplinary teams are very powerful.

In teams, people are the hardest part. So, hiring:

The process is often broken, often hiring is done based on ticking off a list, not matching the person to fit the team. He believes in getting the right person and training them up (a bit) / coaching, if necessary, rather than hiring a checklist-satisfying candidate who doesn’t fit well into the team.

People are more often fired for soft skill problems than core competency problems. [His assertion.] His hiring process:

initial phone screen as a sanity check
followup call to get to know the candidate a bit: aspirations and interests, etc
1 day imersion into the team, see how they fit in, how the team takes to them [is the person paid? is the time flexible? how do they accommodate people who are currently working, into that framework?]

People will be best motivated if they share your goals, so hire people who believe what you believe [but don’t start a cult?]. BUT if you want diversity of thought, you need to bring in people with diverse experience. Needed be a contradiction, but be mindful.

Hire people who are smarter than you.

Hire humility: humility aids effective collaboration.

Staff 1:1: (you can often tell when a deadline’s about to be missed from what’s said, and how, here, he finds conflict is the usual reason). You can take that time with staff to acknowledge where they’re great, but also make sure they know where their weaknesses are (but maybe put it better than that). Important for people to know their own weaknesses, because humility: then they know when to hand over to someone’s who’s better at that particular thing.

Acknoweldge when you’re wrong. As a desgin leader: “My job is not to know more about everything, my job is to be more curious about everything.”

Building a pattern language for the web

Alla Kholmalova (@craftui)

Recommended book Thinking in Systems

System: interconnected elements with a purpose, more than just a collection of elements.

Purpose of a design system? Provide some coherent patterns to facilitate and encourage certain types of behaviour.

Types of behaviour: semantic, structural, visual, behavioural.

Semantic

See Language of Modular Design on A List Apart.

Name things based on the function of that thing in the global system, not its function on an individual page.

Useful to print out UI to distill global functions & name things accordingly (sounds like our naming exercise).

Structural

e.g. atomic design.

They were strict, in hindsight realise they should have adapted more.

A big grey area for them was distinguishing between molecules and organisms. Followed Brad Frost’s advice [check to recapitulate]. Lead to long debates.

After 18 months held a workshop where split into several groups with printouts of all the components and asked to group. There was no consensus still as to which were molecules and which were organisms.

They did find common ground identifying some compeonents as ‘standalones’, and some as ‘helpers’. Standalones being well defined, independent parts of a page, helpers don’t work out of context, but provide help to other components. Identifying this way, they mapped helpers to molecules and standalones to organisms.

Visual

What about style properties that are applied to atoms? In this model do they become sub-atomic particles? Clearly this abstraction is in danger of getting out of control.

Visual patterns cut across the semantics. [This is what I was trying to describe a while ago for our pattern library.]

Relationships 1

Relationships between modules can make picking typographic size & spacing difficult, as the context of a module’s use can affect what works, and that context is not part of the module, it’s operating above of/outside it.

[not sure of my notes at this next bit] Visual modules are of 3 types: global function, typographic style, or spacing. Treat core brand prpoerties separately, don’t mix them with modules. [Good use case for Sass aviables here.]

Define not just elements, but the relationship between them.

A design pattern must be connected to human behaviour: if it looks like a pattern, but it lacks that connection, then it’s just a stylistic rule (something that might be trendy, but adds nothing to aid the desired behaviour for the component - see National Library of France, Paris(?)).

Watch for red flags (she only one example), e.g. modules that have the same behaviour but that look different.

Evolving a design system is gradual, piecemeal, and can be messy, not the result of a grand plan (assume this refers to deriving patterns from existing setup rather than a new build).

Investigate

Tom Osbourne: Visual loudness guide
Design tokens: Salesforce
Brad Frost’s advice to distinguishing between molecules and organisms
stylistic rules

SVG in motion

(Sara Soueidan @sarasoueidan)

Which embedding mechanism to use? Depends on the answers to the questions:

is it animated?
is it interactive?
does animation use css or js?
what’s the browser support for the animation?
what’s the required fallback(, and what’s the browser support for that)?

<object> embedding mechanism her favourite, it allows for good fallback mechanisms: for example the tabular data from which an SVG infographic is derived:

<object ...>
  <!-- fallback -->
</object>

To get at the SVG DOM from an SVG loaded by <object>, use [object_el].contentDocument.

Don’t optimise after setting up animations: they will almost certainly break.

Should you animate with css or do you need js?

transformations: js
path morphing: js
line drawing: js
colour and simple animations/transitions: css

Only some presentation attributes are also represented as css properties and so can be addresssed in CSS, and therefore potentially animatable.

Default transform origin for HTML DOM element is 50% 50% into the elemen (centre).

Default transform origin for SVG element is the origin of the SVG viewport (top left corner of the whole SVG element as displayed).

When setting transform-origin on an SVG element:

using % is relative to the bounding box of the element, including its stroke.
using px is relative to the SVG canvas

SVG animations do not run on the GPU, and so performance sucks.

SVG has 2 coordinate systems, the viewport and the view box. See:

https://sarasoueidan.com/blog/svg-coordinate-systems/
https://sarasoueidan.com/demos/interactive-svg-coordinate-system/index.html

HTTP/2

(Partick Hamann @patrickhamann)

Works at FT.

Slides at https://speakerdeck.com/patrickhamann/http2-what-where-why-and-when-smashing-conference-march-2016

2016: Median # requests per page: 80 95th-percentile # requests per page: 200-300

1995: 1-5 requests per page

Average UK 3G connection takes about 600-1000ms fir DNS/TCP/TLS negotiation.

Head of line blocking means you can’t parallel request on the same connection becsuse there’s no way of telling when one request ends and another starts. Browsers got around this by opening up a brand new connection in parallel for the addtional requests. Latest pre-HTTP/2 spec allows for up to 10 concurrent connections (was 6, before then it was 4).

When even 6 connections aren’t enough, there’s always domain sharding.

So as developers we concatonate our css & js files to reduce the number of requests.

But we might only need 1 line from a huge JavaScript file. It’s a similar case with image spriting.

We inline critical CSS, but even this technique to improve performance render performance has performance hits as well as benefits (e.g. not cacheable - anything else?)

HTTP/2 invented, based heavily on Google’s SPDY (2006), to speed up delivery over high latency connections.

The heart of an HTTP/2 connection is a stream. A stream comprises binary data frames that declare how long they are, and carry a stream identifier. The frame’s stream identifier means that frames for different streams may be interleaved and reassembled correctly in the browser.

There’s a prioritisation system to organise which resources are requested when. Each stream has a weight which the client can send to the server, so the server can decide the order to send things back in. Weights can be changed when the browser comes across something that changes the priorities.

HPACK: header compression. Begins to build state between the client and the server.

Server push can pre-empt client request by sending resource before the client asks for it. For example the server receives a request for an HTML page. If the server knows that the client will request the css next, before any of the html is sent, the server sends the CSS file to the client. Note that this must happen before the HTML itself is sent, in order to avoid possible race conditions where parsing the HTML might also trigger a request for the CSS file.

Reasonable browser support: http://caniuse.com/#search=http2

Sounds like the requirement for TLS is actually a hack. SPDY devs found packets were being dropped at switches and routers that didn’t understand the new protocol [anti-malware got confused?], so sent data over TLS which the middleware was fine with. Spec doesn’t mandate TLS, but every implementation has it as a hard requirement.

If looking for a server for use with HTTP/2, ask about:

support for stream priorities
support for server push
strategies for resource hinting
whether they provide any intelligent optimsisation

Easingn in the implementation:

CDN first
then take a reverse proxy approach
finally HTTP/2 AllTheThings

Don’t overdo it with server push: only push critical assets like core js, critical css and maybe fonts.

Link HTTP header is like <link>. Means could use <link rel="preload"> but Yoav Weiss who implemented preload in Blink advises against it as it uses completely different semantics from push.

[Track intelligent push].

Look at connection view in dev tools. It’s pretty bare of meaningful metrics. Remember headers are now binary so harder to inspect. Jim Shaver has a post on setting up Wireshark to inspect HTTP/2 requests (is it this one: jimshaver.net/2015/02/11/decrypting-tls-browser-traffic-with-wireshark-the-easy-way).

Rebecca Murphy has a tool to inspect HTTP/2 logs.

Generally though, HTTP/2 tooling is in a pretty poor state at the moment.

When to switch?

Go TLS first. It’s a prerequisite anyway, and this way you’ll iron out the TLS wrinkles before you hit the HTTP/2 wrinkles.
Then check the client support for it in your user base
Change your workflow to be HTTP/2 first
Perf basics are still very important!

FT’s experience:

5s improved download speed on mobile and tablet.
start render event brought forward by 500ms.
not much change on desktop
this is expected as HTTP/2 design goal is to improve performance on high latency networks, which you’d expect mobile and tablet to have much more use of.

Think about grouping files based on frequency of change.

Also, because GZIP gets better when sending more data, sending many small files may end up sending a lot more data than sending down a single GZIP’d file - see Kahn Academy’s experience.

Understanding people

(Chris Shiflett @shiflett)

Perception > reality e.g. to make something appear visually centered, it may have to actually be moved off centre by a few pixels.

Lucky iron fish only worked when it was made into a fish. The original hunks of iron were not adopted as people didn’t want to put it in their cooking pot.

Change blindness

Showed a photo, showed a white screen for a few seconds, then showed the same photo again with one small detail changed. Very hard to notice the difference. It’s like this for users when they make a mistake filling in a form, the page posts to the server (white screen), then the form comes back looking very similar but with an error message added. The closer the error-state form looked like the original, the harder it is for users to spot the error state message and realise there’s a problem. Here, inconsistencey can be a good thing.

Users aren’t stupid, they’re human.

Tokyo subway uses ambient signifiers: each train line/station comination has a unique set of chimes so you don’t need to see out of the window to know which stop you’re at (once you’ve learned the chimes). For regular commuters, the anticipation established with this means that they pick up very quickly if something’s gone awry, for example they fell asleep, have just woken up and notice the chimes are wrong - they’ve gone past their stop!

Think songs in a playlist: if you hear a playlist song somewhere else, you’re expecting the next song on your playlist to come on next, and when it doesn’t it can jar.

Decoys: a pricing option that the designer doesn’t expect to be chosen, but that is likely to affect the option that you do choose. Gaps between the price points can affect which options people choose, too.

Beware dark patterns: these are deliberately designed to trick people.

Mony Hall problem: 3 doors, 2 goats, one car. Pick a door, don’t open it. I show you a different door with a goat. Do you stick with your original choice or switch to the other door? Always switch for the best chance of getting the car.

Disruption. Ugh, no. Don’t try to abruptly change your users’ behaviour. Better to understand and shape it instead.

Dirty front end tricks

(Vitaly Friedman @smashingmag)

To nest links(!), place the inner one inside an <object> element. Won’t work in IE8 as it doesn’t support <object> but there are workarounds(?)
Highlihghting the row and column of a cell in a table
To get uniform padding on an inline element that’s wrapping due to the length of its content (so the padding is not just at the beginning of the first line and the end of the last, but applies as a gutter on either side of the inline element’s content), use horizontal (only) box shadow, or box-decoration-break.
Fab four technique for responsive layout in email without floats or media queries: https://medium.freecodecamp.com/the-fab-four-technique-to-create-responsive-emails-without-media-queries-baf11fdfa848 http://responsiveemailpatterns.com/. This uses calc(), width, min-width and max-width and is a work of twisted genius.
To wrap very long words (URLs, sequences), use a combination of word-wrap and overflow wrap.
Jake Archibald on loading CSS
table-layout: fixed fixes table column widths based on the width of their first row. This is fine as long as the first row contains the longest content…
object-fit is to content images what background-size is to background images.
Carlsberg age selector a good example of a redesigned selector.
Redesigning the country selector
Interesting respsonsive grid
Grid systems and zoomable UI: jonikorpi.com
For e.g. a zoomable ticket picker, could do it as canvas, divide it into tiles then redraw only the tiles you need.

Look, no media queries!

(Vasilis van Gemert @vasilis)

Slides
mixed-blend-mode
css columns for horizontal running text
if put an id on <html> you can use a fragment id in the URI along with the :target CSS selector to change the layout of the page. You can add another one onto <head>, and also onto <body>, and then you’ve got up to 3 layouts you can switch between via the URI.

Don’t use vh/vw units to style text, as that can get very crazy, but you can do this:

font-size: calc(2em + 2vh + 2vw);

Even better though, is this:

font-size: calc(4vw + 4vh + 4vmin);

as this will give you perfectly scaled text inside any container and won’t break out.

Can use viewport-relative units in flex-basis. , e.g. vmax: can give you a differeing # coulumns, depending on the viewport width: the effects of a media query, without a media query.

Join the dots

(Haydon Pickering @heydonworks) Slides: http://slides.com/heydon/joining-up-the-dots#/

forcefeed.js(?) Hegel’s dialectical synthesis: git merge...

@t said: “If it’s not curlable, then it’s not the web”

“How modules communicate is more importand than their properties” Alan Kay [also see Alla’s talk].

HYPERLINKS FTW.

Readability tools:

hemmingwayapp.com
Alex (looks for gendered language)
Rousseau (picks up weasel words)
readability-checker

gov.uk aims for sentences no longer than 25 words.

Haydon’s Logical Developer Falacies

Communication is key! (see Aarron’s talk).

Addendum

Rachel Nabor’s links: webanimationweekly.com hacks.mozilla.org

(Find out what happened on day 2.)

Smashingconf 2016: overview

Fri, 18 Mar 2016 15:30:00 +0000

The two related posts linked to below are the writeup of my raw notes from Smashingconf Oxford 2016. I’ll likely add to them as I come across errors, or can update with links to speakers slides or other resources. They contain my transcription of my hand-written notes I took while listening to the speakers. Their primary aim is to capture as much as possible while it’s fresh in my mind. There’s always a chance I’ve misunderstood something, or haven’t represented something quite right because I didn’t catch everything. If so, I apologise, I can only write so fast - and that’s faster than I type! Speaking of which, forgive the typos. I typed up the notes as fast as I could, so they’re a bit rough about the edges.

A huge thank you to all of the speakers, and to Smashing for organising it, it was another phenomenally good conference.

Smashing Conf Day 1 (March 15th):

Building great design teams (Aarron Walter)
Building a pattern language for the web (Alla Kholmatoma)
SVG in Motion (Sara Soueiden)
HTTP/2 (Patrick Hamann)
Understanding people (Chris Shiflett)
Dirty front end tricks (Vitaly Friedman)
Look, no media queries! (Vasilis van Gemert)
Join the dots (Haydon Pickering)

Smashing Conf Day 2 (March 16th):

Design systems in difficult places (Mark Boulton)
Taking layout to the next level (Christopher Wright)
Designing the future of content (Hannah Donovon)
Devtools: an animated journey (Umar Hansa)
Overthinking design and embracing minutia (Jon Setzen)
Living design systems (Jina Bolton)
Modern workflow and tooling (Wes Bos)
Improving on screen legibilty (Tobias Frere-Jones)

Useful resources for front end web development

Wed, 09 Mar 2016 00:00:00 +0000

I was talking to a friend who’s recently started learning front end development, and realised that the sheer abundance of posts on the topic makes it hard for a newcomer to know where which way to turn. In an attempt to provide some kind of orientation, I’ve quickly put together a short list of some of blogs and other resources I find useful myself. Hopefully others will benefit from this too, although obviously as this is a personal selection YMMV.

General

w3.org (the web standards body, incl. html5 spec. But not JavaScript.)
developer.mozilla.org (good for nitty gritty technical details)
caniuse.com (check browser support for the feature you want to use)
smashingmagazine.com and alistapart.com (two superb resources across the spectrum of front end development)

HTML

whatwg.org (separate html5 spec - thankfully extremely similar to the w3c one)
html5doctor.com (useful insight into html5 elements and their useage)

CSS

css-tricks.com (insightful articles & useful examples of many css techniques)
csswizardry.com (thoughful posts on css organisation)
davidcmoulton.github.io/css-selectors (I made this one, and refer to it quite often: it’s an example of every css selector I could think of [not updated with shadow DOM yet])

SVG

sarasoueidan.com (excellent, actionable, detailed posts on all matters svg)

It was tricky trying to distill JavaScript blogs suitable for a beginner, as so much seems to be aimed at intermediate level or higher. I’ll may update this post with js resources if I come across something suitable, but books might be the better bet if you’re starting to learn JavaScript with no prior programming experience.

Finally, there’s stackoverflow.com, which describes itself as a community of 4.7 million programmers, just like you, helping each other. It’s often a great place to find answers to questions you have. Just bear in mind that the quality of the answers can be uneven, so it can be a mixed blessing for a beginner.

(Note this list isn’t trying to be definitive, and I doubt it’s very representative either bearing in mind the sheer volume of stuff out there, so apologies to anyone who’s offended I’ve not mentioned their contribution, Please don’t be, I’m sure you’re awesome! :-) )

Smashingconf 2015: RWD performance optimisation

Mon, 16 Mar 2015 00:00:00 +0000

I was lucky enough to get to Smashingconf Oxford once again this year. In this post I cover the pre-conference workshop run by Guy Podjarny (@guypod), titled “Make a slow responsive website fast”. Guy is CTO for Akamai, a CDN company, and so unsurprisginly Akamai was mentioned a bit in the workshop, but never in an exclusive or selling manner, and always accompanied by mentioning free/open alternatives. It definitely wasn’t a sales pitch, and didn’t feel like one, which I appreciated.

(A note on sources: this post is mainly from my notes and memories of the day. There are some statements that I don’t have sources for as I didn’t manage to record them as well as the statements themselves; I couldn’t type fast enough!)

Mobile web and performance

Cute fact: there a 6-7 times more smartphones being activated every 45 minutes than there are babies being born.

Plain fact: Akamai have seen mobile traffic on their network up from 9% in June 2012, to 36% 18 months later.

We all know how desktop sites fail on mobile: through bad interactions, pages being too big, and pages being too complex.

This performance impacts business results. Walmart measured download time vs conversion rate on its site, and as you might expect, the slower thee page load, the fewer conversions occurred.

EBay performed a similar study that showed a 5% slowdown of the site cost 1% revenue; a 35% slowdown of the site cost them 5% revenue. They found a faster page caused a lower bounce rate and more pages viewed per session.

History lesson: dedicated mobile sites (“mdot” sites)

In the days before responsive web design (RWD), businesses attempted to address the failure of desktop sites on mobile by creating dedicated mobile sites (often on an “m.” or “mobile.” subdomain, hence they’re known as “mdot” sites). These had the advantage at the time of being able to be built by a new team who didn’t need integrating into the main site team to ply their new-fangled mobile website trade, and were able to ship the mdot site without upsetting the main corporate dev site workflow. Of course after a while this duplication/separation was seen for the burden that it is: it usually requires duplication of content, of development and design.

mdot sites are generally fast though.

mdot sites tend to comprise smaller pages with fewer HTTP requests, so you get performance for free. But with an mdot site you typically have redirects, the latency within which can wipe out the gain of the smaller payload.

These edge redirects (where you get sent to an mdot site, with the appropriate URL, if you’re on a device classified by the edge server as “mobile”), have problems of diluted SEO effect, device identification, and portabliity: sending someone a link to an mdot page can give them a horrid experience when they look at it on their large monitor.

An alternative to edge redirects, which addresses the URL portabliity (and probably also the SEO) problems, is adaptive delivery. Here a single URL is used to serve either the desktop or the mdot site, again depending on whether the requesting device is described as “mobile”. So although an improvement, it still has the problem of device identification.

Bearing in mind the sheer number of “mobile” devices out there today (Akamai have identified 8000 different devices on their network), and add to that the fact that with such a plethora of screen sizes and resolutions the “mobile” spectrum is more of a continuum than a binary situation these days, then the suitability of an mdot site in today’s web landscape is generally low.

Present lesson: Responsive Web Design

Google recommend RWD for SEO. If nothing else, this is driving adoption. In October 2014, of the top 100000 websites, 18% used responsive design, up from 10% only 11 months previously.

Almost no difference in number HTTP requests between RWD site at desktop width, and the same site at narrow width with a mobile user agent.

Average compute time is almost double for an RWD site compared to an mdot site (~6s and ~3s respectively).

HTTP archive trends show that although the number of images is staying roughly the same, the average size of an image has increased significantly (a JPEG file’s size on an RWD site is often 150% larger than on a traditional desktop-only site). RWD isn’t causing more objects, it’s causing objects to be bigger. And for objects, read images.

There are great reasons why we need responsive images which I won’t go over again here. Oh okay, just one then (and this one’s less commonly mentioned that some others): when the image scaling is handled on the client, the this generally happens on the GPU. The whole image is pushed from the CPU onto the GPU through what’s a pretty narrow pipe, before the image can be scaled. This is costly.

The Responsive Images Community Group has championed the issue of responsive images, and thanks to their efforts we have the following available either as native implementations, or polyfilled:

srcset attribute
sizes attribute
<picture> element

As the first to have agreement among (some) browser vendors to implement, srcset has pretty good native support now. Sizes and picture came later and so currently need polyfilling. So far, my goto polyfill for responsive images has been picturefill, maintained by Scott Jehl. In the workshop, Guy mentioned another called respimage maintained by Alexander Farkas, which looks interesting, but I’ve not used (yet).

Eric Portis has a couple of great posts on how to use these new responsive image tools: Responsive images in practice and the older srcset and sizes.

Exercises

The exercises were set up on individual Magento servers, so we could individually break things without inconveniencing anyone else. One page in particular was used as the target of most of the optimisations, this is referred to below as the ‘test page’.

(Note: if I talk about relative merits of an approach requiring JavaScript or not, I’m referring to the native implementation. Obviously if the behaviour is polyfilled, that will be JavaScript dependent until support is such that the polyfill can be removed.)

WebPageTest

We were introduced to WebPageTest, a tool for running speed tests from multiple geographical locations, using real browsers at real connection speeds. It’s a free service, and you can use it manually online, request a key to give you 200 automatable page loads, or install it yourself on a server for full integration into your CI stack.

When making optimisations to a site, it’s important you have a baseline to check the effect of what you’re changing. We set off a couple of WebPageTest runs to baseline the page on both desktop and mobile before making any changes.

After each optimisation, we ran WebPageTest to see what its effect.

Obviously for site features it’s not okay if something core only works for 90% of users. With optimisations though, it is okay if they only work for 90% of users.

Exercise 1: download and shrink

Use case

Huge images are being sent to the client for the client to shrink to fit as necessary.

Optimisation

Only send image of appropriate size to client.

Modified the server-side code to provide unique urls for the individual images of different (appropriate) sizes.
Added srcset and sizes attributes to the image elements:

<img src="[default/fallback image path]"
  srcset="[small image path] 300w, [medium image path] 345w
          [large image path] 500w"
  sizes="(max-width: 640px) 300px, (max-width: 800px) 345px,
         (max-width: 1200px) 500px"
  alt="[something appropriate]"
  ... />

Although we only specified width in this case, srcset is often used to specify resolution. Images included in a srcset attribute value are considered equivalent. Because of this, srcset only provides hints to the browser for resolution switching, the browser is not obliged to respect it.

Exercise 2: download and hide

Use case

Images are being sent to the client regardless of the client environment, and are just not shown if e.g. the viewport is too narrow.

Optimisation

Option 1: use JavaScript

Like this:

<script>
 function loadReal(img) {
  if (!img) return;
  if (img.offsetParent != null) {
   img.onload = null;
   img.src = img.getAttribute("data-src");
  }
 }
</script>
...
<img src="1x1.jpg" onload="loadReal(this);" data-src="[url to desired image]" alt="[alt of desired image]" />

JavaScript is required to show these images though.

Option 2: use `<picture>`:

<picture>
  <source media="(min-width: 800px)" src="[url to desired image]" />
  <img src="1x1.jpg" />
</picture>

Unlike images specified in srcset, the child <source> elements of <picture> are not considered equivalent. This means that whatever media query you specify there the browser is required to respect. This can make things slower though, so only use <picture> if you need the art direction usecase.

Note that afaik the <picture> element doesn’t allow for a ‘no-image’ option, hence the 1x1 still specified within <picture>’s <img>

Of the two aproaches above, favour <picture> as it’s a (albiet poiyfilled) native implementation. Always favour standards-based native implementation over custom rolled.

Exercise 3: overdownloading css

Byte for byte CSS has a massive impact on web page performance, because it can be blocking.

Use case

Main CSS files contain significantly over 10% of CSS within media queries that will never apply to the current page.

Optimisation

Refactor the media-query-specific CSS into file(s) specific for the media query/queries. Then conditionally load them.

Option 1: use `<link media...`:

<link rel="stylesheet" type="text/css"  href="base.css" media="all" />
<link rel="stylesheet" type="text/css"  href="mobile.css" media="(max-width:799px)"/>
<link rel="stylesheet" type="text/css"  href="desktop.css" media="(min-width:800px)"/>

Option 2: use JavaScript:

  <link rel="stylesheet" type="text/css"  href="base.css" media="all" />
  <link rel="stylesheet" type="text/css"  data-src="mobile.css" data-mq="(max-width:799px)"/>
  <link rel="stylesheet" type="text/css"  data-src="desktop.css" data-mq="(min-width:800px)"/>
  <script>
    var scripts = document.getElementsByTagName("link");
    for(var i=0;i < scripts.length; i++)
    {
      // Test if the Media Query matches
      var mq = scripts[i].getAttribute("data-mq");
      if (window.matchMedia(mq).matches)
      {
        // If so, append the new (async) element.
        var s = document.createElement("link");
        s.rel = 'stylesheet'
        s.type = 'text/css';
        s.href = scripts[i].getAttribute("data-src");
        document.body.appendChild(s);
      }
    }
  </script>

Using <link>, the file that is under a non-matching media query is still loaded, but its load is deferred so it doesn’t block. This was unexpected, but is apparently standard browser behaviour. I guess so that if the device switches orientation, the CSS for it is already in memory and wouldn’t have to be fetched, which could have really horrible effects.

The JavaScript approach gives you complete control over the load, and beacause we didn’t ask for it, it didn’t defer-load the non-matching media query CSS.

As for the previous exercise, prefer the <link> element approach over the JavaScript approach: it’s a native implementation, and so is a better choice.

This conditional loading introduces extra requests, which is the tradeoff. Whether it’s worth doing for your particular CSS is a value judgement you have to make in your own circumstances.

Exercise 4: RESS (Responsive + Server Side)

RESS is an approach that pushes onto the server the conditional assembly of a design response, where it makes sense to. RESS does not replace responsive design on the client.

Possible approaches are:

regex the user agent string
device characteristics
client hints (not ready yet)
cookies

Using cookies

Can have a JavaScript function that sets a cookie recording the viewport width. The server tests for this and only sends down content for wide screen if it’ll fit.

For example, in JavaScript:

function writeCookie() {
	var today = new Date();
	var the_date = new Date("December 31, 2023");
	var the_cookie_date = the_date.toGMTString();
	var the_cookie = "users_width="+ window.innerWidth;
	var the_cookie = the_cookie + ";expires=" + the_cookie_date + "; path=/";
	document.cookie=the_cookie
}
writeCookie();

then on the server, e.g. in PHP:

<?php
if (isset($_COOKIE["users_width"])){
  if($_COOKIE["users_width"] > 650) {
    echo The_Content_Only_For_Wide_Viewports;
  }
}

dependency on js for wide view content
will only take effect on page load, not window resize nor device orientation switch (unless use ajax to set cookie again with new width, and dynamically inject the content as needed?).
doesn’t work for initial page load as cookie needs to be set first.
can break caching
how much do you gain with this technique? It may not be worth it.

Consider not including the content at all if it wouldn’t show up in landscape nor portrait

Using edge side includes (ESIs)

ESIs are like server side includes, but are in the cache. They were originally developed in 2001 to set cache expiry on fragemnts of a page, rather than the page itself.

available in Varnish, Apache Traffic Server, Akamai…
open standard, but some implementations have written extensions
enables you to cache a single page, but have it with whatever variations you want.
If relying on ESIs, application won’t work without them, unless you configure application with e.g. a flag to indicate when ESIs not in use, that causes server to run code to generate content etc that would otherwise be taken into account by the ESIs.

Example in Varnish

Exercise Image transcoding

Image management vital for any website. Can have many, many image variants for each actual image.

There are (relatively) new image formats like WebP, JPEG2000 etc that have better compression than JPEG and PNG, but there is no solid cross browser support for any of these at the moment.

If you can separate image transcoding from the application, then you can have image selection on a per browser basis. You can be agile about what image gets served to what browser/device, as the situation evolves and new formats come along, or support for current formats improve.

Essentially you have image generation and image routing as two independent functions. Image routing is not new, ImageMagik is good for this. Also consider giving Tinysource(?) and image converter(?)

You could adjust the image quality to the network conditions, but assessing the network is hard. Akamai use round trip time to describe the network as Excellent, Average or Poor.

Serving the right image is difficult, need to consider:

browser version
network
screen resolution/dimensions

Pick a tool wisely. Take into account:

ease of workflow
first view of performance
scaleability
code complexity

If choosing whether to send down a JPEG or a WebP file to the client, you could use a different URL for each format, and write the URLs in the HTML accordingly. The problem with this approach is that if a link is shared and attempted to be opened in a non-supporting client, the view will fail. Also Google will see these as two different URLs and your SEO will be diluted.

Instead, the recommended approach is to have a single URL that supplied different images using RESS. This may not be easy.

There’s a good read by Ilya Grigorik on Deploying WebP via accept content negotiation

And finally

Thanks to Guy (and to his facilitators Michael and Ellen), and Smashingconf for a great workshop! Really interesting, I learned a lot.

Meetup writeup: The Science of (Bio) Data Visualisation

Fri, 16 Jan 2015 19:45:08 +0000

Yesterday evening I went along to the Science of (Bio) Data Visualisation meetup in Cambridge. There were 2 talks: one by Catagay Turkay, who is researching data visualisation, and one from a design company, Science-Practice, who specialise in the science sector. The two talks complemented each other well.

Designing interactive visualisations to solve analytical problems

Catagay Turkay is researching applied data science in the giCentre of City University, London. He’s interested in perceptually optimised visualisations, and in using computational tools in interactive visual analysis. Biological visualisations specifically interest him because they tend to be based on large, heterogeneous datasets, often at multiple scales, and because they often describe dynamic processes, they include temporal complexity, which makes them more challenging.

Visualisation can help:

ease of cognition
relate multiple aspects
compare multiple computational outputs
investigate uncertainties

They enable and foster hypothesis generation

Catagay sees visualisation as operating on three levels: as a presentation medium; with interaction, and with integrated computation.

Visualisations as presentation medium

He showed an example of striking imagery with an illustration of an E. coli cell, highly coloured, with organelles clearly visible. It’s both correct, and aesthetic.

Nature Methods publishes a regular Points of view column on how to make better visualisations. You can see this list of them, but the actual articles are paywalled.

Visualisations with interaction

Example of Mizbee, a free Synteny browser (also, see the article’s record on PubMed, although the actual IEEE paper is behind a paywall).

Strengths of this include:

the ability to compare the overlap between 2 genes
can link multiple aspects
interactively vary the focus
display multiple scales concurrently (multiple scales seem to be a situation reasonably specific to biology).

Visualisations with integrated computation

Rather than provide an interface to interact with static aspects of the dataset (albeit in creative ways), here computation on the data is employed during the data visualisation process itself. For example by making a cluster algorithm part of the actual visualisation process.

The strength of this approach is the combination of human perceptual abilities with a computer’s processing power. AKA Visual Analytics.

Example given was Stratomex by Caleydo. It’s described as an “Integrative visualization of stratified heterogeneous data for disease subtype analysis”. It’s been used for cancer subtype analysis, and he showed multiple stratifications with many patients, and some sample overlaps: which means you can compare the results of different algorithms.

What’s powerful here is that you can link gene expression data with chemical pathway data and clinical data. Visualisations are good here, because:

with multiple, linked datasets you can improve your interpretation
multiple computational results can help you deal with uncertainty

This allows for a fast iterative process that means you can prototype many ideas quickly. You won’t get all the answers from this high level treatment, but it can help you narrow down ideas of interest that is worth putting under more rigorous analysis.

Outlook

Interaction and exploratory analysis is key.

We need seamless support from integrated computations (e.g. t-tests).

Q&A

What work is going on to investigate new methods of interaction, to complement all this work on new methods of visualisation?

There is a lot of work going on in the HCI field to do with this, not crossed over into the visualisation world yet.
What libraries are people using for their visualisations?
- d3 (JavaScript)
- vega (JavaScript)
- GGobi plugin for R (R)
- Catagay does a lot of his work using Python

Closing remarks

Good design principles are essential for maximising the perceptual capabilities of the analyst. This is integral to good visualisations.

Scientists should collaborate with designers/visualisation experts to produce better visualisation outputs.

Sequence bundles

This talk was given by the design agency Science-Practice that specialise in science-related projects in many disciplines. The sequence bundles came out of the effort to work out a new way of visualising protein chains in antibiotic resistance genes in MSA. Something to do with an entry for the Longitude Prize 2014 antibiotics challenge. Their pitch was “Designing visualisations to enable discovery of data features that would otherwise remain hidden.”

Design process

They talked through their design process: it was their process that helped them discover hidden information in the sequence datasets.

The first step was to learn about bioinformatics. Science-Practice are only a handful of people, but they have a scientist on staff in order to help the transfer of scientific knowledge into the design team. Necessary as they have projects in different scientific areas.

They played with various ideas of representing a protein sequence, but decided to focus on the sequence characteristic of it representing a chain of contiguous amino acids.

Having decided on a chain representation, their chosen way of comparing 1809 protein sequences was by graphing as a ribbon connecting the amino acids on the y-axis, and the sequence position on the x-axis. Partial transparency was very important here, in order to see patterns of overlap.

They then played about with many design elements, e.g. colour, spacing of the y-axis, filtering out different info… they changed the layout a few times, he showed one where they tried a string visualisation.

Their playing revealed some surprises that as far as they knew were not known to the data authors, for example a highly conserved residue at position 13. They also found some things that were not as obvious as expected, and there was some considerable variations from the consensus sequence. This was only discoverable because they decided to visualise each individual sequence in full, amino acid by connected amino acid. If they’d performed any kind of transformation on the sequence data before visualising it, these nuances would very likely have been missed.

Interesting that these discoveries came to light during the design process.

On the back of this they’ve developed a desktop tool, and a lighter weight web tool, to enable you to use the sequence bundle approach to visualise not only protein sequences, but also DNA and RNA sequences. The aim is to help scientists uncover information hidden within sequences without having to go through the design process themselves. They had a group of 70 users in a study that they interviewed and got feedback from during the development of the tool [not much info on the user research process, unfortunately].

Update: Science-Practice have pointed out that there is a report published as part of the Proceedings of the 3rd Annual Symposium on Biological Data Visualization: Data Analysis and Redesign Contests. It’s available at BioMedCentral: Sequence Bundles: a novel method for visualising, discovering and exploring sequence motifs (open access).

Closing

This was a great meetup. Thanks to the two speakers, and to William Spooner for organising. It was good to reconnect with old friends, and make some new ones. I hope I’ll be able to make the next one.

(P.S. This writeup is based on my hastily scribbled notes. I think it’s pretty accurate, but if you were speaking that night, and I’ve horribly misrepresented what you said, please get in touch so I can make things right.)

decodeuri

Web typography workshop with Rich Rutter

Readability

Reading distance

Type size

Vertical rhythm

Microtypography

Numbers

Tables

Font choice

OpenType

Variable fonts

SmashingConf London 2018

Preface

Some key points

Vitaly: New Front-End Adventures in Responsive Design

Sketch-related

Grid

Text

Images

Webfonts

3rd parties

CSS custom properties

Performance

ServiceWorkers

Links

Explore

Phil Hawsksworth: Making Platforms and Processes Promote Performance

Look more into

Rachel Andrew: into the weeds of CSS layout

Una Kravets and Martin Splitt: Beyond the basics of image optimisation

Techniques:

Andy Davies: “A/B testing, ads and other third party tags”

Zach Leatherman: Web font performance

Checklist:

No invisible text:

Reflow as little as possible, as soon as possible

Patrick Meenhan: How fast is it?

Metric recommendations

CrUX

Umaar Hansa: DevTools

Render performance

Paint indicators

Ilya Grigorik: Mystery speaker

Mathias Bynens: JavaScript Engine internals

Element kinds in V8

Katie Hempenious: Improving page performance in modern web apps

Remove unnecessary js

Delay js load

Use another tool or context

Bandwidth vs latency

Resource prioritisation

Yoav Weiss: Resource loading: past, present and future

HTTP/2

Critical rendering path: resource loading

Emily Hayman: Hitting 60 fps every time

Allison McKnight: “Building performance for the long term”

Jake Archibald: “In the loop”

CSS layouts: Rachel Andrew

multicol

Flexbox

Grid layout

Building a pattern library for scholarly publishing

Contents

Introduction

Deciding on an approach

Design systems and Atomic Design

PatternLab

Principles

Don’t lock out the readers

Maintain the value of the pattern library

Aims

Identifying and naming the patterns

Deciding on a process

Tickets

Board

Refinement

Code management

Build

Basic build pipeline