Real world examples of how over-optimizing for metrics can be at odds with performance.

Good cautionary reminder of Goodhart’s law. This is why it’s so important to choose your primary metrics with care, and to make sure everyone understands why.

The point that a rewrite is often faster simply because it’s a rewrite is a very valid one—over time we add more features/functionality to our code and it starts to have a cost not just on perf, but on maintainability as well. A rewrite lets us start with those learnings already in mind.

But my favorite point is around the accessibility of JavaScript tools built in JavaScript:

For years, we’ve had both library authors and library consumers in the JavaScript ecosystem largely using JavaScript. I think we take for granted what this enables.

I wrote about this a few years back, but having JavaScript available on the front-end, back-end, on the edge, and in build tools is a powerful way to let developers extend their reach into different part of the tech stack and any decision to move away from that needs to be VERY carefully considered.

So at first, it looked like about 10% of the BuySellAds scripts were being blocked. But after replacing how we were tracking the blocks with an internal service (just a little Redis counter), it was showing more like 28% of scripts being blocked.

Our experiments showed that Early Flush produced a flat reduction in First Contentful Paint (FCP) of around 100ms on every page tested, including the Airbnb homepage.

Could’ve used this just the other day, actually.

• Business
• Sustainability
• Inclusivity

Naturally, I agree.

Creativity happens in two stages: first, unbounded imagination; then — more importantly — ruthless editing.

Loads of great advice in this post from Jason on the part of “ideas” that tends to get less attention: editing.

One of the ones that jumped out to me was his note about the importance of underutilizing people’s time:

On top of that, a healthy team is intentionally underutilized. This creates free time for chasing shiny things with low risk. A roadmap with this kind of slack built-in supports exploratory tinkering by defining a clear plan with clear boundaries: I know I need to complete these 5 tasks this week to keep us on track; I finish them by lunchtime Thursday; I now have a day and a half to do whatever I find exciting without hurting the overall strategic goals or slowing things down.

What a healthy (and wise!) counter from the way most organizations tend to operate.a

All of the above are part of the same issue - a task is an incomplete and inaccurate cadence to measure main-thread blocking.

Image transitions are a technique used to animate images as they appear on screen. Examples include scaling or fading the image into view for visual flare. However, often these transitions are implemented in a way that causes a large degradation in performance and thus user experience.

We worked with Case-Mate to fix this issue on their website, resulting in a 6 second improvement in Largest Contentful Paint (LCP)! In this case study, we’ll walk through the experience and the steps we went through to make this improvement.

• Of the 7 generators tested, only Astro and Eleventy default to 0kb of client-side JavaScript. More 0kb baselines, please.

• Three of the generators hide npm audit reports by default. (Basically, the opposite of “secure by default”)

There’s no way that we’d use this technology to generate outputs for clients, but we certainly might use it to generate inputs.

I think this sums up the way I’ve been feeling about it so far (though struggling to phrase it as succinctly).

Like most, I’ve played with ChatGPT, Midjourney and similar things, purely out of curiosity, and I’ve paid attention to the example outputs I’m seeing from others. For me, the output continues to fall into that camp of “pretty good for a piece of technology but definitely has a distinct ‘smell’ about it”.

I find, more often than not, that I understand something much less well when I sit down to write about it than when I’m thinking about it in the shower. In fact, I find that I change my own mind on things a lot when I try write them down. It really is a powerful tool for finding clarity in your own mind.

This. 100x, this.

I spent close to seven years in a marketing department on a content team as I wrote blog posts, ebooks, tweets, podcast episodes, magazine pieces, and slide decks among other things. Based on all that experience, I wanted to share some of the most important lessons I learned from my time there….

Drawing upon each model, I tried to roughly gauge the perf maturity of organizations, but found I needed a more visual aid — a map of perf work that I would help me identify where orgs are in their perf journey: what areas of performance there are and what level they are in those areas. So I drew up a “Performance Maturity Matrix” with four levels including a “null” level (i.e. lacking the traits of performance maturity) and nine areas of perf work.

It’s true that when you try to anticipate future harms, you won’t spot them all. But as the muscle gets stronger, your success rate improves and you develop better foresight senses. But even spotting some harms is preferable to not looking in the first place.

Owning your content on the web should not require extensive technical knowledge or special skills. It should be just as easy as signing up for a cellphone plan.

Max hits on the some of the same thoughts I’ve had regarding IndieWeb in the past. The whole Mastodon signup process was a stark reminder of the complexity involved. I consider myself a relatively smart person, but even with folks explaining it to me, I’m still not entirely clear on why I would choose one server over another and whether it matters at all. Choosing which server, for me, was just a moment of confusion and while it was a minor one that obviously didn’t stop me from signing up, it’s a point of friction that I’m sure puts an upper cap on Mastodon’s potential for growth.

But like Max, I’m not so convinced mass adoption should be the goal….for any social platform honestly.

I had been using Twitter less and less over the last few years. If you set out to design a platform with the intention of it encouraging increasingly divisive hot-takes, you’d be hard pressed to do a better job of it than Twitter. The brevity of the posts, the immediacy of the feed, the little micro-doses of dopamine from seeing your content shared and liked…all of it encourages off-the-cuff hot takes and discourages anything resembling constructive conversation.

Maybe this is an opportunity not to just reset our social feeds and own our content, but to re-consider the power of social media to connect us and explore what it might mean to design an experience that is more calm and considered.

Matthias wrote about a really straightforward way of sending RSS to Mastodon, so gonna give this a shot.

(This is actually the first test…fingers crossed!)

My favorite nugget is that they tested using an actual video thumbnail for their poster image versus a solid black poster image, and the black image performed better in user studies:

Using a solid black poster image showed the best results in user studies. Users found the transition from solid black to the first frame of the video to be a less-jarring experience for autoplay videos.

Given the higher page RPMs and subscriber conversion rates of a non-AMP page, pulling the plug on AMP looks like an easy win for both programmatic and consumer revenue. And most importantly, we regain full control of the user experience. And that’s perhaps the biggest upside.

It’s no shocker I’ve never been a big fan of AMP. (My first post expressing concern about the approach AMP was taking was literally the day after the initial announcement.)

So naturally, I’m pleased to see folks moving on from it.

This post describes how the Netflix TVUI team implemented a robust strategy to quickly and easily detect performance anomalies before they are released — and often before they are even committed to the codebase.

But most importantly, he suggests that the SEO carrot has tipped the focus of performance, and not for the better.

Sites that truly care about performance and the business impact of that performance, worked hard to make their sites faster.

This changed when Google started using speed as a ranking signal.

I made a similar point in a revamped version of my “Performance Budgets that Stick” talk the other week. If we want this burst of performance interest to stick, and to have the impact we want it to have for users, we’re going to need to make it easier for folks to connect the dots between business metrics and performance.

But now, I find myself all consumed by the question, WHY are links blue? WHO decided to make them blue? WHEN was this decision made, and HOW has this decision made such a lasting impact? 

I turned to my co-workers to help me research, and we started to find the answer. Mosaic, an early browser released by Marc Andreessen and Eric Bina on January 23, 1993, had blue hyperlinks. To truly understand the origin and evolution of hyperlinks though, I took a journey through technology history and interfaces to explore how links were handled before color monitors, and how interfaces and hyperlinks rapidly evolved once color became an option.

The computers sitting on our desks are incomprehensibly fast. They can perform more operations in one second than a human could in one hundred years. We live in an era of CPUs that can perform billions of instructions per second, tens of billions if we take multi-cores into account, of memory that can transfer data to the CPU at hundreds of gigabytes per second, of disks that support streaming reads of gigabytes per second. This era of incredibly fast hardware is also the era of programs that take tens of seconds to start from an SSD or NVMe disk; of bloated web applications that take many seconds to show a simple list, even on a broadband connection; of programs that process data at a thousandth of the speed we should expect. Software is laggy and sluggish — and the situation shows little signs of improvement.

The relevant parts of an image aren’t limited to the cold hard facts. Images can make you feel a particular way, and that’s something that should be made available to a screen reader user.

The mobile web is a pale shadow of its potential because the vehicle of progress that has delivered consistent gains for two decades has silently been eroded to benefit native app platforms and developers. These attacks on the commons have at their core a shared disrespect for the sanctity of user choice, substituting the agenda of app and OS developers for mediation by a user’s champion.

This post summarizes how we analyzed publicly available web transparency data and ad hoc A/B testing to understand the adoption and performance characteristics of native image lazy-loading. What we found is that lazy-loading can be an amazingly effective tool for reducing unneeded image bytes, but overuse can negatively affect performance. Concretely, our analysis shows that more eagerly loading images within the initial viewport—while liberally lazy-loading the rest—can give us the best of both worlds: fewer bytes loaded and improved Core Web Vitals.

If fixing the introverted checkout button caused a three-quarters of a percentage point increase in online orders, it would increase Darden’s revenue by $8.1 million annually.

All of these numbers are guesses. They’re probably wrong. But even if they were a tenth of what I estimated, it would still be $812k. See what I mean about small changes making a big difference at this scale?

Jason documents his struggles trying to order from Olive Garden, and notes how a simple fix could provide them a significant boost in revenue.

Also gave me some ideas for a few things we could start baking into WebPageTest.

Surprisingly, the correlations for each CWV are weak to medium strength and for FID it’s actually a negative correlation, meaning that as the Lighthouse score goes up, real-user FID performance actually tends to go down a bit.

This is the kind of analysis I was hoping to see after Pat added CrUX data to WebPageTest.

Most of this lines up with what I’d expect. Cumulative Layout Shift is measured very differently synthetically versus in the CrUX data (particularly before the new windowing approach) and First Input Delay has always seemed to have a very weak connection to Total Blocking Time in my experience. (First Input Delay itself has plenty of limitations, and I’m eager to see it supplanted by something a bit more useful in the future.)

I think many of us have cautioned against leaning too hard on optimizing for your Lighthouse scores, and it’s nice to evidence as to why. Lighthouse is a great tool, but it works better as a “here’s a list of things you can try to improve” than it does as a goal in and of itself.

Creating a modal that could do all of this required thoughtful consideration and hard work. Under the hood, the modal component is composed of more than 10 sub-components. But that complexity is not passed on to our client.

A good reminder that I really, really need to get with it and spend a bit more time with web components.

Preload can be avoided in many cases, with alternative strategies such as inlining of critical CSS and inlining font-css.

Most of the time, preload gets used as a (not particularly efficient) band-aid for an underlying issue that is probably better solved in other ways.

Also, this is probably a personal hang-up, but whenever someone from the Chrome team shares a Google Doc full of interesting research and ideas (which is super often) I always feel a little anxiety. I just don’t trust these docs to stick around as long as a blog post.

Adding a ‘show password’ option to GOV.UK Accounts seemed like a straightforward task, but the more we looked into it the more complicated and interesting it became. This is how we did it and some of the challenges we faced.

More fodder for my firm belief that the closer you look at anything, the more interesting it becomes.

Apple’s iOS browser (Safari) and engine (WebKit) are uniquely under-powered. Consistent delays in delivery of important features ensure the web can never be a credible alternative to its proprietary tools and App Store.

Heckuva leading assertion from Alex, but he brings some serious data to back it up, including some pretty compelling results from the Web Platform Tests.

There’s a lot of criticism levied at Chrome and how they move through the standards process (or don’t). Some of that criticism is fair, some of it isn’t.

But it’s pretty clear, I think, that we have a mismatch of resources creating an imbalance. On the one hand, we have Google funding the heck out of their web-focused efforts. On the other hand, we have Apple that just never seems willing to invest in it much.

The result isn’t particularly healthy for the web or for anyone who uses it. Alex’s point here rings true:

It’s perverse that users and developers everywhere pay a subsidy for Apple’s under-funding of Safari/WebKit development.

The 95th percentile of RUM data is a great place to assess the slowest experiences. In this case, we see that the streaming Service Worker confers a 40% and 51% improvement in FCP and LCP, respectively, over no Service Worker at all. Compared to the “standard” Service Worker, we see a reduction in FCP and LCP by 19% and 43%, respectively.

This is a terrific post by Sara, where she dives into making “Add to Cart” (and other generic text labels) more accessible to both screen readers and dictation services.

Again, if you’re certain that you’re speaking to peers, that’s fine. But if you’re trying to communicate even a little more widely, then initialisms and abbreviations are obstacles to overcome. And once you’re in the habit of using the short forms, it gets harder and harder to apply context-shifting in your language. So the safest habit to form is to generally avoid using acronyms and initialisms.

This is a good reminder from Jeremy. He mentions performance in particular (we do love our acronyms). I try to avoid this, but I know I’ve been guilty of it many times. Something to improve on for sur.

It’s clever stuff—the combination of ResizeObservers and IntersectionObservers helping to avoid the shifting around that would occur otherwise.

This doesn’t do much though to eliminate the reservations I have about content-visibility. In theory, it’s a great addition, but the fact that it seems to need so much supporting scaffolding to make it usable for a relatively simple use-case makes me feel like it may be missing a few other pieces of native plumbing before it’s really ready for primetime.

For a few months, those who will buy M1 machines will enjoy great responsiveness and blazing start-up time. Some once bloated applications will again behave like most tools should. But soon these metrics will start to degrade. Responsiveness and start-up time will progressively revert to what they used to be and old “non-M1” machines will become even slower than they used to.

For every cycle a hardware engineer saves, a software engineer will add two instructions.

Imagine that situation. You buy a computer. It comes with one web browser pre-installed. You can’t install a different web browser on your computer.

You wouldn’t stand for it! I mean, Microsoft got fined for anti-competitive behaviour when they pre-bundled their web browser with Windows back in the 90s. You could still install other browsers, but just the act of pre-bundling was seen as an abuse of power. Imagine if Windows never allowed you to install Netscape Navigator?

And yet that’s exactly the situation in 2020.

You buy a computing device from Apple. It might be a Macbook. It might be an iPad. It might be an iPhone. But you can only install your choice of web browser on one of those devices.

We analyzed millions of page impressions to understand how these metrics and thresholds affect users. We found that when a site meets the above thresholds, users are 24% less likely to abandon page loads (by leaving the page before it finishes loading).

We also looked specifically at news and shopping sites, sites whose businesses depend on traffic and task completion, and found similar numbers: 22% less abandonment for news sites and 24% less abandonment for shopping sites.

We recognize, of course, that “Always accessible” is not a novel approach. Here in California accessibility is a guiding principle in the state’s digital strategy. And our work is just one part of the state’s larger commitment to ensuring that information and services are accessible.

What is novel is how our team is broadening the definition of accessibility for state government to include performance as a core component. Performance as accessibility.

Our goal is to make COVID19.CA.gov fast and easy to use on any kind of hardware or with any level of bandwidth. 

It’s…dense. I’m going to likely have to re-read this several times to really understand all the details. Lots of interesting bits here.

Performance has quite literally never been more important.

Visits to news sites went up as much as 60%. And people are spending more time playing online games.

A similar pattern is emerging in the U.S. Cloudflare says Internet traffic jumped 20% on Friday, after President Trump declared the pandemic a national emergency. In hard-hit Seattle, Internet use was up 40% last week compared to January.

Latest data put out by the telecom regulator pegs the average monthly wireless data usage per user at 10.37 GB, which analysts say could rise by around 15% in the next two quarters if people continue to work from their homes over a prolonged period.

A handy suite of tests (from Mark Nottingham) to see how different browsers respond to various caching headers.

A collection of good news, positive trends, uplifting statistics and facts — all beautifully visualized by Information is Beautiful.

Conjecture aside, here’s what I do know: the AMP team decided that each of these Story demos was worth showcasing on the official page for AMP Stories. And that sends a powerful signal about where the priorities for AMP Story sit. The content in each AMP Story is wonderful, the visual designs are effective—but if you use a screen reader, each Story is an assault on your senses. And by showcasing these demos, the AMP team is signaling that’s entirely acceptable.

It reminds me of Surma’s comments about JS frameworks and performance:

Unless a globally launched framework labels itself as exclusively targeting the users of the Wealthy Western Web, it has a responsibility to help developers target every phone on The Widening Performance Gap™️ spectrum.

It’s a big responsibility, but if you’re shipping something that will be this widely used, you’ve got a responsibility to make the default state as secure, accessible and performant as possible.

That’s particularly true for something that makes as bold a claim, as aggressively, as AMP has always done.

Gosh I miss when this “someone blogs and then someone else iterates on that on their own blog” thing was more common.

Unless a globally launched framework labels itself as exclusively targeting the users of the Wealthy Western Web, its has a responsibility to help developers target every phone on The Widening Performance Gap™️ spectrum.

I always associated prefers-reduced-motion with CSS, but of course the picture element accepts media queries!

A quick post from Brad showing how you can use the picture element to serve up a static image instead of an animated gif when the “reduce motion” preference is enabled.

Examples like this are why I love how the whole suite of responsive images standards (srcset, sizes and picture) turned out. I know some weren’t as pleased with the final product, but there’s so much darn flexibility (ahem) here to enable us to account for scenarios, like this, that only really emerged after those standards were created.

For government, GOV.UK is often the only place a user can get information. If the website were to perform badly, we become a single point of failure.

Great rundown of why performance is so important to GOV.UK and how the context of their visitors can vary dramatically, even within the same city.

In this post, we’ll look at the new loading attribute which brings native <img> and <iframe> lazy-loading to the web!

Exciting to finally see this ship! Folks have been asking for a standards-based way to support lazy-loading images for years.

Gives me hope that maybe, someday, we’ll have element queries.

When we’re evaluating technologies for appropriateness, I hope that we will do so through the lens of what’s best for users, not what we feel compelled to use based on a gnawing sense of irrelevancy driven by the perceived popularity of newer technologies.

Academic background or not, technical education doesn’t stop once you get a job. On the contrary: nothing in tech stays in one place, and the single most valuable skill you can possess to remain employable over time is learning how to learn.

Some great advice here from Sarah on learning.

I’ve being using preload with clients over the last few years but I have never been completely satisfied with the results. I’ve also seen some things I hadn’t quite expected in page load waterfalls so decided to dig deeper.

Excellent work digging deeper into preload by Mr. Davies.

Ten years ago the network was the main bottleneck. Today, the main bottleneck is JavaScript.

Andy has already taken that page and started tracking how CDN’s are doing (again, not well for most of them).

While ever you build under the assumption that things will always work smoothly, you’re leaving yourself completely ill-equipped to handle the scenario that they don’t.

This pattern leads to such a unique effect on page load that at last week’s Perf.Now() Conference, I coined a new somewhat tongue-in-cheek performance metric called “Second Meaningful Content,” which occurs long after the handy First Meaningful Content (or Paint) metric, which would otherwise mark the time at which a page starts to appear usable.

Some good insights into technical optimizations, but as always, the cultural aspects are the most difficult–and the most important.

Nurturing cultural awareness and enthusiasm for building fast, snappy, responsive, tactile products is arguably the most effective performance improvement you can make, but can be the most challenging, and requires the most ongoing attention.

A chief ethics officer would be too distanced from product and design orgs, where most ethical decisions are made; their duties would come into conflict with those of the CFO, who is already on the hook for financial ethics; and the seniority of the role would mean this person would be seen as an ethical arbiter, an oracle who passes ethical judgment. This is IMO a failure state for ethics. Loading ethical responsibility onto a sole enlightened exec doesn’t scale, and it reduces the chance of genuine ethical discourse within companies by individualising the problem.

I try to distill the types of testing that we do into three distinct categories: Proactive, Reactive, and Passive.

I’ve been using “Active” and “Passive” myself and found that it really helps companies better understand why having both synthetic and RUM monitoring in place is important. I really like the way Harry breaks that “Active” category out further based on whether the tests are run proactively or reactively.

Removing the Base64 encoded font has reduced the total page weight by 16% (75 KB) per request (assuming no caching). This may not sound like a huge difference, but GOV.UK receives approximately 48 million visitors per month, so this adds up to mobile users saving approximately 800 GB per month, cumulatively. This is especially important to users on older mobile devices and expensive data plans.

A good alt text can conjure up wonderfully stimulating mental images. A friendly smile is the same in print, photo or wax crayon. Whether you listen to an image or see it, the emotional response is the key factor, so why should we recommend that these emotion rich images should be given a null alt text and hidden from screen reader users?

Really enjoying Paul’s videos. They’re entertaining, really high quality and super useful.

They do admit that since the server is powered via solar, it’s possible they may have some downtime. I bet they could provide themselves with another layer of protection with a small service worker.

It’s always fun to see the similarities and differences between how other people prep and how I do.

At times I think “will anyone reads this, does anyone care?”, but I always publish it anyway — and that’s for two reasons. First it’s a place for me to find stuff I may have forgotten how to do. Secondly, whilst some of this stuff is seemingly super-niche, if one person finds it helpful out there on the web, then that’s good enough for me. After all I’ve lost count of how many times I’ve read similar posts that have helped me out.

We need to be able to candidly and thoughtfully talk about technology without people assuming you’re calling that technology and the people who create/use it garbage. We have to be mindful of the community we’re fostering, and encourage people to freely discuss all this stuff without getting dog piled on.

The Tarot Cards of Tech are a set of provocations designed to help creators more fully consider the impact of technology.

Some important questions here to answer before building any new piece of technology.

The writing here is so good it makes me want to tear up everything I’ve ever written and try again.

In the Chromium source as well as the Webkit source, we can see that the lifetimes.freshness variable is set to 10% of the time since the object was last modified (provided that a Last-Modified header was returned). The 10% since last modified heuristic is the same as the suggestion from the RFC. When we look at the Firefox source code, we can see that the same calculation is used, however Firefox uses the std:min() C++ function to select the less of the 10% calculation or 1 week.

I love the careful definition of political versus partisan:

First, let’s get one definitional issue out of the way. Sometimes when people hear the term “political,” they understand it as “partisan.” To be political is to acknowledge the lived experiences of people outside of yourself. To be partisan is to advocate for the beliefs or propaganda of a specific party affiliation.

And also her point that the impact of our technology is never neutral:

“Please keep politics out of your talks” takes neutrality as a baseline. It relies on the premise that our viewpoints exist in frictionless purity, and we simply need to keep them there to communicate them appropriately. But this is a myth; there is no such thing as neutrality.

And again:

Our choices are always guided by something—laws, morals, values, rules. And because that something is not neutral, our choices cannot be either. And what is design, if not a series of choices? Our web work, no matter how insignificant we may think it, is inherently political, and to pretend otherwise is willful ignorance.

I am not saying every talk needs to be about the political ramifications of your work. Just don’t pretend those ramifications aren’t there. Recognize that your choices draw boundaries.

Viewing the broader context of what we build is something I’ve been thinking a lot about as of late (while reading some great books on the topic). We need more discussion like this.

Some folks called for browsers to ‘fix’ it. Some folks dug a bit deeper and saw that it only affected sites built in React-like frameworks, and pointed the finger at React. But the real problem is thinking that third party content is ‘safe’.

When do the ends justify the means? Isn’t the whole point of having principles that they hold true even in the direst circumstances? Why even claim that corporations shouldn’t influence politics if you’re going to make an exception for net neutrality? Why even claim that free speech is sacrosanct if you make an exception for nazi scum?

Those two examples are pretty extreme and I can easily justify the exceptions to myself. Net neutrality is too important. Stopping fascism is too important. But where do I draw the line? At what point does something become “too important?”

It’s a lovely post that connects dots between censorship, AMP, HTTPS as a requirement for new features and more.

And today, right now, I don’t think we need to look further than AMP to see an example of what Franklin’s talking about. As of this moment, the power dynamics are skewed pretty severely in favor of Google’s proprietary AMP standard, and against those of us who’d ask this question: What can I do about AMP?

But he goes on to point out that we can, and should, still speak up about our concerns and rally together:

That doesn’t mean it’s not worth speaking up, individually and collectively, and writing about our concerns. Quite the opposite. In fact, that’s why I signed an open letter on AMP, alongside twenty other concerned colleagues. (If you or your organization has a GitHub account, you can sign it, too.) Perhaps together, we can make the issue more visible, and make more people and organizations aware of our concerns. So while there might not be much I can do about AMP, maybe there’s something we can do.

Microsoft’s error rate for darker-skinned women was 21 percent, while IBM’s and Megvii’s rates were nearly 35 percent. They all had error rates below 1 percent for light-skinned males.

Those are bad numbers, but they shouldn’t be surprising—not when we’re training these algorithm’s with a poorly constructed data set.

One widely used facial-recognition data set was estimated to be more than 75 percent male and more than 80 percent white, according to another research study.

The stakes are just too high for us to continue to build technology without making sure we’re taking off our blinders and accounting for our biases. Oversights like this leave people out, at best. At their worst, they are capable of doing even worse.

Look at that form. It has fields like street address, state/province/region, apartment, zip code? What is that? I can only tell you that I live in Kanyanya, a Kampala suburb. If you need my exact home, then I’ll either have to send you a GPS location via apps like Whatsapp, Telegram, or Google Maps, or engage you in a long phone conversation in which I’ll try to describe landmarks, building and trees leading to my house. But street address, zip code? Hell no.

I can’t tell you how many times I have reached this step in shopping process and just froze. Several of my friends have had the same experience and yet this terrible form continues to be used by several upcoming online stores such as Rocket Internet’s Jumia. In the end, users just resign and simply buy stuff from the old-school brick-and-mortar stores.

Set up a blog somewhere, anywhere, and write as much as you can. If I’m in a position to hire you, I don’t just want to see the quality of your final mockup, your finished set of templates: I want to learn how you got there. I want to read what worked, what didn’t, and the decisions you made along the way.

Thankfully, it looks like the folks at Global Voices did. There’s a 36-page PDF report available detailing their findings, as well as several country-specific reports. Their key findings certainly don’t make me feel any better about the app:

Free Basics might not speak your language: Free Basics does not meet the linguistic needs of target users.

Free Basics features little local content, but plenty of corporate services from the US and UK.

Free Basics doesn’t connect you to the global internet – but it does collect your data…

Free Basics violates net neutrality principles: Free Basics does not allow users to browse the open Internet.

Global Voices research findings suggest that most of the content offered via Free Basics will not meet the most pressing needs of those who are not online, and that the data and content limitations built into Free Basics are largely artificial and primarily aimed at collecting profitable data from users.

When we rethink our approach to development, we go beyond just the base level of access to information. Inclusive development means making something valuable, not just accessible, to as many people as we can.

In our little industry, we often work on decent hardware, on reliable networks. But according to Pew Research, thirty percent of Americans don’t have broadband at home. One in ten American adults are smartphone-only internet users, while 13% of American adults don’t use the internet at all.

Meanwhile, we make mobile-friendly websites with widescreen devices, using broadband to design experiences for slow, unstable networks. In a lot of ways, we’re outliers among the people we’re designing for.

Unsurprisingly, a lot of the advice here mirrors the same sort of good advice an organization might here about cultivating cultures of performance, security or any other critical yet overlooked component of design and development: share knowledge, experience the issues first-hand, celebrate improvements, and build it directly into your workflow.

Even in my tiny design practice, every decision I make is shaped by my biases; every decision I make is capable of harm. And it’s so, so easy to forget this: to focus on the layout challenge in front of me, to fulfil the client’s latest request, or to meet a business goal. When I do these things, I occasionally forget to ask myself who’ll be impacted by my work and, most importantly, to ask how I can mitigate that harm.

The Privacy Paradox, a five-part series of podcasts done by Note to Self, does an excellent job of explaining what the risks are and what can be done about it. The episodes are short and actionable: each spends some time on a privacy risk followed by a specific “challenge” you can do to take back a little control. Well worth a listen.

The yellow color was chosen for convenience, according to Nicholson: it was what the lab next door had available, so they used it.

Then there’s this sobering, accurate and important conclusion:

In addition to selective data, as readers we’re over-generalizing our view of the entire other side , based on extreme events or commentary from a select fringe.

This discussion with them about how designers can improve the state of security and privacy online is well worth a read.

…richer teenagers were more likely to use the internet to search for information or to read news rather than to chat or play video games.

If you dig into the actual report itself you’ll find a bit more context.

After accounting for differences in the ability to read and understand printed texts, students’ socio-economic status has only a weak, and often not significant, relationship with performance in the PISA test of digital reading. In other words, students with good reading skills, regardless of their background, have a much easier time finding their way around—and mining the considerable assets of—the Internet.

Seems to echo many other reports about barriers to internet access in stating that literacy—whether digital or language—remains a significant obstacle.

His latest issue mentions this really well-done video from TED-ed about sorting algorithms. The video uses an example of having to sort a pile of books and does a really nice job of illustrating the differences between the various algorithms at your disposal.

Run from data-driven companies. In thrall to semi-science and blinded by their dogma, they’ve lost the ability to see intelligent alternative perspectives on their business, their products, and the world. Embrace instead data-informed companies. This isn’t mere grammatical pedantry — a company genuinely informed by data understands the risks of datafication and adopts sophisticated, balanced approaches to strategy that blend quant, qual, and even some of that unfashionable prediction and intuition.

Here’s the thing: the more we experience how other browsers work, the more we learn about how different users experience our websites.

Animation also aids in perceived performance. Viget conducted a study where they measured user engagement with a standard loading GIF versus a custom animation. Customers were willing to wait almost twice as long for the custom loader, even though it wasn’t anything very fancy or crazy. Just by showing their users that they cared about them, they stuck around, and the bounce rates dropped.

In most cases, I’d argue, it would be even better to provide some sort of feedback to the user about what is happening in the background, but the same general idea applies: taking the time to design for when processes take too long is important.