Journal 2500 Links 7609 Articles 70 Notes 3896
What you write might help someone understand a concept that you may think has been covered enough before. We each have our own unique perspectives and writing styles.
Yes! This!!
That voice telling you that people are just sitting somewhere watching our every step and judging us based on the popularity of our writing is a big fat pathetic attention-needing liar.
I strongly recommend that you read Going Offline by Jeremy Keith. Before his book, I found the concept of service workers quite daunting and convinced myself that it’s one of those things that I’ll have to set aside a big chunk of time to learn. I got through Jeremy’s book in a few hours and felt confident and inspired. This is because he’s very good at explaining concepts in a friendly, concise manner.
The beauty of this approach is that the site doesn’t ever appear broken and the user won’t even be aware that they are getting the ‘default’ experience. With progressive enhancement, every user has their own experience of the site, rather than an experience that the designers and developers demand of them.
A case study in applying progressive enhancement to all aspects of a site.
Progressive enhancement isn’t necessarily more work and it certainly isn’t a non-JavaScript fallback, it’s a change in how we think about our projects. A complete mindset change is required here and it starts by remembering that you don’t build websites for yourself, you build them for others.
Dipphead.
Myself and @dhuntrods really enjoyed our visit to the digitisation department in the Natural History Museum. Thanks, Jen, Josh, Robin, Phaedra, and @scuff_el!
A terrific piece by Hidde, about CSS grid, but also about a much bigger question:
I don’t think we owe it to any users to make it all exactly the same. Therefore we can get away with keeping fallbacks very simple. My hypothesis: users don’t mind, they’ve come for the content.
If users don’t mind, that leaves us with team members, bosses and clients. In my ideal world we should convince each other, and with that I mean visual designers, product owners, brand people, developers, that it is ok for our lay-out not to look the same everywhere. Because serving good-looking content everywhere is more important than same grids everywhere.
Badass ballet in the rain. 💃🏻 🌧
Checked in at Firle Place. with Jessica
I think we often focus on designing or building an element, without researching the other elements it should connect to—without understanding the system it lives in.
Phew! I don’t think anyone at @ConcatenateConf noticed that I was still in my pyjamas when I gave my talk.
Over on A List Apart, you can read the first chapter from Tim’s new book, Flexible Typesetting.
I was lucky enough to get an advance preview copy and this book is ticking all my boxes. I mean, I knew I would love all the type nerdery in the book, but there’s a bigger picture too. In chapter two, Tim makes this provacative statement:
Typography is now optional. That means it’s okay for people to opt out.
That’s an uncomfortable truth for designers and developers, but it gets to the heart of what makes the web so great:
Of course typography is valuable. Typography may now be optional, but that doesn’t mean it’s worthless. Typographic choices contribute to a text’s meaning. But on the web, text itself (including its structural markup) matters most, and presentational instructions like typography take a back seat. Text loads first; typography comes later. Readers are free to ignore typographic suggestions, and often prefer to. Services like Instapaper, Pocket, and Safari’s Reader View are popular partly because readers like their text the way they like it.
What Tim describes there isn’t a cause for frustration or despair—it’s a cause for celebration. When we try to treat the web as a fixed medium where we can dictate the terms that people must abide by, we’re doing them (and the web) a disservice. Instead of treating web design as a pre-made contract drawn up by the designer and presented to the user as a fait accompli, it is more materially honest to treat web design as a conversation between designer and user. Both parties should have a say.
Or as Tim so perfectly puts it in Flexible Typesetting:
Readers are typographers, too.
This is great advice from Lindsay Grizzard—getting agreement is so much more important than personal preference when it comes to collaborating on a design system.
When starting a project, get developers onboard with your CSS, JS and even HTML conventions from the start. Meet early and often to discuss every library, framework, mental model, and gem you are interested in using and take feedback seriously. Simply put, if they absolutely hate BEM and refuse to write it, don’t use BEM.
It’s all about the people, people!
Dan compares the relationship between a designer and developer in the web world to the relationship between an art director and a copywriter in the ad world. He and Brad made a video to demonstrate how they collaborate.
Very valuable observations from Paul on his travels, talking to developers and business people about progressive web apps—there’s some confusion out there.
My personal feeling is that everyone is really hung up on the A in PWA: ‘App’. It’s the success and failure of the branding of the concept; ‘App’ is in the name, ‘App’ is in the conscious of many users and businesses and so the associations are quite clear.
Oh, this is such a good analogy from Mandy! Choosing the right HTML element is like choosing the right data type in a strongly typed programming language.
Get to know the HTML elements available to you, and use the appropriate one for your content. Make the most it, like you would any language you choose to code with.
Overwhelmingly, our software is built by well-paid teams with huge monitors and incredibly fast computers running on a high-bandwidth internet connection. We run MacBook Pros, we have cinema displays, we carry iPhones.
That’s not what the rest of the world looks like.
Nice! It sounds like Lucy and Andy went above and beyond the call of duty when it came to the alt text for 100 Demon Dialogues.
I started writing for myself. The writing was helpful for me and luckily it was helpful for other people as well. But even if you’re the only one that reads your blog it is still helpful as a way to learn.
Writing a talk.
It’s messy.
Whenever I create a fetch event inside a service worker, my code roughly follows the same pattern. There’s a then clause which gets executed if the fetch is successful, and a catch clause in case anything goes wrong:
fetch( request)
.then( fetchResponse => {
// Yay! It worked.
})
.catch( fetchError => {
// Boo! It failed.
});
In my book—Going Offline—I’m at pains to point out that those arguments being passed into each clause are yours to name. In this example I’ve called them fetchResponse and fetchError but you can call them anything you want.
I always do something with the fetchResponse inside the then clause—either I want to return the response or put it in a cache.
But I rarely do anything with fetchError. Because of that, I’ve sometimes made the mistake of leaving it out completely:
fetch( request)
.then( fetchResponse => {
// Yay! It worked.
})
.catch( () => {
// Boo! It failed.
});
Don’t do that. I think there’s some talk of making the error argument optional, but for now, some browsers will get upset if it’s not there.
So always include that argument, whether you call it fetchError or anything else. And seeing as it’s an error, this might be a legitimate case for outputing it to the browser’s console, even in production code.
And yes, you can output to the console from a service worker. Even though a service worker can’t access anything relating to the document object, you can still make use of window.console, known to its friends as console for short.
My muscle memory when it comes to sending something to the console is to use console.log:
fetch( request)
.then( fetchResponse => {
return fetchResponse;
})
.catch( fetchError => {
console.log(fetchError);
});
But in this case, the console.error method is more appropriate:
fetch( request)
.then( fetchResponse => {
return fetchResponse;
})
.catch( fetchError => {
console.error(fetchError);
});
Now when there’s a connectivity problem, anyone with a console window open will see the error displayed bold and red.
If that seems a bit strident to you, there’s always console.warn which will still make the output stand out, but without being quite so alarmist:
fetch( request)
.then( fetchResponse => {
return fetchResponse;
})
.catch( fetchError => {
console.warn(fetchError);
});
That said, in this case, console.error feels like the right choice. After all, it is technically an error.