Una has put together this handy one-pager of flexbox fallbacks for some common grid layouts.
Wednesday, April 25th, 2018
It feels a little strange to refer to Going Offline as “my” book. I may have written most of the words in it, but it was only thanks to the work of others that they ended up being the right words in the right order in the right format.
I’ve included acknowledgements in the book, but I thought it would be good to reproduce them here in the form of hypertext…
Everyone should experience the joy of working with Katel LeDû and Lisa Maria Martin. From the first discussions right up until the final last-minute tweaks, they were unflaggingly fun to collaborate with. Thank you, Katel, for turning my idea into reality. Thank you, Lisa Maria, for turning my initial mush of words into a far more coherent mush of words.
Jake Archibald and Amber Wilson were the best of technical editors. Jake literally wrote the spec on service workers so I knew I could rely on him to let me know whenever I made any factual missteps. Meanwhile Amber kept me on the straight and narrow, letting me know whenever the writing was becoming unclear. Thank you both for being so generous with your time.
Thanks to my fellow Clearlefty Danielle Huntrods for giving me feedback as the book developed.
Finally, I want to express my heartfelt thanks to everyone who has ever taken the time to write on their website about their experiences with service workers. Lyza Gardner, Ire Aderinokun, Una Kravets, Mariko Kosaka, Jason Grigsby, Ethan Marcotte, Mike Riethmuller, and others inspired me with their generosity. Thank you to everyone who’s making the web better through such kind acts of openness. To quote the original motto of the World Wide Web project, let’s share what we know.
Monday, April 23rd, 2018
All of this reminds me of Jake’s proposal for navigation transitions in the browser. I honestly think this would solve 80% of the use-cases for single page apps.
Tuesday, April 10th, 2018
This is such a great write-up of the workshop I did in Hong Kong!
Jeremy, it was a pleasure to work with you and you are always welcome here in Hong Kong!
If you fancy having this one-day workshop at your company, get in touch.
Friday, April 6th, 2018
An Event Apart Seattle just wrapped. It was a three-day special edition and it was really rather good. Lots of the speakers (myself included) were unveiling brand new talks, so there was a real frisson of excitement.
It was interesting to see repeating, overlapping themes. From a purely technical perspective, three technologies that were front and centre were:
- CSS grid,
- variable fonts, and
- service workers.
From listening to other attendees, the overwhelming message received was “These technologies are here—they’ve arrived.” Now, depending on your mindset, that understanding can be expressed as “Oh shit! These technologies are here!” or “Yay! Finally! These technologies are here!”
My reaction is very firmly the latter. That in itself is an interesting data-point, because (as discussed in my talk) my reaction towards new technological advances isn’t always one of excitement—quite often it’s one of apprehension, even fear.
I’ve been trying to self-analyse to figure out which kinds of technologies trigger which kind of reaction. I don’t have any firm answers yet, but it’s interesting to note that the three technologies mentioned above (CSS grid, variable fonts, and service workers) are all additions to the core languages of the web—the materials we use to build the web. Frameworks, libraries, build tools, and other such technologies are more like tools than materials. I tend to get less excited about advances in those areas. Sometimes advances in those areas not only fail to trigger excitement, they make me feel overwhelmed and worried about falling behind.
Anyway, all of this helps me understand my feelings at the end of An Event Apart Seattle. I’m fired up and eager to make something with CSS grid, variable fonts, and—of course—service workers.
Thursday, April 5th, 2018
This is absolutely brilliant!
Forgive my excitement, but this transcript of Charlie’s talk is so, so good—an equal mix of history and practical advice. Once you’ve read it, share it. I want everyone to have the pleasure of reading this inspiring piece!
It is this flirty declarative nature makes HTML so incredibly robust. Just look at this video. It shows me pulling chunks out of the Amazon homepage as I browse it, while the page continues to run.
Let’s just stop and think about that, because we take it for granted. I’m pulling chunks of code out of a running computer application, AND IT IS STILL WORKING.
Just how… INCREDIBLE is that? Can you imagine pulling random chunks of code out of the memory of your iPhone or Windows laptop, and still expecting it to work? Of course not! But with HTML, it’s a given.
Tuesday, April 3rd, 2018
A really deep dive into
display: contents from Ire.
Here are Torre’s notes on my talk at An Event Apart Seattle. (She’s been liveblogging all the talks.)
Navigating Team Friction by Lara Hogan
Lara started as a developer, and then moved into management. Now she consults with other organisations. So she’s worked with teams of all sizes, and her conclusion is that humans are amazing. She has seen teams bring a site down; she has seen teams ship amazing features; she has seen teams fall apart because they had to move desks. But it’s magical that people can come together and build something.
Bruce Tuckman carried out research into the theory of group dynamics. He published stages of group development. The four common stages are:
- Forming. The group is coming together. There is excitement.
- Storming. This is when we start to see some friction. This is necessary.
- Norming. Things start to iron themselves out.
- Performing. Now you’re in the flow state and you’re shipping.
So if your team is storming (experiencing friction), that’s absolutely normal. It might be because of disagreement about processes. But you need to move past the friction. Team friction impacts your co-workers, company, and users.
An example. Two engineers passively-aggressively commenting each other’s code reviews; they feign surprise at the other’s technology choices; one rewrites the others code; one ships to production with code review; a senior team member or manager has to step in. But it costs a surprising amount of time and energy before a manager even notices to step in.
The Hulk gets angry. This is human. We transform into different versions of ourselves when we are overcome by our emotions.
Lara has learned a lot about management by reading about how our brains work. We have a rational part of our brain, the pre-frontal cortex. It’s very different to our amygdala, a much more primal part of our brain. It categorises input into either threat or reward. If a threat is dangerous enough, the amygdala takes over. The pre-frontal cortex is too slow to handle dangerous situations. So when you have a Hulk moment, that was probably an amygdala hijack.
We have six core needs that are open to being threatened (leading to an amygdala hijacking):
- Belonging. Community, connection; the need to belong to a tribe. From an evolutionary perspective, this makes sense—we are social animals.
- Improvement/Progress. Progress towards purpose, improving the lives of others. We need to feel that we do matters, and that we are learning.
- Choice. Flexibility, autonomy, decision-making. The power to make decisions over your own work.
- Equality/Fairness. Access to resources and information; equal reciprocity. We have an inherent desire for fairness.
- Predictability. Resources, time, direction future challenges. We don’t like too many surprises …but we don’t like too much routine either. We want a balance.
- Significance. Status, visibility, recognition. We want to feel important. Being assigned to a project you think is useless feels awful.
Those core needs are B.I.C.E.P.S. Thinking back to your own Hulk moment, which of those needs was threatened?
We value those needs differently. Knowing your core needs is valuable.
Lara has seen the largest displays of human emotion during something as small as moving desks. When you’re asked to move your desk, your core need of “Belonging” may be threatened. Or it may be a surprise that disrupts the core need of “Improvement/Progress.” If a desk move is dictated to you, it feels like “Choice” is threatened. The move may feel like it favours some people over others, threatening “Equality/Fairness.” The “Predictability” core need may be threatened by an unexpected desk move. If the desk move feels like a demotion, your core need of “Significance” will be threatened.
We are not mind readers, so we can’t see when someone’s amygdala takes over. But we can look out for the signs. Forms of resistance can be interpreted as data. The most common responses when a threat is detected are:
- Doubt. People double-down on the status quo; they question the decision.
- Avoidance. Avoiding the problem; too busy to help with the situation.
- Fighting. People create arguments against the decision. They’ll use any logic they can. Or they simply refuse.
- Bonding. Finding someone else who is also threatened and grouping together.
- Escape-route. Avoiding the threat by leaving the company.
All of these signals are data. Rather than getting frustrated with these behaviours, use them as valuable data. Try not to feel threatened yourself by any of these behaviours.
Open questions are powerful tool in your toolbox. Asked from a place of genuine honesty and curiosity, open questions help people feel less threatened. Closed questions are questions that can be answered with “yes” or “no”. When you spot resistance, get some one-on-one time and try to ask open questions:
- What do you think folks are liking or disliking about this so far?
- I wanted to get your take on X. What might go wrong? What do you think might be good about it?
- What feels most upsetting about this?
You can use open questions like these to map resistance to threatened core needs. Then you can address those core needs.
This is a good time to loop in your manager. It can be very helpful to bounce your data off someone else and get their help. De-escalating resistance is a team effort.
Listen with compassion, kindness, and awareness.
- Reflect on the dynamics in the room. Maybe somebody thinks a topic is very important to them. Be aware of your medium. Your body language; your tone of voice; being efficient with words could be interpreted as a threat. Consider the room’s power dynamics. Be aware of how influential your words could be. Is this person in a position to take the action I’m suggesting?
- Elevate the conversation. Meet transparency with responsibility.
- Assume best intentions. Remember the prime directive. Practice empathy. Ask yourself what else is going on for this person in their life.
- Listen to learn. Stay genuinely curious. This is really hard. Remember your goal is to understand, not make judgement. Prepare to be surprised when you walk into a room. Operate under the assumption that you don’t have the whole story. Be willing to have your mind changed …no, be excited to have your mind changed!
This tips are part of mindful communication. amy.tech has some great advice for mindful communication in code reviews.
Mindful communication won’t solve all your problems. There are times when you’ll have to give actionable feedback. The problem is that humans are bad at giving feedback, and we’re really bad at receiving feedback. We actively avoid feedback. Sometimes we try to give constructive feedback in a compliment sandwich—don’t do that.
We can get better at giving and receiving feedback.
Ever had someone say, “Hey, you’re doing a great job!” It feels good for a few minutes, but what we crave is feedback that addresses our core needs.
|General||Specific and Actionable|
The feedback equation starts with an observation (“You’re emails are often short”)—it’s not how you feel about the behaviour. Next, describe the impact of the behaviour (“The terseness of your emails makes me confused”). Then pose a question or request (“Can you explain why you write your emails that way?”).
observation + impact + question/request
Ask people about their preferred feedback medium. Some people prefer to receive feedback right away. Others prefer to digest it. Ask people if it’s a good time to give them feedback. Pro tip: when you give feedback, ask people how they’d like to receive feedback in the future.
Prepare your brain to receive feedback. It takes six seconds for your amygdala to chill out. Take six seconds before responding. If you can’t de-escalate your amygdala, ask the person giving feedback to come back later.
Think about one piece of feedback you’ll ask for back at work. Write it down. When your back at work, ask about it.
You’ll start to notice when your amygdala or pre-frontal cortex is taking over.
Talking one-on-one is the best way to avoid team friction.
Retrospectives are a great way of normalising of talking about Hard Things and team friction.
It can be helpful to have a living document that states team processes and expectations (how code reviews are done; how much time is expected for mentoring). Having it written down makes it a North star you can reference.
Mapping out roles and responsibilities is helpful. There will be overlaps in that Venn diagram. The edges will be fuzzy.
What if you disagree with what management says? The absence of trust is at the centre of most friction.
|Commit||Mature and Transparent||Easiest|
|Don’t Commit||Acceptable but Tough||Bad Things|
Practice finding other ways to address B.I.C.E.P.S. You might not to be able to fix the problem directly—the desk move still has to happen.
But no matter how empathic or mindful you are, sometimes it will be necessary to bring in leadership or HR. Loop them in. Restate the observation + impact. State what’s been tried, and what you think could help now. Throughout this process, take care of yourself.
Remember, storming is natural. You are now well-equipped to weather that storm.
Here are Luke’s notes from the talk I just gave at An Event Apart in Seattle.
Announcing Going Offline from A Book Apart
I decided that I wanted a new mug.
I already have one very nice mug. It was sent to me by A Book Apart because I wrote the book HTML5 For Web Designers back in 2010. If I wanted another nice mug, it was clear what I had to do. I had to write another book.
I think you will enjoy this book. Here’s why…
Does that sound like you? Then Going Offline is for you.
Thinking about it, a more accurate title for the book would’ve been Service Workers For Web Designers …although even that would assume too much existing knowledge (like, what the heck a service worker is in the first place).
Pre-order Going Offline today and it will be in your hands in just a few weeks.
Alas, I have no idea when my new mug will be ready.
Wednesday, March 28th, 2018
Hells, yeah! Want to make an accordion widget? Use the
details element as your starting point and progressively enhance from there.
Tuesday, March 27th, 2018
The canonical example in just about every pattern library is documenting button variations. Here, Tyler shows how even this seemingly simple pattern takes a lot of thought.
Friday, March 9th, 2018
A workshop on building for resilience
The workshop is called The Progressive Web: Building for Resilience. Here’s an excerpt form the blurb:
This workshop will show you to to think in a progressive way that works with the grain of the web. Together we’ll peel back the layers of the web and build upwards, creating experiences that work for everyone while making the best of cutting-edge browser technologies. From URL design to Progressive Web Apps, this journey will cover each stage of technological advancement.
Basically, it’s the workshop version of Resilient Web Design. If that book is the theory, this workshop is the practice.
Tim recently posted his tips for running workshops and there’s a lot in there that resonates with me. Like Tim, I’ve become less and less reliant on slides. In fact, this workshop—like my workshop on evaluating technology—has no slides. Instead it’s all about the exercises and going with the flow.
After starting with a warm-up, I canvas the room to see if there any specific topics, tools or technologies that people are particularly interested in covering. I’ll note those (on post-its slapped on the wall) for reference throughout the day, to try to make sure that those particular things are touched on at some point. Then I start with a thought experiment…
First of all, I get everyone to call out websites, services and apps that they use almost every day: Twitter, Facebook, Gmail, Slack, Google Docs, and so on. Those all get documented on the wall. Then it’s time to ask of each product, “What is the core functionality?” The idea here is to get beneath the surface-level verbs like swiping, tapping and dragging to get to the real purpose of a service: buying, selling, sharing, reading, writing, collaborating, and so on.
At this point I inform the attendees that the year is 1995. And now we’re going to build these services using the technology of this time. This is a playful way of getting answers to the question “What’s the simplest technology to enable the core functionality?” It’s mostly forms, links, and lots of heavy lifting on the server.
Next, we apply this layered mindset to a new service. I split the attendees into groups, and each of them gets a procedurally-generated startup idea …generated by shuffling some cards. This is an exercise I first tried when I was teaching in Porto:
I made five cards with types of sites on them: news, social network, shopping, travel, and learning. Another five cards had subjects: books, music, food, pets, and cars. And another five cards had audiences: students, parents, the elderly, commuters, and teachers. Everyone was dealt a random card from each deck, resulting in briefs like “a travel site about food for the elderly” or “a social network about music for commuters.”
The first few exercises are good creative fun: come up with a name, then a logo, then a business model. Then it’s time to build. It starts with URL design. Then it’s content prioritisation (for a representative URL). Then it’s layout (sketching!). The enhancements have begun. “How might this URL benefit from Ajax?” “How might this URL benefit from geolocation?” “How might this URL benefit from offline storage?” “How might this URL benefit from a service worker?”
At this point, we’ve applied the layered, progressive approach at the scale of an entire service, and at the scale of an individual URL. Finally, we apply the same approach at the level of a component. It might be a navigation, or a carousel, or an interactive widget. In each case, the same process applies: “What’s the core functionality? What’s the simplest technology to enable that functionality? Enhance!”
Along the way, there are plenty of rabbit holes we can go down. Whether it’s accessibility, or progressive web apps, or pattern libraries, I go along with whatever people are curious about. But all of it ties back to the progressive, layered mindset I’m hoping to foster.
By the end of the day, I’m hoping that an attendee has one of two reactions:
- “What a waste of time! Everything in that workshop was blindingly obvious!” (in which case, excellent!—they’re already thinking in a progressive way), or
- “That workshop has completely changed the way I think about building on the web!” (I’m being hyperbolic here, but at the very least I’m hoping to impart a new perspective).
Having given the workshop a few times, I’m really pleased with how it went (and more important, I’m pleased that people enjoyed it). If this sounds like something that your company or team would enjoy, get in touch and we can take it from there.
Wednesday, March 7th, 2018
Thursday, March 1st, 2018
Browsers have had consistent scrolling behavior for years, even across vendors and platforms. There’s an established set of physics, and if you muck with the physics, you can assume you’re making some people sick.
Guidelines to consider before adding swooshy parallax effects:
- Respect the Physics
- Remember that We Call Them “Readers”
- Ask for Consent
Given all the work that goes into a powerful piece of journalism—research, interviews, writing, fact-checking, editing, design, coding, testing—is it really in our best interests to end up with a finished product that some people literally can’t bear to scroll through?
Wednesday, February 28th, 2018
Offline itineraries with service workers
The Trivago website is a progressive web app. That means it
The service worker provides an opportunity for a nice bit of fun branding—if you lose your internet connection, the site provides a neat little maze game you can play. Cute!
That’s a fairly simple example of how service workers can enhance the user experience when the dreaded offline situation arises. But it strikes me that the travel industry is the perfect place to imagine other opportunities for offline enhancements.
Travel sites often provide itineraries—think airlines, trains, or hotels. The itineraries consist of places, times, and contact information. This is exactly the kind of information that you might find yourself trying to retrieve in an emergency situation, like maybe in a cab on the way to the airport or train station. Perhaps you’re stuck in traffic, in a tunnel. Or maybe you don’t have a data plan for the country you’re currently in. Either way, wouldn’t it be great if you could hit the website for your airline or hotel and get your itinerary, even if you’re offline.
Alright, let’s think this through…
Let’s assume that an individual itinerary has its own URL. That URL is a web page of information, mostly text, with perhaps an image or two (like a map). Now when you make your booking, let’s have the service worker cache that URL (and its assets) for offline access.
Hmm …but there’s a good chance that the device you make the booking on is not the same device that you’d have with you out and and about. Because caches are local to the browser, that’s a problem.
Okay, but of these kinds of sites have some kind of log-in mechanism. So we could update the log-in flow a bit: when a user logs in, check to see if they have any itineraries assigned to them, and if they do, fire off an event to the service worker (using
postMessage) to cache the URLs of the itineraries.
Now that the itineraries are cached, the final step is to create a custom offline page. As well as the usual “Sorry, the internet’s down” message, we can say “Sorry, the internet’s down …but here are your itineraries”. (This is kind of like the pattern you see on blogs like mine, Ethan’s, or Mike’s—a custom offline page that lists cached URLs of articles you’ve previously visited).
That’s just one pattern off the top of my head. It’s fun to imagine the different ways that service workers could be used to enhance the experience of just about any site, but they seem particularly relevant to travel sites—dodgy internet connections and travelling go hand-in-hand. At Clearleft, we’ve been working with quite a few travel-related clients lately so that’s why these scenarios are on my mind: booking holidays, flights, and so on. But, as I’ve said before and I’ll say again, every website can benefit from becoming a progressive web app.
Tuesday, February 27th, 2018
Although design gets conflated with creation, its the act of improving what already exists — organising a room, editing a text, refining an interface, refactoring a codebase — that I enjoy the most.
Here’s a really smart approach to creating container queries today—it uses
ResizeObserver to ensure that listening for size changes is nice and performant.
There’s a demo site you can play around with to see it in action.
While the strategy I outline in this post is production-ready, I see us as being still very much in the early stages of this space. As the web development community starts shifting its component design from viewport or device-oriented to container-oriented, I’m excited to see what possibilities and best practices emerge.