A plug-in that lets multiple people collaborate on the same document in Atom. Could be useful for hackdays and workshops.
Sunday, November 19th, 2017
Saturday, November 18th, 2017
Here’s a clever to technique to improve the perceived performance of image loading with a polygonal SVG placeholder.
Friday, November 17th, 2017
What a great way to play around with CSS animations!
In the immortal words of Ultravox,
this means nothing to me.
I’m filing this away for my future self for the next time I (inevitably) get confused about what
Thursday, November 16th, 2017
Yes! I’ve wanted this forever!
I think Dan is on to something here—design tools that offer pixel perfection at an early stage are setting us up for disappointment and frustration. Broad brushstrokes early on, followed by more precise tinkering later, feels like a more sensible approach.
With the help of a robust and comprehensive design system, I am certain that we could design in much broader strokes, and concentrate on making the finished product, rather than our design outputs, highly precise and reflective of our ideal.
Wednesday, November 15th, 2017
What is a Progressive Web App?
It seems like any new field goes through an inevitable growth spurt that involves “defining the damn thing.” For the first few years of the IA Summit, every second presentation seemed to be about defining what Information Architecture actually is. See also: UX. See also: Content Strategy.
Now it seems to be happening with Progressive Web Apps …which is odd, considering the damn thing is defined damn well.
Regardless of the specifics of the name, what I like about Progressive Web Apps is that they have a clear definition. It reminds me of Responsive Web Design. Whatever you think of that name, it comes with a clear list of requirements:
- A fluid layout,
- Fluid images, and
- Media queries.
Likewise, Progressive Web Apps consist of:
- A service worker, and
- A Web App Manifest.
There’s more you can do in addition to that (just as there’s plenty more you can do on a responsive site), but the core definition is nice and clear.
Except, for some reason, that clarity is being lost.
Here’s a post by Ben Halpern called What the heck is a “Progressive Web App”? Seriously.
I have a really hard time describing what a progressive web app actually is.
He points to Google’s intro to Progressive Web Apps:
Progressive Web Apps are user experiences that have the reach of the web, and are:
- Reliable - Load instantly and never show the downasaur, even in uncertain network conditions.
- Fast - Respond quickly to user interactions with silky smooth animations and no janky scrolling.
- Engaging - Feel like a natural app on the device, with an immersive user experience.
Those are great descriptions of the benefits of Progressive Web Apps. Perfect material for convincing your clients or your boss. But that appears on
developers.google.com …surely it would be more beneficial for that audience to know the technologies that comprise Progressive Web Apps?
Ben Halpern again:
Google’s continued use of the term “quality” in describing things leaves me with a ton of confusion. It really seems like they want PWA to be a general term that doesn’t imply any particular implementation, and have it be focused around the user experience, but all I see over the web is confusion as to what they mean by these things. My website is already “engaging” and “immersive”, does that mean it’s a PWA?
I think it’s important to use the right language for the right audience.
If you’re talking to the business people, tell them about the return on investment you get from Progressive Web Apps.
If you’re talking to the marketing people, tell them about the experiential benefits of Progressive Web Apps.
But if you’re talking to developers, tell them that a Progressive Web App is a website served over HTTPS with a service worker and manifest file.
I really like this exercise by Harry. I’ve done similar kinds of grading using dot-voting in the past. It feels like an early step to establishing design principles: “this over that.”
By deciding what we value up-front, we have an agreement that we can look back on in order to help us settle these conflicts and get us back on track again.
Relative Requirements remove the personal aspect of these disagreements and instead focuses on more objective agreements that we made as a team.
I think Eric is absolutely right. The barrier to entry for accomplishing what you want with CSS is much lower now. It only seems more complicated if you’re used to doing things the old way.
I envy “the kids”, the ones just starting to learn front end now. They’re likely never going to know the pain of float drop, or wrestling with inline blocks, or not being able to center along one axis. They’re going to roll their eyes when we old-timers start grumbling about the old days and say, “Floats?!? Who ever thought floats would be a good way to lay out a page? That’s totally not what they’re for, anyone can see that! Were you all high as a kite, or just utterly stupid?” You know, the way “the kids” talked ten years ago, except then it was about using tables for layout.
Thursday, November 9th, 2017
I think this is the best delivery of this talk I’ve ever given. It was something about being in that wonderful venue.
I got quite worked up around the the 32 minute mark.
A clever performance trick for images:
- Reduce image contrast using a linear transform function (Photoshop can do this)
- Apply a contrast filter in CSS to the image to make up for the contrast removal
Wednesday, November 8th, 2017
An extract from Richard’s excellent book, this is a deep dive into styling tables for the web (featuring some CSS I had never even heard of).
Tables can be beautiful but they are not works of art. Instead of painting and decorating them, design tables for your reader.
(It also contains a splendid use of the term “crawl bar.”)
Great advice on writing sensible comments in your code.
Tuesday, November 7th, 2017
The latest edition of Heydon’s Inclusive Components is absolutely fantastic! The pattern itself—toggling sections of content—is quite straightforward, but then there’s a masterclass in how to create a web component that still allows the content to be accessible in older browsers. The key, as ever, is progressive enhancement:
Whether implemented through web components or not, progressive enhancement not only ensures the interface is well-structured and robust. As we’ve seen here, it can also simplify the editorial process. This makes developing the application and its content more inclusive.
Thursday, November 2nd, 2017
The dConstruct Audio Archive works offline
I’m really proud of the three years I ran the show—2012, 2013, and 2014—and I have great memories from each event. I’m inordinately pleased that the individual websites are still online after all these years. I’m equally pleased with the dConstruct audio archive that we put online in 2012. Now that the event itself is no longer running, it truly is an archive—a treasury of voices from the past.
I think that these kinds of online archives are eminently suitable for some offline design. So I’ve added a service worker script to the dConstruct archive.
But what about the individual pages? For something like Resilient Web Design—another site that won’t be updated—I pre-cache everything. I could do that with the dConstruct archive. All of the pages with all of the images add up to less than two megabytes; the entire site weighs less than a single page on Wired.com or The Verge.
In the end, I decided to go with a cache-as-you-go strategy. Every time a page or an image is fetched from the network, it is immediately put in a cache. The next time that page or image is requested, the file is served from that cache instead of the network.
Here’s the logic for fetch requests:
- First, look to see if the file is in a cache. If it is, great! Serve that.
- If the file isn’t in a cache, make a network request and serve the response …but put a copy of a file in the cache.
- The next time that file is requested, go to step one.
Save for offline
That caching strategy works great for pages, images, and other assets. But there’s one kind of file on the dConstruct archive that’s a bit different: the audio files. They can be fairly big, so I don’t want to cache those unless the user specifically requests it.
If you end up on the page for a particular talk, and your browser supports service workers, you’ll get an additional UI element in the list of options: a toggle to “save offline” (under the hood, it’s a checkbox). If you activate that option, then the audio file gets put into a cache.
Now if you lose your network connection while browsing the site, you’ll get a custom offline page with the option to listen to any audio files you saved for offline listening. You’ll also see this collection of talks on the homepage, regardless of whether you’ve got an internet connection or not.
So if you’ve got a long plane journey ahead of you, have a browse around the dConstruct archive and select some talks for your offline listening pleasure.
Or just enjoy the speediness of browsing the site.
Wednesday, November 1st, 2017
A really great case study of a code refactor by Mina, with particular emphasis on the benefits of CSS Grid, fluid typography, and accessibility.
Good advice on writing code that is understandable to your fellow humans (and your future self).
Good question! And a good answer:
If you really need it, which you probably don’t,
readonlyis what you want.