Plasma Active: Designing Flexible and Adaptive User Interfaces

UX Sprint

I am in Berlin right now, for the KDE User Experience sprint. This sprint combines developers and designers into one group to exchange ideas, and discuss possible solutions we in the KDE community are running into. The sprint is kindly hosted by Relevantive, and sponsored by the KDE e.V.. For me personally, the focus is on Plasma Active. In order to make Plasma Active less abstract and give us all a clearer idea of what this is, I’ve brought two tablets running Plasma Active to show people what we’re working on, explaining the concepts while showing where we are right now. The reactions have been very positive and open so far, even if surely I wasn’t able to provide every detail we envision.

One of the goals I came here for is to evaluate and test Plasma Active’s concepts with a wider group of people, with more professional designers, and with people who have expertise in fields that are critical to Plasma Active’s success. This has proven very valuable so far. I’m quite happy with the results, and most of the ideas and concept we worked out with respect to adapting apps (and UIs) to the device spectrum do address the important problems we have. In this morning’s discussion, we also came up with some recommendations to not repeat mistakes others have made in the past.

Design vs Implementation

One of the things that we have to avoid is to mix design and implemenation. If we target a spectrum of devices, that doesn’t mean we can deliver one-size-fits-all solutions. The contrary is true: Every device has a special ‘use-case’ (in a lose meaning), it has special attributes that make the device special. Let me give one example: an app for a smartphone vs. an app for a tablet computer. The most obvious similarity is that they’re both touchscreen devices. This means that an app that works well on a smartphone would probably also run fine on a tablet. A smartphone technically is very much a subset of a tablet (oversimplified, yes). The usage pattern of a tablet is much different, however. Your smartphone may be used “on the run”, with an attention span of a few seconds, while you’re using the tablet on your couch, as a more relaxed way to go through your pile of emails — your not easily distracted though. Apps need to be designed for that, so it is not as easy as just making some screen adjustments. The app has to be made for a specific use-case.

Separate Designs with shared implementation

The solution is of course to design separate applications, that take all this into account (device-specifics, such as input methods, screen size, etc.) and usage patterns (“What is this app used for?”) The design for a specific device has to be made on a blank sheet of paper. In the implementation phase, Plasma’s architecture comes in really handy. As Plasma is very portable and full of generic components for small tasks, we will often end up re-using 90% of the code. The thing we have to watch out for is to not let this ease of development lure us into laziness on the design side.

Plasma Active is creating a lot of blank sheets of paper, waiting to be filled. We need designers that want to help us fill these pages with what becomes the blueprint for desirable interfaces. If this is something you, as a designer (visual-, graphics-, interaction-, product-) find interesting, get in contact with us. We need you.