As has been clear from the past days’ blogposts on Planet KDE, the 2011 Randa sprints are kicking off here in the Wallis in southern Switzerland. Surprisingly, it snowed last night, and as we’re at an altitude of 1400m, it’s sticking around for a while. Those that arrive during the afternoon will be in for a snowballfight, I guess. I’ve also made sure the Free beer (new label!) is still tasty, and that the Suisse version of croissants (Kipferl) doesn’t bear any surprises. My train-ride here was calm, I could get a good couple of hours of sleep on the train that got me here during the past night, and enjoyed the massive mountains (which hide in the cloud) already. It’s slightly weird to see snow at the beginning of June, and I’m sure we’re in for a bunch of “WTF?!?” as more people arrive over the course of today. Mario has already posted some photos, just as quick impression.
Tonight I’ll board a sleeper train which will get me to Randa, Switzerland by tomorrow morning. I’m travelling to that small village in the Swiss Alps to participate in the Platform11 sprint.
What is this platform11 sprint about? (Randa’s trainstation only has 2 platforms, one towards Zermatt, one towards Visp. That’s probably not it.) The wiki page about the sprint makes it more clear, however:
To examine the current state and near future of the KDE Platform (kdelibs and kdebase-runtime), particularly as it relates to the growing usage of it in new contexts such as mobile or on Windows and MacOS and its traditional usage as a set of conveniences and consistency creators for KDE application development. The sprint will aim to create an actionable, multi-year roadmap for kdelibs and kdebase-runtime and will examine issues of modularity, topicality and the inherent dichotomy between the KDE Platform as an application development framework (similar to Qt) and as a stand-alone platform to target (similar to, e.g. Windows, MacOS, etc.)
To me, this sprint marks an interesting point in the lifecycle of KDE 4, as we are now rethinking the structure of our platform.
Platform or Frameworks?
Last week, we had an interesting discussion wether the development libraries KDE software bases upon are called a platform or frameworks. I personally prefer to think of it in terms of frameworks, because that has a less exclusive nature to it. A platform sounds very much monolithic, while frameworks give a modular impression — and indeed, one of the goals of the Platform 11 sprint is modularity of our "platform".
Plasma Active and Platform11
One of the goals for me for participating in Platform 11 is to make our development frameworks more suitable for building non-desktop systems. There have already been efforts that work into this direction for quite some time (the platform build-time profiles come to mind, or recent work on libplasma2), but we haven’t yet had a focused meeting where we sat together to discuss our platform as a whole. That will likely mean a bit of restructuring in our libraries, deprecating some overly old stuff, and examining where we’re lacking a consistent API for modern needs. Geolocation comes to mind here, and rumours are that there’s an exile-kiwi coming with plans to Randa.
Last night, during dinner Kim asked me what I’m looking forward to in Randa other than technical and community bits. My answer was “watching the mountains”. As I’m living in the Netherlands, mountains are not a normal thing in sight, and the magnitude of those Swiss Alps keeps astonishing me. I’m also looking forward to those idle moments staring at the mountains.
For the upcoming Berlin Desktop Summit, some people might need visa. The organisation (KDE e.V. and GNOME foundation) can help here. Since we’re a relatively small team, and visa application can be critical to a person being able to attend, we need you to send us your visa request as soon as possible, but in any case before June, 1st. This is necessary so we can do the necessary paperwork and make sure important contributors will be able to attend. Please get in contact with the GNOME foundations travel committee or the KDE e.V. board of directors if you need a visum.
If (you’re a KDE hacker and) you need assistance with travel costs, and you haven’t already applied, please also do so quickly. There’s also a June 1st deadline for that. (The rationale being here is that we do not want to decide on a first-come-first-serve basis, but we need some planning security.)
We’ve been busy bees in the growing Plasma Active team, so it’s time to post some progress updates. In case you forgot, Plasma Active is a KDE project to create a desirable user experience for the device spectrum, with its first focus to create a system suitable for tablet computers. In my first post about Plasma Active, you can see the basic shell running on a 10 inch Viewsonic Viewtab. In this post, I’m using a Wetab to demo the current state of Plasma Active. The Wetab is one of our test devices. It’s a nice target device since it’s Intel Atom-based, which makes building Plasma Active a bit easier, and thus shortens our development-testing-deployment cycles considerable. The Wetab can currently be gotten from German Ebay for 219€ + shipping, so it’s also quite affordable.
Back to the software, though. Our focus in the past weeks has been two-fold, we’ve done a lot of “small fixes” which greatly improve the user experience. The other class of changes is less visible at this point, but still fun and exciting.
Virtual Keyboard Layout
The virtual keyboard is using a layout that is more suitable for tablet computers, containing more characters on the first, easily reachable “page” of it. This makes text input a lot less annoying (let’s face it, touchscreens are not ideal for typing as they lack haptic feedback, so it can only become so good). There’s still a bunch of things that would make the keyboard better, and of course it has its fair share of bugs, but it basically works and isn’t too annoying, either.
Top Panel and Window Switching
We’ve also done some work on the top panel, holding access to network, power management, the calendar and a bunch of other things. While the panel would slide out a bit in our early versions to make the hit area bigger, we found that this intermediate step is not necessary, we increased the default height of the panel a bit which works nicely. The panel is still meant to be slided out, but for a different purpose. We will be putting a strip of window previews in there, replacing the current appswitcher sitting in the top left corner. Most pieces for the new panel-and-window-switching mechanism are already in place, but it’s not finished yet.
Snazzy new Activity Switcher
During Tokamak, Marco has merged a new, snazzy Activity switcher into Plasma Active. This activity switcher offers a wheel-like interface which you slide in from the right. It has previews (or rather post-views ;)) of your activities, and you use a small slider on those previews to switch to an activity. (These activities right now provide spaces for different sets of widgets, but will be given more meaning thanks to the Contour project, which develops a semantic workspace framework for Plasma Active. As all the parts necessary to make basic activity handling in Plasma Active work, we’ve decided to merge this new switcher already, since the “old” one was really very basic, and wasn’t quite so intuitive, due to lack of visual feedback (i.e. previews).
Try it!
open-slx has created a new Plasma Active image, which can be run live off of a USB stick, you can find the latest version here (spot the plasma-active.current.iso). There are also openSUSE and Meego packages available (the latter being a bit less mature, but we’ve made really good progress in the past days.)
If Plasma Active has spawned your interest, or you would like to find out how you can get your software to run on and integrate well with Plasma Active, get in touch with us, either on IRC, or via our mailinglist. You can find more information on the Plasma Active pages on communitybase.
Quick reading tip: Interaction architect Peter Sikking has blogged about the KDE UX sprint, which happened two weeks ago in Berlin. Read his interesting blog post here. :)
Our two big topics at Tokamak 5 are infrastructural changes and libplasma2, and Plasma Active. In a session yesterday, we discussed the Plasma Active shell, and how we want to interact with it. The discussion was very fruitful, and based on a mockup by Riccardo, we decided to implement a top panel that you can drag out, offering access to the window switcher, the “system tray”, and a couple of other things. That’s quite a big visual change from what we have right now, but it allows us to achieve a number of interaction cleanups. Let’s look in more detail what we’re doing here:
Window switching – The top panel has a horizontal window list, which you can use to switch between app windows and widgets in your workspaces. The window decoration is going away, windows can be closed from the window list. The present windows effect has this already implemented, as a trashcan you can swipe your window into. It works pretty well and is snazzy.
Semantic Resource Visualization – In order to display things like files, contacts, bookmarks, music, etc. we use separate QML elements for different uses (items in a listview, for example). The data comes directly from Nepomuk. This part is also starting to work, we can list different resources, and based on its type (defined in the ontologies), it will choose a suitable QML file to display this Thing in a suitable way and allow for interaction with it.
Storage of bookmarks – As most of the information we use in Plasma Active is coming from Nepomuk, we decided to store the bookmarks in there as well. The NFO Ontology has classes for Bookmark and Bookmark folder, which is what we’re using here. Last night I’ve restructured the metadataengine to make it easier to build special purpose dataengines on top of that. These dataengines allow for easy access and usage in QML / Plasma Quick.
Web Dashboard – I’m doing some work on a nice way to view your bookmarks, as interacting with the web is an important use-case of Plasma Active. We now have (cached) previews of webpages, we can use directly in QML. Combined with the dataengine that lists bookmarks, it’s now easy to implement a bookmarks browser, done entirely in Plasma Quick, shippable as architecture-independent package. Connecting these bits and pieces is next on th list.
Some of these things are working already, others materialise as we speak, some will surely stay on our list until after Tokamak, so we’ve got something to hack on when everybody’s back. :)
This week’s a crazy one, at least according to our cat. The fifth edition of Tokamak (the Plasma team’s sprint) is taking place at my house, so I’ve got the house packed with geeks hacking away at godly and ungodly times. It’s been great so far, but just as well too busy for me to blog, or even answer my emails. (Feeding the various animals here trumps that, sorry. ;-))
So, what’s been happening? We’ve designed, discussed, implemented stuff, fixed bugs left and right and had quite some fun doing that. Aaron has already talked about some of the things we’re working on, my personal focus is on two aspects:
Improving overall user experience in Plasma Active
Visualisation of resources coming from Nepomuk
Both are fun topics, and I’ll blog about them in more detail once things settle down a bit here. If you’re curious, you can update your Plasma Active installation already, and follow our progress. I’m updating the packages regularly, so that you won’t fall behind too far during our development progress.
One of the results of the UX sprint in Berlin which I’m really happy with is that it helped me frame some of the bigger ideas behind in my mind behind Plasma Active, and make it digestable for someone who hasn’t spent a lot of time yet thinking about it, and digesting these ideas.
As really nice example Celeste came up with is “The Box of Crayons“.
Let’s say, we as developers create a crayon, just one color, one thickness, a tool that is fine for jotting down a note on a piece of paper. There’s something magic about this crayon however: You can change it, and you can clone it nearly effortlessly. We start spreading around the clones of this crayon. An artist picks it up, and starts sketching with it, but she’s quickly unhappy with the crayon’s thickness, and the color isn’t very beautiful either (surprise, it’s made by a software developer, those don’t have the same visual tastebuds as many others). The artist takes the crayon, clones it a few times, changes the thickness of some, adjusts the colors of others. She takes a sheet of paper (same magical capabilities) and starts drawing. Happy with this new box of crayons, she tells her friends, and starts sharing it with others (now as a box of coloured crayons, in different colors with different stroke-styles. Others go ahead and add paper, canvases in different forms or shapes…
Applied to Plasma and Active, this means that we have to bring the traditional tasks of application developers to a wider group of people, and deliver the possibilities and infrastructure to share and change our creations. Creating a new “App” (a crayon, or a piece of paper) is not necessarily programming something new, but it can also be a specialized version of something that is already there — as long as it provides added value, it’s a useful addition. An interesting aspect here is that this ties in closely with the core values of Free software, yet provides an intriguing way of blurring the lines between creators and consumers.
Plasma provides these generic crayons with magical capabilities already today. We want these to be used, shared, adapted and combined into new, desirable tools.
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.
What is this platform11 sprint about? (Randa’s trainstation only has 2 platforms, one towards Zermatt, one towards Visp. That’s probably not it.) The wiki page about the sprint makes it more clear, however:
The virtual keyboard is using a layout that is more suitable for tablet computers, containing more characters on the first, easily reachable “page” of it. This makes text input a lot less annoying (let’s face it, touchscreens are not ideal for typing as they lack haptic feedback, so it can only become so good). There’s still a bunch of things that would make the keyboard better, and of course it has its fair share of bugs, but it basically works and isn’t too annoying, either.
During Tokamak, Marco has merged a new, snazzy Activity switcher into Plasma Active. This activity switcher offers a wheel-like interface which you slide in from the right. It has previews (or rather post-views ;)) of your activities, and you use a small slider on those previews to switch to an activity. (These activities right now provide spaces for different sets of widgets, but will be given more meaning thanks to the 
This week’s a crazy one, at least according to our cat. The fifth edition of Tokamak (the Plasma team’s sprint) is taking place at my house, so I’ve got the house packed with geeks hacking away at godly and ungodly times. It’s been great so far, but just as well too busy for me to blog, or even answer my emails. (Feeding the various animals here trumps that, sorry. ;-))