A very handy guide to considering privacy at all stages of digital product design:
This guidance is written for technology professionals such as product and UX designers, software engineers, QA testers, and product managers.
I was chatting with my new colleague Alex yesterday about a link she had shared in Slack. It was the Nielsen Norman Group’s annual State of Mobile User Experience report.
There’s nothing too surprising in there, other than the mention of Apple’s app clips and Google’s instant apps.
Remember those?
Me neither.
Perhaps I lead a sheltered existence, but as an iPhone user, I don’t think I’ve come across a single app clip in the wild.
I remember when they were announced. I was quite worried about them.
See, the one thing that the web can (theoretically) offer that native can’t is instant access to a resource. Go to this URL—that’s it. Whereas for a native app, the flow is: go to this app store, find the app, download the app.
(I say that the benefit is theoretical because the website found at the URL should download quickly—the reality is that the bloat of “modern” web development imperils that advantage.)
App clips—and instant apps—looked like a way to route around the convoluted install process of native apps. That’s why I was nervous when they were announced. They sounded like a threat to the web.
In reality, the potential was never fulfilled (if my own experience is anything to go by). I wonder why people didn’t jump on app clips and instant apps?
Perhaps it’s because what they promise isn’t desirable from a business perspective: “here’s a way for users to accomplish their tasks without downloading your app.” Even though app clips can in theory be a stepping stone to installing the full app, from a user’s perspective, their appeal is the exact opposite.
Or maybe they’re just too confusing to understand. I think there’s an another technology that suffers from the same problem: progressive web apps.
Hear me out. Progressive web apps are—if done well—absolutely amazing. You get all of the benefits of native apps in terms of UX—they even work offline!—but you retain the web’s frictionless access model: go to a URL; that’s it.
So what are they? Are they websites? Yes, sorta. Are they apps? Yes, sorta.
That’s confusing, right? I can see how app clips and instant apps sound equally confusing: “you can use them straight away, like going to a web page, but they’re not web pages; they’re little bits of apps.”
I’m mostly glad that app clips never took off. But I’m sad that progressive web apps haven’t taken off more. I suspect that their fates are intertwined. Neither suffer from technical limitations. The problem they both face is inertia:
The technologies are the easy bit. Getting people to re-evaluate their opinions about technologies? That’s the hard part.
True of progressive web apps. Equally true of app clips.
But when I was chatting to Alex, she made me look at app clips in a different way. She described a situation where somebody might need to interact with some kind of NFC beacon from their phone. Web NFC isn’t supported in many browsers yet, so you can’t rely on that. But you don’t want to make people download a native app just to have a quick interaction. In theory, an app clip—or instant app—could do the job.
In that situation, app clips aren’t a danger to the web—they’re polyfills for hardware APIs that the web doesn’t yet support!
I love having my perspective shifted like that.
The specific situations that Alex and I were discussing were in the context of museums. Musuems offer such interesting opportunities for the physical and the digital to intersect.
Remember the pen from Cooper Hewitt? Aaron spoke about it at dConstruct 2014—a terrific presentation that’s well worth revisiting and absorbing.
The other dConstruct talk that’s very relevant to this liminal space between the web and native apps is the 2012 talk from Scott Jenson. I always thought the physical web initiative had a lot of promise, but it may have been ahead of its time.
I loved the thinking behind the physical web beacons. They were deliberately dumb, much like the internet itself. All they did was broadcast a URL. That’s it. All the smarts were to be found at the URL itself. That meant a service could get smarter over time. It’s a lot easier to update a website than swap out a piece of hardware.
But any kind of technology that uses Bluetooth, NFC, or other wireless technology has to get over the discovery problem. They’re invisible technologies, so by default, people don’t know they’re even there. But if you make them too discoverable— intrusively announcing themselves like one of the commercials in Minority Report—then they’re indistinguishable from spam. There’s a sweet spot of discoverability right in the middle that’s hard to get right.
Over the past couple of years—accelerated by the physical distancing necessitated by The Situation—QR codes stepped up to the plate.
They still suffer from some discoverability issues. They’re not human-readable, so you can’t be entirely sure that the URL you’re going to go to isn’t going to be a Rick Astley video. But they are visible, which gives them an advantage over hidden wireless technologies.
They’re cheaper too. Printing a QR code sticker costs less than getting a plastic beacon shipped from China.
QR codes turned out to be just good enough to bridge the gap between the physical and digital for those one-off interactions like dining outdoors during a pandemic:
I can see why they chose the web over a native app. Online ordering is the only way to place your order at this place. Telling people “You have to go to this website” …that seems reasonable. But telling people “You have to download this app” …that’s too much friction.
Ironically, the nail in the coffin for app clips and instant apps might’ve been hammered in by Apple and Google when they built QR-code recognition into their camera software.
The speed with which Twitter recedes in your mind will shock you. Like a demon from a folktale, the kind that only gains power when you invite it into your home, the platform melts like mist when that invitation is rescinded.
Kevin takes my eleven-year old remark literally and points out at least you can emulate LaserDiscs:
So LaserDiscs aren’t the worst things to archive, networks of servers running code that isn’t available or archivable are, and we are building a lot more of those these days, whether on the web or in apps.
I love this: Terence takes eleven years to reflect on a comment I made on stage at an event here in Brighton. It’s all about the longevity of the web compared to native apps:
If you wrote an app for an early version of iOS or Android, it simply won’t run on modern hardware or software. APIs have changed, SDKs weren’t designed with forward compatibility, and app store requirements have evolved.
The web has none of that. The earliest websites are viewable on modern browsers.
As wrote at the time, I may have been juicing things up for entertainment:
Now here’s the thing when it comes to any discussion about mobile or the web or anything else of any complexity: an honest discussion would result in every single question being answered with “it depends”. A more entertaining discussion, on the other hand, would consist of deliberately polarised opinions. We went for the more entertaining discussion.
But I think this still holds true for me today:
The truth is that the whole “web vs. native” thing doesn’t interest me that much. I’m as interested in native iOS development as I am in native Windows development or native CD-ROM development. On a timescale measured in years, they are all fleeting, transient things. The web abides.
Not much stays in one place for one long, especially when it comes to digital artifacts. When the Yahoo Groups archive was summarily deleted by parent company Verizon just a few years ago, fandom suffered massive losses, just as it had during the Livejournal purges of the late 02000s, and during the Tumblr porn ban in 02018. Fandom preservation, then, ties into the larger issue of digital preservation as a whole, and specifically the question of how individual and group emotions and experiences — which make up so much of what it means to be a fan — can be effectively documented, annotated, and saved.
Robin adds a long-zoom perspective on my recent post:
I am extremely confident that pretty much any HTML I write today will render the same way in 50 years’ time. How confident am I that my CSS will work correctly? Mmmm…70%. Hand-written JavaScript? Way less, maybe 50%. A third-party service I install on a website or link to? 0% confident. Heck, I’m doubtful that any third-party service will survive until next year, let alone 50 years from now.
Deleting your old thoughts may be giving your older self a kick they really don’t deserve. And the beauty of having an archive is that you don’t need to decide whether you were right or not. Your views, with a date attached, can stand as a reflection of a specific moment in time.
Reconciling every past view you’ve ever had with how you feel now isn’t required. It sounds exhausting, frankly.
Obviously, no one does this, I recognize this is a very niche endeavor, but the art and craft of maintaining a homepage, with some of your writing and a page that’s about you and whatever else over time, of course always includes addition and deletion, just like a garden — you’re snipping the dead blooms. I do this a lot. I’ll see something really old on my site, and I go, “you know what, I don’t like this anymore,” and I will delete it.
But that’s care. Both adding things and deleting things. Basically the sense of looking at something and saying, “is this good? Is this right? Can I make it better? What does this need right now?” Those are all expressions of care. And I think both the relentless abandonment of stuff that doesn’t have a billion users by tech companies, and the relentless accretion of garbage on the blockchain, I think they’re both kind of the antithesis, honestly, of care.
Following on from my recently-lost long bet, this is a timely bit of data spelunking from Brian analysing the linkrot of 1400 links over 18 years of time.
This is like the Gashlycrumb Tinies but for websites:
It’s been interesting to see how websites die — from domain parking pages to timeouts to blank pages to outdated TLS cipher errors, there are a multitude of different ways.
Goodreads lost my entire account last week. Nine years as a user, some 600 books and 250 carefully written reviews all deleted and unrecoverable. Their support has not been helpful. In 35 years of being online I’ve never encountered a company with such callous disregard for their users’ data.
Ouch! Lesson learned:
My plan now is to host my own blog-like collection of all my reading notes like Tom does.
If you rely on Word, Evernote or Notion, for example, then you can’t work unless you have Word, Evernote, or Notion. You are helpless without them. You are dependent.
But if you only use plain text, you can use any program on any device, forever. It gives great flexibility and peace of mind.
The Long Now foundation has a write-up on my recently-lost long bet:
On February 22, 02011, Jeremy Keith made a prediction that he hoped would be proven wrong.
Eleven years ago, I made a prediction:
The original URL for this prediction (www.longbets.org/601) will no longer be available in eleven years.
One year later, Matt called me on it and the prediction officially became a bet:
We’re playing for $1000. If I win, that money goes to the Bletchley Park Trust. If Matt wins, it goes to The Internet Archive.
I’m very happy to lose this bet.
When I made the original prediction eleven years ago that a URL on the longbets.org site would no longer be available, I did so in a spirit of mischief—it was a deliberately meta move. But it was also informed by a genuine feeling of pessimism around the longevity of links on the web. While that pessimism was misplaced in this case, it was informed by data.
The lifetime of a URL on the web remains shockingly short. What I think has changed in the intervening years is that people may have become more accustomed to the situation. People used to say “once something is online it’s there forever!”, which infuriated me because the real problem is the exact opposite: if you put something online, you have to put in real effort to keep it online. After all, we don’t really buy domain names; we just rent them. And if you publish on somebody else’s domain, you’re at their mercy: Geocities, MySpace, Facebook, Medium, Twitter.
These days my view towards the longevity of online content has landed somewhere in the middle of the two dangers. There’s a kind of Murphy’s Law around data online: anything that you hope will stick around will probably disappear and anything that you hope will disappear will probably stick around.
One huge change in the last eleven years that I didn’t anticipate is the migration of websites to HTTPS. The original URL of the prediction used HTTP. I’m glad to see that original URL now redirects to a more secure protocol. Just like most of the World Wide Web. I think we can thank Let’s Encrypt for that. But I think we can also thank Edward Snowden. We are no longer as innocent as we were eleven years ago.
I think if I could tell my past self that most of the web would using HTTPS by 2022, my past self would be very surprised …’though not as surprised at discovering that time travel had also apparently been invented.
The Internet Archive has also been a game-changer for digital preservation. While it’s less than ideal that something isn’t reachable at its original URL, knowing that there’s probably a copy of the content at archive.org lessens the sting considerably. I couldn’t be happier that this fine institution is the recipient of the stakes of this bet.
The bet was been won (not by me, thankfully) and Jason has some thoughts.
A potted history of communication networks from the pony express and the telegraph to ethernet and wi-fi.
It’s a bit of a cliché to talk about living in the future. It’s also a bit pointless. After all, any moment after the big bang is a future when viewed from any point in time before it.
Still, it’s kind of fun when a sci-fi date rolls around. Like in 2015 when we reached the time depicted in Back To The Future 2, or in 2019 when we reached the time of Blade Runner.
In 2022 we are living in the future of web standards. Again, technically, we’re always living in the future of any past discussion of web standards, but this year is significant …in a very insignificant way.
It all goes back to 2008 and an interview with Hixie, editor of the HTML5 spec at the WHATWG at the time. In it, he mentioned the date 2022 as the milestone for having two completely interoperable implementations.
The far more important—and ambitious—date was 2012, when HTML5 was supposed to become a Candidate Recommendation, which is standards-speak for done’n’dusted.
But the mere mention of the year 2022 back in the year 2008 was too much for some people. Jeff Croft, for example, completely lost his shit (Jeff had a habit of posting angry rants and then denying that he was angry or ranty, but merely having a bit of fun).
The whole thing was a big misunderstanding and soon irrelevant: talk of 2022 was dropped from HTML5 discussions. But for a while there, it was fascinating to see web designers and developers contemplate a year that seemed ludicriously futuristic. Jeff wrote:
God knows where I’ll be in 13 years. Quite frankly, I’ll be pretty fucking disappointed in myself (and our entire industry) if I’m writing HTML in 13 years.
That always struck me as odd. If I thought like that, I’d wonder what the point would be in making anything on the web to begin with (bear in mind that both my own personal website and The Session are now entering their third decade of life).
I had a different reaction to Jeff, as I wrote in 2010:
Many web developers were disgusted that such a seemingly far-off date was even being mentioned. My reaction was the opposite. I began to pay attention to HTML5.
But Jeff was far from alone. Scott Gilbertson wrote an angry article on Webmonkey:
If you’re thinking that planning how the web will look and work 13 years from now is a little bit ridiculous, you’re not alone.
Even if your 2022 ronc-o-matic web-enabled toaster (It slices! It dices! It browses! It arouses!) does ship with Firefox v22.3, will HTML still be the dominant language of web? Given that no one can really answer that question, does it make sense to propose a standard so far in the future?
(I’m re-reading that article in the current version of Firefox: 95.0.2.)
Brian Veloso wrote on his site:
Two-thousand-twenty-two. That’s 14 years from now. Can any of us think that far? Wouldn’t our robot overlords, whether you welcome them or not, have taken over by then? Will the internet even matter then?
From the comments on Jeff’s post, there’s Corey Dutson:
2022: God knows what the Internet will look like at that point. Will we even have websites?
Dan Rubin, who has indeed successfully moved from web work to photography, wrote:
I certainly don’t intend to be doing “web work” by that time. I’m very curious to see where the web actually is in 14 years, though I can’t imagine that HTML5 will even get that far; it’ll all be obsolete before 2022.
Joshua Works made a prediction that’s worryingly close to reality:
I’ll be surprised if website-as-HTML is still the preferred method for moving around the tons of data we create, especially in the manner that could have been predicted in 2003 or even today. Hell, iPods will be over 20 years old by then and if everything’s not run as an iPhone App, then something went wrong.
Someone with the moniker Grand Caveman wrote:
In 2022 I’ll be 34, and hopefully the internet will be obsolete by then.
Perhaps the most level-headed observation came from Jonny Axelsson:
The world in 2022 will be pretty much like the world in 2009.
The world in 2009 is pretty much like 1996 which was pretty much like the world in 1983 which was pretty much like the world in 1970. Some changes are fairly sudden, others are slow, some are dramatic, others subtle, but as a whole “pretty much the same” covers it.
The Web in 2022 will not be dramatically different from the Web in 2009. It will be less hot and it will be less cool. The Web is a project, and as it succeeds it will fade out of our attention and into the background. We don’t care about things when they work.
Now that’s a sensible perspective!
So who else is looking forward to seeing what the World Wide Web is like in 2036?
I must remember to write a blog post then and link back to this one. I have no intention of trying to predict the future, but I’m willing to bet that hyperlinks will still be around in 14 years.
Matt’s thoughts on that bet. Not long now…
The internet, it turns out, is not forever. It’s on more of like a 10-year cycle. It’s constantly upgrading and migrating in ways that are incompatible with past content, leaving broken links and error pages in its wake. In other instances, the sites simply shutter, or become so layered over that finding your own footprint is impossible—I have searched “Kate Lindsay Myspace” every which way and have concluded that my content from that platform must simply be lost to time, ingested by the Shai-Hulud of the internet.