Round doorways were plenty in Ancient China, but round UIs belong mainly on the decks of alien ships in Star Trek. But what if one can have her desktop UI on a round table such as the one below?

The round table top shown in the figure is divided into several slices, each of which shows items being worked on in a particular task (e.g. coding, surfing, chatting). The user can rotate a slice to be in front of her and widen it. As a slice is widen or narrowed, the items shown in it scale accordingly.

In the middle of the table top is the top level menu—a pie menu! Because the whole UI is circular, a pie menu is natural here.

 

This circular UI breaks quite a few traditional UI assumptions:

• A UI item can be oriented in an infinite number of ways as it is rotated around the table top. In traditional UI, a UI item has exactly one orientation.
• UI items no longer have fixed, intrinsic sizes since they can be scaled as the slices are widened or narrowed.
• "Maximizing" a rectangular item no longer makes sense.
• "Tiling" rectangular items no longer makes sense.

 

Having a whole table top as one's desktop UI might seem extravagant, so let us consider a more economical scenario in which a round table top is shared by more than one user:

In this scenario, we see more of a need for arbitrary orientation of UI items. Different users sit at different positions around the table and their UI items need to be oriented appropriately. When a user wants to show one of her UI items to her colleagues, she would need to rotate it to another orientation appropriate for her colleagues to view. If she were dealing with just a piece of paper, rotating it is so easy to perform that it's not even an issue; in the UI world, however, such support for rotation would demand a complete rewrite of any existing UI toolkit. For instance, a rectangle in all existing UI toolkits is identified either by the coordinates of two opposite corners or by the coordinates of one corner and a width and a height. In our circular UI, an orientation is also required. Such a fundamental change would probably render most existing UI toolkit codes and most application UI codes obsolete.

Once we have a round table top groupwork UI, we can support a capability that paper does not support. In the figure below, three users zoom into three different parts of a common item (e.g. a large poster) to work on those three parts. The users can sit comfortably in three different positions and have their own UI items oriented appropriately for them rather than sharing a common orientation if they were to work on a real paper poster.

 

The reader might be inclined to believe that until we have a round table-top UI, support for arbitrary orientation of UI elements is unnecessary on the rectangular vertically-standing-monitor UI. On the contrary, I am of the opinion that orientation is a means of communicating information that has been under-used. Consider the following UI that shows several documents on a public repository. Each document is displayed as an icon, tilted to indicate recent modification by other users (i.e. the document has been "touched").

User studies are necessary to verify whether this means of indicating modification is superior to other means including color-coding and labelling (decoration). For a color-blind user, orientation is clearly superior than color-coding. Labelling requires more cognitive work to parse the labels, and labels might have already been used to indicate another type of information.

 

The argument here is not that orientation should be supported. It is, rather, that orientation should be experimented with and that the UI toolkits should facilitate such experimentation.

 

 

by David Huynh