It's been two weeks of prototyping now and we have already achieved great progress regarding the fidelity level of the prototypes and have gained many insights that we would have missed otherwise if we would solely rely on static low-fidelity prototypes.

Currently we are trying to figure out what might be a promising metaphor for organizing functionality and making it available to the users. There are a couple of basic constraints that limit our possibilities at hand. We still move around on a 2D surface, for instance. So, we only have two dimensions to organize tons of icons and buttons that give access to the features we have in Impress. In addition, the 2D screen real estate is also limited. The consequences of these constraints can be nicely demonstrated if you switch on all available toolbars and panes in any of the applications we have in OpenOffice.org.

What to do? We need to pretend that we have either more dimensions or more space. One way to simulate a multidimensional environment is to use tabbed navigation. Tabs give us the ability to implicitly squeeze a few dimensions onto a 2D surface by revealing one 2D tab at a time. This concept or metaphor was and still is frequently used in the web. Another way would be to implicitly increase the screen real estate, along the horizontal dimension for instance, and visually focus on those regions that offer functionality that is currently required.

However, since we decided to keep some sort of a menu in the new UI, it is quite a challenge to integrate both into one coherent concept. There is actually an inherent problem that comes along. Having a menu and having additional hierarchical global navigation elements increases the number of choice and adds to visual clutter (See my previous blog about MSO 2008 for Mac). Any user would have to decide where to look for functionality, is it is the menu or is it somewhere else. To solve that issue we need a design strategy that combines the best things of both worlds e.g. if a user wants to explore the abilities of OOo or needs to use advanced features, she will find any of these in the menu. However, the menu should never be the default way of using basic functionality. Therefore, we need to design an efficient way for accomplishing all basic, less advanced tasks without the menu. In addition, this should be as obvious as possible to the users in order to foster learning and to quickly increase familiarity.

These considerations lead us to the prototypes you can currently try out here. A few of those were already deprecated since they did lead to confusion at different screen resolutions. We are still working on basic navigation concepts, so most of the details are not fixed now. This is actually what comes next. The questions we will need to answer soon are 1. How do we label? And 2. How do we group?

So, stay tuned, check out the progress of the prototypes and give feedback.

Best,
Andreas

tags: renaissance user-experience