Would you want to see posts about NoSQL databases on PlanetKDE?

My dear readers, I have agreed with ArangoDB to help them spread the word about their – of course open source – multi-model NoSQL database, and I will be using this blog to do that. It’s not going to be boring marketing bla bla, but I’m planning to write about things like tutorials, interviews with ArangoDB users and contributors, as well as the adventures of a “kind-of-geeky psychologist” (i.e. me) taking a stab at developing a data-intensive web application using ArangoDB.

PlanetKDE is not subscribed to this whole blog, however, but only to a specific category. Therefore, I can control whether these posts show up on the Planet or not. Since many of my readers here are rather on the tech-savvy side of the spectrum, I suppose that these posts might be of interest to at least some, if not many, of you, but I don’t want to “spam” the Planet with these posts if the majority would not be interested in them.

Therefore, I want to give you, my readers, a choice. Please vote using the poll below on whether you’d like to see NoSQL database-related posts show up on the Planet or not. Of course I can revise the decision later if I get a lot of feedback to the contrary on my individual posts, but I’d like to get a quantitative picture of the general preference beforehand.

Posted in KDE

Notes From the PIM Sprint: A Vision for the KDE PIM Framework

I know I know, the PIM sprint has already been last November, but in my defence (@David: !!!), the VDG and KDE as a whole has been so buzzing with activity in the meantime that I didn’t find the time to write the blog post I had meant to write about it. So here it is, better late than never.

Now, what did I do at the KDE PIM sprint?

There where to topics I brought to the table:

  1. Developing a project vision for KDE PIM in general and/or Kontact in particular
  2. Making KMail’s search useful again

In this post I’ll cover the first topic.

A project vision is something that has proven to be useful in product design and development in general, and maybe even more so in Free Software projects. The KDE Human Interface Guidelines define a project vision this way:

A vision describes the goal of the project. It can be emotive and a source of inspiration, for instance by outlining how the final product makes the world a better place. Describe the project’s final goals. Explain who will use the product, and how he or she will take advantage of it. Make sure the vision is shared between all project stakeholders. Leave room in the vision for creativity. Keep it short.

The reason why I (and others) think a project vision is especially useful for FOSS projects is that since the typical FOSS project community is a bunch of quite diverse individuals, each with their own goals and ideas. This is of course one of the great strengths of Free Software, but it also means that, without communicating about those goals and ideas, the members of the community might all march in different directions without even noticing. That is what can lead to what users perceive as a lack of consistency and a lack of common direction.

A project vision can help make the individual ideas and goals explicit, and allow the community to agree on a common goal and direction. That does not mean people are not allowed to add features which are not consistent with the vision, but that the community should think carefully why such a feature should be added anyway. It also helps telling users who keep asking for features which are not consistent with the vision why those features won’t be implemented.

So, I suggested to the KDE PIM community to come up with a vision for their project. Since the KDE PIM project actually produces a whole range of products, the group decided to have specific visions, at least one for the KDE PIM Framework and one for its desktop client Kontact. The time at the sprint was not sufficient for a draft vision for Kontact, but for the framework, we now have a vision draft:

The KDE PIM Framework allows to easily create personal information management applications ranging from personal to large enterprise use, for any target device and major platform.
It seamlessly integrates data from multiple sources, while aiming to be rock-solid and lightning-fast.

The PIM framework focuses on supporting open groupware servers like Kolab, but can be extended to access information from various sources.

Now there are some very important points in there. First is a commitment to broad applicability (it’s a framework, after all!) across usecases and target platforms, as well as a commitment to speed and stability. If the community at large (i.e. also those whop were not present at the sprint) agrees on this vision, this means, for example, that if someone wants to use the framework to create an enterprise application but finds that it currently lacks for example scalability to do so, the team cannot say “But it was never meant for enterprise use!”.

The second part is a commitment to the current driving forces between the PIM Framework: It makes clear that Kolab and similar open groupware servers are what the team cares about most, without excluding other backends. In practice, that means that if someone for example wants the framework to support Microsoft Exchange, the team can say “Please refer to our vision: Exchange is not our focus. So, if you want to integrate support for it in the KDE PIM Framework, you will have to find someone to do it. We’re open to it, but we have other priorities.”

Now as a next step, this vision draft will have to be presented to the whole KDE PIM community, perhaps iterated upon, and finally agreed upon and published officially.

In the same vein, a vision for Kontact should be created. Some input for this formulated by Aaron Seigo:

A high-quality, featureful, scalable, multi-platform groupware suite that provides unified access to groupware data from multiple sources with a focus on full-featured groupware servers.

Now I’d like to see the idea of creating project visions spread to other projects (for example Krita already has one, KDE Telepathy also has a draft which awaits publishing, and the KDE Visual Design Group has committed to creating a vision as a first step when designing or fundamentally redesigning applications). If your project would like to create a vision, feel free to ask any VDG member of your choice or start a thread on the VDG forum.

So, what’s your take on this? Do you think a project vision can be helpful? What do you think about the proposed vision of the KDE PIM Frameworks? Let’s hear your opinion in the comments!

Tagged with:
Posted in KDE

Shared Values ⇒ Shared Ideas? What we can Learn from Firefox Australis

If you’re asking yourself “Huh? Australis? Is that edible?”, then let me explain: Australis is the codename of the new user interface that was introduced with Firefox 29 (see the Article on the Mozilla UX Blog for some background).

Australis is the result of years of design and prototyping iterations, which were lead by the recently defined Firefox Design Values. Of those values, especially one looks quite similar to the KDE design vision/motto/slogan/tagline/mantra (yes, it has been called all that!) that I described in my last blog post and which is described in more detail in the “Design Vision and Principles” page of the KDE HIG (though I swear to Stallman that I hadn’t read the Firefox Design Values when I came up with that tagline):


Balances power and simplicity – Firefox is simple and easy to use, clean and straightforward in its design. But simplicity is a means, not the end – the end is understanding and user-agency.


Simple by default – Simple and inviting. KDE software is pleasant to experience and easy to use.

Powerful when needed – Power and flexibility. KDE software allows users to be effortlessly creative and efficiently productive.

Though not identical, these values are very similar in their meaning: Both the Firefox and KDE User Experience teams aim for a simple overall user interface, which still offers easy access to powerful features for those who need them. The similarity becomes clear when one compares what I’ve outlined in the aforementioned blog post with the principles which the Firefox UX team derives from that value:

80/20/2: default to surface minimalism and easy access to the rest

user-agency and understanding, not just less

Even though neither of us blatantly copied the other (they were first, but I only became aware of that document after we wrote ours), the similarity isn’t purely coincidental, either: Both KDE and Mozilla have started off from a quite tech-savvy user- as well as contributor-base, and both aim to reach a broad(er) audience without taking the powerful features which advanced users need away from them.

And – not surprisingly either – both groups came to a similar conclusion for how to solve this dilemma: Putting those things which most people use regularly on the main user interface, while offering well-integrated access to the more advanced and/or less frequently used features. In the Australis UI, there are three tiers of access to features (from most to least frequently used): The toolbar (actually, also the tab bar, but for the sake of simplicity I’ll just subsume both under “toolbar”), the button menu and the (hidden by default) classical menu bar.

However, the tricky part is that for many applications there isn’t “the normal user” and “the advanced user”, and therefore there isn’t “the normal feature” or “the advanced feature”. The same person can for example be a power user for graphics software who needs a very powerful tool for their job as a designer, but at the same time be an absolute novice when it comes to software development tools, because they have only just started teaching themselves some basic programming to be able to whip up some interactive prototypes.

A browser is one of those applications: It’s an application which every user with an Internet connection uses (with the majority using it every day they use a computer), which many use “casually” but many also use for highly sophisticated tasks (and in case of ChromeOS even for pretty much every task). Therefore there is no chance to say “An average browser user uses this and that feature, whereas an advanced browser user uses this and that feature”. The same goes for frequency of user scenarios: Some people use their browser mostly for reading on websites, others use web applications more often than “plain” websites, web designers/developers frequently use highly specialized tools.

So what did the Firefox UX team do to accommodate to that uncertainty? They made the user interface highly customizable, allowing users to populate both the toolbar and button menu with whatever UI elements they wish, as well as to rearrange the elements within each area freely. This means that users can adapt the UI to their personal usage patterns. And even UI elements that are created by addons are treated just like the ones that ship with Firefox by default.

Screenshot of Firefox in Customize mode

What my Firefox looks like in Customize mode – And yes, I’ve put the search bar in the friggin’ button menu, because I mostly use web shortcuts instead!

Is this high degree of customizability worth the effort for every application? Certainly not. For applications which are only rarely used or for which usage patterns are indeed highly consistent across users, a static user interface works just fine and has the big advantage for users that if they forget where a certain function is, they can consult the documentation or ask someone else, both of which are not possible if they can decide where to put it.

However, for applications which are used frequently and for which usage patterns vary between users, a flexible user interface solves the problem that even the best user research and most carefully designed default user interface cannot accommodate to the users’ idiosyncrasies. And even though some companies or designers may have made some people believe that an option is always a sign of bad user interface design, one of the dialog principles laid out in section 110 of the ISO 9241 (“Ergonomics of Human System Interaction”) is still “suitability for individualization”.

So, for all who feared that somehow KDE now decided to be “like Apple” or “like GNOME”, which translates for them to “Not giving the user any options”, fear not: In those cases where it makes sense, a flexible UI is precisely the embodiment of “Simple by default. Powerful when needed.”

Tagged with:
Posted in KDE, User Experience

Simple by Default, Powerful When Needed

KDE (back when it was still the name of the desktop environment) and our applications historically stood for powerful features and great flexibility and customizeability. This is what our users love about our software, this is why they choose Plasma and KDE software instead of one of the other Free desktop offerings. And it is also something they would fight tooth and nail for if we wanted to take it away (as many a KDE maintainer who dared to remove a feature he thought was unnecessary can tell).

On the other hand, this power and flexibility at times leads to user interfaces that intimidate especially new users if they expose all the features they have to users at once, leading them to avoid our applications altogether. This keeps them from ever experiencing the power which they might enjoy later on, as they use an application for more advanced tasks.

With KDE4 (back then, Plasma as a brand was not born yet), the aim was to keep the power, but do away with the scariness, as the KDE4 Vision states:

“Anything that makes Linux interesting for technical users (shells, compilation, drivers, minute user settings) will be available; not as the default way of doing things, but at the user’s discretion.”

In the design vision and principles section of the KDE HIG, we condensed and evolved this goal into a simple guiding principle:

Simple by default, powerful when needed.

How do we reach that goal?

As the first step, it is necessary to define the target audience and use scenario for an application. Only if we know that, we can define which goals users should be able to reach using the application.

The next step is to define for each goal how likely our target users in the target scenario are to actually have that goal, and how regularly. As an example, when we planned KMail Active (aimed at tablet computers) a year ago, we categorized the tasks we wanted to support in three groups: common, uncommon, and rare.
Only the common actions would be accessible directly in the main user interface. Since the usage scenario we had in mind for KMail Active was “Quickly checking up on new mails on the go or at home on the sofa and occasionally reply”, only those functions relevant to that scenario were planned to be placed in the main UI.
This is how we achieved the “Simple by default goal”:

Tablet email client mockup

Early-stage mockup for an email client for tablet computers, to be used in Plasma Active, applying the “Simple by default. Powerful when needed” philosophy.

We optimized KMail Active for users who would rather use KMail Desktop to actually organize their emails by sorting them into folders, or try to retrieve old emails in any folder. However, we recognized that sometimes users may need to retrieve an email from some otherwise rarely used folder or tag or move an email to a certain folder in order to find it more easily later, but don’t have access to a desktop or laptop PC. Therefore a UI to browse through the whole folder hierarchy and the tags (not mocked-up yet) was included in the design, though only visible if users scrolled the view to the left.

The same goes for writing new emails. The default UI for that won’t include things like HTML formatting or adding attachments (since writing longer and more complex emails is not convenient on a device without a keyboard, and users are less likely to have documents they want to send to people on their tablet), but they, too are only presented on demand, not by default. This is the “powerful when needed” part.

This philosophy will guide the designs provided by the VDG, so you will see more examples coming up, soon!

UPDATE: As I’ve seen in some discussions of my post on the Internet (not the comments here) that people apparently thought the screenshot represented the next KMail desktop UI, I’ve updated the screenshot and the caption to make clear what it is.

UPDATE2: Now that this post has become quite popular (2.394 unique visitors so far today!), I felt the need to make clear that – as always with Free Software – all this is a team effort. The original version of the design principles Wiki page was written by Andrew Lake, the user stories for KMail Active were co-written with Heiko Tietze and Michael Bohlender, the design of the mockup was done by Michael Bohlender with my help, and Michael also contributed to the philosophy tagline, by replacing “complex” with “powerful”.

Tagged with: ,
Posted in KDE, User Experience

Sitting on the Shoulders of Giants

I could write a whole series of blog posts about my Akademy 2014 experience, but

  1. I’m not motivated to do that
  2. You might get bored half-way through

Therefore I’ll try to summarize some of my impressions (and provide insight into the “rusty trombone conspiracy”).

The Talks

First of all, the talks: The two keynotes were both awesome!

Sascha Meinrath told us about the strong connection between Free Software and political activism in the opening keynote, and how crucial our work in Free Software is for a future where citizens are still free instead of constantly being watched and manipulated by companies and governments. I found it very inspiring, because its political implications are one of the major factors that draw me to Free Software.

Cornelius Schumacher‘s community keynote taught us how we all benefit from our involvement with KDE and why he and other long-time KDE contributors are doing what they’re doing. It’s always great to hear the stories of “the elders”. It’s a bit like grampa telling stories from WWII. ;)

Of course there were countless other great talks, too (see also the summary of day 1 and day 2 on the Dot, and the program for video recordings and slides).

The Story Behind the Rusty Trombone

Those of you who have attended Akademy or watched the talks by Àlex Fiestas, Björn Balazs or Jens Reuterberg and myself may have wondered why a certain term came up in each of them: rusty trombone. This sounds innocuous at first, but a quick trip to your ever-helpful Urban Dictionary will reveal that, while “harmless”, it isn’t a term you should utter at a dinner party if there is a chance someone at the table might know what you are referring to.

So how did this term enter our talks? Well, it happened as follows: On Thursday morning, yours truly boarded a train in Langen, suspecting nothing. I had read about a group of Akademy attendees organizing a trip from Berlin to Brno that day, but since my connection did not go via Berlin itself, I thought I’d have nothing to do with them. Therefore I was – of course pleasantly – surprised when I saw Mirko Boehm and Patrick Spendrin at Dresden train station. I then learned that there were quite a few more fellow KDEians on that train, among them Paul Adams. Paul always has an odd story or two to tell, one of those was about a contest which was once held to find a combination of two words which, when entered into Google, would only yield Urban Dictionary or pages linking to it as the top results. One of those was “rustry trombone”. None of the other people in the cabin new what it meant (or at least pretended not to know), so Paul explained it to us, in a vivid-enough way.

Fast forward to Saturday night. We had planned to have dinner together with everyone from the visual design and usability groups (namely Andrew Lake and his husband, conveniently also named Andrew, Jens, Björn, Heiko Tietze and myself), and Àlex decided to join us, too. When I told the others about my trip to Brno, the “rusty trombone” story came up, too. Nobody had heard the term yet (or at least pretended not to have heard it) and of course they wanted to know what it meant. I found just telling them to be too easy, so instead we turned it into a quiz. It took the group quite a while to find out what rusty trombone means, and of course the most fun part were the ideas people came up with what it could be.

After the mystery was solved, someone from the group had the idea that since most of us were giving a talk the next day, we all should try to incorporate “rusty trombone” into it. Andrew chickened opted out because – as his husband confirmed – he would not be able to continue his talk afterwards with even the least amount of seriousness. All the rest promised that all our talks would contain the magic words at least once.

I don’t want to spoil the fun for you by telling you how we (or actually everyone but myself, because I thought that having Jens mention it in our combined talk would be enough, to Björn’s utter disappointment) managed to integrate “rusty trombone” in our talks. Just watch the talks (linked above) and look and listen carefully. Àlex, Björn and Jens really mastered the art of injecting the words into their talks in a way that people who didn’t know what they meant (there were fewer and fewer of those with each of our talks, of course) probably wouldn’t have noticed anything suspicious.

Tales from the User Interface Design Room

For Monday and Tuesday, we had booked a room specifically for user interface design topics. The idea was that anyone could come to us to get input on their user interfaces from visual and interaction designers.

Three people used that opportunity: Jan Grulich for the Network Management System Settings module, Michael Bohlender for his email client which we now codenamed “NextMail”, and Friedrich Kossebau for “Workspace-wide services on non-file objects”. All three design sessions were very productive. In all of them, we aimed at striking the best balanced between “as simple as possible” and “as complex as necessary”, which isn’t easy when dealing with complex matters such as setting up a VPN or dealing with multiple email accounts each with a complex folder hierarchy or with mailing lists vs. regular email conversations, or with a theoretically unlimited number of services which can be offered for dealing with any object (such as an address in a text, or an image in a PDF). More details about the results of these sessions will surely pop up somewhere on Planet KDE over the next weeks.

Another very interesting session was “Human-Centered Design for the KDE HIG”: In that session, we applied one of the standard methods in human-centered design, the usability test, to the KDE Human Interface Guidelines. We had two developers (Frederik Gladhorn and Kai Uwe Broulik) test the HIG as its users. They could choose a task for which they would consult the HIG and then try to complete it live, while the HIG team observed them and then discussed with them why they got lost at a given point and which information they could not find. Friedrich Kossebau offered additional input.

The results from this are very helpful for optimizing the usability and usefulness of the HIG for developers. Some of the findings were that our users would prefer visual examples for first orientation, and text only for details which cannot be well communicated visually, that the structure of the main page should be optimized, and that more cross-linking between related articles would be helpful.

Community from the Perspective of a Temporarily Walking-Disabled Member

One of the most memorable experiences from this year’s Akademy has to do with an injury I suffered there. At some point during my travel to Brno, I got a small graze at the back of my right foot. Nothing serious, I thought, so I didn’t pay much attention to it. Unfortunately, some germs must have entered the blood stream through that graze, causing a serious inflammation. The foot got more and more swollen and walking started to hurt. It got better with each night, but worse during the days. On Sunday evening, I decided to stay in the hotel and visit a doctor the next morning. When I told Dan Vrátil about my inflamed foot the next morning, he had to laugh at first, because the exact same thing happened to Jan Grulich during last year’s Akademy. Last time, Jan had to be taken to the hospital and elsewhere by car, now he was the one driving me around.

At the hospital, the foot got bandaged and I was told not to walk. Not the ideal condition for a conference. This is where I experienced first-hand the helpfulness of our wonderful community. Whenever someone from KDE was near, I was supported while hopping about, and Àlex even carried my through the venue like like a bride over the door sill. We also found that office chairs can be repurposed as makeshift wheelchairs (including the fun of pushing someone around on one, of course).

The most difficult part, though, was the day trip to the water reservoir on Wednesday. Originally, I had thought I’d stay at the hostel during the day trip because I couldn’t even get to the reservoir without walking too much and Jan was not available to drive me there.

When asking on the mailing list whether it was possible to get there without much walking, I got two replies from people willing to give me a ride (Martin Klapetek and Teo Mrnjavac). In the end, it was Martin who took me to the reservoir (and also to the tram station the next morning). I was happy that I could take part in the day trip and take the ferry together with the group, but I had already accepted that I wouldn’t be able to get up to the castle we were visiting (castles are not exactly known for being easy to reach, right?).

When the ferry landed and I said I’d wait there for the group to return from the castle, Frederik Gladhorn said something along the lines of “No, we won’t leave you behind, we can get you there!”. I couldn’t really imagine how, until I found myself first on Frederik and Martin’s arms, then on Friedrich Kossebau’s and then Frederik’s shoulders. There are some KDE members which, due to their compact size, might be relatively easy to carry on one’s shoulders. At about 1,85m in height, though, I’m not exactly one of those, so it must have looked really funny when a fully grown man sat on another’s shoulders. I’ll add a photo as soon as I get one. The foot is now better, though it will take a few more days of rest and antibiotics to fully heal.

This was an example of what KDE means to me (and surely many others): We always help each other out, and even if something seems impossible, together we find ways to make it happen.

Thank you all for making Akademy 2014 such a wonderful experience!

UPDATE: As promised, here is a photo of me sitting on Friedrich’s shoulders and trying to avoid being slapped by a branch

Tagged with:
Posted in KDE

KDE Usability @ Akademy

I’m always excited to go to Akademy, but this year even more so than in previous years!

The reason for this is that I’m going to finally meet at least two guys whom I consider friends by now (Jens Reuterberg and Andrew Lake) in person for the first time ever!

But not only I m excited, everyone who is interested in usability should be, because we have quite a few things planned for you:

  • Björn Balazs will be doing a lightning talk Sunday morning about how to bridge the gap between the KDE community and our users.
  • In the afternoon, I will sneak into Jens Reuterberg’s talk on “The Designer and its habits” to present my idea of integrating one designer into each KDE project (I call them “resident designers”).
  • From Monday through Thursday, I’ve declared Room 3 as the “User Interface Design Room”. There you will find at almost any time at least one usability expert and one visual designer who will help you with all steps of human-centered design for your project, from the first step of creating a vision for your project, to creating a user research profile, down to the details of how to design a specific part of the user interface. Come to us, we’re all yours!
  • On Monday morning, we will also discuss how to proceed further from the ideas Björn presented during his talk, and in the afternoon we will discuss what developers and designers want and need from the KDE Human Interface Guidelines, so come join us to provide your input!

You can find all the details in the conference program and BoF schedule.

I am sure that Akademy will be crazy productive as always, looking forward to meeting you all in Brno!

Tagged with:
Posted in KDE

It’s Aliiiiive!

On February, I wrote a blog post entitled “Leveraging the Power of Choice“, in which I described an idea I had discussed with Àlex Fiestas about making it easy for users to choose between different Plasmoids for the same task (e.g. different application launchers, task managers, clocks, …). At the time of my writing the blog post, Marco Martin already had ideas about how to implement the feature, though he said that he wouldn’t have time to implement it before the Plasma 5.0 release. Shortly after Plasma 5.0 was released, Marco started implementation as promised. We decided it would make sense to start a thread in the VDG forum to collect ideas for the UI’s design. Together with several other forum users (most notably rumangerst and andreas_k) we fleshed out the design, which currently looks like this:

Image of Plasmoid alternatives switching UI draft

Plasmoid alternatives switching UI, latest draft

Fast forward to today, when Marco announced on the Plasma mailing list that “now the alternatives config ui has landed.”. It always feels great to see one’s ideas come to life thanks to the collaboration with developers and designers. Even now, though, input is still welcome in the forum thread!

Everyone who wants to switch between Plasmoid alternatives easily, look forward to Plasma 5.1!

Posted in KDE

Get every new post delivered to your Inbox.

Join 31 other followers