*cursor here. thanks for throwing tomatoes at pesky human, why no cheese too?*

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

No one's making dedicated e-book readers in such quantity that the price drops to the cost of a paperback — the cost at which the average occasional reader may be tempted to take a flutter on one.

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?"

I find that autoscrolling can work very well for me in two cases: I'm reading for about three to five minutes, and I'm using a device with an excellent screen (an iPhone or an N95, for example). The time constraint is simply about eyestrain; something about reading text that's autoscrolling seems to make my eyes work harder. Maybe some readability experts out there can explain this?

The screen issue is pretty obvious; the text isn't really moving, of course; it's an effect caused by controlling the pixels. With lower resolution, that motion is less "convincing" and I find it a bit distracting.

By the way, an autoscrolling effect can be done in a browser window via JavaScript. There are many libraries available and I haven't enough of them to give a recommendation. If you're interested, search the web for "javascript autoscroll" and you'll get thousands of hits.

If I'm not paying careful attention to very subtle contextual cues about interface objects in Windows, for example, I'm likely to click one time when I should click twice, and vice versa. Using MacOS X is a little bit better, but still tends to be inconsistent about how those little pictures on my screen behave. In Linux, the KDE and Gnome user interfaces are on the same level -- maybe a bit more inconsistent, but I'm not doing a formal study.

S60 has at least as many inconsistencies; maybe more. And with a sparser set of contextual cues, it keeps some of this information more of a "secret" than most desktop UI environments. A mobile system doesn't necessarily have fewer contextual cues or less consistency; that's just the way S60 is at its current stage of development.

Lately I expect an interface I'm using to conform to the underlying user model of the web. Click once to make things work; content usually extends beyond the viewing area and is easily accessible, the semantic portion of the content is distinct from the semiotic portion. (OK, even I don't know what that last sentence means -- my point is simply that you can make the window a different size and shape, or change magnification, and the text you're reading is adapted to those changes. It's just that I've been waiting to use "semantic" and "semiotic" in the same sentence since university. Is it a good thing that my life goals can be so easily accomplished?)

Using a browser is refreshingly simple and easy, and the smaller set of available interactions generally work fine. I'm writing this post in an HTML text entry field -- it's very much like NotePad, but it works just fine. I use text entry fields for a great deal of writing now; I could fire up Word, or for that matter a supercharged XML or SGML editor if I wanted to, but...well, I don't; anything else doesn't make the writing any better (sorry) and just gets in the way.

I also manage the file system of my (miserable excuse for a) website using HTML forms. Same controls I use to pay bills, order books, record events in my calendar, and set up and manage both routers and servers.

Maybe it's self-serving for a browser designer to say this, but the faster we bring the web user model to as many software interfaces as possible, the easier the software is going to be for users.

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?

In January 2008 Skyfire launched, currently in private beta and showing videos of their demo. Based on the open source Gecko engine from Mozilla (which powers Firefox), Skyfire claims to handle all web content, even video and dynamic pages. The client software on the phone is written in a native language (e.g. C++) for performance reasons; it doesn't work on today's MIDP mobile Java platforms that are used by Opera Mini, Teashark, and others. The promise of a full browser solution with all the heavy processing done on the server is exciting, but would of course require enormous server capacity to handle tens of millions of users.

• keep my calendar in any of several web-based calendars (Google, Yahoo, Plaxo, and probably a dozen others)
  
• send and receive email using the web (pharbeson [at] gmail [dot] com, by the way)
  
• send SMS using bigfoot.com
  
• maintain a to-do list
  
• view and edit Office documents using Google docs
  
• listen to music
  
• watch videos
  
• back up data (although most of my data isn't local, so it's already backed up)
  
• maintain and use a contact list -- this is not as well integrated as it could be, but it's possible
  
• read ebooks
  
• subscribe to and read RSS feeds
  
• subscribe to podcasts (although I listen to them without the browser)
  

I didn't try games, reasoning that I don't play mobile games anyway, and I don't know what the native games are like on the phone.

Nearly everything I use my mobile phone for I can do with just underlying software for calls, connections, and the like, and a browser. The one thing I would need to make this scenario viable is to pay a flat rate for data. The implications for the device itself are also important: with the same specifications you free up a lot more memory for browser-related operations. The UI gets vastly simpler and (if you do it right) easier. The bug count automatically drops, simply because there are millions of fewer lines of code. Battery life might take a hit because of the near-constant data connection. Some operations might take a performance hit because they're being performed in (for example) Javascript instead of native code. The history of computing, though, clearly shows that such things are temporary issues.

Imagine that a company wanted to create a phone like this. The advantages might be that with vastly fewer pieces of software, that company could devote more resources to the browser. This would enable them to add browser features and updates faster. They'd be able to use their resources to partner with third party developers, who would find the investment manageable because they're creating web apps.

The one thing that company would have to do would be to partner with carriers so that the user experience of the phone -- which is really the user experience of a phone and its infrastructure -- would include a good model for constant data connection.

All of this is fairly obvious.

So far, Apple has made a major step in this direction, and Google is certainly rumored to be planning an even bigger step. Service providers (carriers) in the US have enormous clout in phone design, and often market devices under their own brand names. They're anything but innovative, but I'm sure that there are some people in those companies making exactly these points.

I just spent the past couple of days reading The Wizard of Oz and Treasure Island on mobile devices -- very unadorned Project Gutenberg editions, rendered in a browser -- and to my surprise I've decided I prefer portrait orientation.

The line length in portrait orientation are very short; averaging only around 8-10 words, and I thought at first that this would be a problem. In fact, when I'm reviewing ebook reading software, it does strike me as a problem. As sometimes happens, though, my "reviewer mindset" wasn't successful in replicating my "user mindset".

As I got involved in the text itself (which, by the way, isn't that easy with Dorothy and the Wizard in Oz; it's written in a fairly heavy-handed "1930s children's literature" style), the line length became completely transparent. I found I preferred portrait orientation because I could scroll (or page) further, and seemingly less often. You'd think I would have to scroll about equally -- maybe I really did, but in landscape it was more intrusive.

I still find the ebook reading experience less satisfying than with a paper book, but it's getting better. I've found, by the way, a couple of really interesting approaches by publishers to the whole electronic book arena. Harlequin publishes romance novels, and has a fairly new and very comprehensive web presence. Tor publishes science fiction novels, and is currently giving away ebooks (sign up for the newsletter). If one of these genres appealing, check them out.

For publishing aficionados, there's some great information online from O'Reilly's recently concluded Tools of Change conference. One I found worthwhile: I Had No Idea My Phone Could Do That! by Sophia Stuart from Hearst Digital Media.

• Plain Text -- can be paired pretty well with browser-based display. Depends a great deal on the reader software's ability to wrap lines of plain text in a useful way. Project Gutenberg has thousands of free books available in plain text.
  
• Tagged Text -- the canonical example is html, but there are other tagging languages. Can work really well, but depends on the quality and consistency of the tagging. Depends on the type of text you want to read, too. If the book has tables, for example, plain text usually isn't sufficient and you need some tagging to add structure.
  
• Acrobat (PDF) -- this works reasonably well on desktop displays because it usually attempts to mimic printed text as closely as possible. Although handheld devices can deal with PDF files, the problem is that PDF's underlying model is "the page" -- in other words, the white space around the text is assumed to be just as important as the text itself. Not what you want on a handheld display. However, if you need to see graphically displayed information, and your PDF reader has good zooming capabilities, PDF can work pretty well. It also occurs to me that you could create a PDF file specifically to be read on a mobile device -- I've never seen one, but it won't be hard to create one to try. I'll give it a try and post the results this coming week.
  

• iPhone (excellent screen but some of the ebook readers aren't very good -- aside from mine, of course :-)
  
• E90 (very good, but I found the screen either too wide and short or too narrow in portrait mode)
  
• N80 (very good, but just not enough screen area)
  
• N800 (better screen size but I just find the N800 software awkward compared to S60 -- remember that I use S60 devices all day, every day!)
  
• a PanTech phone, but I don't know the model. Windows Mobile device. (screen was lower resolution; eyestrain set in quickly)
  
• Nokia Series 40 device [I had the number wrong, as one commenter astutely noticed!] -- (very elegant little thing, but the screen is just too small for reading for very long)
  
• Dell Latitude laptop (screen is fabulous for reading but battery life and weight/form factor are killers)
  

I haven't used an N95 long enough at a single stretch to try reading; I'll have to see if I can talk somebody out of one for a weekend. And somebody in Nokia must have a Kindle or a Sony Reader or both. (That they'd loan to a small design team with a larcenous rodent skulking around.)

One issue is hardware.

I have a laptop with an excellent display, and it's easily high enough resolution for reading. But the device itself, a large clamshell really intended to sit open in front of you on a desk, doesn't work very well in many situations where I just want to read. It gets hot. The battery life is only 3-4 hours. It's expensive and has its own special briefcase, and I'm not about to toss it into a bag of other junk to take with me.

I've looked at the Sony Reader and (pictures of) the Amazon Kindle. The screens are pretty good, battery life is said to be excellent, and the combination of price and ruggedness is getting close to the right combination. But they're not as portable as I'd like, and on an electronic device I find it irritating that the "page" still exists -- only now as an interface metaphor. It's like an automobile from a century ago including a holder for your buggy whip. (As an aside, the Kindle comes with a cellular connection. Nothing to do with calls; it's just for data, and the end user doesn't pay anything extra.)

For some reason, I can occasionally find a mobile phone with a pretty good screen. These are much more portable, have better battery life, don't get (quite) as hot as a laptop, and fit in my pocket. On the other hand, even though the screen is high resolution it's still too small for reading for very long. Still, I think this is a pretty good solution, at least for now. A phone with a bigger screen would be nice, if the hardware guys are listening. There are several ebook readers available, but actually I think the browser does a better job than any of them. I'll go into more detail about this in the next post.

I was about to say "but that's not the part of the UI I meant", but that begs the question of whether the user experience of using a web page on a mobile device can be meaningfully parsed into a UI that has qualitatively different categories. Different "parts", so to speak. I think it has three: system UI, application UI, and content UI.

In the desktop/laptop world graphic design is used to keep these kinds of functions distinct. Functions are placed in different locations in an attempt to show both similarity between items in one area, and differences among groups of items. I'm not sure this approach still works particularly well after nearly three decades, but it's firmly in place.

In S60 we still have the same three categories of functions, but we can't rely on graphic location to distinguish them. Not until we have considerably larger displays, at least. So we rely a little bit on location, a little bit on the process you follow to get to a location, and a little bit on each of several other guideposts: labeling, appearance, order, and so on. Of course there might be those who point out that in S60 we distinguish categories of functions by A. "can usually be found", B. "can occasionally be figured out", and C. "if you find this by accident don't think you'll ever find out how" -- but I digress.

Web content already owns a fair amount of the "content" category of UI. There are some serious security concerns about opening up the "system" category of UI to web content. The interesting -- and, I think reasonable -- area to consider is "application UI".

In S60, "application UI" includes things like what you see in the Options menu, whether there even is an Options menu, how you can manipulate your view of the content (zooming, panning, scrolling, etc.) and things like that. That's the category of UI that I think can be considered as reasonable candidates for content-control. Not every website would assume such control -- not every site uses Javascript or CSS, either. But those that do can provide a pretty compelling experience.