|
» Radical Simplicity and Complexifiers » Web location and Physical location » Is a Browser Defined by its Protocol? » The 1887 Website » There's surfing, and then there's surfing |
|
Subscribe RSS 2.0 feed |
Subscribe Atom feed If you wish to receive email notification, please here » |
The Jitterbug phone is a radically simple device; it makes and receives calls. You don't even have to dial numbers if you don't want to. It has no "confusing icons". It's not from Nokia.
It's not that Nokia doesn't make simple phones, although I'm not sure we make a phone entirely free of icons. By "simple" I mean "vastly less complex than any S60 device", by the way. The Jitterbug is a marketing approach, more than anything. There's a bit of design there, but I think it's essentially an off-the-shelf Samsung phone being marketed to people who specifically dislike products like S60 phones. I occasionally meet people in that category, and their dislike can be quite intense.
This is interesting. I don't think "ease of use" is exactly the issue; it's complexity of use, even if that complexity is made easy to cope with. Complexity, for some people, is a problem; a bug in the system. And it's a problem that I think can't be helped by any amount of interface design -- the only acceptable way to design a product that will appeal to people in this category is to remove functions. This is quite the opposite of many people, and I suspect virtually the entire S60 market. Maybe it's a generational thing, as suggested here. I think about it like this: there are "simplifiers" and then there are "complexifiers".
As an interface designer, I find this fascinating. Assuming we could make a product a simplifier would not want to kick us out of town for producing (remember, that dislike can be intense), I like thinking about how to design a browser they'd like.
I even have a personal project in this direction. I'm motivated by something quite personal; my mother is one of these function-averse people. She does not have (will not accept) a telephone answering machine. She barely tolerates a phone at all. Do not mention "mobile phone" to her. Please. I know what will happen. And yet...she loves to read and has quite an extensive library. Before her retirement, she was a nurse and had no difficulty with medical equipment, including electronic monitors with fairly arcane interfaces (I didn't play with them when they were connected to anyone). Anyway, I think she would enjoy the web, and she would be easily able to cope with it aside from attitudinal issues. The design challenge is to create a browser that she, and people like her, would find appealing.
I'll let you know. Um, by a letter written in ink on paper, just like it's supposed to be! :-)
Here's a fun idea: VerveEarth is plotting bloggers on a world map. It's a Google Map, I think. It seems to be quite new, as it's still in beta and the map is not very well populated yet. This idea suggests things like moving the affinity-based connections now exploding on the web into the physical world on a more local level than "big" conferences where everybody goes to, say, Paris all at once.
As blogs become partially hosted on mobile devices, an obvious extension of the VerveEarth idea (that they're probably working on, for all I know) is plotting your current location and indexing by affinity or topic. That would be a way to discover, for example, that an author of one of your favorite food-review blogs is in the same restaurant you're in right now. Which could in turn lead to new connections, and for that matter, you could end up as a guest reviewer. "Oh, you had the salmon? How was it?"
Here's an excellent podcast: Jon Udell interviews Dr. Joel Selanikio about the potential and uses of the dominant developing-world computing platform (the mobile phone) and the dominant communication protocol there (SMS). I owe Mike Rowehl thanks for posting this interview on his blog.
Selaniko is a physician working on public health and technological issues in the developing world. He and Udell muse about SMS as a communication system for physicians with no other access to medical communications. Why not, they say, write a small application that aggregates SMS messages into a larger whole -- such as, for example, a treatment protocol or even a paper in a medical journal. Ten or fifteen years ago we got along with similar transmission speeds and processing power.
This raises an interesting point: if you were to create such a program, it would probably display something like pages of text. It might even have some form of hyperlinking. Except for the fact that it doesn't use HTTP, and probably wouldn't use HTML tagging (too heavyweight), what you'd have would be a browser.
Similarly, think about the other end of the spectrum. HTTP and HTML won't be around forever any more than token ring networks, CP/M, or Wordstar. But the notion of a browser will probably transcend the "plumbing" simply because the ability to open remote documents that contain some kind of hyperlinking is so powerful.
Of course, I'm radically simplifying the idea of a "browser" here. I dunno; what's the basic set of capabilities that makes a piece of software clearly a browser, and how independent are those capabilities from communication protocol and content formatting?
I have beside me a website from 1887. No, really. Here's the story.
Down the road from my house some people were cleaning out the basement, and selling the various things they found. I was walking my dog past their yard sale, and he (the dog) absolutely had to have a little stuffed teddy bear they had in a box on the ground, right in dog range. Since I was obviously buying this bear (the alternative was seeing if the hospital would reattach my fingers after trying to take it away from him), I looked around a bit more and found a book of John Greenleaf Whittier's poems from 1887. Whittier was a local poet, and I like old books, so for 50 cents I was the new owner. The bear also cost 50 cents, by the way.
Leafing through it later it occurred to me that this particular book is a website. It has a comments section (the whole thing), and I know, for instance, that it was given as a Christmas gift in 1888. It has a bookmarking function (the bookmarks are bits of newsprint that have been in the book so long that they've slightly discolored the pages). There's a change tracking area -- there were some earlier editions, noted in this version). And a welcome note from the author, who was nearing the end of his career and wrote an introduction that mentioned his embarrassment about some of his very early work, which is included anyway.
Many of the poems resemble email, in a way. Or at least blog entries. Whittier wrote about some very big, high-level themes like slavery, war, and religion. He also wrote some very local, very down-to-earth pieces about, for example, his neighbors and some local landmarks. And he was certainly as prolific as a blogger (well, maybe not me, but I've heard that some bloggers post a lot more often!)
All in all, a good use of fifty cents. My dog still has that bear, too.
I didn't find this surprising, but maybe I should have. A survey done for SBC Communications, reported in PDA Today, found that people take their web-enabled devices with them on vacation. Not for work, but for recreation. As PDA Today put it:
Today's vacationers overwhelmingly turn to the Internet and Web-enabled consumer electronics to make virtually every part of their summer getaways easier and more enjoyable.
The survey mentions the typical sorts of things -- planning, making reservations, sharing photos and other memorabilia. What it doesn't touch on, though, is using the web as recreation. There are all kinds of games, of course, but it's also fun -- at least for many, including me -- to simply find new things on the web.
Our browser is really pretty good at most of these things, and a mobile phone is obviously the web-enabled device millions of people are vacationing with. I think the area we have the furthest to go, though, is using the web recreationally. As my daughter might say (okay, might have said several years ago), "we have the bestest browser, but do we have the funnest"?
I've tried a number of times to use RSS regularly. As a user, that is. I always end up deciding I don't like it. And I usually try again because I keep thinking I ought to like it; a short "feed" that alerts me to some new posting somewhere seems like a useful idea.
I think it might be the brevity. Feeds are often headlines of a sort, and good headlines are very difficult to write. I prefer the long version of most things; I'd rather get the whole picture. Or maybe I just have too much time to waste!
I do wonder, though, if my dissatisfaction with feeds is unique or whether there are other Feed Abandoners out there. Maybe we should start a support group.
For each web page you look at, how much do you actually read? Or use other than by reading? Sometimes only a fairly low percentage of a page is useful. The question, of course, is which part is useful.
Our browser works on a device where in many cases the content costs extra. If you have a phone with wifi and you're in range of a hotspot, so much the better. But for the most part mobile users pay for the data. So it would be a benefit to users if the browser was clever enough to load only the right portion of a page.
It would not, of course, be a benefit to everyone. The network operators would get less data-transfer revenue. Pages with advertising support would get fewer "eyeballs" (well, assuming the ads aren't the important portion of the page). Web designers would have another task as they designed for a browser that was going to load only parts of their pages. Users are my main concern, though.
There are some systems that already try to modify the page displayed on a mobile device, generally using a proxy server to "do something" to the content and send a smaller number of bits to the mobile user. Opera Mini, for example, is partly server-based and works pretty well. There have been (and are) other proxy-based solutions. So that particular part of the problem can be solved.
The harder problem is figuring out which parts of a given page are the important parts. It's a hard problem because it depends on a lot of things. It's not necessarily the biggest piece of text. It's not necessarily the most prominent graphic element. It might be the portion of a page containing a form, but it might just as well be just the inverse; the part of the same page that doesn't contain a form. Even assuming you could get it right for a particular set of pages in a given situation -- news pages, for example, or blog pages, or photo pages -- users differ. What's important to one might be quite different from what's important to another.
It might even vary over time. The part of page "x" important to me today might not be the same tomorrow. Worst of all, some pages really only work "unabridged", as it were. The whole thing is important, and there's no apparent range of priority; you just need the whole page.
I think this is still a solvable problem, even given all these constraints. Part of the answer lies in collaboration of the "page ranking" sort. Part of it lies in adaptability of the "smart menu" sort. Some other technologies will help, too.
The large question, of course, is whether all this effort to reduce the amount of data flowing to the mobile is, in the end, a good idea. Flat-rate data service would just simplify the whole thing, wouldn't it?
Lately I've been thinking about the limits of browsers. The limits largely live in the address bar, not the multiverse of the content area. There are all kinds of things right on the phone that you can't browse. Your contacts, for example.
What would it be like if you could browse your contact list? The way I'd want to do it would be to have a list of names, each one of which would be a link. The link wouldn't always be the same thing, though.
Some of the people in my contact list are there because of who they are, and some of them have web pages. So some of the links would be to web pages. Some of the people in my list don't have web pages, and their links would just call them, if that's mostly how I contact them, or maybe email or text them if that's what I mostly do.
Some people in list are there because of what they are. The local representative of my insurance company, for example, is there because that's his job. The link to his name on my contact page would bring me to a page about me -- policy numbers, for example, and probably contact information not just for him, but for claims.
Some items in my list aren't people at all; they're companies. In some cases what I would want to link to would be my information, in some cases information about the company, and in some cases neither. If I were to shop for a car, for example, a few salespeople might temporarily inhabit my contact list. The important thing about them would be neither their names nor their companies, but the fact that I was shopping for a car. A link to some sort of model comparison would help me find the economy-class 300 horsepower, 200 mile-per-hour, 100 mile-per-gallon luxury SUV sports bus convertible I was looking for (see, this is why I hate shopping for cars...).
The point is that if you think of various kinds of information in your phone as browsable, categories start to blur. A contact can be many different things. Browsing encompasses all of them, and more. As David Weinberger says, Everything is Miscellaneous!
One approach to making the web usable on tiny devices is to use a "smart" server that modifies the original content in some way. Here's an example: Intelligent Mobile Platform from InfoGin. It looks like they're reformatting content to eliminate horizontal scrolling, which is the most common approach.
It has certain advantages for some tasks, but I can't help noticing it changes the experience of mobile browsing to "scrolling a list". This works fine if your view of the Web is, I dunno, an online order-taking system. That sounds dismissive, but systems like that are great; I'm in favor of anything that saves me from physically shopping. But that's hardly all there is to the Web. I'd like to have a narrow-but-tall page layout sometimes, but I'm not convinced it's a good solution in all cases.
To be fair, I haven't had a chance to use IMP extensively; all I've seen is demos. Maybe they have more flexible solutions in the package that do exactly what I want, which means adaptation to user context as well as screen size.
It says here that InfoGin has partnered with InfoSpace .
Thanks to Rachel for pointing out a column about mobile browsing in today's Washington Post.