|
» Autoscrolling and Reading » Webification of UI » What's all that other software for? » Mobile eBooks and Display Orientation » eBook Formats: html, pdf, text, custom |
|
Subscribe RSS 2.0 feed |
Subscribe Atom feed If you wish to receive email notification, please here » |
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.
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:
- 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 can't use the camera through the browser, and I didn't find a useful web-based way to do reminders when they're tied to specific times -- for example, "wake up, you have a meeting in five minutes".
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.
Just like hardware and software for ebooks, there are tradeoffs in the formatting of the ebook itself. Here's a completely inadequate list; what can you add to it?
- 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.
I just tried opening a PDF book (from TOR) on the iPhone. It opens in the browser but without any pdf-specific tools so (AFAIK) you can scroll but can't go to a specific page. The pages are horizontally wrapped to the screen, so in landscape mode reading is fine -- but this book has maps, and they've disabled zooming (which you can do in CSS, or maybe that's just the way PDFs work on the iPhone). It's not great. I'll try the same book on in an S60 viewer; I expect it will be better in a true PDF application.
I've been fascinated by ebooks for years. It seems like such a good idea to load books I want to read onto some sort of electronic device; easier to carry, less paper production, added interaction...the advantages just seem to go on and on. And yet I have yet to find an ebook solution that really works for me.
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.
My last post touched on the idea of the content owning the UI. Now, some of that is already possible; web pages can control a great deal of the UI you see when you load the page. If a page uses Java, Flash, or Javascript this can go pretty far, but even if you limit yourself to XHTML and CSS you can do a lot.
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.
An operating system doesn't necessarily have to have a user interface; the UI can be provided by a completely separate piece of software. This is pretty well illustrated by the variety of window managers available in Linux; if you want your Linux system to look and feel like Windows, or NextStep, or MacOS, or something different from any of those, you just choose the window manager you want.
Not to get into a too-technical discussion of this, in a metaphorical sense a web browser is like an operating system, and the sites you load are like applications. Different browsers such as IE, Firefox, and Safari provide different degrees to which the content can provide the UI. And also provide different means to do so, which is an ongoing annoyance to web developers.
Mobile browsers, including ours, have lagged behind the desktop in enabling the content to provide the UI. Today you can create a web page that turns off our mouse pointer, but you can't control the options menu, softkeys, or status indicators to any reasonable extent. Here's a modest proposal, which is really just a thought experiment: maybe the content should be able to control a great deal more of the UI. I'm working up some samples of what that might be like.
Years ago, Sun Microsystems came up with the slogan "The Network Is The Computer". It was a great slogan for a Unix hardware company, but it didn't apply very well to The Rest Of Us (obviously I'm thinking in slogans today). Lately, though, it's starting to come true. Nokia just announced Ovi, which the website says is "the door to Nokia internet services." (I don't know any more than you do; not even what "ovi" means).
The key here is that it's a service. This is clearly the wave of the...well, present, I guess, as well as the future. But think about it: from office applications from Google, to software setup from Microsoft, to services from Apple to Nokia to just-about-everybody, now that computing hardware (PCs, laptops, smartphones, PDAs, etc) is better and cheaper than ever, the software is sort of leaving.
I suppose there's nothing wrong with this, although in the words of the Boston Globe (talking about Steampunk hobbyists), "there's something vaguely alienating" about it. Services are more steps removed from me. If the hard drive in my unconnected PC crashes, it's a problem I can work around myself. If I'm using the XYZ Corporation's location-based spreasheet processing entertainment mashup, and something goes wrong somewhere in the network, I can at best call customer service.
The rejoinder I heard years ago to Sun's slogan was usually something like "the network may be the computer, but the network is down!" Hmmm.
We're still in the era of iPhone enthusiasm, so at the moment this will probably sound like a contrarian stance, if not sour grapes. Regardless, here goes. I think touch screens are in most cases inferior to other input systems for computing devices.
Touch-screen input has many disadvantages, but the overwhelming problem is that you can't see what you're touching while you're touching it. The most famous touch screen interface at the moment -- the iPhone -- has a user interface gets around some of this with some dodges that would be properly called "hacks" if they weren't so visually attractive. But hacks they are. In order to input text, a virtual keyboard appears on the screen. Lacking the tactile feedback provided by real keys, you need o see which key you're touching. You can't see the key itself; it's hidden by your fingers. So another key representation appears, this one offset far enough to be visible. But there's a problem with this, too: you have to look. I'd bet that virtually every reader of this blog can send a text message blindfolded. Try that with any touch device.
Touch screens work pretty well when you have a large screen and very trivial levels of interaction such as moving the contents of the entire display or tapping one time on oversized virtual buttons. Personally, I hope S60 doesn't pursue the fashion show in marching toward touch; it's not based on good design.