SteelRat edge menus

As mentioned earlier, I'll present an overview on the basics of our Steelrat Tablet reference UX here. I will start with the edge menus, as they are rather central to the overall concept.

The UX heavily emphasizes the use of edge-based menus for occasionally used functionalities. Only the most often used controls of an application are provided on screen at all times, while the rest are tucked away into menus. There are four distinct kind of menus, each opened by swiping from a different screen edge towards center of screen:

1) System menu: Opens from top edge; Contains system-wide functionalities such as power off, sleep, and network connectivity. Can be activated at any time (except when a system-wide modal dialog is on screen).

2) Task switcher: Opens from right edge; Has thumbnails for all running applications as well as for the home screen. Can be activated at any time (except when a system-wide modal dialog is on screen).

3) Application toolbar: Opens from left edge; Contains application-specific toolbar icons that are relevant to whatever content the application is currently displaying. In other words, "quite an ordinary application toolbar". May also in some applications contain additional UI elements, such as in the subsequent example image the browser location bar and such controls.

4) Context menu: Opens from bottom edge; provides thumbnails to switch between different contexts within the same application. For example, web browser allows switching between tabs by using context menu. Also e.g. media player allows switching between music browsing, video file browsing, as well as internet radio station catalog by having those available as different contexts.

(The screenshots above are early mock-up graphics that were drawn to explain the design to the development team; the actual UX has a more polished theme to it.)

Responsiveness of the UX as a primary driver for development

Responsiveness of the user interface is one of the most important aspects of a good user experience. The response to individual actions such as touch gestures needs to be immediate; even a small but noticeable lag degrades the overall user experience greatly. Reasonable response times to various user actions as specified by our UX team are a real design constrait to our technical teams.

This also includes things like application startup times. To enhance the feel of responsiveness while launching an application, the user interface of practically any application should bring itself up in a reasonably short time (in contrast with typical desktop PC applications, that often take several seconds to initialize before any visible response is provided on screen). For SteelRat, we currently use an assumption of 1 second for an acceptable time from launch of an application to having its user interface constructed and visible on screen. Not exactly an easy goal for some of the larger applications, but with clever caching, spare pre-instantiated processes, library optimizations, combined with some UX smoke and mirrors ;-) this is possible to achieve on typical target hardware.

Regardless of whether the SteelRat Tablet reference UX or a custom-built UX is used, we have the responsiveness/performance as one of the primary drivers for the actual implementation. Those who saw our latest SteelRat prototype in San Fransisco MeeGo conference in last month, already know what I'm talking about.