Tags: webapps



Progressing the web

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.

Here’s an article with the spot-on title Progressive Web Apps — The Next Step In Responsive Web Design:

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.

And here’s someone feeling the cognitive dissonance of turning a website into a progressive web app, even though that’s exactly the right thing to do:

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.

Far more troubling is the entanglement of the term “progressive web app” with the architectural choice of “single page app”. I’m not the only one who’s worried about this.

Here’s the most egregious example: an article on Hacker Noon called Before You Build a PWA You Need a SPA.

No! Not true! Literally any website can be a progressive web app:

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.

Literally any website can—and should—be a progressive web app. Don’t let anyone tell you otherwise.

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!

Like Frances says:

Remember, this is for everyone.

Progressive Web App questions

I got a nice email recently from Colin van Eenige. He wrote:

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.

Less JavaScript

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.

In his talk on service workers (what else?), Jake makes the point that not everything needs to be a single page app, echoing Ada’s talk at FFConf.

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.

Alex followed up his barnstorming talk from the Polymer Summit with some more uncomfortable truths about how mobile phones work.

Cell networks are basically kryptonite to the protocols and assumptions that the web was built on.

And JavaScript frameworks aren’t helping. Quite the opposite.

But make no mistake: if you’re using one of today’s more popular JavaScript frameworks in the most naive way, you are failing by default. There is no sugarcoating this.

Today’s frameworks are mostly a sign of ignorance, or privilege, or both. The good news is that we can fix the ignorance.


Laurie Voss has written a thoughtful article called Web development has two flavors of graceful degradation in response to Nolan Lawson’s recent article. But I’m afraid I don’t agree with Laurie’s central premise:

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

  1. This is a web app so it’s built as a single page app.
  2. Why do you define it as a web app?
  3. 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.

This remark by Tom is the very definition of a false dichotomy:

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.

Tom’s tweet included a screenshot of this part of Nolan’s article:

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:

  • They’ll mostly be running Android.
  • They’ll have decent specs (1GB RAM, quad-core processors).
  • They’ll have an evergreen browser and WebView (Android 5+).
  • What they won’t have, however, is a reliable internet connection.

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.

That’s why I choose to use progressive enhancement …and build progressive web apps.

The imitation game

Jason shared some thoughts on designing progressive web apps. One of the things he’s pondering is how much you should try make your web-based offering look and feel like a native app.

This was prompted by an article by Owen Campbell-Moore over on Ev’s blog called Designing Great UIs for Progressive Web Apps. He begins with this advice:

Start by forgetting everything you know about conventional web design, and instead imagine you’re actually designing a native app.

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.

See, when a developer has to implement a feature that the browser should be providing, that seems like a bad code smell to me. This is a problem that Opera is solving (and Google says it is solving, while meanwhile penalising developers who expose the URL to end users).

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:

  1. 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.
  2. Web—you’re building for the web. Don’t lose sight of that. URLs matter. Accessibility matters. Performance matters.
  3. App—sure, borrow what works from native apps if it makes sense for your situation.

Jason asks questions about how your progressive web app will behave when it’s added to the home screen. How much do you match the platform? How do you manage going chromeless? And the big one: what do users expect?

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.

Getting the “add to home screen” prompt for https://huffduffer.com/ on Android Chrome.

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:

  1. Switch over to HTTPS if you aren’t already.
  2. Use a service worker, even if it’s just to provide a custom offline page and cache some static assets.
  3. 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.

I’m really excited about progressive web apps …but mostly for the “progressive” and “web” parts. Maybe I’ll start calling them progressive web sites. Or progressive web thangs.

The Language of the Web

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 Assthen 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.

Jeremy Keith @adactio

My talk was concerned with language; 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”?

I also talked about the power of naming things, invoking the foreword I wrote for Ethan’s book:

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 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: “.”

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.

Make sure you check out the notes from Stephanie’s mind-blowing case study of browser.nokia.com. The slides are on Slideshare too.

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.

The Future of Web Apps, day two

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.

Thank you, Khoi. And now it’s Simon’s turn. Hmmmm… I wonder what he’ll be talking about: OpenID, perhaps?

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.

  1. The virtual office. Okay, that works.

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

  3. 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.

Time for a quick announcement.

Tariq Krim

Tariq is from Netvibes. I haven’t played with it myself but Mike Stenhouse was raving about it yesterday.

There’s a big announcement coming right now. Here it is… a Universal Widget API or UWA if you prefer a TLA.

If you care, you heard it here first folks.

Wait, here’s another announcement: support for OpenID. Yay! All the cool kids are doing it.

Right. Make way for the guys from Moo.

Richard Moross and Stefan Magdalinski

Print is dead? Bollocks says Richard. And of course he’s right. Derek Powazek would agree, I’m sure.

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?

The Future of Web Apps, day one

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.

The comments of crowds

The Future Of Web Apps summit took place in San Francisco this week. By all accounts, it was an excellent two days although it did spark an interesting hand-wringing debate about diversity which reminded me of the best ever episode of Father Ted: “I hear you’re a racist now, Father”.

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 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 .

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

  1. 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.

  2. 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.

  3. 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?

Comments are open.