An interesting proposal to allow websites to detect certain SMS messages. The UX implications are fascinating.
Saturday, September 7th, 2019
Sunday, June 16th, 2019
Although this piece is ostensibly about why we should be using web workers more, there’s a much, much bigger point about the growing power gap between the devices we developers use and the typical device used by the rest of the planet.
While we are getting faster flagship phones every cycle, the vast majority of people can’t afford these. The more affordable phones are stuck in the past and have highly fluctuating performance metrics. These low-end phones will mostly likely be used by the massive number of people coming online in the next couple of years. The gap between the fastest and the slowest phone is getting wider, and the median is going down.
Saturday, December 22nd, 2018
Craig writes about reading and publishing, from the memex and the dynabook to the Kindle, the iPhone, and the iPad, all the way back around to plain ol’ email and good old-fashioned physical books.
We were looking for the Future Book in the wrong place. It’s not the form, necessarily, that needed to evolve—I think we can agree that, in an age of infinite distraction, one of the strongest assets of a “book” as a book is its singular, sustained, distraction-free, blissfully immutable voice. Instead, technology changed everything that enables a book, fomenting a quiet revolution. Funding, printing, fulfillment, community-building—everything leading up to and supporting a book has shifted meaningfully, even if the containers haven’t. Perhaps the form and interactivity of what we consider a “standard book” will change in the future, as screens become as cheap and durable as paper. But the books made today, held in our hands, digital or print, are Future Books, unfuturistic and inert may they seem.
Thursday, August 2nd, 2018
Chris has written about switching code editors. I’m a real stick-in-the-mud when it comes to switching editors. Partly that’s because I’m generally pretty happy with whatever I’m using (right now it’s Atom) but it’s also because I just don’t get that excited about software like this. I probably should care more; I spend plenty of time inside a code editor. And I should really take the time to get to grips with features like keyboard shortcuts—I’m sure I’m working very inefficiently. But, like I said, I find it hard to care enough, and on the whole, I’m content.
I was struck by this observation from Chris:
When moving, I have to take time to make sure it works pretty much like the old one.
That reminded me of a recent switch I made, not with code editors, but with browsers.
I’ve been using Chrome for years. One day it started crashing a lot. So I decided to make the switch to Firefox. Looking back, I’m glad to have had this prompt—I think it’s good to shake things up every now and then, so I don’t get too complacent (says the hypocrite who can’t be bothered to try a new code editor).
Just as Chris noticed with code editors, it was really important that I could move bookmarks (and bookmarklets!) over to my new browser. On the whole, it went pretty smoothly. I had to seek out a few browser extensions but that was pretty much it. And because I use a password manager, logging into all my usual services wasn’t a hassle.
Of all the pieces of software on my computer, the web browser is the one where I definitely spend the most time: reading, linking, publishing. At this point, I’m very used to life with Firefox as my main browser. It’s speedy and stable, and the dev tools are very similar to Chrome’s.
Maybe I’ll switch to Safari at some point. Like I said, I think it’s good to shake things up and get out of my comfort zone.
Now, if I really wanted to get out of my comfort zone, I’d switch operating systems like Dave did with his move to Windows. And I should really try using a different phone OS. Again, this is something that Dave tried with his switch to Android (although that turned out to be unacceptably creepy), and Paul did it ages ago using a Windows phone for a week.
There’s probably a balance to be struck here. I think it’s good to change code editors, browsers, even operating systems and phones every now and then, but I don’t want to feel like I’m constantly in learning mode. There’s something to be said for using tools that are comfortable and familiar, even if they’re outdated.
Sunday, June 3rd, 2018
I’ve come to believe that the goal of any good framework should be to make itself unnecessary.
The ultimate purpose of PhoneGap is to cease to exist.
That makes total sense, especially if your code is a polyfill—those solutions are temporary by design. Autoprefixer is another good example of a piece of code that becomes less and less necessary over time.
But I think it’s equally true of any successful framework or library. If the framework becomes popular enough, it will inevitably end up influencing the standards process, thereby becoming dispensible.
querySelector without jQuery. The library proved the need for the feature. The same is true for a whole load of DOM scripting features.
The same process is almost certain to occur with React—it’s a good bet there will be a standardised equivalent to the virtual DOM at some point.
When Google first unveiled AMP, its intentions weren’t clear to me. I hoped that it existed purely to make itself redundant:
As well as publishers creating AMP versions of their pages in order to appease Google, perhaps they will start to ask “Why can’t our regular pages be this fast?” By showing that there is life beyond big bloated invasive web pages, perhaps the AMP project will work as a demo of what the whole web could be.
Alas, as time has passed, that hope shows no signs of being fulfilled. If anything, I’ve noticed publishers using the existence of their AMP pages as a justification for just letting their “regular” pages put on weight.
Worse yet, the messaging from Google around AMP has shifted. Instead of pitching it as a format for creating parallel versions of your web pages, they’re now also extolling the virtues of having your AMP pages be the only version you publish:
In fact, AMP’s evolution has made it a viable solution to build entire websites.
On an episode of the Dev Mode podcast a while back, AMP was a hotly-debated topic. But even those defending AMP were doing so on the understanding that it was more a proof-of-concept than a long-term solution (and also that AMP is just for news stories—something else that Google are keen to change).
But now it’s clear that the Google AMP Project is being marketed more like a framework for the future: a collection of web components that prioritise performance …which is kind of odd, because that’s also what Google’s Polymer project is. The difference being that pages made with Polymer don’t get preferential treatment in Google’s search results. I can’t help but wonder how the Polymer team feels about AMP’s gradual pivot onto their territory.
If the AMP project existed in order to create a web where AMP was no longer needed, I think I could get behind it. But the more it’s positioned as the only viable solution to solving performance, the more uncomfortable I am with it.
Which, by the way, brings me to one of the most pernicious ideas around Google AMP—positioning anyone opposed to it as not caring about web performance. Nothing could be further from the truth. It’s precisely because performance on the web is so important that it deserves a long-term solution, co-created by all of us: not some commandents delivered to us from on-high by one organisation, enforced by preferential treatment by that organisation’s monopoly in search.
It’s the classic logical fallacy:
- Performance! Something must be done!
- AMP is something.
- Now something has been done.
By marketing itself as the only viable solution to the web performance problem, I think the AMP project is doing itself a great disservice. If it positioned itself as an example to be emulated, I would welcome it.
I wish that AMP were being marketed more like a temporary polyfill. And as with any polyfill, I look forward to the day when AMP is no longer necesssary.
I want AMP to become extinct. I genuinely think that the Google AMP team should share that wish.
Tuesday, May 22nd, 2018
Like a nicotine patch for your phone hand.
Monday, May 21st, 2018
Chris weighs up the ethical implications of Google Duplex:
The social hacking that could be accomplished is mind-boggling. For this reason, I expect that having human-sounding narrow AI will be illegal someday. The Duplex demo is a moment of cultural clarity, where it first dawned on us that we can do it, but with only a few exceptions, we shouldn’t.
But he also offers alternatives for designing systems like this:
- Provide disclosure, and
- Design a hot signal:
…design the interface so that it is unmistakeable that it is synthetic. This way, even if the listener missed or misunderstood the disclosure, there is an ongoing signal that reinforces the idea. As designer Ben Sauer puts it, make it “Humane, not human.”
Wednesday, May 9th, 2018
I can’t recall the last time I was so creeped out by a technology as I am by Google Duplex—the
AI that can make reservations over the phone by pretending to be a human.
I’m not sure what’s disturbing me more: the technology itself, or the excited reaction of tech bros who can’t wait to try it.
Thing is …when these people talk about being excited to try it, I’m pretty sure they are only thinking of trying it as a caller, not a callee. They aren’t imagining that they could possibly be one of the people on the other end of one of those calls.
The visionaries of technology—Douglas Engelbart, J.C.R Licklider—have always recognised the potential for computers to augment humanity, to be bicycles for the mind. I think they would be horrified to see the increasing trend of using humans to augment computers.
Thursday, April 5th, 2018
This is absolutely brilliant!
Forgive my excitement, but this transcript of Charlie’s talk is so, so good—an equal mix of history and practical advice. Once you’ve read it, share it. I want everyone to have the pleasure of reading this inspiring piece!
It is this flirty declarative nature makes HTML so incredibly robust. Just look at this video. It shows me pulling chunks out of the Amazon homepage as I browse it, while the page continues to run.
Let’s just stop and think about that, because we take it for granted. I’m pulling chunks of code out of a running computer application, AND IT IS STILL WORKING.
Just how… INCREDIBLE is that? Can you imagine pulling random chunks of code out of the memory of your iPhone or Windows laptop, and still expecting it to work? Of course not! But with HTML, it’s a given.
Yeah. Fuck this. That’s creepy. Technically I opted into this feature because Google Maps asked “Google Maps would like to know your location, YES or NO?” Of course my answer was “YES” because, hey, it’s a fucking map. I didn’t realize I consented to having my information and location history stored indefinitely on Google’s servers.
I began all the work of disabling this “feature” but it seemed like a fruitless task. Also worth noting, Google Maps for iOS keeps Location History as well.
Tuesday, January 30th, 2018
Famous first words
Saturday, September 23rd, 2017
This could be a one-word article: don’t.
More specifically, don’t design websites for any specific device. That way lies pain (and it is not the way of the web).
But read on for a textbook example of how not to introduce new CSS properties. Apple proposed the new syntax that they’re shipping. Now it’s getting standardised …with a different name. So basically Apple are shipping the equivalent of a vendor-prefixed property without the vendor prefix.
Thursday, September 21st, 2017
One more reason not to use sticky headers on mobile.
Wednesday, July 19th, 2017
The magical and the mundane
The iPhone—and by extension, the smartphone—is a decade old. Ian Bogost has written an interesting piece in The Atlantic charting our changing relationship with the technology.
First, it was like a toy dog:
A device that could be cared for, and conspicuously so.
Then, it was like a cigarette:
A nervous tic, facilitated by a handheld apparatus that releases relief when operated.
Later, it was like a rosary:
Its toy-dog quirks having been tamed, its compulsive nature having been accepted, the iPhone became the magic wand by which all worldly actions could be performed, all possible information acquired.
Finally, it simply becomes …a rectangle.
Abstract, as a shape. Flat, as a surface. But suggestive of so much. A table for community. A door for entry, or for exit. A window for looking out of, or a picture for looking into. A movie screen for distraction, or a cradle for comfort, or a bed for seduction.
Technology tweaks our desire for novelty; but as soon as we get it we’re usually bored. There are no technologies that I can think of that haven’t become mundane.
This is something I touched on in my talk last year at An Event Apart. There’s a thread throughout the talk about Arthur C. Clarke, and of course I quote his third law:
Any sufficiently advanced technology is indistinguishable from magic.
I propose an addendum to that:
Any sufficiently advanced technology is indistinguishable from magic at first.
The magical quickly becomes the mundane. That’s exactly the point that Louis CK is making in the piece that Ben references.
Seven years ago Frank wrote his wonderful essay There Is A Horse In The Apple Store:
I have a term called a “tiny pony.” It is a thing that is exceptional that no one, for whatever reason, notices. Or, conversely, it is an exceptional thing that everyone notices, but quickly grows acclimated to despite the brilliance of it all.
We are surrounded by magical tiny ponies. I mean, just think: right now you are reading some words at a URL on the World Wide Web. Even more magically, I just published some words at my own URL on the World Wide Web. That still blows my mind! I hope I never lose that feeling.
Friday, March 24th, 2017
Steps you can take to secure your phone and computer. This is especially useful in countries where ubiquitous surveillance is not only legal, but mandated by law (such as China, Australia, and the UK).
Monday, March 20th, 2017
The second part of Bruce’s excellent series begins by focusing on the usage of proxy browsers around the world:
But how!? Well, Bruce has the answer:
I call this amazing new technique “progressive enhancement.”
You heard it here first, folks!
Wednesday, January 25th, 2017
A service for US citizens that suggest five phone calls they can make at any time—based on their location—to influence their representatives.
Calling is the most effective way to influence your representative. 5 Calls gives you contacts and scripts so calling is quick and easy. We use your location to give you your local representatives so your calls are more impactful.
Friday, September 30th, 2016
This is what tells all our browsers on all our devices to set the viewport to be the same width of the current device, and to also set the initial scale to 1 (not scaled at all). This essentially allows us to have responsive design consistently.
<meta name="viewport" content="width=device-width, initial-scale=1">
viewport value for the
meta element was invented by Apple when the iPhone was released. Back then, it was a safe bet that most websites were wider than the iPhone’s 320 pixel wide display—most of them were 960 pixels wide …because reasons. So mobile Safari would automatically shrink those sites down to fit within the display. If you wanted to over-ride that behaviour, you had to use the
meta viewport gubbins that they made up.
That was nine years ago. These days, if you’re building a responsive website, you still need to include that
That seems like a shame to me. I’m not suggesting that the default behaviour should switch to assuming a fluid layout, but maybe the browser could just figure it out. After all, the CSS will already be parsed by the time the HTML is rendering. Perhaps a quick test for the presence of a crawlbar could be used to trigger the shrinking behaviour. No crawlbar, no shrinking.
Maybe someday the assumption behind the current behaviour could be flipped—assume a website is responsive unless the author explicitly requests the shrinking behaviour. I’d like to think that could happen soon, but I suspect that a depressingly large number of sites are still fixed-width (I don’t even want to know—don’t tell me).
There are other browser default behaviours that might someday change. Right now, if I type
example.com into a browser, it will first attempt to contact
http://example.com rather than
https://example.com. That means the
example.com server has to do a redirect, costing the user valuable time.
You can mitigate this by putting your site on the HSTS preload list but wouldn’t it be nice if browsers first checked for
HTTPS instead of
HTTP? I don’t think that will happen anytime soon, but someday …someday.
Saturday, May 28th, 2016
Remy looks at the closing gap between native and web. Things are looking pretty damn good for the web, with certain caveats:
The web is the long game. It will always make progress. Free access to both consumers and producers is a core principle. Security is also a core principle, and sometimes at the costs of ease to the developer (but if it were easy it wouldn’t be fun, right?).
That’s why there’ll always be some other technology that’s ahead of the web in terms of features, but those features give the web something to aim for:
Flash was the plugin that was ahead of the web for a long time, it was the only way to play video for heavens sake!
Whereas before we needed polyfills like PhoneGap (whose very reason for existing is to make itself obsolete), now with progressive web apps, we’re proving the philosophy behind PhoneGap:
If the web doesn’t do something today it’s not because it can’t, or won’t, but rather it is because we haven’t gotten around to implementing that capability yet.