Next Iterations of the KDE Workspaces

In this post, I’ll try to provide an overview of the results of the work we’ve done during the Workspace sprint in Pineda de Mar, Catalunya, Spain. The sprint is still going on, unfortunately I had to leave early to attend a friend’s wedding. Before going into any details, a few thank yous and credits are in place: Aleix Pol and Alex Fiestas for being excellent hosts organising this sprint (including picking this terrific location which allowed us to concentrate 100% on our processes and 0% on the beach), KDE Spain for sponsoring our food, the KDE e.V. (and its donators!) for sponsoring travel expenses and providing organisational backing, Kevin Ottens who took a sizable slice of time out of his vacation account in order to facilitate meetings, enabling group dynamical processes and generally being a good moderator, Björn Balasz for chipping in time and providing his background in psychology and usability and of course open-slx, my awesome employer.

Activities central: One focus that we have been working on in Plasma quite extensively is organising your documents, contacts, applications, files and other digital assets into Activities. Activities provide a contextual way of organising your devices. Activities usually enclose these resources into personal context which might include locations, contacts, documents and any other resource we’re able to express in terms of semantics. (So pretty much all. :))
We’ve identified areas where we can improve the activities workflow. Switching between Activities and getting an overview can surely be improved. There have already been some ideas floating around, and some smaller and larger improvements are in the pipeline to see the light of day in one of our future releases. In some parts, we’re transplanting features we have matured in the Plasma Active user experience into the desktop. The Plasma Way: Share code across devices, investigate workflows across apps and device borders. (So a workflow which we want to enable may actually involve using more than one device — we want to make especially these patterns a lot easier, intuitive and fun to use. There’s a few real challenges in there, although many parts involve someone “just sitting down and doing it”.

Personas: I’ve dedicated a separate blog entry to Carla and Raj, our brand new personas, so I’ll kindly refer you to that.

Social networks and messaging: Carla’s and Raj’s lives involve talking to people across different channels. We want to enable these patterns by providing deep integration of messaging and social networks into the desktop. While we likely will not ever support every single feature of all social networks, we definitely want things like native notifications for messages, and being able to keep tabs on the going ons around you. Technologies we’ve been working on in the part years and which are coming to mature now will be a great help in creating a nice user experience here: Akonadi, Telepathy being at the forefront of double-plus-useful frameworks here.

Along with the integration of more social services into the workspace, we also want to enable cross-device workflows using online services. Examples for getting your data across devices are ownCloud, but also commercial services like FlickR. I think we are in the position to put Free software solutions first, but not excluding proprietary services, but enabling Carla and Raj to mix and mesh whatever they uses. In this, we need to pick up the user where he or she is now. We’re not going to switch users to Free software users if we require social disruption in their lives. :)

Something I found particularly exciting was the call by a few participants to reinvigorate Project Silk. The idea is to make the web, web apps, -applications and -services first class citizens in the desktop. This can range from the introduction of a site-specific browser to deeper integration of online content and services: think of FlickR integration in Gwenview, caching data from online sources, providing native UIs for services that are otherwise a bit cumbersome to use, and much, much more. I’m surely hoping we’ll see a surge of improvements in this area. I’m also happy that Richard and I documented our ideas quite well when we came up with them in 2009 at the Desktop Summit in Gran Canaria (coincidentally also Spain, at least technically ;-)).

There’s almost too much exciting new ideas that it’s hard to report about all of it without choking your feedreaders or webbrowsers, so I’ll just mention a few more telegramme-style. Feel free to ask in the comments if you have specific questions, or just head over to the plasma-devel@kde.org mailinglist where you can discuss with the whole team involved.

  • As base for identifying needed improvements, we will concentrate our thinking on which workflows we can enable for users. This first line of identification will be thought about without a specific device in mind. Much more so, workflow can and often do include different devices. We want this to be at the heart of our designs.
  • Virtual desktop will remain what they are, orthogonal to the principle of Activities, We do not plan any sweeping changes here, in order not to break engrained workflows. Nepomuk synchronisation across devices is still a very challenging problem. It needs more design and research work to define an achievable scope.
  • We’ve proposed a few changes to KDE’s release rythms, basically decoupling the releases of workspaces, applications and (in the future) KDE Frameworks. This is basically a continuation of KDE’s effort to implement branding closer aligned to how we work and what we produce; currently under discussion.
  • Notifications will likely receive a rework in order to make them more activity aware, and to display insensitive information on a lock screen, just to name two examples.
  • Everybody agreed that stability and quality are key for users. We will avoid disruptive changes, but concentrate on making existing tools better, and new features not get in the way of existing workflows. A few changes in our processes have also been planned,
  • Clemens of Blue Systems attends the sprint as well, it’s good to see new faces participating and supporting KDE. We’ve had very interesting conversations about all kinds of topics.
  • Maybe the most important thing was the sharing of the Plasma vision with a wider team of contributors. It strikes that Plasma lately has been moving so incredibly fast that we built up a backlog of communication, some of which we managed to knock down in the past days, but it surely will take some time until all ideas, concepts and processes are ingrained into everybody’s brains. The first steps for this have been taken, however.

As you can see, that’s a lot of stuff we have carved in sand in the past days. It will need refinement, and consolidation, more design, ungodly amounts of hacking and surely won’t all be implemented in a whim. It does however give everyone a good idea where we’re going, and what the steps into that direction are. Exciting times ahead. If you’re looking for more sprint results, I’d also read Marco’s blog about it.

Saying good bye was relatively easy this time around, as most people attending the sprint will also be at Akademy, which starts in two weeks in Talinn, Estland. The next Plasma sprint is planned in September in Switzerland. The plan is to mostly work on libplasma2, QtQuick2 and Frameworks 5 in order to technically pave the way into the future of the Linux workspaces.

16 Responses to “Next Iterations of the KDE Workspaces”

  1. Cornelius Schumacher says:

    It’s great to hear of the activity around the workspaces. Sprints for the win :-)

    It’s also great that you created personas. Have you also talked about doing more of this user interaction design work? Doing user observations and tests, evaluating different prototypes, iterating design on user feedback and expert inspections, stuff like that? Getting to the right decisions before there is a huge effort invested into final code?

    • sebas says:

      Unfortunately, we weren’t able to go into too much detail how we can include these personas deeper in our development process. We did talk about how they’re useful, and how they should be used, but we did not, for example have design sessions where we actually used this process.

      On the other hand, for some people it is quite common. When we asked around, everybody was familiar with the concept. The main purpose of this exercise was to streamline our vision among the team. Creating personas was successful in that regard.

  2. Hello Sebastian and thank you for all your work so far.

    I will take the opportunity to ask, on the matter of taking activities one step further, are there any plans for applications to use different profiles under each activity?

    For example, it would be nice if Dolphin had the ability to show different entries under the “places” tab, depending on the activity it is associated with.

    I have no idea if that is technically possible, just wanted to drop it here for some brainstorming. If it’s the wrong place, just let me know. =)

    Neophytos

    • sebas says:

      It’s technically very easy, the activities-related part (which activity are we on right now? When does it change? What activities are there?) are really easy to do, using libkactivities it’s just a few straightforward lines of code. That’s the main purpose of this lib, anyway.

      We’d love to see applications making more use of that, Activity-aware places would be cool, maybe KMail only showing emails from certain accounts or folders, different recently opened documents in Kickoff, different startup screens with recent documents for gwenview, okular, etc. would all be wonderful, different start folders for apps’ file dialogs, different bookmarks for the browser, … the possibilities are endless.

      My guess would be that we will see more and more activity awareness in apps. :)

  3. Mark says:

    What I would like to see is the possibility to switch activities depending on time and also on network enviroment. The switching of network environment should also allow to automatically switch the standard printer.

    • sebas says:

      Automatic activity switching is planned, but I think it’s not quite easy to get perfectly right. Manual switching should be made easier, and if we can know for sure, then automatic switching should be possible as well. I’d rather have the user switch manually, then disrupting his/her workflow by trying to be (too) smart.

      As Activities are all about context, you’re basically right.

  4. Kevin Kofler says:

    > We’ve proposed a few changes to KDE’s release rythms, basically decoupling the releases of workspaces, applications and (in the future) KDE Frameworks.

    That’s going to make life really hard for us packagers: No more coordinated releases, harder to track minimum version requirements etc. I think it is a big mistake to do away with the coordinated software compilation releases.

    • sebas says:

      We are currently discussing advantages and disadvantages of it. I personally think it would bear some value, but I’d much rather have this discussion on the appropriate mailing lists (kde-core-devel, for example) than here.

      The proposal is not about no more coordinated releases, but about decoupling the release schedules. That is also already explained by a few people on the list.

  5. Tony says:

    Interesting developments.

    In relation to Activities, I think it would be really useful that particular Applications are automatically started when starting an activity (or switching to). Perhaps applications with certain profiles (e.g. Dolphin open with tabs showing all folders related to a project).

    I don’t think that this is possible at present. (Which makes activities redundant in my case).

    Thanks.

    • sebas says:

      Au contraire :) Starting and stopping applications is entirely possible, and just works in the default setup of Plasma Desktop. There’s a niggle here and there, but overall, Session Management and Activities works together very well.

      Some apps don’t restore their state properly, for those, we’ll need fixes (and bugs filed), but overall it works surprisingly well. I’m in fact using that mechanism daily, on more than one machine. You’ll want Plasma Desktop 4.8 for that.

  6. Tony says:

    Thanks Sebas,

    Good to know that this is possible right now. I’ve been testing, but I have some issues with the sessions/activities combination (I got message ‘invalid option -session’ on running the activity). But it did work on the last try. I’m using KDE 4.8.3 (kubuntu)

    I think it would be useful to implement separately from the sessions. The functionality seems to be ‘hinted-at’ if you do as follows: Create Activity –> Templates –> Development Activity… A dialog box appears “This activity template requests to run the following applications” (empty in my case — perhaps I do not have the intended applications installed).

    Keep up the good work.

  7. fasd says:

    Ok… but will this convert KDE to facefuckin’-like-this-like-that-look-at-my-duck-face-in-the-bathroom-mirror-have-to-log-in-to-fb-to-run-konsole thing? Will you force this in invasive way for regular users?

  8. apache says:

    I wonder from where developers draw ideas about KDE future and based on what factors they do planning of their work.
    It would be great if developers could have a look at KDE brainstorm and implement some user’s ideas. At the moment I as a user I am not even sure if they read it at all. KDE brainstorm and bugs.kde wishlist should be integrated into one system and developers should be more active in giving feedback.

    • sebas says:

      For me personally, I have an overall idea which aspects I want to see improved, and I work on those. It almost never happens that I’m actively looking for something to work on, the in-queue is always more than full, so I never actually lack ideas what I think needs doing, and what I’m working on.

      Much of what we work on is decided on an individual basis (either by the person herself, or the employer), and fleshed out in communication with the team (either online, or during sprints).

      The thing with brainstorm is that it addresses a problem, developers don’t usually have. Sure, it’s a good source of information, but given that I already have way too many things on my plate (and almost everybody I know in KDE has that), it doesn’t provide much direct value to me.