The opening paragraphs of this article should be a mantra recited by every web developer before they begin their working day:
Fortunately, we as engineers can avoid, or at least mitigate the impact of breakages in the web apps we build. This however requires a conscious effort and mindset shift towards thinking about unhappy scenarios just as much as happy ones.
I love, love, love the emphasis on reducing assumptions:
Taking a more defensive approach when writing code helps reduce programmer errors arising from making assumptions. Pessimism over optimism favours resilience.
Accepting the fragility of the web is a necessary step towards building resilient systems. A more reliable user experience is synonymous with happy customers. Being equipped for the worst (proactive) is better than putting out fires (reactive) from a business, customer, and developer standpoint (less bugs!).
Always refreshing to see some long-term thinking applied to the web.
An excellent explainer from Trys and James of their supersmart Utopia approach:
Utopia encourages the curation of a system small enough to be held in short-term memory, rather than one so sprawling it must be constantly referred to.
Vitaly has rounded up a whole load of accessibility posts. I think I’ve linked to most of them at some point, but it’s great to have them all gathered together in one place.
I really like the approach that Carie takes here. Instead of pointing to specific patterns to use, she provides a framework for evaluating technology. Solutions come and go but this kind of critical thinking is a long-lasting skill.
This is a very thoughtful and measured response to Alex’s post Platform Adjacency Theory.
Unlike Alex, the author doesn’t fire off cheap shots.
Also, I’m really intrigued by the idea of certificate authorities for hardware APIs.
Standardizing `select` And Beyond: The Past, Present And Future Of Native HTML Form Controls — Smashing Magazine
While a handful of form controls can be easily styled by CSS, like the button element, most form controls fall into a bucket of either requiring hacky CSS or are still unable to be styled at all by CSS.
Despite form controls no longer taking a style or technical dependency on the operating system and using modern rendering technology from the browser, developers are still unable to style some of the most used form control elements such as
select. The root of this problem lies in the way the specification was originally written for form controls back in 1995.
Stephanie goes back in time to tell the history of form controls on the web, and how that history has led to our current frustrations:
The current state of working with controls on the modern web is that countless developer hours are being lost to rewriting controls from scratch, as custom elements due to a lack of flexibility in customizability and extensibility of native form controls. This is a massive gap in the web platform and has been for years. Finally, something is being done about it.
A wonderful introduction to the indie web—Ana really conveys her sense of excitement!
I’ve always been a fan of using the first few milliseconds of a user’s attention getting what I have to share with them — in front of them. Then worrying setting up the interaction layer while the user can start processing what they’re seeing.
Don’t miss this—a masterclass in SVG animation with Cassie (I refuse to use the W word). Mark your calendar: August 20th.
A fascinating look at the web today with IE8. And it’s worth remembering who might be experiencing the web like this:
Whoever they are, you can bet they’re not using an old browser just to annoy you. Nobody deliberately chooses a worse browsing experience.
The article also outlines two possible coping strategies:
- Polyfilling Strive for feature parity for all by filling in the missing browser functionality.
- Progressive Enhancement Start from a core experience, then use feature detection to layer on functionality.
Take a wild guess as to which strategy I support.
There’s a bigger point made at the end of all this:
IE8 is today’s scapegoat. Tomorrow it’ll be IE9, next year it’ll be Safari, a year later it might be Chrome. You can swap IE8 out for ‘old browser of choice’. The point is, there will always be some divide between what browsers developers build for, and what browsers people are using. We should stop scoffing at that and start investing in robust, inclusive engineering solutions. The side effects of these strategies tend to pay dividends in terms of accessibility, performance and network resilience, so there’s a bigger picture at play here.
This article conflates progressive web apps with having an app shell architecture. That’s a real shame.
Rachel does some research to find out why people use CSS frameworks like Bootstrap—it can’t just be about grids, right?
In our race to get our site built quickly, our desire to make things as good as possible for ourselves as the designers and developers of the site, do we forget who we are doing this for? Do the decisions made by the framework developer match up with the needs of the users of the site you are building?
Not for the first time, I’m reminded of Rachel’s excellent post from a few years ago: Stop solving problems you don’t yet have.
Rachel goes into detail on how she uses pattern libraries—built with Fractal to build interfaces. I know it sounds like we paid her to say all the nice things about Fractal, but honestly, we didn’t even know she was writing this article!
After discovering Fractal two years ago, we have moved every new project — large and small — into Fractal.
A lot of the issues here are with abuses of the
placeholder attribute—using it as a label, using it for additional information, etc.—whereas using it quite literally as a placeholder can be thought of as an enhancement (I almost always preface mine with “e.g.”).
Still, there’s no getting around that terrible colour contrast issue: if the contrast were greater, it would look too much like an actual pre-filled value, and that’s potentially worse.
Rachel gives a terrific explanation of CSS layout from first principles, starting with the default normal flow within writing systems, moving on to floats, then positioning—relative, absolute, fixed, and sticky—then flexbox, and finally grid (with a coda on alignment). This is a great primer to keep bookmarked; I think I’ll find myself returning to this more than once.
A good core experience is indicative of a well-structured web page, which, in turn, is usually a good sign for SEO and for accessibility. It’s usually a well designed web page, as the designer and developer have spent time and effort thinking about what’s truly core to the experience. Progressive enhancement means more robust experiences, with fewer bugs in production and fewer individual browser quirks, because we’re letting the platform do the job rather than trying to write it all from scratch.
Good advice on print styles from Rachel. The browser support situation is frustrating; I suspect it’s because the people working on browsers would rather get stuck in on shinier stuff.