18

I got an intriguing email recently from someone who’s a member of The Session, the community website about Irish traditional music that I run. They said:

When I recently joined, I used my tablet to join. Somewhere I was able to download The Session app onto my tablet.

But there is no native app for The Session. Although, as it’s a site that I built, it is, a of course, progressive web app.

They went on to say:

I wanted to put the app on my phone but I can’t find the app to download it. Can I have the app on more than one device? If so, where is it available?

I replied saying that yes, you can absolutely have it on more than one device:

But you don’t find The Session app in the app store. Instead you go to the website https://thesession.org and then add it to your home screen from your browser.

My guess is that this person had added The Session to the home screen of their Android tablet, probably following the “add to home screen” prompt. I recently added some code to use the window.beforeinstallprompt event so that the “add to home screen” prompt would only be shown to visitors who sign up or log in to The Session—a good indicator of engagement, I reckon, and it should reduce the chance of the prompt being dismissed out of hand.

So this person added The Session to their home screen—probably as a result of being prompted—and then used it just like any other app. At some point, they didn’t even remember how the app got installed:

Success! I did it. Thanks. My problem was I was looking for an app to download.

On the one hand, this is kind of great: here’s an example where, in the user’s mind, there’s literally no difference between the experience of using a progressive web app and using a native app. Win!

But on the other hand, the expectation is still that apps are to be found in an app store, not on the web. This expectation is something I wrote about recently (and Justin wrote a response to that post). I finished by saying:

Perhaps the inertia we think we’re battling against isn’t such a problem as long as we give people a fast, reliable, engaging experience.

When this member of The Session said “My problem was I was looking for an app to download”, I responded by saying:

Well, I take that as a compliment—the fact that once the site is added to your home screen, it feels just like a native app. :-)

Easy access to resort staff and holiday details that could be viewed offline to help as many customers as possible travel without stress and enjoy a fantastic holiday

Luke explains why they choice not to go with a progressive web app.

The current level of support and leap in understanding meant we’d risk alienating many of our customers.

The issue of support is one that is largely fixed at this point. When Clearleft was working on the Virgin Holidays app, service workers hadn’t landed in iOS. Hence, the risk of alienating a lot of customers. But now that Mobile Safari has offline capabilities, that’s no longer a problem.

But it’s the second reason that’s trickier:

Simply put, customers already expected to find us in the App Store and are familiar with what apps can historically offer over websites.

I think this is the biggest challenge facing progressive web apps: battling expectations.

For over a decade, people have formed ideas about what to expect from the web and what to expect from native. From a technical perspective, native and web have become closer and closer in capabilities. But people’s expectations move slower than technological changes.

First of all, there’s the whole issue of discovery: will people understand that they can “install” a website and expect it to behave exactly like a native app? This is where install prompts and ambient badging come in. I think ambient badging is the way to go, but it’s still a tricky concept to explain to people.

But there’s another way of looking at the current situation. Instead of seeing people’s expectations as a negative factor, maybe it’s an opportunity. There’s an opportunity right now for companies to be as groundbreaking and trendsetting as Wired.com when it switched to CSS for layout, or The Boston Globe when it launched its responsive site.

Weekly active users on mobile web have increased 103 percent year-over-year overall, with a 156 percent increase in Brazil and 312 percent increase in India. On the engagement side, session length increased by 296 percent, the number of Pins seen increased by 401 percent and people were 295 percent more likely to save a Pin to a board. Those are amazing in and of themselves, but the growth front is where things really shined. Logins increased by 370 percent and new signups increased by 843 percent year-over-year. Since we shipped the new experience, mobile web has become the top platform for new signups. And for fun, in less than 6 months since fully shipping, we already have 800 thousand weekly users using our PWA like a native app (from their homescreen).

Now admittedly their previous mobile web experience was a dreadful doorslam, but still, those are some amazing statistics!

Maybe we’re underestimating the malleability of people’s expectations when it comes to the web on mobile. Perhaps the inertia we think we’re battling against isn’t such a problem as long as we give people a fast, reliable, engaging experience.

The two major candidates are Twitter and Instagram. I added them to my home screen, and banished the native apps off to a separate screen. I’ve been using both progressive web apps for a few months now, and I have to say, they’re pretty darn great.

There are a few limitations compared to the native apps. On Twitter, if you follow a link from a tweet, it pops open in Safari, which is fine, but when you return to Twitter, it loads anew. This isn’t any fault of Twitter—this is the way that web apps have worked on iOS ever since they introduced their weird web-app-capable meta element. I hope this behaviour will be fixed in a future update.

Also, until we get web notifications on iOS, I need to keep the Twitter native app around if I want to be notified of a direct message (the only notification I allow).

Apart from those two little issues though, Twitter Lite is on par with the native app.

Instagram is also pretty great. It too suffers from some navigation issues. If I click through to someone’s profile, and then return to the main feed, it also loads it anew, losing my place. It would be great if this could be fixed.

For some reason, the Instagram web app doesn’t allow uploading multiple photos …which is weird, because I can upload multiple photos on my own site by adding the multiple attribute to the input type="file" in my posting interface.

Apart from that, though, it works great. And as I never wanted notifications from Instagram anyway, the lack of web notifications doesn’t bother me at all. In fact, because the progressive web app doesn’t keep nagging me about enabling notifications, it’s a more pleasant experience overall.

Something else that was really annoying with the native app was the preponderance of advertisements. It was really getting out of hand.

Well …(looks around to make sure no one is listening)… don’t tell anyone, but the Instagram progressive web app—i.e. the website—doesn’t have any ads at all!

Service worker. It’s a no-brainer. Now that the Clearleft site is (finally!) running on HTTPS, having a simple service worker to cache static assets like CSS, JavaScript and some images seems like the obvious next step.

You know how it is. Those no-brainer tasks are exactly the kind of thing that end up on a to-do list without ever quite getting to-done. Meanwhile I’ve been writing and speaking about how any website can be a progressive web app. I think Alanis Morissette used to sing about this sort of situation.

The service worker logic is fairly straightforward, and taken almost verbatim from Going Offline. As you navigate around the site, the service worker applies different logic depending on the kind of file you’re requesting:

Pages are served fresh from the network, falling back to the cache when there’s a problem.

Everything else is served from the cache where possible, resorting to the network only if there’s no match in the cache—quite the performance boost!

In both cases, if a page or a file is retrieved from the network, it’s gets put into a cache. I’ve got one cache for pages, and another for everything else. And even if a file is retrieved from that cache, I still fire off a fetch request to grab a fresh copy for the cache. So while there’s a chance that a stale file might be served up, it will only ever be slightly stale, and the next time it’s requested, it’ll be fresh.

In the worst-case scenario, when a page can’t be retrieved from the network or the cache, you end up seeing a custom offline page. There you can see a list of any pages that are cached (meaning you can revisit them even without an internet connection).

It’s not ideal—page titles would be friendlier than URLs—but it’s a start. I’m sure I’ll revisit it soon. Honest.

Oh, and after a year of procrastinating about doing this, guess how long it took? About half a day. Admittedly, this isn’t my first progressive web app, and the more you build ‘em, the easier it gets. Still, it’s a classic example of a small investment of time leading to a big improvement in performance and user experience.

If you think your company’s website could benefit from being a progressive web app (and believe me, it definitely could), you have a couple of options:

Arm yourself with a copy of Going Offline and give it a go yourself. Or

I gave a quick talk at the Delta V conference in London last week called Any Site can be a Progressive Web App. I had ten minutes, but frankly I only needed enough time to say the title of the talk because, well, that was also the message.

There’s a common misconception that making a Progressive Web App means creating a Single Page App with an app-shell architecture. But the truth is that literally any website can benefit from the performance boost that results from the combination of HTTPS + Service Worker + Web App Manifest.

See how I define a progressive web app as being HTTPS + service worker + web app manifest? I’ve been doing that for a while. Here’s a post from last year called Progressing the web:

That last step can be tricky if you’re new to service workers, but it’s not unsurmountable. It’s certainly a lot easier than completely rearchitecting your existing website to be a JavaScript-driven single page app.

Regardless of the specifics of the name, what I like about Progressive Web Apps is that they have a clear definition. It reminds me of Responsive Web Design. Whatever you think of that name, it comes with a clear list of requirements:

A fluid layout,

Fluid images, and

Media queries.

Likewise, Progressive Web Apps consist of:

HTTPS,

A service worker, and

A Web App Manifest.

There’s more you can do in addition to that (just as there’s plenty more you can do on a responsive site), but the core definition is nice and clear.

But here’s the thing. Outside of the confines of my own website, it’s hard to find that definition anywhere.

On Google’s developer site, their definition uses adjectives like “reliable”, “fast”, and “engaging”. Those are all great adjectives, but more useful to a salesperson than a developer.

Progressive web apps use modern web APIs along with traditional progressive enhancement strategy to create cross-platform web applications. These apps work everywhere and provide several features that give them the same user experience advantages as native apps.

Hmm …I’m not so sure about that comparison to native apps (and I’m a little disturbed that the URL structure is /Apps/Progressive). So let’s click through to the introduction:

PWAs are web apps developed using a number of specific technologies and standard patterns to allow them to take advantage of both web and native app features.

Okay. Specific technologies. That’s good to hear. But instead of then listing those specific technologies, we’re given another list of adjectives (discoverable, installable, linkable, etc.). Again, like Google’s chosen adjectives, they’re very nice and desirable, but not exactly useful to someone who wants to get started making a progressive web app. That’s why I like to cut to the chase and say:

You need to be running on HTTPS,

Then you can add a service worker,

And don’t forget to add a web app manifest file.

If you do that, you’ve got a progressive web app. Now, to be fair, there’a lot that I’m leaving out. Your site should be fast. Your site should be responsive (it is, after all, on the web). There’s not much point mucking about with service workers if you haven’t sorted out the basics first. But those three things—HTTPS + service worker + web app manifest—are specifically what distinguishes a progressive web app. You can—and should—have a reliable, fast, engaging website before turning it into a progressive web app.

Jason has been thinking about progressive web apps a lot lately (he should write a book or something), and he said to me:

I agree with you on the three things that comprise a PWA, but as far as I can tell, you’re the first to declare it as such.

I was quite surprised by that. I always assumed that I was repeating the three ingredients of a progressive web app, not defining them. But looking through all the docs out there, Jason might be right. It’s surprising because I assumed it was obvious why those three things comprise a progressive web app—it’s because they’re testable.

Lighthouse, PWA Builder, Sonarwhal and other tools that evaluate your site will measure its progressive web app score based on the three defining factors (HTTPS, service worker, web app manifest). Then there’s Android’s Add to Home Screen prompt. Here finally we get a concrete description of what your site needs to do to pass muster:

Includes a web app manifest…

Served over HTTPS (required for service workers)

Has registered a service worker with a fetch event handler

(Although, as of this month, Chrome will no longer show the prompt automatically—you also have to write some JavaScript to handle the beforeinstallprompt event).

Anyway, if you’re looking to turn your website into a progressive web app, here’s what you need to do (assuming it’s already performant and responsive):

It’s the afternoon of the second day of An Event Apart Seattle and Jason is talking about Designing Progressive Web Apps. These are my notes…

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):

HTTPS

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.

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.

Offline mode

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.

Push notifications

The JavaScript for push notifications is relatively easy, says Jason. It’s the back-end stuff that’s hard. That’s because successful push notifications are personalised. But to do that means doing a lot more work on the back end. How do you integrate with preferences? Which events trigger notifications?

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.

It seems like any new field goes through an inevitable growth spurt that involves “defining the damn thing.” For the first few years of the IA Summit, every second presentation seemed to be about defining what Information Architecture actually is. See also: UX. See also: Content Strategy.

Now it seems to be happening with Progressive Web Apps …which is odd, considering the damn thing is defined damn well.

Regardless of the specifics of the name, what I like about Progressive Web Apps is that they have a clear definition. It reminds me of Responsive Web Design. Whatever you think of that name, it comes with a clear list of requirements:

A fluid layout,

Fluid images, and

Media queries.

Likewise, Progressive Web Apps consist of:

HTTPS,

A service worker, and

A Web App Manifest.

There’s more you can do in addition to that (just as there’s plenty more you can do on a responsive site), but the core definition is nice and clear.

Engaging - Feel like a natural app on the device, with an immersive user experience.

Those are great descriptions of the benefits of Progressive Web Apps. Perfect material for convincing your clients or your boss. But that appears on developers.google.com …surely it would be more beneficial for that audience to know the technologies that comprise Progressive Web Apps?

Ben Halpern again:

Google’s continued use of the term “quality” in describing things leaves me with a ton of confusion. It really seems like they want PWA to be a general term that doesn’t imply any particular implementation, and have it be focused around the user experience, but all I see over the web is confusion as to what they mean by these things. My website is already “engaging” and “immersive”, does that mean it’s a PWA?

I think it’s important to use the right language for the right audience.

If you’re talking to the business people, tell them about the return on investment you get from Progressive Web Apps.

If you’re talking to the marketing people, tell them about the experiential benefits of Progressive Web Apps.

But if you’re talking to developers, tell them that a Progressive Web App is a website served over HTTPS with a service worker and manifest file.

I vaguely remember there being some talk of changing the labelling, but I could’ve sworn it was going to change to “install”. I’ve got to be honest, just having the word “add” doesn’t seem to provide much context. Based on the quick’n’dirty usability testing I did with some co-workers, it just made things confusing. “Add what?” “What am I adding?”

Additionally, the prompt appeared immediately on the first visit to the site. I thought there was supposed to be an added “engagement” metric in order for the prompt to appear; that the user needs to visit the site more than once.

You’d think I’d be happy that users will be presented with the home-screen prompt immediately, but based on the behaviour I saw, I’m not sure it’s a good thing. Here’s what I observed:

We web designers and web developers have trained users to dismiss overlays and pop-ups if they actually want to get to the content. Nobody’s going to bother to actually read the prompt if there’s a 99% chance it’s going to say “Sign up to our newsletter!” or “Take our survey!”.

The prompt appears below the “line of death” so there’s no way to tell it’s a browser or OS-level dialogue rather than a JavaScript-driven pop-up from the site.

Because the prompt now appears on the first visit, no trust has been established between the user and the site. If the prompt only appeared on later visits (or later navigations during the first visit) perhaps it would stand a greater chance of survival.

It’s still possible to add a Progressive Web App to the home screen, but the option to do that is hidden behind the mysterious three-dots-vertically-stacked icon (I propose we call this the shish kebab icon to distinguish it from the equally impenetrable hamburger icon).

When a Firefox 58 user arrives on a website that is served over HTTPS and has a valid manifest, a subtle badge will appear in the address bar: when tapped, an “Add to Home screen” confirmation dialog will slide in, through which the web app can be added to the Android home screen.

This kind of badging also has issues (without the explicit text “add to home screen”, the user doesn’t know what the icon does), but I think a more persistently visible option like this works better than the a one-time prompt.

Sadly, I feel that any solution that relies on an unrequested overlay is doomed. That’s on us. The way we’ve turned browsing the web—especially on mobile—into a frustrating chore of dismissing unwanted overlays is a classic tragedy of the commons. We blew it. Users don’t trust unrequested overlays, and I can’t blame them.

For what it’s worth, my opinion is that ambient badging is a better user experience than one-time prompts. That opinion is informed by a meagre amount of testing though. I’d love to hear from anyone who’s been doing more detailed usability testing of both approaches. I assume that Google, Mozilla, and Samsung are doing this kind of testing, and it would be really great to see the data from that (hint, hint).

But it might well be that ambient badging is just too subtle to even be noticed by the user.

On one end of the scale you’ve got the intrusiveness of an add-to-home-screen prompt, but on the other end of the scale you’ve got the discoverability problem of a subtle badge icon. I wonder if there might be a compromise solution—maybe a badge icon that pulses or glows on the first or second visit?

Ever since its founding in 2005, Clearleft has been laser-focused on user experience design.

But we’ve always maintained a strong front-end development arm. The front-end development work at Clearleft is always in service of design. Over the years we’ve built up a wealth of expertise on using HTML, CSS, and JavaScript to make better user experiences.

Recently we’ve been doing a lot of strategic design work—the really in-depth long-term engagements that begin with research and continue through to design consultancy and collaboration. That means we’ve got availability for front-end development work. Whether it’s consultancy or production work you’re looking for, this could be a good opportunity for us to work together.

There are three particular areas of front-end expertise we’re obsessed with…

Pattern Libraries

We caught the design systems bug years ago, way back when Natalie started pioneering pattern libraries as our primary deliverable (or pattern portfolios, as we called them then). This approach has proven effective time and time again. We’ve spent years now refining our workflow and thinking around modular design. Fractal is the natural expression of this obsession. Danielle and Mark have been working flat-out on version 2. They’re very eager to share everything they’ve learned along the way …and help others put together solid pattern libraries.

Performance

Thinking about it, it’s no surprise that we’re crazy about performance at Clearleft. Like I said, our focus on user experience, and when it comes to user experience on the web, nothing but nothing is more important than performance. The good news is that the majority of performance fixes can be done on the front end—images, scripts, fonts …it’s remarkable how much a good front-end overhaul can make to the bottom line. That’s what Graham has been obsessing over.

Progressive Web Apps

Over the years I’ve found myself getting swept up in exciting new technologies on the web. When Clearleft first formed, my head was deep into DOM Scripting and Ajax. Half a decade later it was HTML5. Now it’s service workers. I honestly think it’s a technology that could be as revolutionary as Ajax or HTML5 (maybe I should write a book to that effect).

There’s endless possibilities of what you can do with this technology. It’s very powerful.

Combine a service worker with a web app manifest and you’ve got yourself a Progressive Web App. It’s not just a great marketing term—it’s an opportunity for the web to truly excel at delivering the kind of user experiences previously only associated with native apps.

I’m very very keen to work with companies and organisations that want to harness the power of service workers and Progressive Web Apps. If that’s you, get in touch.

Frances has written up some of the history behind her minting of the term “progressive web app”. She points out that accuracy is secondary to marketing:

I keep seeing folks (developers) getting all smart-ass saying they should have been PW “Sites” not “Apps” but I just want to put on the record that it doesn’t matter. The name isn’t for you and worrying about it is distraction from just building things that work better for everyone. The name is for your boss, for your investor, for your marketeer.

Personally, I think “progressive web app” is a pretty good phrase—two out of three words in it are spot on. I really like the word “progressive”, with its echoes of progressive enhancement. I really, really like the word “web”. But, yeah, I’m one of those smart-asses who points out that the “app” part isn’t great.

That’s not just me being a pedant (or, it’s not only me being a pedant). I’ve seen people who were genuinely put off investigating the technologies behind progressive web apps because of the naming.

The name is one of the reasons I didn’t look into PWAs 6 months ago. Can we change the name itself? 😎

Late last week, Smashing Magazine, one of the largest and most influential online publications for web design, posted on Facebook that their website was “now running as a Progressive Web App.”

Honestly, I didn’t think much of it. Progressive Web Apps are for the hardcore web application developers creating the next online cloud-based Photoshop (complicated stuff), right? I scrolled on and went about my day.

My personal website is a collection of static HTML files and is also a progressive web app. Transforming it into a progressive web app felt a bit weird in the beginning because it’s not an actual application but I wanted to be one of the cool kids, and PWAs still offer a lot of additional improvements.

Still, it could well be that these are the exceptions and that most people are not being discouraged by the “app” phrasing. I certainly hope that there aren’t more people out there thinking “well, progressive web apps aren’t for me because I’m building a content site.”

In short, the name might not be perfect but it’s pretty damn good.

What I find more troubling is the grouping of unrelated technologies under the “progressive web app” banner. If Google devrel events were anything to go by, you’d be forgiven for thinking that progressive web apps have something to do with AMP or Polymer (they don’t). One of the great things about progressive web apps is that they are agnostic to tech stacks. Still, I totally get why Googlers would want to use the opportunity to point to their other projects.

That last step can be tricky if you’re new to service workers, but it’s not unsurmountable. It’s certainly a lot easier than completely rearchitecting your existing website to be a JavaScript-driven single page app.

Alas, I think that many of the initial poster-children for progressive web apps gave the impression that you had to make a completely separate app/site at a different URL. It was like a return to the bad old days of m. sites for mobile. The Washington Post’s progressive web app (currently offline) went so far as to turn away traffic from the “wrong” browsers. This is despite the fact that the very first item in the list of criteria for a progressive web app is:

Responsive: to fit any form factor

Now, I absolutely understand that the immediate priority is to demonstrate that a progressive web app can compete with a native mobile app in terms of features (and trounce it in terms of installation friction). But I’m worried that in our rush to match what native apps can do, we may end up ditching the very features that make the web a universally-accessible medium. Killing URLs simply because native apps don’t have URLs is a classic example of throwing the baby out with the bath water:

Up until now I’ve been a big fan of Progressive Web Apps. I understood them to be combining the best of the web (responsiveness, linkability) with the best of native (installable, connectivity independent). Now I see that balance shifting towards the native end of the scale at the expense of the web’s best features. I’d love to see that balance restored with a little less emphasis on the “Apps” and a little more emphasis on the “Web.” Now that would be progressive.

If the goal of the web is just to compete with native, then we’ve set the bar way too low.

So if you’ve been wary of investing the technologies behind progressive web apps because you’re “just” building a website, please try to see past the name. As Frances says:

It’s marketing, just like HTML5 had very little to do with actual HTML. PWAs are just a bunch of technologies with a zingy-new brandname.

I was at an event last year where I heard Chris Heilmann say that you shouldn’t make your blog into a progressive web app. I couldn’t believe what I was hearing. He repeats that message in this video chat:

When somebody, for example, turns their blog into a PWA, I don’t see the point. I don’t want to have that icon on my homepage. This doesn’t make any sense to me.

Excuse me!? Just because you don’t want to have someone’s icon on your home screen, that person shouldn’t be using state-of-the-art technologies!? Excuse my French, but Fuck. That. Shit!

Our imaginations have become so limited by what native mobile apps currently do that we can’t see past merely imitating the status quo like a sad cargo cult.

I don’t want the web to equal native; I want the web to surpass it. I, for one, would prefer a reality where my home screen isn’t filled with the icons of startups and companies that have fulfilled the criteria of the gatekeepers. But a home screen filled with the faces of people who didn’t have to ask anyone’s permission to publish? That’s what I want!

For my graduation project I’m researching the development of Progressive Web Apps and found your offline book called resilient web design. I was very impressed by the implementation of the website and it really was a nice experience.

I’m very interested in your vision on progressive web apps and what capabilities are waiting for us regarding offline content. Would it be fine if I’d send you some questions?

I said that would be fine, although I couldn’t promise a swift response. He sent me four questions. I finally got ‘round to sending my answers…

1. https://resilientwebdesign.com/ is an offline web book (progressive web app). What was the primary reason make it available like this (besides the other formats)?

Well, given the subject matter, it felt right that the canonical version of the book should be not just online, but made with the building blocks of the web. The other formats are all nice to have, but the HTML version feels (to me) like the “real” book.

Interestingly, it wasn’t too much trouble for people to generate other formats from the HTML (ePub, MOBI, PDF), whereas I think trying to go in the other direction would be trickier.

As for the offline part, that felt like a natural fit. I had already done that with a previous book of mine, HTML5 For Web Designers, which I put online a year or two after its print publication. In that case, I used AppCache for the offline functionality. AppCache is horrible, but this use case might be one of the few where it works well: a static book that’s never going to change. Cache invalidation is one of the worst parts of using AppCache so by not having any kinds of updates at all, I dodged that bullet.

But when it came time for Resilient Web Design, a service worker was definitely the right technology. Still, I’ve got AppCache in there as well for the browsers that don’t yet support service workers.

2. What effect you you think Progressive Web Apps will have on content consuming and do you think these will take over the purpose of some Native Apps?

The biggest effect that service workers could have is to change the expectations that people have about using the web, especially on mobile devices. Right now, people associate the web on mobile with long waits and horrible spammy overlays. Service workers can help solve that first part.

If people then start adding sites to their home screen, that will be a great sign that the web is really holding its own. But I don’t think we should get too optimistic about that: for a user, there’s no difference between a prompt on their screen saying “add to home screen” and a prompt on their screen saying “download our app”—they’re equally likely to be dismissed because we’ve trained people to dismiss anything that covers up the content they actually came for.

It’s entirely possible that websites could start taking over much of the functionality that previously was only possible in a native app. But I think that inertia and habit will keep people using native apps for quite some time.

The big exception is in markets where storage space on devices is in short supply. That’s where the decision to install a native app isn’t taken likely (given the choice between your family photos and an app, most people will reject the app). The web can truly shine here if we build lightweight, performant services.

Even in that situation, I’m still not sure how many people will end up adding those sites to their home screen (it might feel so similar to installing a native app that there may be some residual worry about storage space) but I don’t think that’s too much of a problem: if people get to a site via search or typing, that’s fine.

I worry that the messaging around “progressive web apps” is perhaps over-fetishising the home screen. I don’t think that’s the real battleground. The real battleground is in people’s heads; how they perceive the web and how they perceive native.

After all, if the average number of native apps installed in a month is zero, then that’s not exactly a hard target to match. :-)

3. What is your vision regarding Progressive Web Apps?

For me, progressive web apps don’t feel like a separate thing from making websites. I worry that the marketing of them might inflate expectations or confuse people. I like the idea that they’re simply websites that have taken their vitamins.

So my vision for progressive web apps is the same as my vision for the web: something that people use every day for all sorts of tasks.

I find it really discouraging that progressive web apps are becoming conflated with single page apps and the app shell model. Those architectural decisions have nothing to do with service workers, HTTPS, and manifest files. Yet I keep seeing the concepts used interchangeably. It would be a real shame if people chose not to use these great technologies just because they don’t classify what they’re building as an “app.”

If anything, it’s good ol’ fashioned content sites (newspapers, wikipedia, blogs, and yes, books) that can really benefit from the turbo boost of service worker+HTTPS+manifest.

I was at a conference recently where someone was given a talk encouraging people to build progressive web apps but discouraging people from doing it for their own personal sites. That’s a horrible, elitist attitude. I worry that this attitude is being codified in the term “progressive web app”.

4. What is the biggest learning you’ve had since working on Progressive Web Apps?

Well, like I said, I think that some people are focusing a bit too much on the home screen and not enough on the benefits that service workers can provide to just about any website.

My biggest learning is that these technologies aren’t for a specific subset of services, but can benefit just about anything that’s on the web. I mean, just using a service worker to explicitly cache static assets like CSS, JS, and some images is a no-brainer for almost any project.

So there you go—I’m very excited about the capabilities of these technologies, but very worried about how they’re being “sold”. I’m particularly nervous that in the rush to emulate native apps, we end up losing the very thing that makes the web so powerful: URLs.

Every front-end developer at Clearleft went to FFConf last Friday: me, Mark, Graham, Charlotte, and Danielle. We weren’t about to pass up the opportunity to attend a world-class dev conference right here in our home base of Brighton.

The day was unsurprisingly excellent. All the speakers brought their A-game on a wide range of topics. Of course JavaScript was covered, but there was also plenty of mindfood on CSS, accessibility, progressive enhancement, dev tools, creative coding, and even emoji.

Normally FFConf would be a good opportunity to catch up with some Pauls from the Google devrel team, but because of an unfortunate scheduling clash this year, all the Pauls were at Chrome Dev Summit 2016 on the other side of the Atlantic.

I’ve been catching up on the videos from the event. There’s plenty of tech-related stuff: dev tools, web components, and plenty of talk about progressive web apps. But there was also a very, very heavy focus on performance. I don’t just mean performance at the shallow scale of file size and optimisation, but a genuine questioning of the impact of our developer workflows and tools.

He makes the point that if you really want fast rendering, nothing on the client side quite beats a server render.

They’ve written a lot of JavaScript to make this quite slow.

Unfortunately, all too often, I hear people say that a progressive web app must be a single page app. And I am not so sure. You might not need a single page app. A single page app can end up being a lot of work and slower. There’s a lot of cargo-culting around single page apps.

…web app development and web site development are so different now that they probably shouldn’t be called the same thing anymore.

This is an idea I keep returning to, and each time I do, I find that it just isn’t that simple. There are very few web thangs that are purely interactive without any content, and there are also very few web thangs that are purely passive without any interaction. Instead, it’s a spectrum. Quite often, the position on that spectrum changes according to the needs of the user at any particular time—are Twitter and Flicker web sites while I’m viewing text and images, but then transmogrify into web apps the moment I want add, update, or delete a piece of text or an image?

In any case, the more interesting question than “is something a web site or a web app?” is the question “why?” Why does it matter? In my experience, the answer to that question generally comes down to the kind of architectural approach that a developer will take.

That’s exactly what Laurie dives into in his post. For web apps, use one architectural approach—for web sites, use a different architectural approach. To summarise:

in a web app, front-load everything and rely on client-side JavaScript for all subsequent interaction,

in a web site, optimise for many page loads, and make sure you don’t rely on client-side JavaScript.

I’m oversimplifying here, but the general idea is:

build web apps with the single page app architecture,

build web sites with progressive enhancement.

That’s sensible advice, but I’m worried that it could lead to a tautological definition of what constitutes a web app:

This is a web app so it’s built as a single page app.

Why do you define it as a web app?

Because it’s built as a single page app.

The underlying question of what makes something a web app is bypassed by the architectural considerations …but the architectural considerations should be based on that underlying question. Laurie says:

If you are developing an app, the user ideally loads the app exactly once — whether it’s over a slow connection or not.

And similarly:

But if you are developing a web site consisting of many discrete pages, the act of loading goes from a single event to the most common event.

I completely agree that the architectural approach of single page apps is better suited to some kinds of web thangs more than others. It’s a poor architectural choice for a content-based site like nasa.gov, for example. Progressive enhancement would make more sense there.

But I don’t think that the architectural choices need to be in opposition. It’s entirely possible to reconcile the two. It’s not always easy—and the further along that spectrum you are, the tougher it gets—but it’s doable. You can begin with progressive enhancement, and then build up to a single page app architecture for more capable browsers.

I think that’s going to get easier as frameworks adopt a more mixed approach. Almost all the major libraries are working on server-side rendering as a default. Ember is leading the way with FastBoot, and Angular Universal is following. Neither of them are doing it for reasons of progressive enhancement—they’re doing it for performance and SEO—but the upshot is that you can more easily build a web app that simultaneously uses progressive enhancement and a single-page app model.

I guess my point is that I don’t think we should get too locked into the idea of web apps and web sites requiring fundamentally different approaches, especially with the changes in the technologies we used to build them.

We’ve made the mistake in the past of framing problems as “either/or”, when in fact, the correct solution was “both!”:

you can either have a desktop site or a mobile site,

you can either have rich interactivity or accessibility,

you can either have a single page app or progressive enhancement.

We don’t have to choose. It might take more work, but we can have our web cake and eat it.

The false dichotomy that I’m most concerned about is the pernicious idea that offline functionality is somehow in opposition to progressive enhancement. Given the design of service workers, I find this proposition baffling.

People who say your site should work without JavaScript are actually hurting the people they think they’re helping.

He was also linking to Nolan’s article, which could indeed be read as saying that you should for offline instead of building with progressive enhancement. But I don’t think that’s what Nolan is saying (at least, I sincerely hope not). I think that Nolan is saying that we should prioritise the offline scenario over scenarios where JavaScript fails or isn’t available. That’s a completely reasonable thing to say. But the idea that we should build for the offline scenario instead of scenarios where JavaScript fails is absurdly reductionist. We don’t have to choose!

But I can certainly understand how developers might come to be believe that building a progressive web app is at odds with progressive enhancement. Having made a bunch of progressive web apps—Huffduffer, The Session, this site, I can testify that service workers work superbly as a layer on top of an existing site, but all the messaging around progressive web apps seems to fixated on the idea of the app-shell model (a small tweak to the single page app model, where a little bit of interface is available on the initial page load instead of requiring JavaScript for absolutely everything). Again, it’s entirely possible to reconcile the app-shell approach with server rendering and progressive enhancement, but nobody seems to be talking about that. Instead, all of the examples and demos are built with an assumption about JavaScript availability.

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.

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:

Those seem like a reasonable set of assumptions. But even there, things aren’t so simple. Will people really be using “an evergreen browser and WebView”? Millions of people use proxy browsers like Opera Mini, which means you can’t guarantee JavaScript availability beyond the initial page load. UC Browser—which can also run in proxy mode—is now the second most popular mobile browser in the world.

That’s just one nit-picky example, but what I’m getting at here is that it really isn’t safe to make any assumptions. When we must make assumptions, let’s try to make them a last resort.

And just to be clear here, I’m not saying that just because we can’t make assumptions about devices or browsers doesn’t mean that we can’t build rich interactive web apps that work offline. I’m saying that we can build rich interactive web apps that work offline and also work when JavaScript fails or isn’t supported.

You don’t have to choose between progressive enhancement and a single page app/progressive web app/app shell/other things with the word “app”.

Progressive enhancement is an architectural approach to building on the web. You don’t have to use it, but please try to remember that it is your choice to make. You can choose to build a web app using progressive enhancement or not—there is nothing inherent in the nature of the thing you’re building that precludes progressive enhancement.

Personally, I find progressive enhancement a sensible way to counteract any assumptions I might inadvertently make. Progressive enhancement increases the chances that the web site (or web app) I’m building is resilient to the kind of scenarios that I never would’ve predicted or anticipated.

This makes me squirm. I mean, I’m all for borrowing good ideas from other media—native apps, TV, print—but I don’t think that inspiration should mean imitation. For me, that always results in an interface that sits in a kind of uncanny valley of being almost—but not quite—like the thing it’s imitating.

With that out of the way, most of the recommendations in Owen’s article are sensible ideas about animation, input, and feedback. But then there’s recommendation number eight: Provide an easy way to share content:

PWAs are often shown in a context where the current URL isn’t easily accessible, so it is important to ensure the user can easily share what they’re currently looking at. Implement a share button that allows users to copy the URL to the clipboard, or share it with popular social networks.

Anyway, I think my squeamishness about all the advice to imitate native apps is because it feels like a cargo cult. There seems to be an inherent assumption that native is intrinsically “better” than the web, and that the only way that the web can “win” is to match native apps note for note. But that misses out on all the things that only the web can do—instant distribution, low-friction sharing, and the ability to link to any other resource on the web (and be linked to in turn). Turning our beautifully-networked nodes into standalone silos just because that’s the way that native apps have to work feels like the cure that kills the patient.

If anything, my advice for building a progressive web app would be the exact opposite of Owen’s: don’t forget everything you’ve learned about web design. In my opinion, the term “progressive web app” can be read in order of priority:

Progressive—build in a layered way so that anyone can access your content, regardless of what device or browser they’re using, rewarding the more capable browsers with more features.

Will people expect an experience that maps to native conventions? Or will they be more accepting of deviation because they came to the app via the web and have already seen it before installing it?

These are good questions and I share Jason’s hunch:

My gut says that we can build great experiences without having to make it feel exactly like an iOS or Android app because people will have already experienced the Progressive Web App multiple times in the browser before they are asked to install it.

In all the messaging from Google about progressive web apps, there’s a real feeling that the ability to install to—and launch from—the home screen is a real game changer. I’m not so sure that we should be betting the farm on that feature (the offline possibilities opened up by service workers feel like more of a game-changer to me).

People have been gleefully passing around the statistic that the average number of native apps installed per month is zero. So how exactly will we measure the success of progressive web apps against native apps …when the average number of progressive web apps installed per month is zero?

I like Android’s add-to-home-screen algorithm (although it needs tweaking). It’s a really nice carrot to reward the best websites with. But let’s not carried away. I think that most people are not going to click that “add to home screen” prompt. Let’s face it, we’ve trained people to ignore prompts like that. When someone is trying to find some information or complete a task, a prompt that pops up saying “sign up to our newsletter” or “download our native app” or “add to home screen” is a distraction to be dismissed. The fact that only the third example is initiated by the operating system, rather than the website, is irrelevant to the person using the website.

My hunch is that the majority of people will still interact with your progressive web app via a regular web browser view. If, then, only a minority of people are going to experience your site launched from the home screen in a native-like way, I don’t think it makes sense to prioritise that use case.

The great thing about progressive web apps is that they are first and foremost websites. Literally everyone who interacts with your progressive web app is first going to do so the old-fashioned way, by following a link or typing in a URL. They may later add it to their home screen, but that’s just a bonus. I think it’s important to build progressive web apps accordingly—don’t pretend that it’s just like building a native app just because some people will be visiting via the home screen.

I’m worried that developers are going to think that progressive web apps are something that need to built from scratch; that you have to start with a blank slate and build something new in a completely new way. Now, there are some good examples of these kind of one-off progressive web apps—The Guardian’s RioRun is nicely done. But I don’t think that the majority of progressive web apps should fall into that category. There’s nothing to stop you taking an existing website and transforming it step-by-step into a progressive web app:

Switch over to HTTPS if you aren’t already.

Use a service worker, even if it’s just to provide a custom offline page and cache some static assets.

Make a manifest file to point to an icon and specify some colours.

See? Not exactly a paradigm shift in how you approach building for the web …but those deceptively straightforward steps will really turbo-boost your site.

The Breaking Development conference is wrapping up here on spacecraft Opryland One. It’s been a wonderful experience. The conference itself was superbly curated—a single track of top-notch speakers in a line-up that switched back and forth between high-level concepts and deep-dives into case studies. I hope that other conferences will take note of those key phrases: “single track”, “curated”, “top-notch speakers” (see also: An Event Apart, dConstruct, Mobilism).

I opened the show with a talk that sounds controversial: There Is No Mobile Web. Actually, it wasn’t as contentious as it sounds (I originally proposed a talk called Fuck The Mobile Web: Fuck It In The Ass—then it would’ve been controversial). You can download a PDF of my slides if you want but, as usual, they won’t make much if any sense outside the context of the presentation.

My talk was concerned with language; Lakoffian political language in particular. When I say “there is no mobile web,” I mean it quite literally: there isn’t a separate world wide web for mobile devices. But by using the phrase “mobile web” we may be unintentionally framing the discussion in terms of separate silos for different kinds of devices (desktop and mobile) in a similar way that a term like, say, “tax relief” automatically frames the discussion of taxation as something negative. By subtly changing the framing from “the mobile web” to a more accurate phrase such as “the web on mobile” we could potentially open new avenues of thinking.

By the same token the phrase “one web”—which is the drum that I bang—is really a tautology. Of course there’s only one web! But the phrase has political and philosophical overtones.

So I asked the assembled audience if we could come to an agreement: I’ll stop saying “one web” if you stop staying “mobile web.” How about …”the web”?

When Ethan Marcotte coined the term “responsive web design” he conjured up something special. The technologies existed already: fluid grids, flexible images, and media queries. But Ethan united these techniques under a single banner, and in so doing changed the way we think about web design.

I’m not invoking the Sapir Whorf hypothesis here, I just wanted to point out how our language can—intentionally or unintentionally—have an effect on our thinking.

One of the other phrases I discussed was “web app.” The timing couldn’t have been better. Fellow Breaking Development speaker James Pearce has just written a blog post all about defining what makes something a web app. It’s very detailed and well thought-out but I’m afraid at the end of it, we’re still no closer to having a shared agreed-upon definition. It’s like the infamous Supreme Court definition of obscenity: “I know it when I see it.”

My concern is that the phrase “web app” is wielded as a talisman to avoid best practices. “Oh, I totally agree that we should care about accessibility …but this isn’t a web site, it’s a web app.” “I think that progressive enhancement is great …for websites; but this is a web app.” The term is used as a get-out-of-jail free card and yet we can’t even agree what it means. I call shenanigans. I don’t think it is useful or productive to create an artificial boundary between documents and applications when the truth is that almost everything on the web exists on a continuum between the two poles.

Luke has published his excellent notes from my talk. You should read ‘em. While you’re at it, you should read all of the notes that he took at the conference.

As I said, the Breaking Development conference did an excellent job of balancing the practical with the inspirational. Stephanie’s intensely useful case study was perfectly balanced by an absolutely incredible call to arms from Scott Jenson called Why Mobile Apps Must Die (and you thought my talk title was contentious), in which he expanded on his brilliant writings over on the Beyond Mobile blog.

The next Breaking Development event will be next April in Orlando. Single track. Curated. Top-notch speakers.

I’m feeling quite refreshed and ready for another day of geekery. There weren’t too many drinking shenanigans going on last night.

The official watering hole for the FOWA drinkipoos turned out to be a yuppie nightmare. The entrance hallway was filled with gaudy images that were probably intended to recall 1950s pin-ups but actually just looked like page 3 pages torn from a tatty copy of The Sun. The drinks were ludicrously overpriced and getting out of the toilets required a significant toll charge. All of this would have been mitigated if there were some ancillary benefits such as watching young nubile bodies gyrating on a dancefloor but a sign at the entrance made it very clear that dancing was forbidden. This being England, the sign added, “we apologise for the inconvenience.”

Before long, a rebellion was organised and a gaggle of geeks made a mass exodus to a lovely cosy pub across the street. Happiness and chattiness emerged. After that, there was time for one civilised nightcap in the hotel bar with the dynamic duo of Tara and Chris, Google’s Jonathan Rochelle (a scholar and a gentleman) and Natalie—free from Simon’s clutches while he worked frantically on his slides.

It’s day two of FOWA now and there’s still no sign of free WiFi. Khoi has kindly given me a BT Openzone scratch’n’sniff WiFi card he got yesterday so I’ll use that to dip in and out of the river of connectivity and expand on this running commentary throughout the day.

Mark Anders

Adobe kicked off the day with a Flex demo. Having attended Flash on the Beach, there wasn’t anything new for me here but it was interesting to watch other people’s reactions to the speed of Actionscript 3 and the ease of downloading an Apollo app.

Chris Wilson

Microsoft’s Chris Wilson is on stage giving a state of the Web address. He talked about the origins of Ajax, gave a nice shout out to microformats and he mentioned the power of tagging (Hi, Chris!). There’s plenty of talk about security which isn’t that enthralling to me personally but its probably the most important aspect of IE7 for most people on the planet. Alpha transparency in PNGs; now that’s more like it.

Khoi Vinh

Khoi is talking about The Future (capitalisation intentional) which will, as he says, be awesome. But first, let’s hear about some of the design challenges at The New York Times. He’s showing some nice examples of what art direction is. You’ll see art direction in the print version of the paper all the time, but the online counterparts are just templated. There are exceptions like the fifth anniversary of the September 11th attacks and the infographics for the November elections, but of course these are events that are predictable and can be planned for. For breaking news, real-time design just isn’t possible… yet.

Khoi makes an interesting point about the schizophrenia in new technology. At the same time that we’re getting into hi-def television and DVDs, we’re also flocking to YouTube even though the video quality is really lo-fi. And while SLR cameras are getting more and more powerful, we’re using crappy little camera phones more and more. This schizophrenia throws up some design challenges for a media outlet like The New York Times.

There’s no such thing as a free feature, says Khoi. And remember, the more expressive a designer gets, the more the user has to pay for it (download times and such). So for any new feature, there must be a really valid reason for it to exist. Oh, and options are obstructions. Too many prefs are a sign of unresolved design issues that couldn’t be squeezed into the main interface.

Simon Willison

Oh man, Simon’s on a roll. Talking a mile a minute, getting jibes in at Microsoft, cracking jokes about Ben and Mena Trott… he’s got the audience in the palm of his twirling, whizzing hand.

Long story, short: OpenID rocks. If you’re creating any kind of membership-based site, you need to check this out. If you’re member of a lot of different sites, you need to check this out. Oh, and in case you missed it, both AOL and Digg announced support for OpenID over the past few days. The momentum looks unstoppable at this stage.

I love the fact that the evangelism for OpenID is coming from passionate developers like Simon, not from some corporate representative. Like the microformats movement, it’s bottom-up rather than top-down. Other companies are buying slots at this conference to pitch their products but Simon gets to talk about OpenID because it’s so freakin’ cool and can’t simply be ignored.

Ah, OpenID and microformats: now there’s a cool combo. Simon has won my heart and the hearts of everyone else in the audience, I suspect. He’s talking about portable social networks and everything. Bravo, Mr. Willison!

Jonathan Rochelle

After a pleasant lunch with some of the Last.fm posse, I’m back in the auditorium to hear what Jonathan from Google has to say about Google Docs and Spreadsheets (killer name, indeed). These aren’t the kind of Web apps I’m likely to use myself but I’m interesting in the technology behind them. I’m assuming that, given the complexity of the applications, the Ajax used will be of the non-Hijax variety.

Open Mic

Time to break out into something a little unusual. This, as Ryan puts it, is the user-generated part of the conference. Over the past few weeks, delegates have been able to log on to the FOWA site and vote for some short presentations they’d like to see at this point. The three highest-scoring subjects will now present.

The virtual office. Okay, that works.

A documentation technique called Jedi — Just Enough Documentation for Interactions. Great backronym!

The topic with the most votes is… which apps will succeed and which will fail in 2007? Who knows?

Daniel Appelquist

And now it’s time for a talk on mobile. Let’s hear from Daniel Appelquist from Vodaphone. I’m not entirely sure that a provider is necessarily going to be the most subjective voice on this but we’ll see.

Actually, there’s something interesting stuff here, especially around the intersection of mobile and Ajax. There’s plenty of talk about standards, so that’s all good. I’ll have to corner him later for a chat.

Rasmus Lerdorf

Now let’s hear from the creator of PHP, Rasmus Lerdorf. He’s taking us on a trip down memory lane, looking at Mosaic and early versions of HTML and PHP. Rasmus basically wrote PHP to scratch his own itch—it’s the typical open source story.

Here’s a reassuring confession from someone who has written a programming language:

I hate programming. It’s tedious. It’s no fun. It’s like flying: sitting in a smelly metal tube with other people. But I love problem-solving.

Looking at PHP today, it’s a lot more verbose. The Computer Science geeks like it now but it sure has moved far away from being a quick and dirty tool for getting something done. Ironically, there are students today that only have a background in object-oriented programming and have to be taught what procedural programming is.

Here’s an interesting idea on why people join an open-source community: oxytocin, a neuropeptide otherwise known as nature’s trust hormone. That’s in addition to the usual incentives like self-interest and self-expression. It’s the same motivation that drives people to play World of Warcraft in a big way. Open source projects like PHP are like Web 2.0 community sites: Flickr, Digg and Wikipedia would be nothing without the user-contributed content. The same goes for any open-source project.

In addressing the issue of performance, Rasmus has lost me but that’s due to my own mental deficiency rather than any fault with his presentation style.

Security is even tougher. As he says, “basically, you can never click on a link.” He has two browsers: one for browsing and one for sites that have personal data. It’s kind of paranoid, it’s kind of sad but, when you understand the consequences of cross-site scripting, it’s entirely justified.

PHP5 makes it trivially easy to take XML from Web services and do stuff with it. I can vouch for that.

Richard Moross and Stefan Magdalinski

Moo cards are cool. I’ve got some: little cards with my Flickr food pictures and the URL of Principia Gastronomica. A significant proportion of this audience also have Moo cards. Best of all, anybody here can get free Moo cards if they give these guys a business card in return.

Business cards don’t have to be boring. They can tell a story.

With Moo cards, the difference makes all the difference. Y’know, Qoop launched much the same product—business cards made with the Flickr API—a week before Moo cards launched. But Moo could compete on the differences: unusual size and high-quality recycled card. Everybody talked about Moo cards; nobody talked about Qoop’s cards.

Partnership is everything for Moo. Without Flickr, they’d be nothing.

Marketing is a four letter word: free. Giving away free cards is great marketing. I concur: the free cards I got from Moo clinched the decision to buy cards from them.

The attention to detail in Moo’s physical package really seals the deal. There are little Easter eggs in there and the luggage-tag card that comes with every pack gets everyone talking. There’s an incredible amount that has to be done by hand but that’s what guarantees the right level of quality.

Now Stefan is giving a peak behind the curtain at the technical side of Moo. If you want to know what he’s saying, well, you should have come to the conference then, shouldn’t you? You can’t expect me to do everything now, can you?

I’m spending more time in London than in Brighton this week. After BarCamp London 2 at the weekend I had one day to recover and now I’m back up for the Future of Web Apps conference.

Like last year, the event is being held in the salubrious surroundings of Kensington; normally the home turf of Sloane Rangers, now overrun by geeks. But the geeks here are generally of a different variety to those at BarCamp (although I’m seeing a lot of familiar faces from the weekend).

The emphasis of the conference this time is more on the business, rather than the techy side of things. It makes sense to focus the event this way, especially now that there’s a separate Future of Web Design conference in a few months. The thing is… I don’t have much of a head for business (to put it mildy) so a lot of the material isn’t really the kind of thing I’m interested in. That’s not to say that it isn’t objectively interesting but from my subjective viewpoint, words like “venture”, “investment” and “business model” tend to put me to sleep.

That said, the presentations today have been less soporific than I feared. There was some good geeky stuff from Werner Vogels of Amazon and Bradley Horowitz of Yahoo, as well as some plain-talkin’ community advice from Tara Hunt.

The big disappointment of the day has been WiFi. Despite the fact that Ryan paid £6,000—remember, he’s not afraid of announcing figures in public—nothin’s doin’. For all the kudos that BT deserve for hosting the second London BarCamp, they lose some karma points for this snafu.

The day ended with Kevin Rose giving the Digg annual report. He left time for some questions so I put this to him:

I see Digg as a technological success and a business success but I think it’s a social failure. That’s because when I read the comments attached to a story, people are behaving like assholes.

At this point, people started applauding. I was mortified! I wasn’t trying get in a cheap shot at Digg; I had a point to make. So after informing the crowd that there was nothing to applaud, I continued:

This is probably because of the sheer size of the community on Digg. Contrast this to something like Flickr where there are lots and lots of separate groups. My question is; should you be trying to deliberately fragment Digg?

The answer was a resounding “Yes!” and it’s something that he touched on his talk. Afterwards, I was talking to Daniel Burka and he reckoned that Digg could take a leaf out of Last.fm’s book. The guys from Last.fm had previously talked about all the great features they were able to roll out by mining the wealth of attention data that users are submitting every day. Digg has an equally rich vein of data; they just need to mine it.

Anyway, it was a good day all in all but I feel kind of bad for putting a sour note on the Digg presentation. Plenty of people told me “great question!” but I felt a bit ashamed for putting Kevin on the spot that way.

Still, it’s far preferable to make these points in meatspace. If I had just blogged my concerns, it would have been open to even more misinterpretation. That’s the great thing about conferences: regardless of whether the subject matter is my cup of tea or not, the opportunity to meet and chat with fellow geeks is worth the price of entry.

One of the speakers was Mike Davidson. During his talk about Newsvine and online communities, my ears started burning. Why, I do believe he’s talking about me!

It all goes back to this post I made where I talked about how crap most comments are:

I’d like to propose a corollary of Sturgeon’s Law for blogs: Comments should be disabled 90% of the time.

Mike made the point that he finds it frustrating not being able to comment on my posts. Fair enough. He also speculated that the lack of a comment facility here might well lead to a decrease in traffic. I think he’s probably right.

But here’s the thing: I’m okay with that. I don’t think lots of traffic is a goal to strive for. There’s no doubt that comments are a simple and effective way of driving traffic to your site, but to what end? Instead of having lots of visitors, I’d much rather have a small amount of the right kind of visitors.

I’ve tried to explain this to people in the past (especially people just starting out in blogging) but I keep running into the same problem over and over: nobody believes a word I’m saying. But I swear it’s true! I’ve seen the way that useless comments can lower the tone on other sites and I don’t want it happening here.

Let me reiterate that this problem is particularly troublesome on sites that cover a diverse range of topics. Narrowly focused sites tend to foster higher quality comments. That’s why I’ve got comments enabled on the DOM Scripting blog which is focused entirely on JavaScript, but not here on Adactio, which is a smorgasbord of any ol’ rubbish that pops into my head.

It’s definitely a challenge for a wide-ranging site like Newsvine which seems to be handling the situation quite well. It’s certainly doing a lot better job than Digg. The rude, pointless, spiteful bickering that goes on over there makes me want to block any referrals from that domain. Mind you, it could simply be a matter of numbers. Digg users have clearly left their Dunbar number in the dust while Newsvine still feels cosy enough.

I’ve been trying to get at the root of my issues with comments on blogs. Ironically, I was able to crystalize my thoughts through participating in the comments on a blog post by Bryan Veloso. Oh, the irony!

I realised that comments on blogs are trying to fulfil two roles. On the one hand, they are a feedback mechanism — “Good post!”, “Me too!”, “You’re full of crap!”, et cetera. On the other hand, people claim that comments are a great way of fostering conversation.

Well, which is it? Feedback or conversation? Comments are a so-so way of dealing with both although better tools exist. Email is better for feedback. Mailing lists, forums, and instant messaging are better for conversations.

Now that I’ve had my satori about the dual nature of comments, I can better address what I want from them.

Here at Adactio, I don’t want to start conversations. I’m not looking to foster a community. I already run one large online community and I’d rather keep this site separate from all that. I am, however, interested in getting occasional feedback or hearing what other people have to say about some of the things I write about here. So, after much deliberation, here’s the moment that almost nobody has been waiting for:

I’m opening up comments here… but with a twist. To encourage feedback whilst discouraging conversation, I’m turning to the wisdom of crowds.

There are a number of factors that go into making a wise crowd:

Numbers. Generally, the bigger the crowd, the better. I have no idea how many people read this blog so I have no clue as to whether there will be enough people to make this work.

Diversity. A diverse range of backgrounds and opinions is vital. I suspect that my site is mostly read by geeks, but I know there are non-geek friends and family that also stop by. Everybody’s opinion is valuable.

Independence. This is the clincher. To really get wisdom from a crowd, it is vital that each person is acting independently. For a practical demonstration, just think about the “ask the audience” part of Who Wants to be a Millionaire? The results are strikingly good because each audience member has no idea what the others are choosing.

Comments on blogs fall down on that last point. Traditionally, comments are visible, thereby influencing future comments. That’s good if you’re trying to stoke a conversation, but lousy for getting some honest feedback.

So here’s what Im going to do:

I will occasionally open up some posts for comments. You will be presented with the usual form: name, email, url, etc. I would greatly appreciate getting your opinion. However, your comment will not be published immediately.

Comments will remain open for a set period of time; sometimes a week, sometimes a month. At the end of this time, all the comments will be published at once. At this point, it will no longer be possible to add a comment.

I still need to iron out a few technical details. It would be nice if there were a cron job set up so that you could be notified when your comment goes live. But mostly it’s a pretty straightforward set-up. It’s really only a minor variation on the traditional comment model but I’m intrigued to see what the results turn out to be.

Like I said, I won’t be doing this for every post. I intend to stick to my rule of thumb and keep comments closed 90% of the time.

Let’s get the ball rolling. What do you think of this idea? How vehemently do you disagree with my assessment of comments on blogs? Exactly how pretentious and arrogant do you think I am?