July 30, 2019 | Day 2 – Session 6

Dave Rupert is pretty much just the coolest. He’s from Austin,

We are entering the 9th or 10th year of responsive web design and he thinks it’s a good time to step back and reflect on where we’ve been and where we are now.

He’s been doing a lot of ‘rehabbing’ websites that he’s been doing in the last few years but first let’s do a history refresher.

2010
A blog post by Ethan Marcotte that then turned into a book in 2011 – Responsive Web Design. In it, Ethan proposed 3 techniques that help us deal with the changing landscape. We were making desktop websites and m. websites and poorly maintaining them. He proposed 1. flexible grids, 2. fluid media, and 3. media queries. He smashed them together and made a website that works as well on a phone as it does on a desktop.

Dave was so mad at Ethan because he had mastered pixel-perfect web design and eventually he got it figured out.

RWD is just a technique that we apply to our websites.

But it didn’t stop there – then we learned to think ‘Mobile First’ (Luke Wroblewski). Instead of squeezing desktops down to a phone, and instead of doing that we should make a mobile site that expands out to desktops.

Then a lot of us had to learn SASS to do our job and then experimenting with Web Fonts, and then we had to build our responsive websites responsibly. And then we realize we need to build our websites for touch. Then Ethan pitched back in with ‘Responsive Web Design part 2’ (Patterns & principles), then David teaches you how to make money doing RWD, and Karen wrote a book about ‘going responsive.’

Karen threw in her work with consulting and working with lots of companies making the transition to RWD, and realized that a lot of how we used to make websites doesn’t work anymore. The old waterfall process doesn’t work anymore. A lot of websites as they were making a responsive website they realized the process wasn’t working.

RWD then stopped becoming a technique and more of a philosophy.

BUT IT JUST KEPT GOING!
Then we had to learn GIT to deploy our website and SVG which are images made with math, had to learn JS and stinking Command Line from the 70’s, had to learn animation with CSS, had to learn how to put a webfoot on a webpage cuz it’s kind of not that easy, we had to remind ourselves oh yeah! this internet is for everyone and needs to be accessible. We had to learn a whole new layout (flexbox then grid), learn how to put an image on a webpage (a whole book!), how to make progressive web apps, and then design systems.

Looking at the data you can see this trend of complexity growing and growing.

So he chooses to flash back to the year 2014 – this is the year that a lot of organizations actually started building out responsive websites.

From 2014 to now, the average mobile website has basically tripled in size from 560kb to nearly 1.7Mb. Yowza! JS isn’t the only problem – it’s gone up 2.5x, but CSS has tripled in size, and he thinks this is curious because he doesn’t think we have 3x the amount of design problems we’re solving. He wonders if it’s frameworks, if it’s us being lazy…. Images is where most of it comes from – they’ve gone up about 600kb or so in the last 5 years.

He feels 2 conflicting ways about this. 1) you absolutely have an image problem on your website. He bets you $100 he can find an unoptimized image on your homepage right now. 2) not my fault, man! Retina displays and triple retinas happened and that’s an external factor that required him to triple the size of his images. We have a lot of visual stuff that is happening!

In some ways he feels like ‘wow this is not exactly our fault’ and at the same time ‘you can make it better, just optimize your damn image.’

There are Gzipped vs Unzipped stats.
Gzipped refers to the transfer speed, and Unzipped reflects the amount of time the CPUs are going to take after it’s unzipped and load all of it, or even the maintenance cost.

All bytes are not equal.
JS bytes that have to be downloaded, parsed, and executed and cause a style recalculation on the client are more expensive than CSS bytes. JS bytes are about 6x CSS bytes right now.
Image bytes are memory intensive and ore expensive to resize on the device itself. It’s expensive not just on the CPU but also on the battery.

But aren’t mobile phones and mobile connection speeds getting faster? Won’t this problem go away? you may ask…

Yes, but no.

Let’s look at the data!

Our websites are getting slower faster than devices are getting faster.

We’re out crappy-ing these miracle devices in our pockets. Something to think about…

Why does this matter?
DoubleClick did a study and found out that 53% of visits are abandoned if a mobile site takes more than three seconds to load. Yikes!

In most cases there is a big disparity between what users want and what we’re delivering.

Dave wants to look at some examples of how we can try to meet this gap.

Khoros – a social media platform
They started with one company, had a 6 month contract to build a new site (to rehab it), but it went through a merger, and 3 weeks after the merger there was a new Creative Director, and a bit after that there was a new CMO, and they were told they still needed to deliver the site in March even though they wouldn’t get the new company’s branding elements until February. So, they built a design system and when they got the branding they skinned the design system, and were able to quickly put out the site.

Austin Chamber of Commerce – the COC sites end up being a lot like nonprofit sites. They collect a lot of information because their job is to drum up business or the city. So there is a lot of pages and posts and content. They made a design system for them (about 3 months) and then they handed it off to a design team who took 3 months to integrate it into their CMS. What’s cool about is they stopped asking Dave for design help at some point. They were like ‘oh hey, we built a whole page based on the components you gave us.’ Oh, that’s cool!

Papa John’s – The site was built by HappyCog in 2013 and handed off to the client, and then it grew… by a lot. They were delivering 1MB of CSS and 1MB of JS being delivered to the client. THAT’S A LOT.
37,000 lines of CSS is really hard to work in. It’s kind of like whenever you have to change a button you have 37,000 land mines you could step on. They tried to explain that this was really hard to work in and they pitched making a design system to make the CSS more manageable.

Step 1: Interface Inventory
They did an interface inventory and found 32-ish buttons on the site. About 20 of them were green with different font weights, text, padding, shapes. 14 different product cards which is ironic for a company that sells one product more or less. 3 footers, 5 headers, etc.

Step 2: Measure
They like to use cssstats.com – a really good tool to analyze your CSS and get a 10,000 foot view to analyze your site.
He got some stats and then ran it through lighthouse which is a dev environment that you can get some numbers from.

Step 3: Patternize
Once they got their real data, they patterned. They built a style guide / pattern library. They got the colors down to 16 colors and half of them were greige… then they tackled the button problem and got the 32 buttons down to about 9 (3 sizes, 3 different conveyances). Then they took the product cards and got it down to 5 with distinct meanings (like a pizza card and then a featured product card, then a banner card for the big thing, and a special offer card for the meal-deal, and a HERO offer card which goes under the HERO unit).

Step 4: Measure Change
They ended up with 28 major components, 68 total variants (flavors of the components), and 105 pages built out.

They feel very strongly that your design system has to have specific targeted pages you’re designing against.
Some people may say ‘oh you made a prototype’ and he says ’no, I made a test case.’ Like if he changes a button he has 105 pages he can go check to see if it messaged anything up.

This helps design a lot of discussions:
With any design system, somebody could come and say ’this doesn’t work’ and you can answer ‘oh that’s interesting it worked for 105 other pages, what’s not working for you?’

Source Map Explorer – you chuck your source maps at this tool and it will spit out a tree map of your site. Before you can see a 1MB map of the old file, and After you can see the 100kb file of the new file.

With this map he can look at the data this tool spits out and estimate the weight and impact on a new element or variant on the design system or the website’s performance / load.

With Papa John’s, they reduced by rules by 83%, selectors by 91%, floats down by 99%, unique colors down by 69%… but what’s interesting is that he noticed there were #333 and #333333 so he fixed that and the colors are now down by 75% 😉

The performance improved, accessibility improved, SEO improved (data from Lighthouse). Lighthouse tells you exactly what’s wrong with your website and exactly how much time it can beef up your website. If they follow the advice from Lighthouse they know based on their estimations they’ll be within the green-zone (under 3s!).

First CPU idle was hugely improved which helps reach this goal of the site loading in 3s or less (especially on mobile).

Managing JS

In the last 5 years the JS ecosystem has matured in an MPM (a managed packaged format) which is a command line tool that will install things for you.

What’s neat about it is it will not only install things but install the things that thing needed to install, and quickly you have about 1000 packages, but hey at least it’s organized?

It generates this files called package.json
* it tells you dependencies – the base JS elements required for your thing to run.
* In your base JS file you import the thing you need from the thing you need, then you export.
* this is pretty cool and pretty simple, you’re importing and exporting.

But they didn’t have that with Papa John’s, it was a 1MB jQuery ‘App’ which is like looking at a bowl of spaghetti and saying ‘yeah, that’s useful…’

So he went through all 67 files and looked for a unique identifier and found how many times that thing was being used, how many dependencies it has… in a jQuery app you just put the files in the right order that’s how execution happens, but that’s not really great because what if something is out of order…

And he discovered some things you might not need anymore, like:

• matchMedia polyfill which you don’t need anymore
• respond.js was a library to add media queries to IE8, you don’t need that anymore
• Modernizr – not sure you need this anymore
• Picturefill – contentious – you technically need it for IE11
• HTML5shiv – you don’t need that anymore, every browser has HTML5 now
• FastClick – don’t need it anymore, what this was fixing went away
• LoadCSS – you don’t need this anymore (he found that out like last week)
• Webfontloader.js was a tool to display web fonts, but we don’t need it anymore
• Require.js was a little thing you used to use to load JS but you don’t need it!
• jQuery.?!!!!!? – this is on here because jQuery was very helpful for a time – but a lot of the problem it solved are now in the browser.

It sort of feels like malpractice to write jQuery now to him – you don’t need it, it’s just adding extra bytes, let’s move away from it…

However he looked at the Papa John’s JS package and all of those items require jQuery.

He did the math to figure out it was 20 weeks of human work to replace that file and then you still had a jQuery app… so it helped inform conversation to discuss if a framework would be better.

JS frameworks have kind of a bad name so he likes to call them DOM managers because they help you to make sense of your code.

That which is not managed grows.

CSS has a bad rep – it just grows and grows and grows. And it does!

You need a way to manage your CSS and JS.

You need to inventory and measure!

Building a design system / pattern library helps you if you’re trying to manage your CSS. Using an MPM is helpful for JS.

Creating a Design System

A design system is when a group of people come together and assemble patterns.

He’s seen a people push a design system to the cloud and then they loved it. He’s also seen a bunch of people get ready to push a design system to the cloud and get taken away from it.

The puzzle pieces – creating the design systems – is not the hard part. The hard part is the people part.

“Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organization.” – Melvin Conway

“Your website is a manifestation of your organization’s problems.” – Dave Rupert

Websites are artifacts of our organizations, and it shows.

Any successful web product he’s been on has buy-in from someone on the client side at the top who controls the project and has buy-in to a design system.

JS Frameworks

Angular, React, Vue are made by Google, Facebook, and a guy named Evan Muse

These are incredibly popular. what’s interesting about JS frameworks s that they’re solving the design system problem from the JS side.

It’s all about components.

There are other buzzwords like JAMStack (you can write html and use JS to fetch cool stuff from a server), and GraphQL. Serverless is another buzzword and a cool thing he’s interested in.

Mobile has hit the tipping point in 2019.

Looking at an internet trends report, time on mobile device is ballooning but it’s not eating away at time on other devices, we’re just doing triple more.

One thing he noticed in this report is that mobile time spent on mobile is now more than television. That’s huge. That’s going to affect ad spends and those sorts of things.

Even what he’s seeing in clients is that it’s all mobile.

The big thing about the tipping point is we have a huge gap we have to close on the speed of our web pages.

Let’s go forward to 2024

Some things he’s excited about:

Web Components are an attempt to build that JS component stuff into the browser. That’s kind of handy, might save you some CPU cycles…

December 15, 2014 – Firefox advocated for ‘we’re going to see how this JS Components thing shakes out and wait on it’ and that kind of killed the HTML side of web components in Dave’s opinion.

Web Components Part 2:
There are 2 components on the web component table he’d like if we could tweet about.

1. if statements and for loops written into the browser
2. Unity component specification proposed by Edge

Web Assembly – you can compile C++ code into something the browser understands. There’s a lot of powerful technology that was written in stuff that doesn’t work on the web. Web Assembly gives this old code an opportunity to live again on the web. Example: Image optimizers

Liquid.lab.lorenzocadamuro.com
Doing water based physics in the browser. Javascript is bad at math. This in Javascript would melt your computer.

perceptiontoolkit.dev
This is in Chrome an dit’s an AI in the browser that you can program to scan a barcode or a logo and it will pop up a link to a URL. You could scan a product and it shows you the price. You can train a model on your phone and program it however you want.

What’s cool about this is Web Assembly came in and said oh for browsers that don’t support this, we built it in Web Assembly using a polyfill. Polyfills in browsers for future stuff – so cool!

CSS Houdini
Gives you the ability to control the painting, compositing, and layout of a website. example: https://css-houdini.rocks/rough-boxes You can control the browser and how it paints object. We’re not limited to squares anymore! You can make irregular grids!

MOBILE FIRST
ONCE MORE, WITH FEELING

If you’ve gotten anything from his talk, he thinks we really need to evaluate how we think of websites and mobile in that interaction. The time has come, the tipping point has happened and we need to be way way way more mobile first and close that gap.