S60 Open to new features

Generally the more a UI designer knows about the users of a piece of software, the better the design will be. By “better” I mean “providing more of the things users want to do, in ways users discover and understand.” There are three aspects to that: features, discoverability, and understandability. Sometimes these aspects work against each other.

In the case of the browser, we generally want to create more features, but some users reach an impasse in discovering those features. This is partly because the S60 user environment is more constrained than, say, Linux, Windows or MacOS. We don’t have the display area to offer status bars, toolbars, docks, menu bars, and scroll bars all at the same time. We have a more “vertical” menu control structure — that is, rather than starting with a set of categories like “File”, “Edit”, “View”, and the like, we start with just one: “Options”. That means that some features are going to be “buried” in the vertical control structure.

Features can certainly be buried in a desktop windowing UI as well (did you ever find the screen saver that used to be built into Microsoft Word?) But desktop UI designs often offer more than one path through the UI; you might find a particular feature in different ways. In S60’s more constrained UI environment, there’s less of that. So some users get stuck and don’t discover some feature that might be useful.

We’re still working on this problem. We serve a vast array of kinds of users, and generally try to strike a balance between features that would be useful to some number of them versus the additional UI complication a new feature might add. Then once we do decide to add something, we try to predict the situation that might lead a user to an impasse, and redesign in order to avoid that situation.

Often we have to simply choose what we think is the best design approach even though we know some users might get stuck. If you use a mobile device to open a web page with embedded sound, for example, it can lead to some potentially confusing situations because the user’s situation may very well make the sound problematic. Or a feature that “power users” really want might be so confusing to nontechnical users that it’s hard to decide to include it. If you know what a user agent string is, and how it works, you might want the ability to modify it in your browser. But if you don’t know, and you end up in that part of the UI anyway, it would be bad if your browser no longer worked the way you expect.

Longer term, I think the fact that the WBfS60 is an open-source project offers and answer to this. I think eventually you’ll start seeing different kinds of browsers, still based on WebKit, but serving more specific audiences. We don’t have enough developers to create a special browser for a specific group of users, but just because those developers aren’t here doesn’t mean they aren’t somewhere else. I think the future may well hold some special-purpose browsers to choose from.