|
» Whoa there! » Radical Simplicity and Complexifiers » Dedicated Hardware Considered Unlikely » Web location and Physical location » Autoscrolling and Reading |
|
Subscribe RSS 2.0 feed |
Subscribe Atom feed If you wish to receive email notification, please here » |
OK, (ouch) everybody out there (bonk) in the blogosphere just (oof) take a deep (splat) breath! We are not backing away from Webkit no matter what you might have read on one of those new-fangled "website" things -- I'll have to get somebody to show me one sometime soon. As I understand it, one of our developers did some housekeeping on the Tiger branch of the webkit project, and some people thought it looked like we were backing away from the whole open-source project. No, no, no -- it's just that we're focusing on the newer Leopard branch, we have a lot on our plates right now (you might have heard about Nokia's acquisition of Trolltech, for example) and there's only so much we can do at once. It's not that we don't appreciate the attention, of course, but any talk about S60 Browser backing away from Webkit isn't true. Gotta run; just heard Elvis was spotted in Boston Commons...
*cursor here. thanks for throwing tomatoes at pesky human, why no cheese too?*
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! :-)
It's interesting to think about the possibilities around a piece of hardware dedicated to reading ebooks, and fun to play with design possibilities. When it comes right down to it, though, like most people I don't have one. I don't even have any plans to get one unless the price comes down drastically; I like reading ebooks, but I already have a mobile phone (okay, I have about six) and a laptop, and those work fine. Not perfectly, perhaps, but good enough for me. Author Cory Doctorow addresses this in his Locus Magazine essay:
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.
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 a feature of some ebook readers that I have a mixed reaction to: autoscrolling. Autoscrolling is simply automatically moving the content so you don't have to scroll or page through it manually.
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.
Do you ever click on an item in a piece of software (any software, from an OS to an application) and find that the program doesn't respond as you expect? This happens to me all the time, particularly when I have my "UI Designer" hat on (yes, it has a little helicopter rotor on the top) and I'm thinking about how actions and interface objects should be consistent. (No, I'm not posting a photo of me wearing this hat).
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.
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?
An update to my August 07 post on mobile browsing proxies, adding Skyfire:
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.
I decided to see how much I could do with my mobile without using any software other than making/receiving calls and using the browser. The answer is: almost everything I need or want to do. Here's what I can do with 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.
Many (maybe all) mobile ebook readers allow you to read with the screen in portrait orientation (taller) or landscape orientation (wider). I've generally assumed that because mobile displays are so narrow, most people would prefer landscape orientation. Including me, I thought.
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.
