S60 Open to new features

Years ago I read the phrase "intuitive just means you learned it somewhere else". I don't recall who said this and can't seem to find it -- if you know, drop me a note!

One of the most important things to me about designing user interfaces is trying to figure out if an audience of users has already learned something, and where they learned it. "Where they learned it" is important because that may determine whether the users will bring that particular piece of intuition into play in relation to the design.

You usually want your designs to be "intuitive". If a design is not "intuitive", designers are told, it's not a success. In design reviews, "intuitive" is frequently an important criterion. This is generally a pretty good idea; if users can use your design right away without pausing to figure it out first, so much the better.

There are many levels of "intuitive", though, and these have to do with where you learned something. As humans we have enormous implilcit understanding of mass and gravity; that's why we can toss a ball accurately (or semi-accurately in my case) and how you know by looking whether to try jumping a certain distance. As inhabitants of high-tech civilization we have a lot of implicit understanding of graphic user interface, and that's why we don't expect an object on a screen -- in most contexts -- to drop to the bottom because it's "heavy". In fact, even more than that, we even know that in some contexts, such as certain games, we do expect objects to have mass and react as if there was gravity.

When you see a new user interface, sometimes there's a little "aha!" moment. Something surprises you, and at the same time seems suddenly obvious. I think that moment represents a realization that you can bring a different intuition into play in a context you already understood in a different way.

Intuitive design is about ease of use. Counterintuitive design -- done really well -- is about aha.

"Simplify, simplify."
-Henry David Thoreau

"Everything should be made as simple as possible, but not one bit simpler."
Albert Einstein

Simplicity is one of the ideals we try to attain when designing the browser user interface. A reaction I'd like to evoke in browser users is "that was easy!" In general, easy is often associated with simple.

It's not always easy to pin down "simplicity" though. For one thing, it's very subjective. When you're accustomed to doing something in a particular way with specific tools, you come to regard it as simple. Introduce someone else to the process, though, and they may have a very different opinion. Not because you're smarter or more capable then this neophyte (it goes without saying that you are, of course, but one tries to be nice :-), it's because you have different knowledge.

The knowledge you rely on to determine what's "simple" includes things you may not regard as explicit knowledge. Hand your mobile to anyone you know and ask them to call a number. Most of them will find it "simple". Hand the same mobile to someone who's never seen a phone and the task isn't simple at all. The task is exactly the same; it's the user that's different. Although if asked to list all the things you know, you might not include "how to use a mobile phone"; it's something we tend to assume.

We design for simplicity, then, for a particular collection of users. Mobile phones are inherently complex devices, and some of the tasks users want to do are also very complex, so sometimes we "hide" the complexity, or put it somewhere else. John Maeda in his book The Laws of Simplicity talks about this, and says (simply!) that "some things can never be made simple." But many things can, and as Rob Tannen notes at Boxes and Arrows: This does not mean that things cannot be made simpler.

Given time (which means time left alone, and stop bothering me about those TPS reports) designers can often do a pretty good job with simplicity. So what's the problem? Why are S60 devices widely regarded as the opposite of simple? There isn't just one answer, of course, but a big one harks back to where I started: when you design for simplicity you aim at a particular collection of users. S60 has an astonishingly wide array of users, and while S60 devices may be marketed to them on the basis of fairly cohesive groups with a lot of similarity, they're not (yet) designed that way. You'll be able to immediately think of some ways each of these would be unique: a kids' browser, a university students' browser, a European professional's browser, an Indian entrepreneur's browser, an African health care worker's browser, and a Chinese urban dweller's browser. I can too, but even working at The Browsary we can't create all those products.

Not yet anyway. Once, the story goes, the Model T Ford was available in whatever color you wanted, as long as you wanted black. Today cars are nearly made to order; one car is likely to be quite different from another even while both are clearly identifiable as cars. I think the days of "idustrial-model" software -- one version for everybody, limited customization that you have to do yourself (and it's not simple!) -- are numbered. It's actually fairly curious that the industrial model came to be applied to software, where it (arguably) doesn't apply particularly well.

Want to call us and order a browser with the UI and features you like? I'd love to take that call and fill that order -- just wait a while; I have these TPS reports that need cover sheets...

A lot of the web is all about removing context. Digital content can be reused -- "repurposed", in the clumsier corporate argot. Here is a good cinematic treatment of the idea. This is certainly what browsers are about. If a web page can be said to have "a design", browsers don't really present that design so much as present an interpretation of the ideas behind the design.

If anything, this is an even stronger characteristic of browsers, like the S60 browser, that are designed for devices with unique characteristics. In our case the display is small and the input is limited. But you could imagine something using, for example, a monochrome vector display that would still be recognizable as a "web browser". In that case the characteristics of the device would be unique in a different way. You could even imagine a web browser that used a really unusual display mechanism. How about using a web page as a map for planting a flower garden? You plant the seeds and a few months later the flowers bloom and from above you can see the "page". Talk about latency...

Web designers generally accept the fact that their page designs are more like guidelines, and even celebrate it. It's certainly different, and in many cases exciting (empowering?) to create things in a dynamic medium. You can go the other way, too. As a designer or artist, you might decide that a work you want to convey depends not just on the words "this is not a pipe", but on those words being presented in a particular typeface in a particular size, color, and position. You can do that, but when you do, "the web" doesn't work quite as well. To control those things completely you might resort to one big jpg file instead of any text at all. You can certainly do that, of course, but there are costs. Searchability is one, and page size (and thus loading time, particularly on a mobile) is another. Art and communication are nothing if not sets of combined compromises, after all. And yet...

A big thing about the web is deconstruction. Let's call it "dismantling" to get away from any connotations of the term. A web page is called a "page" because it resembles a page in a book or newspaper. (That is why it's called a page, isn't it? Seems obvious, but I've been wrong before.) The characteristics of a printed page include words, typeface, size, absolute position, position relative to other items on the page, and sometimes various kinds of pictures. A printed page includes all those things together; they have fixed interrelationships. The page has its own context. A web page dismantles all those interrelationships. Each characteristic becomes a standalone thing that can be presented all by itself in different contexts. The text could become part of an RSS feed. An image can be used in any number of ways. As for the layout, typeface and the like, well, those things have meaning only in the context of their interrelationships. In other words, the meaning inherent in the context is lost in the process of dismantling.

There's always a context, of course. Just because text from a web page is presented via RSS doesn't mean it lacks context; it just acquires a new context. In other words, after deconstruction there's reconstruction with some new materials.

When the meaning of a page is “just the text”, that’s okay. It’s even an advantage, as the new context may work out better, changing the meaning in a useful way. An RSS feed may increase the importance of a news story, for example. In my own case, I’ve noticed some news items in feeds that I suspect I would have missed on the original page.

But sometimes pages are more than "just the text". Contextual meaning involves subtleties and nuance. Here's an example of a page that I think suffers when you start to dismantle it. You could reproduce the "factual" content of the page, I suppose, without much of the context. But something would be lost, and I think on a page with elegant, subtle design the loss is significant.

What I'm really arguing is that in some cases the natural web-centric process of dismantling all the aspects of content and reassembling them in other ways can be destructive. Creative distruction, you might say, but sometimes it makes me uneasy.

For much more depth on some of these ideas, have a look here.

The term satisficing comes from the work of Herbert Simon. It's a product of the area of bounded rationality; the observation that humans are not completely rational in all areas. Actions are partly based on rationality, but also affected by emotions and other internal factors. Moreover, it's rare to have enough objective information to make a completely rational, informed decision. In most cases it's just not worth the effort to become fully informed, even if that were possible.

We might have a need, desire, or goal, but instead of completely satisfying the need, we come as close as we can within the constraints of our current situation. That's satisficing. If you need a watch, for example, a precision timepiece milled out of solid unobtanium might appeal to you, but an inexpensive model from eBay might be good enough. Good enough is the hallmark of satisficing.

In designing a software user interface we do a good deal of satisficing. Even UI designs from Apple Computer, usually touted as the best, coolest, easiest-to-use interfaces available, are at some level "good enough" rather than "perfect" or "ideal".

The trick, of course, is that as a UI designer you know this but you don't often admit it. You try to make your designs as close to perfect as possible, even when you understand that "perfect" in this arena isn't even a reasonable notion, all things considered.

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.

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.

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

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.

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

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.