Tags: webapp

8

sparkline

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.

Defining the damn thang

Chris recently documented the results from his survey which asked:

Is it useful to distinguish between “web apps” and “web sites”?

His conclusion:

There is just nothing but questions, exemptions, and gray area.

This is something I wrote about a while back:

Like obscenity and brunch, web apps can be described but not defined.

The results of Chris’s poll are telling. The majority of people believe there is a difference between sites and apps …but nobody can agree on what it is. The comments make for interesting reading too. The more people chime in an attempt to define exactly what a “web app” is, the more it proves the point that the the term “web app” isn’t a useful word (in the sense that useful words should have an agreed-upon meaning).

Tyler Sticka makes a good point:

By this definition, web apps are just a subset of websites.

I like that. It avoids the false dichotomy that a product is either a site or an app.

But although it seems that the term “web app” can’t be defined, there are a lot of really smart people who still think it has some value.

I think Cennydd is right. I think the differences exist …but I also think we’re looking for those differences at the wrong scale. Rather than describing an entire product as either a website or an web app, I think it makes much more sense to distinguish between patterns.

Let’s take those two modifiers—behavioural and informational. But let’s apply them at the pattern level.

The “get stuff” sites that Jake describes will have a lot of informational patterns: how best to present a flow of text for reading, for example. Typography, contrast, whitespace; all of those attributes are important for an informational pattern.

The “do stuff” sites will probably have a lot of behavioural patterns: entering information or performing an action. Feedback, animation, speed; these are some of the possible attributes of a behavioural pattern.

But just about every product out there on the web contains a combination of both types of pattern. Like I said:

Is Wikipedia a website up until the point that I start editing an article? Are Twitter and Pinterest websites while I’m browsing through them but then flip into being web apps the moment that I post something?

Now you could make an arbitrary decision that any product with more than 50% informational patterns is a website, and any product with more than 50% behavioural patterns is a web app, but I don’t think that’s very useful.

Take a look at Brad’s collection of responsive patterns. Some of them are clearly informational (tables, images, etc.), while some of them are much more behavioural (carousels, notifications, etc.). But Brad doesn’t divide his collection into two, saying “Here are the patterns for websites” and “Here are the patterns for web apps.” That would be a dumb way to divide up his patterns, and I think it’s an equally dumb way to divide up the whole web.

What I’m getting at here is that, rather than trying to answer the question “what is a web app, anyway?”, I think it’s far more important to answer the other question I posed:

Why?

Why do you want to make that distinction? What benefit do you gain by arbitrarily dividing the entire web into two classes?

I think by making the distinction at the pattern level, that question starts to become a bit easier to answer. One possible answer is to do with the different skills involved.

For example, I know plenty of designers who are really, really good at informational patterns—they can lay out content in a beautiful, clear way. But they are less skilled when it comes to thinking through all the permutations involved in behavioural patterns—the “arrow of time” that’s part of so much interaction design. And vice-versa: a skilled interaction designer isn’t necessarily the best at old-skill knowledge of type, margins, and hierarchy. But both skillsets will be required on an almost every project on the web.

So I do believe there is value in distinguishing between behaviour and information …but I don’t believe there is value in trying to shoehorn entire products into just one of those categories. Making the distinction at the pattern level, though? That I can get behind.

Addendum

Incidentally, some of the respondents to Chris’s poll shared my feeling that the term “web app” was often used from a marketing perspective to make something sound more important and superior:

Perhaps it’s simply fashion. Perhaps “website” just sounds old-fashioned, and “web app” lends your product a more up-to-date, zingy feeling on par with the native apps available from the carefully-curated walled gardens of app stores.

Approaching things from the patterns perspective, I wonder if those same feelings of inferiority and superiority are driving the recent crop of behavioural patterns for informational content: parallaxy, snowfally, animation patterns are being applied on top of traditional informational patterns like hierarchy, measure, and art direction. I’m not sure that the juxtaposition is working that well. Taking the single interaction involved in long-form informational patterns (that interaction would be scrolling) and then using it as a trigger for all kinds of behavioural patterns feels …uncanny.

By any other name

I’m not a fan of false dichotomies. Chief among them on the web is the dichotomy between documents and applications, or more broadly, “websites vs. web apps”:

Remember when we were all publishing documents on the web, but then there was that all-changing event and then we all started making web apps instead? No? Me neither. In fact, I have yet to hear a definition of what exactly constitutes a web app.

I’ve heard plenty of descriptions of web apps; there are many, many facets that could be used to describe a web app …but no hard’n’fast definitions.

One pithy observation is that “a website has an RSS feed; a web app has an API.” I like that. It’s cute. But it’s also entirely inaccurate. And it doesn’t actually help nail down what a web app actually is.

Like obscenity and brunch, web apps can be described but not defined.

I think that Jake gets close by describing sites as either “get stuff” (look stuff up) or “do stuff”. But even that distinction isn’t clear. Many sites morph from one into the other. Is Wikipedia a website up until the point that I start editing an article? Are Twitter and Pinterest websites while I’m browsing through them but then flip into being web apps the moment that I post something?

I think there’s a much more fundamental question here than simply “what’s the difference between a website and a web app?” That more fundamental question is…

Why?

Why do you want to make that distinction? What benefit do you gain by arbitrarily dividing the entire web into two classes?

I think this same fundamental question applies to the usage of the term “HTML5”. That term almost never means the fifth iteration of HTML. Instead it’s used to describe everything from CSS to WebGL. It fails as a descriptive term for the same reason that “web app” does: it fails to communicate the meaning intended by the person using the term. You might say “HTML5” and mean “requires JavaScript to work”, but I might hear “HTML5” and think you mean “has a short doctype.” I think the technical term for a word like this is “buzzword”: a word that is commonly used but without any shared understanding or agreement.

In the case of “web app”, I’m genuinely curious to find out why so many designers, developers, and product owners are so keen to use the label. Perhaps it’s simply fashion. Perhaps “website” just sounds old-fashioned, and “web app” lends your product a more up-to-date, zingy feeling on par with the native apps available from the carefully-curated walled gardens of app stores.

In his recent talk at Port 80, Jack Franklin points to one of the dangers of the web app/site artificial split:

We’re all building sites that people visit, do something, and leave. Differentiating websites vs. web apps is no good to anyone. A lot of people ignore new JavaScript tools, methods or approaches because those are just for “web apps.”

That’s a good point. A lot of tools, frameworks, and libraries pitch themselves as being intended for web apps even though they might be equally useful for good ol’-fashioned websites.

In my experience, there’s an all-too-common reason why designers, developers, and product owners are eager to self-identify as the builders of web apps. It gives them a “get out of jail free” card. All the best practices that they’d apply to websites get thrown by the wayside. Progressive enhancement? Accessibility? Semantic markup? “Oh, we’d love to that, but this is a web app, you see… that just doesn’t apply to us.”

I’m getting pretty fed up with it. I find myself grinding my teeth when I hear the term “web app” used without qualification.

We need a more inclusive term that covers both sites and apps on the web. I propose we use the word “thang.”

“Check out this web thang I’m working on.”

“Have you seen this great web thang?”

“What’s that?” “It’s a web thang.”

Now all I need is for someone to make a browser plugin (along the lines of the cloud-to-moon and cloud-to-butt plugins) to convert every instance of “website” or “web app” to “web thang.”

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.

TeuxDeux Part Deux

I’ve tried a few different to-do list apps in my time: Ta-da List, Remember The Milk. They’re all much of a muchness (although Remember The Milk’s inability to remember me on return visits put me off it after a while).

The one that really fits with my mental model is TuexDeux. It’s very, very simple and that’s its strength. It does one thing really well.

Now it has been updated with a few little changes.

TeuxDeux Part Deux on Vimeo

I’m very pleased to see that it has become more flexible and fluid. I’ve said it before but I really think that web apps should aim to be adaptable to the user’s preferred viewing window. With more content-driven sites, such as webzines and news articles, I understand why more control is given to the content creator, but for an application, where usage and interaction is everything, flexibility and adaptability should be paramount, in my opinion.

Anyway, the new changes to TeuxDeux make it better than ever. Although…

If I had one complaint—and this is going to sound kind of weird—it’s that you mark items as done by clicking on them (as if they were links). I kind of miss the feeling of satisfaction that comes with ticking a checkbox to mark an item as done.

I told you it was going to sound kind of weird.

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.