CSS Conf Au 2015 Day 1

- 5 min read

This is the first part of my CSS Conf Australia 2015 notes featuring speakers from the first day.

Shortcut to talks

  1. CSS For Humans - Matt Sawkill
  2. Colour in the real world - Katie Kurkoski
  3. 4½ methods for theming in (S)CSS - Harry Roberts
  4. Newton Meets CSS - Evangelina Ferreira
  5. Delivering responsibly - Scott Jehl
  6. Fundamentals of front end ops - Ian Feather
  7. Bye-bye Bootstrap bloat - Fiona Tay
  8. Let’s move - Benjamin de cock

CSS For Humans - Matt Sawkill

“Every hour you spend making the web faster, more accessible and easier to use, turns into days for real people”
– Matt Sawkill
  • You all work for people, you are the ultimate responsibility of whether it’s good
  • A lot of talk these days are focused on tooling, why aren’t we talking about who this stuff is for?
  • The web is an essential service like electricity
  • Worked on gov project to look at the web serivces, 60% of customers who filled out an online form had to print something out
  • Problems with government forms where the form wouldn’t let you complete
  • An example: a person from a culture without surnames wasn’t able to fill out because surname was required
  • Fixing these issues gave overwhelming positive feedback ‘It doesn’t look like a government website!’
  • On ‘Business Victoria’ there were 55 decision points on the homepage, 70% of the traffic were going down to one small section toward the bottom left of the page
  • Far fewer decisions to make – The site has a ‘navigation style’ interface
  • Co–designed with the government, they were deeply involved with user research and testing
  • By co–designing the people who are on the client team that collaborated were able to stand up for the work from their organisational point of view
  • Removed confusion, removed cognitive overhead. Made it 72% faster. Time to content (reduced intermediate pages).
  • Tools like Calibre are helpful to see the performance of the site.
  • Everyone should have a UX hat on, even if you’re an engineer.
  • Can’t just add UX at the end of the process
  • A concept ‘Assisted digital’ is about everyone using a web service
  • Affordance – Get angry about stuff that doesn’t make sense, don’t let badUX happen
  • If you solve these problems once, you’ve done the hard work for everyone else
  • Performance: set a budget. Measure what matters. The people paying for you work care about this.
  • Testing: there are no edge cases, Reframing accessibility for the web - Anne Gibson
  • Every hour you spend making the web faster, more accessible and easier to use, turns into days for real people

Colour in the real world - Katie Kurkoski

“Colour is progressive enhancement”
– Katie Kurkoski
  • Cochineal was one of the first chemical colours, it was and is made from beetles
  • Tyrian purple – fermented shelfish
  • Lead White – strips of lead in vinegar, paint and make up
  • What is colour? Wavelengths of light. X–ray, infrared, etc.
  • Additive, emitted light. Yellow + blue = green etc.
  • Subtractive, used for t-shirt/printed posters: Subtractive colour
  • How do we see colour? our eyeballs have cones for sensing green red and blue. Dogs only see yellow and blue
  • Not everyone has functional cones.
  • 4% of humans, 8% of men, 0.5% of women have a type of colour blindness
  • You probably support browsers that are less than 4% of your traffic
  • Deuteranopia is the most common – no or low green.
  • Protanopia is less common.
  • Colour is progressive enhancement
  • Some tools you can use to help: Color oracle, Spectrum.
  • Colour = sensors + brain. Example: The famous dress shared cross social media.
  • We can mix colours with Sass and SVG. Mix() can give you a finer result than lighten() or darken()
  • in SVG and Sass we can fill: mix($variable, complement($variable), 70%) to complement itself when mixing
  • Demos

4½ methods for theming in (S)CSS - Harry Roberts

  • Theming is common: SaaS clients, white–label, hub clients, social network clients
  • Difference from theming and customisation: on top of the design we can sit a theme, on top of a theme we can sit customisation
  • Theming requires dev input, finite amount of variants, known rules and constraints
  • Example: Jeremy Keith website, number of different themes – users can control which theme
  • Customisation is defined entirely by users. Myspace was an example, you could completely customize. Requires no dev input. Whatever user says goes.
  • More modern example: Twitter.com profile customisation
  • Advice on theming: avoid if possible, KISS. Only make changes to cosmetic aspects. Encorce rules - deviation is expensive. Use it as an up–sell.
  • No.1 Method: Theme Layer: Overriding default style with additional css. Most common approach. - suited to bespoke. New CSS overrides with different stylesheet. Good: Easy to plug in and remove, Bad: redundancy, wasted CSS, shards styles across multiple files.
  • No.2 Method: Stateful theming: Styling a UI based on a state or condition. Skins based on conditions, allow themes to be switched on the client. Example: Trello style switcher, BBC.
  • SMACSS style t- theming: .t-red .tabs
  • Stateful utility classes .t-red .u-color-curent { color: red; }
  • You can then put .u-color-current anywhere else on the site
  • The bad: bundles a number of themes, potential redundancy
  • No. 3 Method: Config theming. Compling the same CSS with different skin based on a setting.
  • Compiled server side
  • No. 4 Method: Theme palettes – holding entire themes in a palette file, preload all your theme settings into a palette. Suited to full theming for clients
  • No. 5 Method (half): User customisation – letting user style their own UI. Done through a CMS interface. User customisation can be bad if people start make bad choices (low contrast etc)
  • Lose the ability to cache these styles
  • When to use which method?
  • Who is doing the styling you or the user? – User customisation
  • do themes need to chance once they’re on the client – stateful or user customisation
  • Do you have toggle themes? – Stateful
  • Do you have sections of the site that need to look different? – Stateful
  • Do you have preset themes that a client can choose from? – Config theming
  • Do you offer bespoke theming for white–label clients? – Theme layer or theme palette.
  • Speakerdeck Slides

Newton Meets CSS - Evangelina Ferreira

  • Forwards makes the animation become permanantly the last state
  • Backwards the opposite, Infinite allows the animation to operate indefinitely
  • Steps() function divides the animation into steps. The number will be the quantity of frames across the animation. Steps can be like old frame film
  • Timing functions belong in transitions, better defined in transition than in animation
  • Why steps and not gifs? More than 256 colours, better way to handle opacity. better gradients. better quality.
  • The downside is you have to put the images together.
  • Speed: rate of change in object position in which it covers distance
  • Acceleration: Change in speed over time interval.
  • Gravity: speed increases over time, and so does the distance. This is what Cubic Bezier curves are
  • Apply newtowns 3rd law, action and reaction.
  • All 5 timing functions are cubic bezier curves with numbers (with 4 points)
  • A Cubic bezier curve can be represented as progress vs time on X and Y axis.
  • Negative in the progress will go back
  • Positve out of range will go beyond the limit of finish. Bigger numbers, more elastic.
  • These are animation concepts, not restricted to just the web
  • Slides

Delivering responsibly - Scott Jehl

“We need to build with empathy”
– Scott Jehl
  • Our sites seem to respond to all sorts of factors and conditions
  • It requires careful consideration, research, testing and creativity
  • We want to deliver sites that feel ‘at home’ on any given device
  • Our user interfaces need to respond and adapt to viewport size.
  • along with screen sized conditions, we need to pair the fidelity of components of what can be ‘expected’ of particular devices. This means we need to qualify the support. We don’t make enhancements that can break.
  • Our interfaces need to be usable and respond to a variety of input mechanisms.
  • Most devices offer multiple modes of interaction, we can’t make assumptions about any one input mode being in play at any given time. Often there are many at one time.
  • For CSS larger click areas, for JS having a standard click event and layering other input listeners on top of those
  • We need to respond quickly, speed broadens access
  • The greatest advantage to the web is reach, our sites tend to reach those under those with different conditions than the people making the sites, assumptions we make can inhibit our reach
  • Not just a matter of empathy, access is our job
  • It’s a missed opportunity, there is a business case for access.
  • Example: FB executives travelling through Nigeria – They realized that they were the exception
  • “Much of the world’s web traffic this year will come from cheaper under-featured devices’
  • As web designers we have the ability to impact those conditions. We need to build with empathy.
  • Access can be expensive, there’s a real cost to accesing the web. Disney.com weighs 4mb, in Vanuatu that costs $1.33 What does my site cost
  • Easy wins: optimize images, minify & gzip text. Optimize everything you can.
  • In addition to optimizing images, it makes sense to offer different sizes. Picture element/srcset/sizes
  • Framework bloat – reduce dependencies and remove what you can. It’s nice if you can avoid frameworks entirely. There’s always tradeoff.
  • Optimizations like this only getting us so far, the raw size isn’t the users biggest problem. The problem is the speed of light. Latency, not bandwidth. A trip to a server and back sometimes takes a lot of time. This is why CDNs matter, trying to make the round trips shorter.
  • Grace Hopper is awesome, and explains physicality of time: Grace Hopper – nanoseconds
  • What difference does 500ms make? Scott showed a word cloud of comments. 500ms faster - ‘easy to use.’
  • Focusing on perceived performance –, improve the perception of fast
  • The critical path represents the steps that occur between the request for a site and the things that happen imbetween render. Shortest, fastest path to render.
  • Great tools for testing the critical path Web page test, the summary page time to first byte and start render.
  • More interesting is the timeline view, actually showing you what people see when it actually loads
  • Google page speed tests - “identify and ‘inline’ the css necessary for rendering the above the fold content”
  • What Javascript is critical? ideally none. Feature tests. File loading function for additional assets, Conditional logic, Font loading listeners
  • Async loader loadCSS
  • Async script loader similar thing
  • Add a mustard cutter. BBC cutting the mustard technique
  • Font loading matters, Flash of invisible text (FOIT) will show no text on your site until the font loads
  • Wired optimization went from 12.5 second to 3.9 seconds first render/usable content after optimization. End result is identical, same amount of file size
  • The steps we can do today will look different in the long term thanks to HTTP/2
  • a feature called server push will request the assets related to a page, meaning no more inlining. No more spriting. But it will take a little time. Another layer of progressive enhancement.
  • To respond responsibly requires foresight.

Fundamentals of Front End Ops - Ian Feather

“Code review starts with a discussion when you’re designing a feature – not when you’re done”
– Ian Feather
  • ‘ the metric by which a front end operations engineer would be judged is speed’
  • ‘ stop throwing code over the wall!’
  • Create a certain number of gates for the code to go through to protect it
  • At no point should there any blame pointing at a particular person. Save & pre–commit
  • Linting and style compliance. Remove accidental code. This has to be fast.
  • Pre–commit hooks allow us to deal with accidental code. The first gate.
  • Post–push: our first async part of the pipeline. Code size, quality and complexity analysis.
  • Code review. Thoroughness > speed. An opportunity to share knowledge. Not a personal critique.
  • Github issues are littered with people criticising code styles, and that’s not an environment we want to foster
  • Continuous integration: a centralised, near-production environment. A series of task runners. A potential bottleneck.
  • Deployment: predictable, consistent, automated. Continuous deployment vs delivery. Delivery means we push lots of small pieces of code - makes it easier to track QA.
  • Enable a fast user experience. A broken app can’t have a good experience.
  • The network: understand protocols, plan for failure, get secure.
  • CDN: cache as much as you can, ensure it doesn’t disrupt development.
  • Browser: tune your cache hit rate, leverage new file formats like WOFF2, WebP etc. Keep an eye on frame rate.
  • Set up monitoring: JS errors, real user performance. Asset sizes.
  • Expose feedback: make it really accessible, reduce signal to noise ratio. Refine and evolve.
  • Use the feedback to decide what to work on. Remove HIPPOs from the equation

Bye–Bye Bootstrap bloat - Fiona Tay

“Versioning a UI framework is really difficult (understatement of the year)”
– Fiona Tay
  • Over time AirBNB css grew larger and larger
  • Why don’t we use a CSS framework?
  • O2: AirBnb forked bootstrap.
  • Why bootstrap worked? consistency, rapid development, performance, reliability
  • Had trouble in paradise with Bootstrap:
  • (Harry Roberts) Why people dont use CSS frameworks: bloated, unique, prescriptive/opinionated, all things to all people, get in your way
  • Tonnes and tonnes of jquery and custom components (bootstrap)
  • Rewriting O2 was a (necessary) leap of faith, including only the elements needed.
  • Rolled out in a course of a year. Being able to get away from the bootstrap conventions
  • The bootstrap navigation is undesirable, and wasn’t suitable for Airbnb
  • Flexibility: decoupling
  • Versioning a UI framework is really difficult (understatement of the year)
  • CSS changes often manifest in subtle, hard to discover ways.
  • Complicated by having to support multiple browsers
  • “Legacy code is untested code” - Michael Feathers
  • Upgrading bootstrap = difficult, but a known process
  • Documentation is great when economies of scale come into play
  • Legacy code is untested code.
  • A lot of problems have already been solved by bootstrap
  • Made rebrand really easy
  • A style guide is only as valuable as it is up-to-date
  • Keeping it in sync with design pulse is necessary
  • Use sinopia to do a private NPM server

Let’s move! - Benjamin De Cock

“Actual speed barely matters, perceived speed truly matters”
– Benjamin De Cock
  • Making visuals a little bit richer by bringing motion in
  • 4 pillars of good animations
  • Animate exclusively opacity and transform
  • Keep your animations fast (usually around 300ms)
  • Animate things independently
  • Always use custom easings
  • Why animate? because animations are fun, they make your product look more polished, and plenty of other valid reasons
  • Animations help understanding the flow between states
  • Remember me on stripe takes you to a new view. By animating into the new view it doesn’t disrupt the flow as much
  • Animation can make your app feel faster (but also slower, when used the wrong way)
  • Dribbbox - Fetches from the dribbble api, uses canvas to draw a gradient over the top
  • Used animation to change the perception of the speed of the fetch, the loading time is exactly the same
  • spinner, sent, confirmation, makes it seem fast
  • the whole animation is a lie, why do we lie to our customers? there’s always a small delay so we don’t know when its sent
  • its to change the perception
  • actual speed barely matters, perceived speed truly matters
  • One technique is to use two different easings inside the animation
  • make the animation linear but change the timing functions inside the animation declaration
  • Embrace JS, CSS won’t be enough
  • CSS is the best rendering engine for animations
  • use javascript to create and trigger these animations
  • why js? access to events. Allows you to chain animations - transitionend and animationend
  • define random durations, delays, positions
  • Fights your laziness and encourages you to think about new kind of animations
  • Animation example: break apart each letter and wrap with spans, animate each letter and animate with delay based on which order they’re in
  • Wrote animation helper
  • Code shouldn’t hurt your creativity. It should enhance it. It should give super powers.
  • 3d Transforms, how to bring depth into your animations
  • 3d helps a lot to show how objects behave and how they relate to each other
  • Skeumorphism shouldn’t be about how things look, but how things work
  • Using shaking animation to improve interface. Using 3d transform to make it rotate slightly. Animation on remember me on stripe. The 3d effect amiplifies the behaviour.
  • 3d unfolding animation – transform: perspective(500px) rotateX( -.25 turn), transform origin to the top.
  • Animate responsiblty and have fun !