I am having a hard time seeing the business benefits weighing in more than the user cost (at least for those many organisations out there who rarely ever put that data to proper use). After all, keeping the costs low for the user should be in the core interest of the business as well.
This great post by Mandy ticks all my boxes! It’s a look at the combinatorial possibilities of some of the lesser-known HTML elements: abbr, cite, code, dfn, figure, figcaption, kbd, samp, and var.
As a community, we love to talk about meritocracy while perpetuating privilege.
This is playing out in full force in the front-end development community today.
Front-end development is a part of the field that has historically been at least slightly more accessible to women.
Shockingly, (not!) this also led to a salary and prestige gap, with back-end developers making on average almost $30,000 more than front-end.
(Don’t read the comments.)
Weighing up the pros and cons of adding tracking scripts to a website, from a business perspective and from a user perspective.
When looking at the costs versus the benefits it is hard to believe that almost every website is using tracking scripts.
The next time, you implement a tracking script it would be great if you could rethink it and ask yourself if it is really worth it.
This is very timely. I’ve been doing some consulting at a company where they are perhaps a little over-reliant on automated accessibility tests.
Automated accessibility tests are a great resource to have, but they can’t automatically make your site accessible. Use them as one step of a larger testing process.
Feedbin has removed third-party iframes and JavaScript (oEmbed provides a nice alternative), as well as stripping out Google Analytics, and even web fonts that aren’t self-hosted. This is excellent!
JavaScript is the web’s CO2. We need some of it, but too much puts the entire ecosystem at risk. Those who emit the most are furthest from suffering the consequences — until the ecosystem collapses. The web will not succeed in the markets and form-factors where computing is headed unless we get JS emissions under control.
Damn, that’s a fine opening! And the rest of this post by Alex is pretty darn great too. He’s absolutely right in calling out the fetishisation of developer experience at the expense of user needs:
The swap is executed by implying that by making things better for developers, users will eventually benefit equivalently. The unstated agreement is that developers share all of the same goals with the same intensity as end users and even managers. This is not true.
I have a feeling that this will be a very bitter pill for many developers to swallow:
If one views the web as a way to address a fixed market of existing, wealthy web users, then it’s reasonable to bias towards richness and lower production costs. If, on the other hand, our primary challenge is in growing the web along with the growth of computing overall, the ability to reasonably access content bumps up in priority. If you believe the web’s future to be at risk due to the unusability of most web experiences for most users, then discussion of developer comfort that isn’t tied to demonstrable gains for marginalized users is at best misguided.
Oh,captain, my captain!
Tools that cost the poorest users to pay wealthy developers are bunk.
You really don’t need jQuery any more …and that’s thanks to jQuery.
Here, the Github team talk through their process of swapping out jQuery for vanilla JavaScript, as well as their forays into web components (or at least the custom elements bit).
Testing time with Tim.
Long story short, the NOSCRIPT intervention looks like a really great feature for users. More often than not it provides significant reduction in data usage, not to mention the reduction in CPU time—no small thing for the many, many people running affordable, low-powered devices.
I love this deep dive that Sara takes into the question of marking up content for progressive disclosure. It reminds me Dan’s SimpleQuiz from back in the day.
Then there’s this gem, which I think is a terrificly succinct explanation of the importance of meaningful markup:
It’s always necessary, in my opinion, to consider what content would render and look like in foreign environments, or in environments that are not controlled by our own styles and scripts. Writing semantic HTML is the first step in achieving truly resilient Web sites and applications.
This checklist came in very handy during a performance-related workshop I was running today (I may have said the sentence “Always ask yourself What Would Zach Do?”).
- Start Important Font Downloads Earlier (Start a Web Font load)
- Prioritize Readable Text (Behavior while a Web Font is loading)
- Make Fonts Smaller (Reduce Web Font load time)
- Reduce Movement during Page Load (Behavior after a Web Font has loaded)
The first two are really straightforward to implement (with rel="preload" and font-display). The second two take more work (with subsetting and the font loading API).
Harsh but fair words about Google AMP.
Google has built their entire empire on the backs of other people’s effort. People use Google to find content on the web. Google is just a doorman, not the destination. Yet the search engine has epic delusions of grandeur and has started to believe they are the destination, that they are the gatekeepers of the web, that they should dictate how the web evolves.
Take your dirty paws off our web, Google. It’s not your plaything, it belongs to everyone.
I’m going through a pattern library right now, and this rings true:
I’m of the opinion that all cards in a Card UI are destined to become baby webpages. Just like modals. Baby hero units with baby titles and baby body text and baby dropdown menu of actions and baby call to action bars, etc.
In some ways this outcome is the opposite of what you were intending. You wanted a Card UI where everything was simple and uniform, but what you end up with is a CSS gallery website filled with baby websites.
A step-by-step walkthrough of a really useful service worker pattern: allowing users to save articles for offline reading at the click of a button (kind of like adding the functionality of Instapaper or Pocket to your own site).
This is a terrific spot-on piece by Rachel. I firmly believe that healthy competition and diversity in the browser market is vital for the health of the web (which is why I’m always saddened and frustrated to hear web developers wish for a single monocultural rendering engine).
I love, love, love all the little details of HTML that Aaron offers up here. And I really like how he positions non-visual user-agents like searchbots, screen readers, and voice assisants as headless UIs.
HTML is a truly robust and expressive language that is often overlooked and undervalued, but it has the incredible potential to nurture conversations with our users without requiring a lot of effort on our part. Simply taking the time to code web pages well will enable our sites to speak to our customers like they speak to each other. Thinking about how our sites are experienced as headless interfaces now will set the stage for more natural interactions between the real world and the digital one.
Just last week I came across an example of what Ethan describes here: accessibility (in a pattern library) left to automatic checks rather than human experience.
I share many of Cole’s concerns. I think we’re in fairly similiar situations. We even share the same job title: Technical Director …whatever that even means.
I worry about our over-reliance and obsession with tools because for many these are a barrier to our discipline. I worry that they may never really make our work better, faster or easier and that our attention is increasingly focussed not on the drawing but on the pencils. But I mostly worry that our current preoccupation with the way we work (rather than necessarily what we work on) is sapping my enthusiasm for an industry I love and care about immensely.
I had a great time chatting with Lea and Emily about service workers on this episode of their podcast—they’re such great hosts!
Here’s the huffduffed audio.
Every single font-feature-settings value demonstrated in one single page.