Summer vacations came and went, with blog not being updated for a while, but rest assured: Steelrat is progressing nicely :-)
We are moving from the venerable X11 based graphics stack to a cutting-edge and more lightweight system. Our tests indicated that all our application UIs have radically better performance when X11 is eliminated and Steelrat UX layer is run on top of Wayland. Latest MeeGo compliance drafts do not appear to require X.org as a mandatory component any more, opening the door to higher performance while still staying compliant.
As of now, Steelrat has its own compositor and window manager, which support both Wayland and X11 as plugins, without having an effect on the actual Qt applications. This is achieved with the use of QPA - Qt Platform Abstraction. Wayland is used natively (EGL/GLESv2, with no libGL needed). Multiprocess support works, and windowing is done in compositor.
For Qt version, we are currently using Qt 4.8 snapshot with Qt Lighthouse and Qt Quick 2.0, but as the next target we're making the stack work with the latest Qt 5 development snapshots as well (We're almost there already!).
With the legacy-free software stack, our application UIs had quite a consistent 60fps performance on a commodity tablet with a typical screen resolution. Same hardware was struggling with less than 20fps with exactly the same applications running on top of X.org.
24.8.2011
15.6.2011
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.)
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.
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.
25.5.2011
Video coverage of SteelRat from Meego Conference
There is a few minutes video on SteelRat on youtube, taken at Meego Conference by netbooknews.com.
24.5.2011
Introducing SteelRat
Hello, and welcome to my blog, where I will try to document the development of Nomovok's SteelRat product every now and then. I will be concentrating mostly on the UX side, as that's the domain I am most involved with, however I try to cover other aspects as well.
So, to begin with, SteelRat is the name for Nomovok's MeeGo-based software platform (or rather, a family of platforms), targeting various sorts of embedded devices such as tablets, IVI systems and handsets. We demonstrated the first version of SteelRat Tablet Reference UX at the San Fransisco MeeGo Conference in this month. The tablet UX is the first one to be released, for others I'm not able to publicly give a launch date yet. SteelRat is to my understanding named as a tribute to Slippery Jim, but as the name was inherited from an earlier project the origins are a bit of a mystery. At some point our little mascot just ... evolved.
So, to begin with, SteelRat is the name for Nomovok's MeeGo-based software platform (or rather, a family of platforms), targeting various sorts of embedded devices such as tablets, IVI systems and handsets. We demonstrated the first version of SteelRat Tablet Reference UX at the San Fransisco MeeGo Conference in this month. The tablet UX is the first one to be released, for others I'm not able to publicly give a launch date yet. SteelRat is to my understanding named as a tribute to Slippery Jim, but as the name was inherited from an earlier project the origins are a bit of a mystery. At some point our little mascot just ... evolved.
But what's SteelRat, really? First of all, we have the SteelRat platform, based on a slightly modified MeeGo and being compatible with it (compatible as in "adheres to compliance specification version this-and-that"). Ordinary MeeGo-compatible applications will run on SteelRat out-of-the-box. However, SteelRat provides certain enhancements that are not available in mainline MeeGo yet. For Steelrat 1.1 (San Francisco release) we used a MeeGo snapshot from early April as the MeeGo baseline. On top of that, we packaged a version of Qt with support for Qt Quick 2.0, also known as the QML Scenegraph. This allowed our UX developers to use all the fancy effects. Scenegraph engine makes the rendering decisions and is the #1 core feature for the up-and-coming Qt 5.0 - we simply wanted to enable it already. The same holds true to Qt Mobility, as the version in MeeGo didn't quite play together with the declarative stuff in the future Qt. In fact, our entire Qt stack is running ahead of the official MeeGo platform, and this allows us to experiment with, and deploy features which are not yet available for users of the stock platform.
On top of the platform, there is a device category specific reference UX layer, which consists of general system UX components and individual applications. The UX part itself is entirely made with Qt/QML, and decorated with GLSL shader effects to create UI that doesn't look dull and static. The UX is practically a full replacement for MeeGo UX, but as said, we do support running MeeGo-compliant applications on SteelRat. The reference UX is designed to serve as the product UX for products that do not require extensive vendor-specific UX design, but it can also be replaced quickly with another UX implementation, thanks to the power of QML. In further posts I will provide a walkthrough of SteelRat tablet reference UX.
Oh, almost forgot: We have an existing Youtube account here where videos of SteelRat will be posted. However, the UX was basically overhauled completely since February, so any material that is there is completely obsolete and doesn't look like current SteelRat at all. I'll arrange some new videos to be uploaded soon, I'll post links here as soon as they are available!
Tilaa:
Blogitekstit (Atom)