There was a moment that it seemed like a proliferation of flickr-like webservices would result in a network of deep shared pools of cultural resource, from which every user could build expressions and applications, but the “entrap and surveil” economics of platforms kicked in.
And now we have no history, and rather than communicating via visualizations of our own shared cultural record, we are left waiting like dogs for treats as facebook decides to surface one of our own images from 3 or 8 years ago. Don’t try to search the graph! Advertisers only.
Saturday, April 21st, 2018
Wednesday, April 18th, 2018
What these brands are taking from web-brutalism — and truly, we should all be learning something here — is that User-centered design doesn’t need to be monopolized by the same colors, same buttons, same photography and even same copy you see in pretty much every single website or product.
This excerpt from Claire L. Evans’s new book Broad Band sounds like Halt and Catch Fire, but for real.
Many people saw the web for the ﬁrst time in Jaime’s loft, on a Mac II her hacker friend Phiber Optik set up with a 28.8K internet connection. As avant-garde guitarist Elliott Sharp performed live, and another friend, DJ Spooky, played house tracks, Jaime’s guests gathered around the Mac’s small screen. At the top of 1994, there were fewer than 1,000 websites in the world, mostly personal home pages. These converts would call themselves the “early true believers,” counting the year of their arrival online as a mark of status, the way the ﬁrst punks claimed 1977.
Tuesday, April 17th, 2018
A thorough run-down of the whys and wherefores of being part of the indie web, from Chris.
Wednesday, April 11th, 2018
Tuesday, April 10th, 2018
It’s so great to see the initial UX work that James and I prototyped in a design sprint come to fruition in the form of a progressive web app!
In the case of this web-app, if the tablets go offline, they will still store all the transactions that are made by customers. Once the tablet comes back online, it will sync it back up to the server. That is, essentially, what a Progressive Web App is — a kind of a website with a few more security and, most importantly, offline features.
This is such a great write-up of the workshop I did in Hong Kong!
Jeremy, it was a pleasure to work with you and you are always welcome here in Hong Kong!
If you fancy having this one-day workshop at your company, get in touch.
Friday, April 6th, 2018
This is so great! I don’t just mean the Kickstarter project itself, but this write-up of the origins of pitas.com—it’s a fascinating, heartfelt, genuine piece of web history.
The whole point behind Pitas was, and is, being a simple way to blog. You just open the site, type something into the entry box, and click POST.
And now it’s coming back …if this project gets funded.
I guess if the site gets infested by Nazis we’ll probably not do anything about it for 10 years, then make a bunch of wimpy statements, do nothing, maybe finally request free help from the community and still do nothing about it.
Just kidding, their asses will be kicked off immediately.
Thursday, April 5th, 2018
The first 22 years of the web platform were revolutionary. The open, accessible, and feature-rich applications that exist on the platform continue to drive the global economy. The next 5 years look like they’ll be filled with more innovation and growth than ever.
The web will be the platform of the Next Big Thing. Not just as the distribution network many see it as today; the web platform will deliver the most innovative experiences. They’ll be innovative not just for how they use new technology, but also because of how easy it will be for new users to experience.
Wednesday, April 4th, 2018
I approve of Dries’s plan!
Tuesday, April 3rd, 2018
Designing Progressive Web Apps by Jason Grigsby
Jason wants to talk about a situation you might find yourself in. You’re in a room and in walks the boss, who says “We need a progressive web app.” Now everyone is asking themselves “What is a progressive web app?” Or maybe “How does the CEO even know about progressive web apps?”
Well, trade publications are covering progressive web apps. Lots of stats and case studies are being published. When executives see this kind of information, they don’t want to get left out. Jason keeps track of this stuff at PWA Stats.
Answering the question “What is a progressive web app?” is harder than it should be. The phrase was coined by Frances Berriman and Alex Russell. They listed ten characteristics that defined progressive web apps. The “linkable” and “progressive” characteristics are the really interesting and new characteristics. We’ve had technologies before (like Adobe Air) that tried to make app-like experiences, but they weren’t really of the web. Progressive web apps are different.
Despite this list of ten characteristics, even people who are shipping progressive web apps find it hard to define the damn thing. The definition on Google’s developer site keeps changing. They reduced the characteristics from ten to six. Then it became “reliable, fast, and engaging.” What does that mean? Craigslist is reliable, fast, and engaging—does that mean it’s a progressive web app.
The technical definition is useful (kudos to me, says Jason):
- service worker
- manifest file
If you don’t have those three things, it’s not a progressive web app.
We should definitely use HTTPS if we want make life harder for the NSA. Also browser makers are making APIs available only under HTTPS. By July, Chrome will mark HTTP sites as insecure. Every site should be under HTTPS.
Service workers are where the power is. They act as a proxy. They allow us to say what we want to cache, what we want to go out to the network for; things that native apps have been able to do for a while. With progressive web apps we can cache the app shell and go to the network for content. Service workers can provide a real performance boost.
A manifest file is simply a JSON file. It’s short and clear. It lists information about the app: icons, colours, etc.
Once you provide those three things, you get benefits. Chrome and Opera on Android will prompt to add the app to the home screen.
So that’s what’s required for progressive web apps, but there’s more to them than that (in the same way there’s more to responsive web design than the three requirements in the baseline definition).
The hype around progressive web apps can be a bit of a turn-off. It certainly was for Jason. When he investigated the technologies, he wondered “What’s the big deal?” But then he was on a panel at a marketing conference, and everyone was talking about progressive web apps. People’s expectations of what you could do on the web really hadn’t caught up with what we can do now, and the phrase “progressive web app” gives us a way to encapsulate that. As Frances says, the name isn’t for us; it’s for our boss or marketer.
Jason references my post about using the right language for the right audience.
Should you have a progressive web app? Well, if you have a website, then the answer is almost certainly “Yes!” If you make money from that website, the answer is definitely “Yes!”
But there’s a lot of FUD around progressive web apps. It brings up the tired native vs. web battle. Remember though that not 100% of your users or customers have your app installed. And it’s getting harder to convince people to install apps. The average number of apps installed per month is zero. But your website is often a customer’s first interaction with your company. A better web experience can only benefit you.
Often, people say “The web can’t do…” but a lot of the time that information is out of date. There are articles out there with outdated information. One article said that progressive web apps couldn’t access the camera, location, or the fingerprint sensor. Yet look at Instagram’s progressive web app: it accesses the camera. And just about every website wants access to your location these days. And Jason knows you can use your fingerprint to buy things on the web because he accidentally bought socks when he was trying to take a screenshot of the J.Crew website on his iPhone. So the author of that article was just plain wrong. The web can do much more than we think it can.
Another common objection is “iOS doesn’t support progressive web apps”. Well, as of last week that is no longer true. But even when that was still true, people who had implemented progressive web apps were seeing increased conversion even on iOS. That’s probably because, if you’ve got the mindset for building a progressive web app, you’re thinking deeply about performance. In many ways, progressive web apps are a trojan horse for performance.
These are the things that people think about when it comes to progressive web apps:
- Making it feel like a app
- Installation and discovery
- Offline mode
- Push notifications
- Beyond progressive web app
Making it feel like a app
What is an app anyway? Nobody can define it. Once again, Jason references my posts on this topic (how “app” is like “obscenity” or “brunch”).
A lot of people think that “app-like” means making it look native. But that’s a trap. Which operating system will you choose to emulate? Also, those design systems change over time. You should define your own design. Make it an exceptional experience regardless of OS.
It makes more sense to talk in terms of goals…
Goal: a more immersive experience.
Possible solution: removing the browser chrome and going fullscreen?
You can define this in the manifest file. But as you remove the browser chrome, you start to lose things that people rely on: the back button, the address bar. Now you have to provide that functionality. If you move to a fullscreen application you need to implement sharing, printing, and the back button (and managing browser history is not simple). Remember that not every customer will add your progressive web app to their home screen. Some will have browser chrome; some won’t.
Goal: a fast fluid experience.
Possible solution: use an app shell model.
You want smooth pages that don’t jump around as the content loads in. The app shell makes things seem faster because something is available instantly—it’s perceived performance. Basically you’re building a single page application. That’s a major transition. But thankfully, you don’t have to do it! Progressive web apps don’t have to be single page apps.
Goal: an app with personality.
Possible solution: Animated transitions and other bits of UI polish.
Really, it’s all about delight.
Installation and discovery
In your manifest file you can declare a background colour for the startup screen. You can also declare a theme colour—it’s like you’re skinning the browser chrome.
You can examine the manifest files for a site in Chrome’s dev tools.
Once you’ve got a progressive web app, some mobile browsers will start prompting users to add it to their home screen. Firefox on Android displays a little explainer the first time you visit a progressive web app. Chrome and Opera have add-to-homescreen banners which are a bit more intrusive. The question of when they show up keeps changing. They use a heuristic to decide this. The heuristic has been changed a few times already. One thing you should consider is suppressing the banner until it’s an optimal time. Flipkart do this: they only allow it on the order confirmation page—the act of buying something makes it really likely that someone will add the progressive web app to their home screen.
What about app stores? We don’t need them for progressive web apps—they’re on the web. But Microsoft is going to start adding progressive web apps to their app store. They’ve built a site called PWA Builder to help you with your progressive web app.
On the Android side, there’s Trusted Web Activity which is kind of like PhoneGap—it allows you to get a progressive web app into the Android app store.
But remember, your progressive web app is your website so all the normal web marketing still applies.
A lot of organisations say they have no need for offline functionality. But everyone has a need for some offline capability. At the very least, you can provide a fallback page, like Trivago’s offline maze game.
You can cache content that has been recently viewed. This is what Jason does on the Cloud Four site. They didn’t want to make any assumptions about what people might want, so they only cache pages as people browse around the site.
If you display cached information, you might want to display how stale the information is e.g. for currency exchange rates.
Another option is to let people choose what they want to keep offline. The Financial Times does this. They also pre-cache the daily edition.
If you have an interactive application, you could queue tasks and then carry them out when there’s a connection.
Or, like Slack does, don’t let people write something if they’re offline. That’s better than letting someone write something and then losing it.
Workbox is a handy library for providing offline functionality.
There are third-party push notification services that take care of a lot of this for you. Jason has used OneSignal.
Remember that people are really annoyed by push notifications. Don’t ask for permission immediately. Don’t ask someone to marry you on a first date. On Cloud Four’s blog, they only prompt after the user has read an article.
Twitter’s progressive web app does this really well. It’s so important that you do this well: if a user says “no” to your push notification permission request, you will never be able to ask them again. There used to be three options on Chrome: allow, block, or close. Now there are just two: allow or block.
Beyond progressive web apps
There are a lot of APIs that aren’t technically part of progressive web apps but get bundled in with them. Like the Credentials Management API or the Payment Request API (which is converging with ApplePay).
So how should you plan your progressive web app launch? Remember it’s progressive. You can keep adding features. Each step along the way, you’re providing value to people.
Start with some planning and definition. Get everyone in a room and get a common definition of what the ideal progressive web app would look like. Remember there’s a continuum of features for all five of the things that Jason has outlined here.
Benchmark your existing site. It will help you later on.
Assess your current website. Is the site reasonably fast? Is it responsive? Fix those usability issues first.
Next, do the baseline. Switch to HTTPS. Add a manifest file. Add a service worker. Apart from the HTTPS switch, this can all be done on the front end. Don’t wait for all three: ship each one when they’re ready.
Then do front-end additions: pre-caching pages, for example.
Finally, there are the larger initiatives (with more complex APIs). This is where your initial benchmarking really pays off. You can demonstrate the value of what you’re proposing.
Every step on the path to a progressive web app makes sense on its own. Figure out where you want to go and start that journey.
Here are Torre’s notes on my talk at An Event Apart Seattle. (She’s been liveblogging all the talks.)
Here are Luke’s notes from the talk I just gave at An Event Apart in Seattle.
Friday, March 30th, 2018
On moving from silos to your own website:
Over the last year, especially, it has seemed much more like “blog to write, tweet to fight.” Moreover, the way that our writing and personal data has been used by social media companies has become more obviously problematic—not that it wasn’t problematic to begin with.
Which is why it’s once again a good time to blog, especially on one’s own domain.
But on the other hand…
It is psychological gravity, not technical inertia, however, that is the greater force against the open web. Human beings are social animals and centralized social media like Twitter and Facebook provide a powerful sense of ambient humanity—the feeling that “others are here”—that is often missing when one writes on one’s own site.
That’s true …which is why brid.gy is such an incredibly powerful service for, well, bridging the gap between your own personal site and the silos, allowing for that feeling of ambient humanity.
Tuesday, March 27th, 2018
Anil documents the steady decline of empowering features from web browsers: view source; in-situ authoring; transclusion, but finishes with the greatest loss of all: your own website at your own address.
There are no technical barriers for why we couldn’t share our photos to our own sites instead of to Instagram, or why we couldn’t post stupid memes to our own web address instead of on Facebook or Reddit. There are social barriers, of course — if we stubbornly used our own websites right now, none of our family or friends would see our stuff. Yet there’s been a dogged community of web nerds working on that problem for a decade or two, trying to see if they can get the ease or convenience of sharing on Facebook or Twitter or Instagram to work across a distributed network where everyone has their own websites.
(Although it’s a bit of shame that Anil posted this on Ev’s blog instead of his own.)
Tuesday, March 20th, 2018
Brendan shows how he uses IFTTT and a webhook to post to his own site from Instagram. I think I might set up something similar to post from Untappd to my own site.
Sunday, March 18th, 2018
Congratulations, Jason—twenty years of kottke.org is a hell of an achievement!
I’ve been reading back through the early archives (which I wouldn’t recommend), and it feels like excavating down through layers of sediment, tracing the growth & evolution of the web, a media format, and most of all, a person.
Monday, March 12th, 2018
What was once a rich selection of blogs and websites has been compressed under the powerful weight of a few dominant platforms. This concentration of power creates a new set of gatekeepers, allowing a handful of platforms to control which ideas and opinions are seen and shared.
Tim Berners-Lee on the 29th anniversary of Information Management: A Proposal.
Two myths currently limit our collective imagination: the myth that advertising is the only possible business model for online companies, and the myth that it’s too late to change the way platforms operate. On both points, we need to be a little more creative.
While the problems facing the web are complex and large, I think we should see them as bugs: problems with existing code and software systems that have been created by people — and can be fixed by people.
Saturday, March 10th, 2018
You’ll need to be comfortable with using the command line, but this is a very useful font subsetting tool from those clever folks at Filament Group.
An astoundingly great piece of writing from Paul Ford, comparing the dot-com bubble and the current blockchain bubble. This resonates so hard:
I knew I was supposed to have an opinion on how the web and the capital markets interacted, but I just wanted to write stuff and put it online. Or to talk about web standards—those documents, crafted by committees at the World Wide Web consortium, that defined the contract between a web browser and a web server, outlining how HTML would work. These standards didn’t define just software, but also culture; this was the raw material of human interaction.
And, damn, if this isn’t the best description the post-bubble web:
Heat and light returned. And bit by bit, the software industry insinuated itself into every aspect of global enterprise. Mobile happened, social networks exploded, jobs returned, and coding schools popped up to convert humans into programmers and feed them to the champing maw of commerce. The abstractions I loved became industries.
Oof! That isn’t even the final gut punch. This is:
Here’s what I finally figured out, 25 years in: What Silicon Valley loves most isn’t the products, or the platforms underneath them, but markets.