replicator.org ... continuous garbage collection

Today, I’ve had some time to install Windows 8 in a Virtual Box to get a first impression of the Developer Preview.

And I am not impressed!

The Metro User Interface (Metroface?)

A tile based interface is probably a great choice for a phone or may be a tablet, but tiles don’t seem to be a good fit for the desktop experience.

For once, they all look alike. They don’t have clear characteristic properties that make them distinguishable. And animations make them even harder to remember.

And then, they are edged, which goes against every design study I’ve ever read about. Rounded corners are easier on the eye and resemble forms that occur in nature. I personally would take it even so far that I feel “offended” by this razor sharp user interface that may attack and cut me the very next moment.

The Full Screen Start Menu

Well, that is just another name for the Metro interface, Microsoft decided to remove the start menu and replaced it by the Metroface. Which means that every time you need to search for an application or a file, you are forced to switch from your desktop to Metroface in full screen. This happened all the time while I had my first Windows 8 session. I don’t want to imagine how much of a cognitive burden this would put on me when I use Windows 8 on my 3 screen setup. Fullscreen flash to Desktop, flash to Metro and back. Disgusting. Microsoft should not have removed the classic start menu from Windows 8 Desktop.

Update: Here is a tool that enables the classic start menu in Windows 8

Mouse Usability

The Metroface can not be effectively used with a mouse. There are (pretty ugly) scrollbars everywhere and the distances you need to move the mouse are often too far. And because everything scrolls in the horizontal direction, the mouse wheel can not be used to scroll the pages. Microsoft should have either supported direct mouse-down and drag gestures or vertical scrolling pages like in the WeTab user interface.

And the back-button experience is entirely confusing. Some apps do support a back button, but they only work inside the application, they never lead back to the start menu from where you started (or entered?) the app.

And on the desktop, even if no touch device is connected, the title bars look huge and ugly and the usually small title bars of the toolbar windows are as big as regular ones.

Development

Microsoft has created a completely new set of APIs to program against the Metroface. I think that Microsoft is making a huge error here by introducing yet another XAML API. They claim that one of their choices were that it is harder to create vivid apps with a managed language and so needed to create a new API that is accessible from the CLR, native C++ and JavaScript. But I doubt it. While JavaScript is a great language for making small apps in the short term, everything breaks down in the long term.

They should have used Silverlight as their base for Metroface, but I guess the kids that Microsoft employed to create the Metroface were just cheaper and more proficient in JavaScript. I hope that this does not end up like every large JavaScript project I’ve seen: as unmaintainable spaghetti code.

What I do like

The Explorer got its parent button back.

The Task Manager is better structured and cleaned up. You can see network traffic and IO transfers of each application individually in a well-arranged grid.

Conclusion

Either the Windows 8 Developer Preview is a very early beta, or Microsoft is taking a huge risk to introduce the next Vista. For a desktop user, the alieness in usability and style of the Metroface feels intensely distinct to the normal desktop experience and should not have been integrated into Windows at all. A better option would have been a clear separation between the two user interfaces. The Windows Phone 7 operating system and its Silverlight based application framework could have been extended to make a great tablet OS. And honestly, who wants to use Windows desktop apps on a small tablet screen?

Most details of user interfaces , for example, text, buttons, layout, and terminology, can be classified into how much prior knowledge is required to make them understandable:

Details that require Common Knowledge

That is, details that can be understood without having to learn anything new. The user is expected to have some form of prior knowledge that – in effect – creates a correct interpretation of what is being presented.

Examples are: The shape of buttons, or links that represent clickable elements, text written in the language the user knows about, or a layout that prioritizes information in terms of how the user scans the user interface visually.

Details that require New or Learned Knowledge

These are details or concepts that are specific to the domain of the user interface. The goal of the user interface is to communicate them to the user with the least amount of effort on both sides.

Examples are: New terminology, keyboard shortcuts, or graphical representations of concepts.

Creating a good user interface is largely dependent on how the details are working together to create a deep understanding of what the user interface represents.

If possible, simple user interfaces should use details that require common knowledge only, but any more advanced user interface needs to introduce details that need to be absorbed first.

Building a simple user interface that merely uses details of common knowledge often restricts your users from working efficiently. For example: Complex task can not be combined without introducing a new user interface element, or specific tasks may require a detailed understanding of the domain terminology before they should be used at all.

As soon the required knowledge level of each detail is defined, user interfaces can be built so that they start up with the simpler details and introduce the user to more efficient and natural abstractions over time.

So obviously, there are two steps to make a better user interface:

First, every little detail needs to be classified into “commonly known” or “new to learn” category. Details that are in the gray area should be placed in the “new to learn” category.

Remember, you are a developer or designer and you know this stuff, but – for example - most computer users may have never heard of a context menu, though they may use it all the time. You don’t need to envision a senior person who has recently learned to use a computer, but a conservative decision about what details need a introduction may be a good start to cover most users.

Second, every detail in the “new to learn” category needs an introduction. This is the hard, challenging and creative part. For once this can be implemented explicitly, by writing a textual introducing somewhere where a new detail appears. Or – and that is the most exciting part of user interface design – by a contextual introduction that automatically produces an aha-effect.

Producing The Aha-Effect by Contextual Introduction

One good example for a contextual introduction of a new user interface is the scrollbar of the iPhone. While the scrolling itself is a simple feature that every user gets as soon he touches the screen, the iPhone’s scrollbar, which shows how much of the current scrolling area lies outside of the screen, introduces itself by simply appearing and changing while the user is scrolling the list. Sooner or later, the user gets what the scrollbar represent. It clicks.

But often it’s not so simple. For example, more complex touch gestures may not be introduced at all and are buried in the manual that no one reads. These gestures will be overlooked by a lot of users. But when the same functionality is reachable by a menu, for example, a small transition animation that resembles the gesture in some abstract form may be introduced to the user.

I think that getting aware about what user interface details need an introduction and the implementation of contextual introductions that produces an Aha-Effect are the most important, challenging and creative part of user interface design.

Yesterday a friend visited me and he had brought a Windows Phone 7 with him. For a few minutes I was allowed to tap around and try some of the apps that are installed. As expected the user interface is pretty minimalistic, but does not compromise on functionality. Everything seems to be more ambient, more hidden, but appears right when you need it.

Some observations I made:

• The UI does not feel cluttered. Most layouts are just scrollable lists, icons left, text right, that’s it. If columns are used, they span multiple screens.
• There is a clear distinction about what is important and what not. The text on the menu items are white and large, the hints are small and grey.
• User interface elements hide when they are not required. For example in the top bar, all the status indicators except the clock just hide after some time. A great choice to reduce cognitive load. You just tap on the bar, and the indicators appear again.
• Selector wheels, like the one to select the month, day and year for the clock, appear not until you start touching the digits. I like that, information that is displayed when required, not sooner!
• The app and tile icons are designed to be simple, and their background color is adjustable. That leads to a common look and feel among them. On iOS or Android, every app icon is just completely different (except may be the glare effect on IOS), which is much more distracting, I guess.

So I am getting excited by the Metro Design, and I have high hopes that Microsoft changes its current strategy and will use their WP7 UI in upcoming tablets.

I just couldn’t believe that in Windows 8, the Windows Explorer may get a Ribbon Toolbar. I personally think that a ribbon toolbar is the worst ever UI concept invented to present content related functionality.

Why I think a ribbon toolbar is bad:

• It wastes space. After all, it's all about content.
• It is not physically close to the content you want to work with. Moving the mouse is a time waster.
• It is placed first alongside the “reading direction” (left / right / top / down) and so it costs cognitive resources all the time. Whether you want it or not, you need to scan over the ribbon to find the actual content. And there is a lot of information on a ribbon (ghosted items or not).
• Different ribbons at the same place make it hard to remember the individual item's locations. So before targeting the mouse you need to reprocess the kind of the ribbon that is active right now, then remember or find the location of the item, then target the mouse. It's even simpler to remember an item position inside a drop-down list in a menu, because to get there, you have to consciously select its context.

I don't know why ribbons are in existence at all. Is it that some developers find them cool, merely because it was a challenge to program them? Or because developers don't want to think about how to present the application's functionality and just like to present them all.

A ribbon may fix one usability problem (the initial discover-ability of functionality), but it does that by making every other task much harder.

So what other options exist?

• Context-menus. It may be hard to discover for a new computer user, but once you get used to it, pressing the right mouse button over some content item should present all the functionality that is related to it. The problem here is that despite there are context menus in Mac OS X, some users don’t have a right mouse button. And moreover websites don’t support a context menu, because the browser took it away. Which was a very egoistic move.
• Context aware overlays. They could be either presented around the content as soon the mouse hovers over a content item for a while, or immediately in the whitespace surrounding the content (like in Twitter’s new web UI). The functions are invoked by pressing the left mouse button. If there are a lot of functions to present, a long-click (holding the left mouse button for some time) or a simple “more…” button could be used to show a drop-down menu for the expert user.

While these are not so many alternatives, they have proven to work fine for a lot of applications. I am not quite sure if they fit for applications that have a lot of content related functionality like Microsoft Word for example. But may be you can come up with more alternatives to a ribbon toolbar. If so, you are welcome to comment!

Update:

I am glad to hear that the ribbon can be turned off, but I really doubt that tablets are a proper justification for introducing them.

I hope that Microsoft considers an auto-hide feature for the ribbon. I think this would be a good compromise for tablet and desktop use. But it would scroll the content, so actually, if the ribbon auto-hides, it needs to be placed to the right or to the bottom, so that the content does not need to be moved.