On 15/16 March I headed over to Oxford for Smashing Conference. The speaker lineup was packed with great minds, so naturally I learned a few things. Here’s a quick summary.
There were plenty of mentions of HTTP/2 throughout the week, most referenced it as a way to do away with having to concatenate All The Things. However there was one dedicated, in-depth talk on HTTP/2 by Patrick Hamann and that offered perhaps the best advice on how we will change our workflow when it comes to concatenation.
The future of concatenation?
Instead of, say, just serving potentially hundreds of JS and CSS files individually and therefore failing to take advantage of the glorious nature of compression algorithms we should split our current mega bundles into smaller packages that are grouped based on how likely they are to change. This should mean we aren’t sending bloated files over the wire whilst making sure we aren’t having to invalidate huge files because one line has changed (at least not too often).
Advantage of switching
Even without changing their workflow, Patrick showed how the FT has improved site performance by switching to HTTP/2 with very little effort.
Change blindness is a concept I hadn’t come across before and Chris Shiflett gave a great introduction to it. In essence, when there is a clear visual interruption whilst doing something we’re often blind to any subtle changes that have taken place.
This was demoed to the room by displaying a photo which was interrupted with a flash of white and then a subtle change taking place during the flash. Most of the room was unable to spot the change, even though we knew a change would happen.
In simple terms this was being used to show how something as harmless as a page refresh can make it quite difficult for users to know anything has changed. This is particularly useful to bare in mind when working with form validation. There are two take aways from this:
- If possible AJAX the change into the page without refreshing
- If it isn’t make the change visually obvious
This is a small thing. Just how Carlsberg have elevated simple age verification validation above the standard select boxes using sensible validation. See Carlsberg’s example to see what I mean. It is deceptively clever:
- Defaults to 19xx as it’s not(currently) possible to pass the validation with a date in the 00s
- If you choose the year that is the current borderline (where people can be either 17 or 18) then it asks for the month and if you then choose the current month then you have to select a day to prove your age
- If you choose a year that is before the border, then you are allowed into the site without having to put a month or day in
This means that most users don’t have to do anything more than tap 2 keys. Only those that need to provide finer detail have to do so. We could all apply this kind of thinking to our data validation.
I loathe HTML emails and try to avoid them if I can. However I did discover a tiny trick which may come in useful.
Outlook has very patchy support for the margin property, often ignoring our declarations altogether. However one, slightly hacky method means that using an uppercase M (e.g. Margin-top: 10px; rather than margin-top: 10px;) Outlook will use our declaration.
Two talks focussed on layout at the conference and both had tons of useful information. A couple of things stood out.
Creative use of what we already have
Vasilis can Gemert focussed on how we can use the inherently flexible nature of modern CSS to create new types of layout. His use of ems when using CSS Columns was a subtle yet useful tip which I’ll keep in mind.
Flexbox isn’t slow
Christopher Wright walked us through the newer features of CSS such as Flexbox and CSS Grids. The thing I found intriguing though, was the research he’d done to find the truth behind Jake Archibald’s assertion that we shouldn’t use Flexbox for page-level layout. In short there is little evidence that Flexbox is expensive to layout in modern browsers using the correct spec. So go ahead and Flexbox away (responsibly)
My final thoughts come from Umar Hansa‘s talk on some of the new features in Chrome’s dev tools.
There were loads of new things I’ll be checking out, including the following:
Chrome will soon have a draggable visual layout editor. This means you can avoid trial and error using the arrow keys to see how something would look with certain values and instead just drag it to look how you’d want. This should rapidly speed up our workflow when tweaking a design.
We can now right click a resource in the network panel and block it loading on future page loads. This helps us to test what happens where an external service we rely on suddenly fails. My main use for this is going to be simulating Typekit being down, which seems to happen just often enough to have to worry about.
Chrome will soon have several ways of evaluating how accessible your webpages are. One thing that will have an obvious use is related to colour. When using the colour picker tool, a curved line will appear over the options. Anything below the line will pass the minimum contrast guidelines.
Most of us are working with high-end machines which rarely suffer from performance when using websites. However plenty of other devices in the world may be running our sites in more severe conditions. One particular problem with handheld devices is the comparative lack of CPU power on them. Chrome will soon have an option to throttle your own CPU to simulate the effect of using your site on a slower device. This will be great when working hand-in-hand with network throttling.
So in short, I learned a fair amount this week. Now to put it all to good use…