The amazon dash is a pinnacle of modern web design. It’s one of the most intrusive, complex, and resource-dependent devices we’ve introduced into our homes, yet it appears as a simple
oval with a single button for a single use. The use is absurdly narrow: the button will have a picture of Tide detergent, and when you press the button, Tide detergent is sent to your
door.
Barely a week goes by between the times that I discover some horrifically over-engineered “solution” on the Internet. Amazon’s Dash buttons are terrible: disposable (plastic)
single-purpose computers that could so easily have been made into something “more” – more-versatile, more-open, more-configurable, more-flexible. Indeed: people have been doing exactly that kind of thing! But the vanilla Dash button remains little more than selling you
convenience (and not much convenience, if we’re honest) in exchange for more and more of your feeling of digital freedom. Yet another example of what replaced the Web we lost…
By hiding the technical processes, and simplifying the onboarding and engagement of their services, Amazon can continually reinforce your depression for a profit— and you can get
name-brand laundry detergent faster.
Also, can I just take a moment to point out how awesome Zach’s website is. Not only is it the perfect example of how fun and weird the Internet can be and having a mixture of fascinating and curious content, it’s also available via dat:// for those of you who’ve got some love for the datbaseiverse.
The web’s founders fully expected some form of digital payment to be integral to its functioning. But nearly three decades later, we’re still waiting.
Back in the 1990s, when Tim Berners-Lee and his team were creating the infrastructure of the World Wide Web, they made a list of the error codes that would
pop up when something went wrong. You’ve surely encountered many of them: “404 Not Found,”
which pops up if you click on a dead link; “401 Unauthorized” when you hit a page that needs a password; and so on.
Here’s one you probably haven’t seen—and its absence from your life speaks to why the promise of the early web seems increasingly out of reach: “402 Payment Required.”
That’s right: The web’s founders fully expected some form of digital payment to be integral to its functioning, just as
integral as links, web pages, and passwords. After all, without a way to quickly and smoothly exchange money, how would a new economy be able to flourish online? Of course there ought
to be a way to integrate digital cash into browsing and other activities. Of course.
Yet after almost three decades, that 402 error code is still “reserved for future use.” So I still have to ask: Where are my digital micropayments? Where are those frictionless,
integrated ways of exchanging money online—cryptographically protected to allow commerce but not surveillance?
…
In response to this article being discussed on MetaFilter, I wrote:
The Web Payments Working Group published a specification for a standardised mechanism for the collection of card payment details online,
a couple of years ago. It’s not quite the same thing because it’s done in the page application rather than at the HTTP(S) level, but it goes a long way towards solving a lot of the
problems with our existing approach to payment processing online.
It’s already seeing adoption in browsers, but merchants and payment processors are unlikely to start rolling it out until adoption until later because (a) they want critical mass and
(b) they’re wary of change. But within a few years, you’ll probably see it for the first time, and you might not even notice.
The idea is that instead of asking you to fill out an (arbitrary) form, a web page will ask your browser to get payment details from you in a standardised format. That might
mean entering your card details if that’s how you prefer to work (but even if you choose to do this, the form you fill in will look the same every time) but it would instead allow you
to use a payment tool built in to your browser, operating system, or password safe to do it for you. I know that browsers and password safes will offer to try to do this
today, but standardising the format means that they’ll always be able to achieve it.
Once this technology’s in place, there’s nothing to stop HTTP 402’s implementation being completed: all the infrastructure will exist.
The thing about the future is that when it arrives, you don’t even notice. It’s never jetpacks and flying cars: it’s a series of iterative changes, each one predictable after the
completion of the last but the entire ensemble seeming innovative and surprising when taken as a whole.
In the days before the web was mainstream, it was a place of creation. First for education, then for every random idea that any creator had!
As the web transitioned from a network of educational institutions to the consumer force it is today, the early adopters were technologists… AKA geeks!
A hallmark of geek culture is fandom – a deep knowledge of whatever topic interests them. This could be about a book, TV show, movie or band. With this passion comes a desire to share
it with the world. Before the internet, there was no clear path. After the web started gaining traction, it was the biggest and easiest megaphone you could want.
It wasn’t always easy to be found, though. There was no search algorithm. Google was not ubiquitous with search. To be found, you needed to be listed on a site that aggregated other
sites about your topic.
…
There was always a certain joy to a well-kept webring, back in the day. I’d love to see a return to this kind of “Indieweb dream”, but I don’t think that just wishing for it nor even
telling people to go out and do it goes far enough, alone. Hopefully Bryan’s post will help nudge a few people in the right direction, though.
We need a movement of developers and enthusiasts who loudly, proudly, use @mozilla@firefox
as their primary browser. On our desktops and our laptops. We test in it, extend it, contribute to it. But we never, ever, take it for granted.
Even if you love Chrome, adore Gmail, and live in Google Docs or Analytics, no single company, let alone a user-tracking advertising giant, should control the internet.
…
Diversity is as good for the web as it is for society. And it starts with us.
Yet more fallout from the Microsoft announcement that Edge will switch to Chromium, which I discussed earlier. This one’s pretty inspirational, and gives a good reminder about what our responsibilities are to the Web, as its
developers.
Microsoft is officially giving up on an independent shared platform for the internet. By adopting Chromium, Microsoft hands over control of even more of online life to Google.
This may sound melodramatic, but it’s not. The “browser engines” — Chromium from Google and Gecko Quantum from Mozilla — are “inside baseball” pieces of software that actually
determine a great deal of what each of us can do online. They determine core capabilities such as which content we as consumers can see, how secure we are when we watch content, and
how much control we have over what websites and services can do to us. Microsoft’s decision gives Google more ability to single-handedly decide what possibilities are available to
each one of us.
From a business point of view Microsoft’s decision may well make sense. Google is so close to almost complete control of the infrastructure of our online lives that it may not be
profitable to continue to fight this. The interests of Microsoft’s shareholders may well be served by giving up on the freedom and choice that the internet once offered us. Google is
a fierce competitor with highly talented employees and a monopolistic hold on unique assets. Google’s dominance across search, advertising, smartphones, and data capture creates a
vastly tilted playing field that works against the rest of us.
From a social, civic and individual empowerment perspective ceding control of fundamental online infrastructure to a single company is terrible. This is why Mozilla exists. We compete with Google not because it’s a good business opportunity. We compete with Google because the health
of the internet and online life depend on competition and choice. They depend on consumers being able to decide we want something better and to take action.
Will Microsoft’s decision make it harder for Firefox to prosper? It could. Making Google more powerful is risky on many fronts. And a big part of the answer depends on what the web
developers and businesses who create services and websites do. If one product like Chromium has enough market share, then it becomes easier for web developers and businesses to decide
not to worry if their services and sites work with anything other than Chromium. That’s what happened when Microsoft had a monopoly on browsers in the early 2000s before Firefox was
released. And it could happen again.
If you care about what’s happening with online life today, take another look at Firefox. It’s radically better than it was 18 months ago — Firefox once again holds its own when it
comes to speed and performance. Try Firefox as your default browser for a week and then decide. Making Firefox
stronger won’t solve all the problems of online life — browsers are only one part of the equation. But if you find Firefox is a good product for you, then your use makes Firefox
stronger. Your use helps web developers and businesses think beyond Chrome. And this helps Firefox and Mozilla make overall life on the internet better — more choice, more security
options, more competition.
Scathing but well-deserved dig at Microsoft by Mozilla, following on from the Edge-switch-to-Chromium I’ve been going on about. Chris is right:
more people should try Firefox (it’s been my general-purpose browser on desktop and mobile ever since Opera threw in the towel and joined the Chromium hivemind in 2013, and on-and-off
plenty before then) – not just because it’s a great browser (and it is!) but also now because it’s important for the diversity and
health of the Web.
We used to have much more diversity in terms of browser engines years ago than we do today. This is easy to understand as the Web in 2018 is far more complex than it was in the early
noughties. It is very costly to develop and maintain a Web engine and few companies have the necessary talent and cash to do it. Microsoft is one of those companies but the fact that
it might be throwing in the towel on its engine signals a bad development for all
of us.
…
Further evaluation of the dangers of the disappearing diversity on the Web, following in the theme of my thoughts the other day about
Microsoft’s adoption of Chromium instead of EdgeHTML in its browser.
Andre raises a real point: how will we fight for a private and decentralised Web when it becomes “the Google Web”?
Yesterday, Quora
announced that 100 million user accounts were compromised, including private activity like downvotes and direct messages, by a “malicious third party.”
Data breaches are a frustrating part of the lifecycle of every online service — as they grow in popularity, they become a bigger and bigger target. Nearly every major online service
has had a security breach: Facebook, Google, Twitter, Yahoo, Tumblr, Uber, Evernote, eBay, Adobe, Target, Twitter, and Sony all extensively leaked user data in the last few years.
Security breaches like these are a strong argument for using a password manager, but not a compelling reason to avoid a service you love, unless you plan to quit the internet
entirely.
But this does seem like a good time to remind you of all the other reasons why you should never, ever use Quora.
…
Short summary of why you shouldn’t use Quora (even ignoring the recent security scare), for those who can’t be bothered clicking-through:
They claim to want to share knowledge, but they hoard and restrict access to knowledge
They’re actively hostile to the free exchange of data, both technically and politically
They directly oppose the archiving and backup of the knowledge they hoard
If you look closely, you’ll find I’ve shown you a sneak-peek at some of what’s behind tomorrow’s door. Shh. Don’t tell our social media officer.
As each door is opened, a different part of a (distinctly-Bodleian/Oxford) winter scene unfolds, complete with an array of fascinating characters connected to the history, tradition,
mythology and literature of the area. It’s pretty cool, and you should give it a go.
If you want to make one of your own – for next year, presumably, unless you’ve an inclination to count-down in this fashion to something else that you’re celebrating 25 days
hence – I’ve shared a version of the code that you can adapt for yourself.
The open-source version doesn’t include the beautiful picture that the Bodleian’s does, so you’ll have to supply your own.
Features that make this implementation a good starting point if you want to make your own digital advent calendar include:
Secure: your server’s clock dictates which doors are eligible to be opened, and only content legitimately visible on a given date can be obtained (no path-traversal,
URL-guessing, or traffic inspection holes).
Responsive: calendar adapts all the way down to tiny mobiles and all the way up to 4K fullscreen along with optimised images for key resolutions.
Friendly: accepts clicks and touches, uses cookies to remember the current state so you don’t have to re-open doors you opened yesterday (unless you forgot to open
one yesterday), “just works”.
Debuggable: a password-protected debug mode makes it easy for you to test, even on a production server, without exposing the secret messages behind each door.
Expandable: lots of scope for the future, e.g. a progressive web app version that you can keep “on you” and which notifies you when a new door’s ready to be opened,
was one of the things I’d hoped to add in time for this year but didn’t quite get around to.
Warp and Weft by Paul Robert Lloyd(paulrobertlloyd.com)
Earlier this month I had the good fortune to attend Material, a conference that explores the concept of the web as a material and all the intrinsic characteristics that entails. The
variety of talks provided new perspectives on what it means to build for – and with – the web, and prompted me to …
…
What it means for something to be of the web has been discussed many times before. While the technical test can be reasonably objective – is it addressable, accessible and available – culturally it remains harder to judge. But I don’t know about you, I’ve found that
certain websites feel more ‘webby’ than others.
…
Despite being nonspecific on the nature of the feeling he describes, Paul hits the nail on the head. Your favourite (non-Medium) blog or guru site almost certainly has that feel of
being “of the web”. Your favourite API-less single-page app (with the growing “please use in Chrome” banner) almost
certainly does not.
If something I want to do with JavaScript can be done with CSS instead, use CSS.
CSS parses and renders faster.
For things like animations, it more easily hooks into the browser’s refresh rate cycle to provide silky smooth animations (this can be done in JS, too, but CSS just makes it so damn
easy).
And it fails gracefully.
A JavaScript error can bring all of the JS on a page to screeching halt. Mistype a CSS property or miss a semicolon? The browser just skips the property and moves on. Use an
unsupported feature? Same thing.
…
This exactly! If you want progressive enhancement (and you should), performance, and the cleanest separation of behaviour and presentation, the pages you deliver to your users
(regardless of what technology you use on your server) should consist of:
HTML, written in such a way that that they’re complete and comprehensible alone – from an information science perspective, your pages shouldn’t “need” any more than this (although
it’s okay if they’re pretty ugly without any more)
CSS, adding design, theme, look-and-feel to your web page
Javascript, using progressive enhancement to add functionality in-the-browser (e.g. validation on the client-side in addition to the server side validation, for speed and
ease of user experience) and, where absolutely necessary, to add functionality not possible any other way (e.g. if you’re looking to tap into the geolocation API, you’re going
to need Javascript… but it’s still desirable to provide as much of the experience as possible without)
Developers failing to follow this principle is making the Web more fragile and harder to archive. It’s not hard to do things “right”: we
just need to make sure that developers learn what “right” is and why it’s important.
Incidentally, I just some enhancements to the header of this site, including some CSS animations on the logo and menu (none of them necessary, but all useful) and some
Javascript to help ensure that users of touch-capable devices have an easier time. Note that neither Javascript nor CSS are required to use this site; they just add value… just
the way the Web ought to be (where possible).
But on the second day, Sebastiaan spent a fair bit of time investigating a more complex use of service workers with the Push API.
…
While I’m very unwilling to grant permission to be interrupted by intrusive notifications, I’d be more than willing to grant permission to allow a website to silently cache timely
content in the background. It would be a more calm technology.
…
Then when I’m on a plane, or in the subway, or in any other situation without a network connection, I could still visit these websites and get content that’s fresh to me. It’s kind of
like background sync in reverse.
…
Yes, yes, yes.The Push API’s got incredible potential for precaching, or even re-caching existing content. How about if you could always instantly open my web site,
whether you were on or off-line, and know that you’d always be able to read the front page and most-recent articles. You should be able to opt-in to “hot” push notifications if that’s
what you really want, but there should be no requirement to do so.
By the time you’re using the Push API for things like this, why not go a step further? How about PWA feed readers or email clients that use web-pushes to keep your Inbox full? What
about social network clients that always load instantly with the latest content? Or even analytics packages to push your latest stats to your device? Or turn-based online games that
push the latest game state, ready for you to make your next move (which can be cached offline and pushed back when online)?
There are so many potential uses for “quiet” pushing, and now I’m itching for an opportunity to have a play with them.
Last week, I attended W3C TPAC as well as the CSS Working Group meeting there. Various changes were made to specifications, and discussions had which I feel are of interest to web
designers and developers. In this article, I’ll explain a little bit about what happens at TPAC, and show some examples and demos of the things we discussed at TPAC for CSS in
particular.
…
This article describes proposals for the future of CSS, some of which are really interesting. It includes mention of:
CSS scrollbars – defining the look and feel of scrollbars. If that sounds familiar, it’s because it’s not actually new: Internet Explorer 5.5 (and
contemporaneous version of Opera) supported a proprietary CSS extension that did the same thing back in 2000!
Aspect ratio units – this long-needed feature would make it possible to e.g. state that a box is square
(or 4:3, or whatever), which has huge value for CSS grid layouts: I’m excited by this one.
:where() – although I’ll be steering clear until they decide whether the related :matches() becomes :is(), I can see a million uses for this (and its widespread
existence would dramatically reduce the amount that I feel the need to use a preprocessor!).
Are you a time-traveller? Just arrived in 2018? Want to know what the Web of our day is like? This. This is what it’s like (click through for the full horror).
This article is a follow-up to my article “Why Google AMP is a threat to the Open
Web”. In the comments of that article I promised I’d soon provide a follow-up, and for reasons I’ll get into, that has not been possible until now – but now I’m finally
providing it.
Back in February I wrote an article saying how I believed Google AMP has been imposed on the web by Google as a ‘standard’ for developing fast webpages, and my dismay about that.
Google apparently developed this as an internal project without any open collaboration, and avoiding the W3C standardization processes. Google made implementation of Google AMP a
requirement to show at the top of the search results for common news searches.
To many of us open web folk, Google’s AMP violated the widely held principle of search engines not putting bias into search results, and/or the principle of web standards (take your
pick – it would not be bias if it was a standardized approach that the wider web community had agreed upon).
…
You know how I feel about AMP. I’m not alone, and others are doing a pretty good job of talking to Google about our concerns. Unfortunately, Google aren’t
listening.
