|
» Web location and Physical location » Autoscrolling and Reading » Webification of UI » Is a Browser Defined by its Protocol? » More on browsing proxies |
|
Subscribe RSS 2.0 feed |
Subscribe Atom feed If you wish to receive email notification, please here » |
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:
- 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.
Comments are now fixed. Sorry for the interruption!
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.
OK, quick poll; who else has read ebooks on mobile devices? I've tried:
- 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.)
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.
Cursor here. New year, new portrait. Do these whiskers make me look fat?
Browser humans running around, very busy. Almost got stepped on today. New human left lunch on desk. Thanks, was good. This thing fun, Cursor likes it.
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.
