Now blogging at diego's weblog. See you over there!

the web is not the browser, a year later

About a year ago (a year and three days, actually) I wrote a post titled the web is not the browser. At that point the discussion was whether "RSS usage" was "web usage" or not. Russ posted his thoughts on the Mobile Web yesterday, and there's a bit of deja-vu there, but going in some new directions. So here's my thoughts, updated. :)

The Web isn't just HTML+HTTP

Russ starts:

Now, when I say "web", you know what I saying right? I'm generally thinking HTML over HTTP and though you could probably say there's a lot of "dark content" out there on the internet - like in email, etc. it's generally not publicly accessible. The web in 2004 is the lingua franca of internet based information, I don't think there's much argument on this...
Actually, I think there is some argument on this, and Russ and I basically discussed it in the comments of that entry of mine a year ago. Russ made exactly the same argument in his comment and I replied with this in another comment:
Russ: you say the web is HTTP + HTML. Okay. However, what you type in your browser is a URL. The URL is post-web (RFC 1738 is dated Dec. 1994), and as it says in the RFC: "The specification is derived from concepts introduced by the World-Wide Web global information initiative" [Just to clarify, I mean "post-web" in that the concepts in general use today were developed after the initial web was launched]. Yes, originally "The Web" was the world wide web, HTML+HTTP. But very quickly things became intermixed. Today, you'll click on a link that is "ftp://" to download a file. FTP dates back to the pre-WWW days. Is clicking on ftp:// *not* the web too? If people click on a text file obtained through FTP and read it on their browser, is that not the web? Or on a quicktime video?

Today we often use HTTP to download files, not to see HTML, or to stream video, or audio, or Flash animations, or, yes, RSS, and it's an integral part of the "web experience". Some clients take HTML and present it in different ways "syndicating" it. So what I'm saying is that, even though at the beginning the web was indeed just HTTP+HTML, it went beyond that very quickly. Even if you only consider what you see within the browser the "web experience" includes a multitude of formats and protocols.

Purely in terms of content "weight" (storage capacity + bandwidth) I'd bet that web protocols are carrying as much, if not more, content types that are not text/html. As an example of what I mean, consider that downloading the full page for Russ's post on the mobile web clocks at 35,703 bytes--34 KB or so, and it's a typical post, image, a decent amount of text, some comments. Now, about a month ago Russ was talking about that 25 GB that he saw of downloads from an MP3 he posted (size 5,649,826 bytes, or about 5.5 MB).

That single MP3 amounts to about 160 posts.

Russ generally posts once a day. So that MP3 equaled his production for half a year in terms of size (the bandwidth ratio is probably a bit lower than 1:1 though, since the MP3 doesn't get hits from search). Since Russ has also been doing audioblogging, there are several MP3s posted in his blog, which I'd wager amount for quite a lot more than all of the text/html content he's ever produced (even if you count images, CSS, etc). Then, elsewhere, there's Flash, Java, video, and everything else.

So, I think the assumption that most content is text/html is wrong. I don't see this as a big problem for the discussion that follows though, because mobile browsers will eventually support most if not all of the advanced features.

To mobile or not to mobile

Russ's next point is that delivering a "dumbed down" version of the web (or using some other kind of content delivery system) is wrong because a) devices are appropriate and b) people want "the whole web". I agree with the second, but not the first (not for any use-case+context at least, more on that in a bit).

Paradoxically, the title of Russ's post undermines his argument a bit. If you have to use an adjective for something, then it's different right? Russ's vision is not a "mobile web" but "the web on mobiles". After all, we didn't start calling the web "the video web" or "the audio web" when streaming arrived--it was just the web. This is just semantics though. :)

Russ then goes through the common arguments against browsing on mobiles. These arguments generally fall into one of two categories:

  • Capabilities. These include: "The screen is too small," "Mobile phone browsers are too limited (no Javascript, no frames, etc.)," "Other platforms (Flash, Java, Brew) provide more richer experience (with less latency)," "Mobile data connectivity - even using 3G networks - has massive latency between pages."
  • Usage. "People use their mobile devices "differently" - thus need snippets of data." "Why use a mobile phone when you're not more than 10 minutes away from a PC ever," "Prefer laptops and WiFi, rather than struggling with a mobile."
To this list I'd add "Navigation" in the Capabilities section. I think the small screen is less a factor than the fact that with most phones you have to use the keypad/tiny-joystick for input. The Web, however, has been designed with keyboard/mouse in mind. I think solving the navigation issue is more important (and more difficult) than worrying about the latency for example. People browsed the web with 14.4kpbs modems for quite a while, after all.

The capabilities problems might be a factor at the moment but clearly will not go on forever. If there's a need, they'll be fixed (eventually). Moore's Law and all that. So I don't see those things as a major problem.

Usage is to me the most important category, but it's generally overlooked. Capabilities matter, but assuming you fix most of them (it will be hard to get around the screen-size problem for a few years though--but even so I don't think it's a major roadblock), usage is really where the crux of the matter is, and one that can easily get muddled. When Russ mentions "People use their mobile devices "differently" - thus need snippets of data," he's no doubt writing down something he's heard many times. And while the first part is hard to argue with (People definitely use their mobile devices differently), the second part doesn't follow from it. At all. Blackberry users handle quite a lot of email. Many users enjoy streaming on phones, or online games. Those hardly count as "snippets" of data. However makes that statement is pushing forward their own assumptions about phones: "People use mobiles differently, and mobiles are small and puny, hence you need snippets of data."

But the use cases are different and it's worthwhile to spend a bit of time on that topic, because I think that's a big part of what's actually being discussed, though not directly, when someone says "I don't want the web on a mobile."

It's all about the use case and the context

Use-cases and context are what drive usage, not product features (the "capabilities" from above). Product features can enable new use cases, but given a certain base of devices (i.e., given today's technology, maybe looking a few months into the future at most), it's the use-cases+context that matter most IMO.

Consider the following use-cases+context:

  1. If I'm sitting at a PC with a broadband connection, it's almost unthinkable that I'd use a phone for browsing the web. In fact, if I'm sitting at a PC, it's almost unthinkable that I'd use any other device. And why would I? Everything is right there.
  2. I'm on the road, and I have a laptop that is turned on with WiFi running, and a smartphone. I'd use the laptop. Cheaper, faster, better UI, etc.
  3. Same case as before: laptop and smartphone. Only this time the laptop is turned off. The phone is on standby. How long does it take to get everything up and running on the laptop? Maybe 5 minutes? The phone, though, being always-on, is nearly instantaneous. So if I just need to check something (say, the weather) the phone is probably a better choice. But if I'm going to be online for a while, I'll probably use the laptop anyway.
  4. If I have nothing but a phone, that's clearly what I'd use. But would I use it just like a PC? Doubtful. A phone doesn't go well with "multitasking", e.g., I can't easily browse the web and talk, and check my calendar, and check a relevant email at the same time, and I've often found myself doing all of those things while in the middle of a conversation (real-world, phone, or VoIP). Phones are more of an immersive experience (speaking of phones being immersive, check this out :)).

My point is that what we think "people" will do or won't do is heavily influenced by our own experience and usage. I suspect that phones will find entrenched niches at first, things where the availability, mobility, and form factor takes precedence (similar to how game consoles have their place against ever-more-powerful PCs). If I'm carrying a laptop around most of the time, then it's unlikely that I'll see the phone as more than a stopgap measure. If, however, I only carry a phone around most of the time, the phone will gain importance.

Do I want the whole web on a phone? Absolutely.

Will it eventually become a much smoother experience? Certainly.

Does that mean that I'll (that is, me personally) stop using PC and PC-like devices, and use phones as my primary method of browsing? Not a chance.

But does that mean that nobody is going to use the phone as their primary interface to the web? Of course not.

For some people though, the use-case, or the context, or both, will be there, and maybe what makes the discussion more complex is that "some people" here means tens of millions of users. As I understand it, in Japan, for example, people use their phones to access online services more than their PCs, or at least nearly as much. Phones will grow in importance, and take their rightful place in the continuum of capabilities we have today--browsing the whole web, yes, but not necessarily pushing PCs out of the way because of that.

Categories: technology
Posted by diego on November 17, 2004 at 9:12 AM

Copyright © Diego Doval 2002-2011.