S60 Open to new features

I've been assuming that readers of this blog probably know things like this already, but maybe not. Did you know the WBfS60 (the marketing guys are probably going to come after me for that sobriquet) supports the file scheme? That is, if you create a folder called "web" on your phone's memory card, and put an html file named "foo.html" in it, you can choose Go To Address in the browser, enter file://e:/web/foo.html and your internal-to-the-phone web page appears. Not the most useful thing in the world, but it can be handy.

Designing a website for a mobile browser means you’re working with some additional constraints. To focus on an obvious one, the display is tiny. With such a small display, you have very little margin of error in page layout.

Just for the sake of discussion, let’s say you want to place a navigation bar at the bottom of your pages. If you need that navigation bar visible as soon as the page opens, that means you’re limited to fewer than 10 lines of text per page. And they’re short lines, too. It depends on the screen size of the user’s device, the font size they prefer, and last but certainly not least, the browser in use. Let’s make it easy and assume your users all have, say, Nokia N80 phones (we should be so lucky) and use our browser with the default font size setting. That means if you don’t want them to have to scroll, you have only about 70 words per page, at best. And no room for graphics other than in the background.

It doesn’t take long to conclude that scrolling is going to be quite necessary on mobile pages. 70 words is not very many; it took me over 150 just to find my way out of the previous paragraph. So if you really can’t design pages to both fit a tiny display and be more than minimally useful, what to do?

In any mobile browser you’re going to see the whole page as a series of tiny "pieces" of a page. One of the things you have to work with, then, is time. You know the user’s first view of a page is going to be the upper left corner. The same page, when viewed on a ponderous screen, still has that upper left corner, but it’s nowhere near as important. That makes the upper left corner the "hot corner" of your page; you know the user's attention is going to be concentrated there at first.

How about making use of that corner in a way that benefits the mobile user without hindering the desktop user? A small site map, or table of contents, would give the mobile browser an immediate way to navigate to the choicest content. The little map would still be available to the desktop user, but it's out of the way. It won't spoil your page design, and it probably won't be used. After all, you’ve got pixels to burn in a desktop situation, and can highlight what you want in many different ways.

I can't affect the overall layout of this site (at least I don't think I can), but I've done some informal tests and I think the "hot corner" has some potential.

In the next installment, more ideas for mobile designers.

Sometimes you find an artifact, whether software or something material, that has great "depth of design". What I mean by that is not easy to explain, but I know it when I see it. Something with great depth of design rewards attention, study, and use. As you use a thing, it becomes more familiar. If its design is deep, that familiarity is rewarding; you discover things that are just "right" no matter how far you go with it.

Scott Berkun talks about something like this that he found in (gulp) a Japanese sword. Edward Tufte's books are very much about this quality. Not only that, but his books themselves tend to have the quality of design depth.

One of the first examples of design depth I ever found in a complex artifact was an automobile. I've mentioned before that I enjoy doing my own maintenance and repair work on cars, and I once owned a 1977 SAAB 99. The deeper I got into that car the more I found design details that I liked. At some level, that made it a very good car (particularly for the 1970s, hardly the acme of automobile technology). But it was also very pleasing to find these things; the design and positioning of components, the design of a subsystem, and so on.

There's depth of design in software as well. Here I'm primarily talking about user interfaces, as the underlying design isn't always easy to see or appreciate. I think Microsoft Excel is an example of fairly deep design. Things "make sense" down to a relatively low level. This is particularly impressive given the "feature mania" Excel went through a few years ago, I suppose when they still had significant competitors. Adding too many features dragged down the overall design of Excel, but not too badly.

Our browser, I think, has a certain depth of UI design, but not enough. At the top level, I think the design works very well. If you go down to the smaller details in some areas, though, the clean design starts to look pretty smudged. We're not even close to done with this browser.

There are at least two aspects of design depth in software user interfaces: the details and the pattern. The details have to make sense, include the things you need, exclude the things you don't, and work understandably (which is usually, but not always, the same as working consistently). The pattern is the way all those details are put together, and I think of it a little bit like the HTML rules for nesting multiple elements. The pattern should be based on consistent design principles, and those principles should be able to emerge from the implementation. That is, if you're experienced using a piece of good software UI, you'd probably be able to articulate the principles just from that use. Our browser isn't quite there yet, but we're on the right track, I think.

You probably know what Google Bombing is. Reprehensible manipulation, many would say. But in this case I think it's a great cause. See this link for why.

--Franklin

Martin Luther King Jr. - Wikipedia
The King Center
The Martin Luther King You Don't See on TV
Martin Luther King - Biography - Nobel Prize site
The Seattle Times: Martin Luther King Jr.
Time 00: Martin Luther King Jr.
Dissing the King - Salon
Dr. King Timeone
The Martin Luther King Jr., Research and Education Institute

Now that we have a pretty good browser you can really keep in your pocket, I've been experimenting with using it (or trying to remember to use it) in places I normally wouldn't use a browser.

Here's the oddest I have so far. I enjoy working on automobiles; some people (really just my daughter) accuse me of driving a 10-year-old car because I'm a coldhearted miser who refuses to spend the money to get a car with a built-in DVD player like some people (guess who) think he should. But it's really because I find new cars boring; I have a garage full of tools and there's never anything to be done to a new car.

Last weekend my car's onboard computer (it's not that old a car) reported a problem in its typically taciturn way (oops, there's a problem, better flick that light on again). I read the error code (by the way, there are error code readers for Palm hardware, but why can't I find one for S60?). A leak in a vacuum hose. Oh good, there are only 4 or 5 dozen vacuum hoses routed everywhere.

This time while I was looking around the engine, I opened the browser and checked a website for hobbyists with similar cars. Somebody had posted a question about the same problem, and there was a simple troubleshooting procedure to follow to find the source of the problem, and some tips for where to look. And sure enough, the rubber vaccuum hoses on my car are starting to harden with age, and one had simply slipped loose. New hose, problem solved, thanks to a pocket-sized browser with an "everywhere" connection. By the way, if you actually try this, put your S60 in a clear plastic bag first or you might get grease on it!

Can you name an even odder place you've used our browser?

In his excellent book The Professor and the Madman, Simon Winchester makes a obvious but important point. Shakespeare couldn't look anything up in a dictionary. Not only were there no dictionaries; the whole notion of "looking something up" didn't exist back then.

In an even earlier day (although not as much earlier as you might think), Johannes Gutenberg couldn't buy a book that was just the same as any other. Books, in those days, were handmade, one-off items.

Both the creation of the dictionary and the creation of movable type vastly changed the world for many people. Web browsing has changed the world too, although I don't pretend to know whether it's nearly as big a change. The question I've been toying with lately, is this: is the browser "movable type", or is it "the dictionary"? Or is it something more subtle, like what Aldus Manutius did in creating the octavo book that was easy to carry and (relatively) affordable? I don't have an answer; I'm just wondering about it.

The notion of bookmarks, or favorites, seems to be part of every web browser I've ever seen. And yet, as Scott Berkun puts it, "favorites are dumb as rocks". They're shortcuts that many people use to return to sites they've visited before, but there are other ways to do that, too. You can use your history list, in our browser you can use automatic bookmarks ("persistent history", sort of), or you can do something I've seen in several usability tests: remember (or bookmark) one site that you know will lead you to the other sites you really want.

This last strategy is interesting because it quickly illustrates something about how people use some bookmarks -- they don't want to go the exactly the same site; they want new information that fits the pattern they recognize from their previous visit. You don't want to read the same news story about the large ball of twine discovered in the arctic, but you liked the general topic, the presentation, the writing, and so forth. To use a newspaper as a metaphor, you might have a favorite paper (the Morning Spew, for example), and always read the Twine Insights department on page 13, but you don't want to read the November 21 edition over and over.

Website designers face this issue constantly: users want variety within a familiar pattern or framework. At the level of browser design, we face the same thing. The content can be infinitely variable, but the "holder" of the content -- the browser -- stays very familiar. And yet, as we add new features and improve old ones, the browser must provide variety as well.

Different people, of course, have different desires for variety and familiarity in a browser. And that's yet another level of design challenge: providing individual variety within a broadly familiar framework. At the moment we're basically limited to changing the display properties of individual pages and the general settings of the browser itself. This is very similar to desktop browsers. I'm not sure, though, that this model is going to be viable much longer. People use browsers in enormously different ways, and we're going to need to revisit the balance between variety and familiarity in new ways.

Cursor here. Blog getting dumb; start writing about other blog. Cursor not interested. Guess humans read anything.

Good news for Cursor tonight. Humans order dinner sometimes. Tonight Chinese food. If Cursor quick, Cursor get some too. Chinese food very good. Needs more cheese though.

Over at the S60 Multimedia Blog, Oren mentioned a music video filmed entirely with an S60. Apparently there's also a Boston University class in mobile filmmaking. This reminded me of something I've considered from time to time, without really getting anywhere with the idea: software design is like filmmaking.

At least the two are alike in many ways. Film is a stream of events. Although each set and situation is important, you want to think mostly about that stream rather than getting stuck in just one frame. Software UI is like that too. You're designing a stream of possible experiences for users. You can get stuck in just one "frame" here, too -- for instance, I think a lot about the Options menu and its various states and constituent items. It's possible to get stuck on a set of items and fruitlessly struggle to get it "just right". But some states and items just don't make a lot of sense if the user hasn't proceeded through a stream of events to get there.

A big thing to avoid, in UI design, is arriving at a state or a "scene" out of sequence. It's confusing if "Save Download" appears as an option before there's a download to save. Similarly, in a movie, every scene has to proceed from the previous scene and to the next scene. When the hero suddenly pulls out a revolver he never seemed to have before, and we never saw him get it from somewhere, it gets pretty difficult to suspend our disbelief. In short, we stop believing the movie.

UI design and filmmaking even have some tools in common: storyboards, scripts, and the like. Even walkthroughs. And both a film and a browsing session have a beginning, a middle, and an end. In film, there's more closure in a literary sense. In browsing, there's more (or can be more) of a concrete outcome. You find the information you want, for example.

The problem, for me, is that while this is a fascinating juxtaposition of two creative processes, I've never been able to really glean anything useful from it. If I think of browsing sessions as films, it just doesn't seem to help me design the browser UI any better. It hasn't made my amateur movies any better, either.

Is it me? Am I missing something crucial? Or is this just another interesting comparison on the order of "An Ogre is like an onion"?

Here's a question that's been coming up lately, in blog comments as well as some other places.

Is the Web browser for S60 a mobile browser?

And here's the answer, which may surprise you: no, it's not. It's just a browser. Our browser acts like a desktop (technically, we support the "screen" media type in CSS). If you create a website in the new ".mobi" domain, we'll be glad to render it just like we render any website. This is the way desktop browsers behave.

S60 devices are pretty obviously mobile, of course. You're going to be using this browswer on a device you hold in your hand. In that sense, the S60 browser is "mobile". But in terms of interacting with the world-wide web in any unique way, our browser is, very consciously, not a mobile browser. One of the most fundamental design decisions concerning this browser is that it's not at all directed at anything that might be called the "mobile web".

When I use "mobile web" here, I'm referring to part of the web. Some websites are designed to adapt to very constrained browsers. There's not just one website at their address, there are two or more. The site you probably think of as "the site" is designed for desktop or laptop computers with fast connections, color screens that display graphics, user-input systems such as keyboards and mice, lots of RAM, lots of offline storage, and output options including printing. Then there's the "mobile site", which is especially for tiny screens, limited input, limited RAM, slow connections, and slow processing.

I'm not suggesting there's anything at all wrong with creating a site just for mobile devices; there are perfectly valid reasons to do that, and users of some mobile devices prefer those sites. Arguments range far and wide among web designers, browser designers, and others about the "mobile web", whether it exists, whether it's useful, and so on. But this project, the Web Browser for S60, is all about making the best browsing experience on an S60 device, and if all you can access is the "mobile web", there's very little about that (at the moment, at least) that could be described as "best".

We don't have the only possible answer to this question. There are other browsers that work on handheld devices (some even on S60 handheld devices) that do present themselves to websites as "mobile browsers". Just not this one. Our browser is not a mobile browser. It's not a desktop browser. It's a web browser.

Imagine the Web Browser for S60 suddenly available on your favorite computer desktop. I'm not talking about porting it, or rewriting it; just wave a magic mouse and there it is. It runs, but it's completely unchanged. What translates well, and what doesn't? After all, we're constantly thinking in the other direction, as in "Firefox does this" or "Internet Explorer does that".

First of all, our browser wouldn't do a very good job of making use of the rich collection of user input capabilities your desktop machine offers. A full keyboard, a separate pointing device with one or more buttons, special keys for faster scrolling, and the like. The basic S60 environment is radically constrained in terms of user input; we've got a few buttons and some sort of joystick or directional rocker key, and that's about it.

We don't support some services you find on desktop systems, such as printing. On the other hand, the browser would be ready the moment your desktop system received a mobile call!

The S60 browser is designed for a world that doesn't have the inherent layering built into a windowing OS; that is, the display doesn't have special areas that belong to the content, browser controls (such as a menu bar), and the underlying system. A windowing system is spatial, while the S50 system is only partially so.

I think the biggest issue in imagining our browser in a desktop environment is the layering problem. You could probably use a browser on your desktop system with a much-reduced input system. Imagine your keyboard partially disabled (if you have trouble imagining this, I'll send Cursor over to "help"; you wouldn't believe what he did...well, never mind). But when our browser ran on your desktop, it would commandeer the entire display area. There wouldn't be anything that worked as a control layer. I think this would be the major usability problem. You would be instantly transported back to pre-windowing interfaces, where each application owned the entire display, and any system-level commands were the responsibility of the application.

Switching back to our comfortable handheld world for a moment, think about the one control area we have available: the Options menu. In a pre-windowing way, it belongs to the browser, not to the OS. We can include "outside the browser" commands, and we do, but it really works more like issuing system commands from emacs or vi than using a windowing system. Not that there's anything wrong with that; emacs in particular is an enormously powerful tool (although it now works in a windowing UI). But it makes our UI more difficult to understand and master, particularly for the part of our audience that's used to windowing systems.

Underlying this argument are two assumptions: windowing UIs are more usable than their predecessors, and it's not just because of the mouse or the nice graphics. It's because of the conceptual hierarchy built in. The system, applications, and services coexist in a logical, clear structure that's reinforced visually and behaviorally.

One of the keys to effective S60 UI development is to compensate for the lack of meaningful layering in the underlying UI. The more we master that, the more usable any S60 application will be.

Oh, and by the way, don't go starting any rumors about a desktop version of our browser! The closest you can get is Safari or maybe Konqueror. Feel free, however, to start any rumors you want about there being a magic mouse somewhere in S60...

We've received quite a number of comments and questions, some of which are pretty technical. I'm not a developer, and hopefully there are some other resources available to address issues like these. Here are some:

Forum Nokia has SDKs (Software Development Kits) for Symbian, Java, and the like. You can also find discussion forums at Forum Nokia.

Nokia has an open-source software site that includes an area dealing with the browser. This is less interactive than the Forum Nokia discussions, but there's a lot of material available.

Finally, S60.com has developer support, too. Hopefully the answers everyone needs will be in at least one of those places.

On an unrelated note, our marketing folks asked me to be more consistent about the terms I use for the browser. So if you notice me calling it anything other than "Web Browser for S60", send a nastygram! I'm going to do my best to avoid calling it...er...well, what I've called it before. A bit of inside information though: just about everybody here, including the marketing folks, wishes the Web Browser for S60 just had a real name. You know, like Firefox, Safari, or Opera!

Emergence is, as I understand it, a process in which simple things combine in complex ways. That's probably an oversimplification, but it works for me. There's a good Wikipedia page about emergence, including some fascinating references. If you take a very broad view of software development, I think it could be described as having emergent properties. Maybe it's a stretch, as the constituent parts of software development are not generally regarded as simple, and there's a lot of purpose involved. But for the sake of argument, let's say there are some emergent properties involved in software development as a whole.

Convergence is an "approach toard a definite value" or a common opinion. It can be another way to look at the same processes examined for emergence. For instance, a complex structure emerges from the individual behavior of ants in a colony, and the behavior of ants in a population converges toward a "standard ant", so to speak. Software development shows convergence, too. Take any popular category of software, from word processors to pocket calculators. Every word processor looks pretty much like every other word processor, and while I have an old HP calculator that uses RPN, nowadays that's getting to be pretty unusual (especially since I could buy a brand-new calculator for less than the cost of the batteries in my HP). Also I can't remember the last time I actually used a standalone calculator even though I have some. But I digress.

The point I'm working toward here is that the world of browsers exhibits both emergence and convergence. There's emergence in the sense that new functionality appears in browsers, and convergence in the sense that all browsers are pretty much the same except for the details. There have been browsers with very different features and properties -- does anyone remember "Cyberdog" from Apple, years ago?

I'm not sure whether emergence and convergence are "forces", exactly, or just descriptions of aggregate activity. They're easier to talk about as forces, so I will for now. These two forces act in different "directions" on browsers. I find the S60 OSS browser particularly fascinating from this perspective because both of these forces have acted especially strongly on our browser. I think most people agree that we have some features that are pretty new and innovative. From a "world of browsers" perspective, these complexities have very recently emerged. And yet they've emerged, in large part, because of convergence! The intent of our browser is to be a desktop browser, not a "handheld browser". It just happens to be a desktop browser on a very small device.

This is fairly subversive, in some ways. We're implicitly rejecting the idea of a "mobile web". "The web is the web," our design says, "and you shouldn't have to care whether you're using a big screen or a little one. We think convergence trumps emergence at this level. But at the level of the device itself, we're interested in emergence. The basic functional components of an S60 device differ (a little) from the basic components of a computer. Change the components, and the emergent properties change, at least in theory. So what we're really doing is designing a great desktop browser tailored to a handheld device.

What's really going on is that we're putting ideas together in a slightly different way, and seeing what comes out of that. It probably does make us a bit of a "bunch of wackos", as one commenter put it! I guess that would be more emergent than convergent -- it's also a lot of fun.

Cursor here.

This is one of those questions that seems trivial at first glance, but takes on more significance the more you consider it. Why is a web browser called a "browser" at all?

Browsing, before the Web era, meant perusing, skimming, just looking at. It connoted something relaxed, nonspecific, and relatively unimportant. You'd be more likely to say you were "just browsing" than to reserve 10:00 to 11:00 for "browsing" as a task in itself. You'd browse through People magazine, but you'd be more likely to read, study, or consult a "serious text." Not that I'm suggesting that there's anything frivolous about Britney, Paris, or Tom!

At some point the term browsing came into use for computer software that let you peruse some set of "things". There are file browsers, database browsers, and, of course, web browsers.

In the process of UI design, it's often useful to explore connotations -- in this case, connotations of the term we use. If we used a different term, how would that impact our design decisions? Would we go in different directions if we were designing the S60 Research Assistant? The S60 Page Viewer? How about the S60 Server Object Loader?

Although a great deal of web browsing today is anything but relaxed, nonspecific, and unimportant, I think it's pretty significant that we still call it "browsing". The connotation of a relaxed, noncritical activity constantly prods us to keep the user interface easy -- something you don't have to work at; something that has a certain element of fun and leisure.

When you design software with a serious, work-related intent, you're often more willing to expect that the user will make more of an investment in learning the software. If finding information in a database is part of your job, you'll do your best to learn to use it. But "browsing"...well, that's something you do because you want to. So software that makes that possible should be clear and easy for everyone, right?

I have a pet theory (and there's a connotation too: a relaxed, noncritical set of ideas I like to think about but probably wouldn't explore in a rigorous way) that you can predict something about the adoption of new ideas purely by the language used to describe them, and how well the language fits the context of use. "Browser" is really an exceptionally good term. Some associated terms are equally good. "Link" (much better than "cross reference"). "Home page" (much better than "default view"). But there are some that I wonder about. Anyone want to predict the lifespan of terms like "Plugin", "RSS", or even the currently fashionable "AJAX"?

Thanks for the comments, everyone. Here are some responses.

Browser team in Boston

It's true, most of us are in the US. Not everybody, though. We have associates in India and Europe. All we need is the right combination of...well, I'm not completely sure what that combination is, but as one commenter said, it definitely includes wackiness!

Browser availability

The S60 browser doesn't currently work on older S60 phones. I don't personally know if there are any plans in that direction, although we're already very busy without any additional porting or support projects to address. Keep in mind, though, that it is an open source browser, so it's quite possible that our little development group won't be the only source of cool S60 browser code. Have a look at the Browser Open Source site, for more info.

S60 Browser and Safari

Dani asked about Safari -- that's not the same as our browser, but it's on the same family tree. Safari is the web browser from Apple Computer. It's based on the same open-source code as the S60 browser. Have a look at the Webkit OSS project site for more info.

Browser features requests

Keep them coming! It sounds like better page-oriented scrolling, as well as a home/end function and text selection and copying, would be useful additions. I can't comment on what we're planning, but we hear you.

Cursor

I've gotten a number of requests to meet Cursor the Virtual Mouse (the Browser group's unofficial mascot). He's not the most obedient fellow, though. In fact, as I think about it, he may be a candidate for the least obedient fellow. But I'll see what I can do.

A natural part of designing something -- almost anything, I suppose -- is looking around for inspiration. How did somebody else do this? How has this problem been solved before? What already works, and what could work better?

Every design and development group probably does this. I'm sure there's a department deep inside Toyota that buys the latest Honda, and vice versa. We're no different; we look at browsers all the time. In a previous post I mentioned that one of the goals around here is for other browser design groups to say "let's do this the way that S60 browser did; that works really well."

Some design groups are good at looking further afield for inspiration. I once read that years ago at Apple Computer, Steve Jobs parked a BMW motorcycle in the lobby of the building where development was proceeding toward what became the Macintosh. Not because they were designing the first internal-combustion computer (I guess that came much later and had to do with laptop batteries...) but because there was something the motorcycle could offer as inspiration. I don't know exactly what it was -- maybe just the fact that some products, whether motorcycles or computers, could be so coveted they commanded a higher price.

When I think about our browser, and what it should "be like", I try also to cast my mental nets further afield than just other browsers. To pick on Apple again, iTunes is a pretty good application -- can it suggest anything about our browser? Even stranger (maybe I've had too much coffee), if we used Lego blocks as inspiration, our browser would be almost infinitely configurable. Or possibly it would come in a bag. If we're inspired by a busy coffee shop, maybe our browser would have a "focus" (like the screen of your laptop), and a "periphery" with semirandom information (like the conversations going on around you).

There's no need to limit your sources of inspiration, of course. The examples I've mentioned, possibly excluding the coffee shop, are very common. I'd wager that Legos and iPods are mentioned these days in every design group in the world, almost no matter what their actual product focus. This is, iteslf, fascinating, and I'll say more about it later. Think "emergent properties" and "recursiveness".

And by the way, has anybody seen that extra phone I thought I left in my drawer the other day? The things keep disappearing for some reason, especially the black ones.

Cursor here. Very good week. Humans bring candy from hollow ween. Don't know what a ween is. Humans don't notice missing candy.

OK, human coming back. Cursor hide. Bye.