This is a smart collection of situations to consider and the CSS to resolve them. It’s all about unearthing assumptions.
Tuesday, December 14th, 2021
Tuesday, August 3rd, 2021
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!).
Friday, June 4th, 2021
On framework-dependency and longevity:
Monday, August 17th, 2020
Mind the gap
In May 2012, Brian LeRoux, the creator of PhoneGap, wrote a post setting out the beliefs, goals and philosophy of the project.
The beliefs are the assumptions that inform everything else. Brian stated two core tenets:
- The web solved cross platform.
- All technology deprecates with time.
That second belief then informed one of the goals of the PhoneGap project:
The ultimate purpose of PhoneGap is to cease to exist.
Last week, PhoneGap succeeded in its goal:
Since the project’s beginning in 2008, the market has evolved and Progressive Web Apps (PWAs) now bring the power of native apps to web applications.
Today, we are announcing the end of development for PhoneGap.
I think Brian was spot-on with his belief that all technology deprecates with time. I also think it was very astute of him to tie the goals of PhoneGap to that belief. Heck, it’s even in the project name: PhoneGap!
I recently wrote this about Sass and clamp:
jQuery is the perfect example of this. jQuery is no longer needed because cross-browser DOM Scripting is now much easier …thanks to jQuery.
Successful libraries and frameworks point the way. They show what developers are yearning for, and that’s where web standards efforts can then focus. When a library or framework is no longer needed, that’s not something to mourn; it’s something to celebrate.
That’s particularly true if the library of code needs to be run by a web browser. The user pays a tax with that extra download so that the developer gets the benefit of the library. When web browsers no longer need the library in order to provide the same functionality, it’s a win for users.
In fact, if you’re providing a front-end library or framework, I believe you should be actively working towards making it obselete. Think of your project as a polyfill. If it’s solving a genuine need, then you should be looking forward to the day when your code is made redundant by web browsers.
One more thing…
I think it was great that Brian documented PhoneGap’s beliefs, goals and philosophy. This is exactly why design principles can be so useful—to clearly set out the priorities of a project, so that there’s no misunderstanding or mixed signals.
If you’re working on a project, take the time to ask yourself what assumptions and beliefs are underpinning the work. Then figure out how those beliefs influence what you prioritise.
Ultimately, the code you produce is the output generated by your priorities. And your priorities are driven by your purpose.
You can make those priorities tangible in the form of design principles.
You can make those design principles visible by publishing them.
Friday, January 10th, 2020
We have to stop confusing the excesses of capitalism with the hallmarks of quality. Sometimes Google aren’t better, they’re just more pervasive.
cough AMP cough
Tuesday, August 7th, 2018
Oh, this is magnificent! A rallying call for everyone designing and developing on the web to avoid making any assumptions about the people we’re building for:
People will use your site how they want, and according to their means. That is wonderful, and why the Web was built.
I would even say that the % of people viewing your site the way you do rapidly approaches zilch.
Saturday, May 12th, 2018
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.
Sunday, December 3rd, 2017
Monday, November 27th, 2017
The Fallacies of Distributed Computing (Applied to Front-End Performance) – CSS Wizardry – CSS Architecture, Web Performance Optimisation, and more, by Harry Roberts
Harry cautions against making assumptions about the network when it comes to front-end development:
Yet time and time again I see developers falling into the same old traps—making assumptions or overly-optimistic predictions about the conditions in which their apps will run.
Planning for the worst-case scenario is never a wasted effort:
If you build and structure applications such that they survive adverse conditions, then they will thrive in favourable ones.
Wednesday, November 2nd, 2016
We all make assumptions, it’s natural and normal. But we also need to be jolted out of those assumptions on a regular basis to help us see that not everyone uses the web the way we do. I’ve talked about loving doing support for that reason, but I also love it when I’m on a slow network, it shows me how some people experience the web all the time; that’s good for me.
I’m privileged to have fast devices and fast, broadband internet, along with a lot of other privileges. Not remembering that privilege while I work and assuming that everyone is like me is, quite possibly, one of the biggest mistakes I can make.
Saturday, October 29th, 2016
As Benedict Evans has noted, the next billion people who are poised to come online will be using the internet almost exclusively through smartphones. And if Google’s plans with Android One are any indication, then we have a fairly good idea of what kind of devices the “next billion” will be using:
- They’ll mostly be running Android.
- They’ll have decent specs (1GB RAM, quad-core processors).
- They’ll have an evergreen browser and WebView (Android 5+).
- What they won’t have, however, is a reliable internet connection.
This is the same argument that Tom made in his presentation at Responsive Field Day. The main point is that network conditions are unreliable, and I absolutely agree that we need to be very, very mindful of that. But I’m not so sure about the other conditions either. They smell like assumptions:
Assumptions are the problem. Whether it’s assumptions about screen size, assumptions about being able-bodied, assumptions about network connectivity, or assumptions about browser capabilities, I don’t think any assumptions are a safe bet. Now you might quite reasonably say that we have to make some assumptions when we’re building on the web, and you’d be right. But I think we should still aim to keep them to a minimum.
It’s not necessarily true that all those new web users will be running WebView browser like Chrome—there are millions of Opera Mini users, and I would expect that number to rise, given all the speed and cost benefits that proxy browsing brings.
I also don’t think that just because a device is a smartphone it necessarily means that it’s a pocket supercomputer. It might seem like a reasonable assumption to make, given the specs of even a low-end smartphone, but the specs don’t tell the whole story.
Alex gave a great presentation at the recent Polymer Summit. He dives deep into exactly how smartphones at the lower end of the market deal with websites.
Alex’s talk prompted Michael Scharnagl to take a look back at past assumptions and lessons learned on the web, from responsive design to progressive web apps.
We are consistently improving and we often have to realize that our assumptions are wrong.
This is particularly true when we’re making assumptions about how people will access the web.
It’s not enough to talk about the “next billion” in abstract, like an opportunity to reach teeming masses of people ripe for monetization. We need to understand their lives and their priorities with the sort of detail that can build empathy for other people living under vastly different circumstances.
That’s from an article Ethan linked to, noting:
When I read articles defining “the mobile web” as “decent hardware and evergreen browsers”, I start thinking hard about our industry biases.— Ethan Marcotte (@beep) October 13, 2016
Sunday, October 23rd, 2016
A collection of assumptions programmers often make.
“Dates and Times” is tied with “Human Identity” for the most links.
Monday, September 7th, 2015
Tuesday, June 30th, 2015
This is the way to approach building for the web:
I want to make as few of those assumptions as possible. Because every assumption I make introduces fragility. Every assumption introduces another way that my site can break.
It’s progressive enhancement, but like Stuart, Tim is no longer planning to use that term.
Monday, May 16th, 2011
Susan pushes back on the notion of the mythical mobile user.
Thursday, February 24th, 2011
Yes! Yes! Yes! Mark nails it: just because someone visits a site with a certain kind of device doesn’t mean you can make assumptions about their intentions.
- Mobile != low download speed
- Context != intent