Monday, April 13, 2015

Gone Hacking

This week we have Hack Week at SUSE. The whole engineering team works on projects of their choice during this week. Everybody is free to innovate, to learn, and to collaborate with others.


We are doing it for the twelfth time. Sometimes magic happens, sometimes people learn a new skill, sometimes we become smarter because we know one more way how not to do things. We always have lots of interesting projects. Hack Week is an amazing experience. You actually can join.

I'm part of the organization team again, providing the environment where our engineers can be creative, productive, have fun, and learn. If I find some time to work on my own project I will tackle the one I worked on last Hack Week already, Project MySelf.

I'm gone hacking now. See you next week.

Friday, April 10, 2015

55.555 downloads of ownCloud in a box

Recently I passed a magic number with my ownCloud in a box appliance. It hit the five fives, 55.555 total downloads, on SUSE Studio. It is the most popular download there. I would never have imagined that so many people would be interested in it and use it when I started with this. Amazing.


When Frank started to discuss the idea of ownCloud and announced it at Camp KDE five years ago (another five, hooray) I was immediately intrigued. The idea of giving people control about their data in the cloud was powerful. Over the years it actually has gained even more power and relevance, as not only the cloud has become ubiquitous but also the threats to abuse it.

With SUSE Studio it became so easy to build easily deployable images for a broad variety of targets, such as a live CD, a VMware image, or an installation disk for a physical machine, that I just had to do it. It follows along the philosophy of ownCloud to make it as easy as possible to run it, so many people can do it on their own. ownCloud in a box is an easy way to try it and get started.

I'm looking forward to the next fives, whatever they will be. ownCloud has great success, and its development is coming along nicely, but I would still like to see some more things.

From a technical point of view, client-side encryption would allow to use a hosted ownCloud without having to trust who is hosting the server. That would extend the benefit of controlling your data in the cloud to a whole new group of people, who can't or don't want to run their own server. There is some work going on in this area. Let's see where this goes.

From a community point of view it would be great, if the contributor agreement would be a bit more fair towards contributors. It's quite asymmetric. You broadly give all rights on contributions to ownCloud Inc. but only get back what you would get anyway by publishing your code under the AGPL. I understand that this enables the ownCloud Inc. business model, and that a successful company is good for the community. I also have no doubt that the company is operating with the best intentions for the community. But if there needs to be a formal agreement, it would be nice if it would better take into account the interests of both sides. I'm sure there would be ways how to do that without jeopardizing the business model.

In general I'm very impressed with how far ownCloud has come, and I'm happy that I could contribute my little part in it.

Saturday, April 4, 2015

The Space-Time Continuum of KDE's Activities

This is not about KDE e.V.'s new time travel program. This is about Plasma and its concept of Activities. They have been a topic of hot debates. Some people love them, some don't care. Björn called for finding a new metaphor which better fits the mental model of the user, so that Plasma's activities can appeal to a larger group of people. Here are my thoughts.

Orthogonal or hierarchical?

The premise of Björn's quest for a new metaphor is that the current one doesn't fit the mental model of the people using activities, especially how activities are related to virtual desktops. He sees activities not as an orthogonal concept to virtual desktops, but as an hierarchical one.

Matching the mental model of the user is crucial, because this defines how natural and easy it is to use them. You can learn abstract concepts and be trained in creating new mental models or in using rules to work with concepts without having a good deeper understanding. But this needs time and effort, which especially casual users are rightfully not willing to spend. And it's not fun.

Orthogonal concepts are independent of each other, they live in different dimensions, you can use one without affecting the other. Hierarchical concepts use the same dimension, but there is an order, one concept is above the other, such as one providing a grouping for another.

You could see activities as independent of virtual desktops, and that's how they are implemented. But there is one issue with that. The presentation we use addresses the same mental model, that of areas arranged in space.


That makes it hard for the user to know where things are. Does the screen present an activity or a desktop? Do I have to change the activity to go to my email client or do I have to switch desktops? When I go to the left or right, do I change activities or desktops? You can learn the concept of activities to be able to answer these questions, but if you use the same mental model for activities and desktops it can appear confusing and inconsistent.

I think there are two ways to address this issue. One is to clearly express that the concepts are orthogonal in the user interface and the naming. The other is to make activities and virtual desktops fit into the same mental model by clearly separating their responsibilities, and eliminate the metaphors which use the same mental model for different parts of functionality.

Time

One powerful way of expressing the orthogonality of activities and virtual desktops would be to represent virtual desktops in space and activities in time. These are two different dimensions, and it actually would go quite naturally with what the two concepts represent.

Virtual desktops are different segments of the space of your desktop. They are usually arranged in a plane and there is a relation of left/right and above/below. Desktop effects support this model by providing spacial transitions when switching desktops.

Activities are less about where you do something but about when you do it. They represent projects or different times of your usage of a computer. You program as part of your job in your IDE in the morning, browse the web and watch YouTube movies in the evening, and once everybody else is sleeping you play a game. You use different applications at different times, need different configurations of your desktop, and there is a relation of before/after between these.

To express this in the UI the activity switcher and configuration should not use concepts of space which overlap with how virtual desktops are presented. The closest idea I have seen is the activity switcher in Plasma Active. This uses a different and specific mechanism to switch activities. It even vaguely resembles a clock with its circular movement of activities when browsing through available activities, expressing the concept of time.

Screenshot from contourproject
When going with this mental model and the corresponding metaphors, suitable names for activities and virtual desktops could be "times" and "spaces".

Space

Following the idea of a hierarchical relationship of activities and virtual desktops we could represent them using the same dimension, but express activities in groups of virtual desktops.

Here is a mockup illustrating this idea:


Activities would control how groups of virtual desktops would behave. They would be used to define what wallpaper and which desktop widgets to show, what applications to start or stop, what settings for notifications or power saving to use, etc. All this would be tied to on what virtual desktop the user is. But there wouldn't be two different ways how to switch between desktops and activities, but there would only be one. Activities would implicitly be switched by switching between virtual desktops.

So when you are at work you would be on the left side of your desktop with your corporate wallpaper, running IDE, web browser, what you need for work. The right side of your desktop with the games would be shut off. For a presentation you would go to the desktop which switches off notifications and power saving. Email would be there as a shared resource all the time. In your free time you would be on the right of your desktop, with nude pictures of your cat as background, running inappropriate videos in your web browser, and switching off everything else than your games for maximum frame rates. Or something like that...

In some way activities would be a subset of virtual desktops and in some other way they would be a configuration for a virtual desktop. This follows along the lines of the "Different widgets for each desktop" configuration option, where each virtual desktop more or less gets its own activity.

The hierarchy would not strictly be activities above and desktops below, but there would be two concepts, the group above the desktop, and the configuration below the desktop.

This would need a few changes in representation of activities and virtual desktops, but it could better match the mental models of users, because concepts are clearly separated and existing understanding of controls can be used.

When going with this mental model and the corresponding metaphors, suitable names for activities could be "desktop groups" and "desktop configuration", and virtual desktops would just remain "desktops".

Conclusion

Naming is important, but even more important is expressing concepts clearly and unambiguously. In the user interface behavior and visual representation trumps names. That said, for talking about the concepts, especially in code and documentation, good names are essential.

To me seeing activities as configuration of groups of desktops is most natural. That matches my mental model.

Thursday, September 4, 2014

Going to Akademy 2014

I'm going to Akademy. Now. I'm about to leave for the train to Brno and am looking forward to the people, presentations, discussions, workshops, hacking sessions, beers, ideas, and everything else which makes Akademy special every single time.


For me Akademy will start with a series of presentations:

On Friday I'm presenting the report of the KDE e.V. board to the membership. It will be the last time I do this, as my term ends, and I will not run again. It's the end of nine years being on the board of KDE e.V. Not being on the board anymore will be a change, but I'm happy that we have great candidates to fill the open positions. I also still want to and will be involved in KDE e.V., but as a regular member.

On Saturday I will give a short talk about Inqlude. This is a side project, I really enjoy working on, and it gains more and more traction. With the release of KDE Frameworks 5 we now have a huge number of libraries from KDE listed there. There is plenty of awesome stuff to use for any Qt developer. I will report about the current state, and would also be happy to see more people getting involved with further developing the tool and the site.

On Sunday I will give the community keynote. I will talk about how KDE makes you a better person. Some more information is on the dot in the announcement of the Akademy keynotes, and the interview Carl did with me. KDE is an amazing environment which has given me a lot. I will talk about how I see KDE enabling growth in people, and how we can maintain that.

There are many more interesting talks in the program. I'm especially looking forward to Kevin's talks about craftsmanship, and agile, as I think we can learn some good things from what others and the software development community in general are doing. I'm also excited to hear more from the KDE Visual Design Group. They will talk about community design and how designers tick. The visual design group has made a big difference to KDE in a short time, and I'm looking forward to see more of that.

But there is more than presentations to Akademy, meeting old and new friends, discussing technology, community, and many other things, hacking with others on the latest projects, and more...

See you all in Brno tomorrow.

Tuesday, August 26, 2014

Running on Cheese and Chocolate

This is a big thank you, a thank you to all the people who made the Randa Meeting 2014 possible, the people who invested their time and their energy to go there and work on free software, and the people who made donations to support this.

Tons of things happened at Randa this year. Among other things there was lot of porting work to KDE Frameworks 5 done on kdevplatform, KMyMoney, Gwenview, KMix, Artikulate, and Kig. KDevelop got QML and Javascript support, the API docs got some love, Phonon 4.8 Beta was released, KStars tools got polishing, Kdenlive got a roadmap, and the first alpha of the Inqlude tool was released. We wrote a book, and made a movie:


It can't be overestimated what kind of magic place Mario created at Randa. It is such a focused and supportive environment, that it's hard to not be productive. It generates a sense of community which reaches way beyond the meeting itself, and fuels so much of future work. I have written about what makes this special spirit. But I suspect that the real secret is that Mario runs us on Swiss cheese and chocolate for a week.

So thanks again to the donors, to the sponsors, to the people who wrote code, or text, or took photos, or brought their kids, or organized, or simply provided happiness, or helped in any other way. It was an awesome event.

Wednesday, August 13, 2014

The Book

When inviting to the Randa 2014 meeting, Mario had the idea to write a book about KDE Frameworks. Valorie picked up this idea and kicked off a small team to tackle the task. So in the middle of August, Valorie, Rohan, Mirko, Bruno, and me gathered in a small room under the roof of the Randa house and started to ponder how to accomplish writing a book in the week of the meeting. Three days later and with the help of many others, Valorie showed around the first version of the book on her Kindle at breakfast. Mission accomplished.


Mission accomplished is a bit of an exaggeration, as you might have suspected. While we had a first version of the book, of course there still is a lot to be added, more content, more structure, more beautiful appearance. But we had quickly settled on the idea that the book shouldn't be a one-time effort, but an on-going project, which grows over time, and is continuously updated as the Frameworks develop, and people find the time and energy to contribute content.

So in addition to writing initial content we spend our thoughts and work on setting up an infrastructure, which will support a sustained effort to develop and maintain the book. While there will come more, having the book on the Kindle to show it around indeed was the first part of our mission accomplished.

Content-wise we decided to target beginning and mildly experienced Qt developers, and present the book in some form of cook book, with sections about how to solve specific problems, for example writing file archives, storing configuration, spell-checking, concurrent execution of tasks, or starting to write a new application.



There already is a lot of good content in our API documentation and on techbase.kde.org, so the book is more a remix of existing documentation spiced with a bit of new content to keep the pieces together or to adapt it to the changes between kdelibs 4 and Frameworks 5.

The book lives in a git repository. We will move it to a more official location a bit later. It's a combination of articles written in markdown and compiling code, from which snippets are dragged into the text as examples. A little bit of tooling around pandoc gives us the toolchain and infrastructure to generate the book without much effort. We actually intend to automatically generate current versions with our continuous integration system, whenever something changes.

While some content now is in the book git repository, we intend to maintain the examples and their documentation as close to the Frameworks they describe. So most of the text and code is supposed to live in the same repositories where the code is maintained as well. They are aggregated in the book repository via git submodules.

Comments and contributions are very welcome. If you are maintaining one of the Frameworks or you are otherwise familiar with them, please don't hesitate to let us know, send us patches, or just commit to the git repository.



I had fun writing some example code and tutorials for creating new applications and how to use KPlotting and KConfig. The group was amazing, and after some struggling with tools, network, and settling on what path to take, there was a tremendous amount of energy, which carried us through days and nights of writing and hacking. This is the magic of KDE sprints. There are few places where you can experience this better than in Randa.

Update: Many people are involved with creating the book, and I'm grateful to everybody who is contributing, even if I haven't mentioned you personally. There is one guy I should have mentioned, though, and that is Bruno Friedmann who made the wonderful cover and always is a source of energy and inspiration.

Sunday, August 10, 2014

Announcing first Inqlude alpha release

Three years ago, at Randa 2011, the idea and first implementation of Inqlude, the Qt library archive, was born. So I'm particularly happy today to announce the first alpha release of the Inqlude tool, live from Randa 2014.

Picture by Bruno Friedmann

I use the tool for creating the web site since quite a while and it works nicely for that. It also can create and check manifest files, which is handy when you are creating or updating these for publication on the web site.

The handling of download and installation of packages of libraries listed on Inqlude is not ready yet. There is some basic implementation, but the meta data needed for it, is not there yet. This is something for a future release.

I put down the plan for the future into a roadmap. This release 0.7 is the first alpha. The second alpha 0.8 will mostly come with some more documentation about how to contribute. Then there will be a beta 0.9, which marks the point where we will keep the schema for the manifest stable. Release 1.0 will then be the point where the Inqlude tool will come with support for managing local packages, so that it's useful for developers writing Qt applications as end users. This plan is not set in stone, but it should provide a good starting point. Longer term I intend to have frequent releases to address the needs reported by users.

You will here more in my lightning talk Everything Qt at Akademy.

Inqlude is one part of the story to make the libraries created by the KDE community more accessible to Qt developers. With the recent first stable release of Frameworks 5, we have made a huge step towards that goal, and we just released the first update. A lot of porting of applications is going on here at the meeting, and we are having discussion about various other aspects how to get there, such as a KDE SDK, how to address 3rd party developers, documentation of frameworks, and more. This will continue to be an interesting ride.