Long time no see. My blog is moving, to be precise here. With the hope of starting to write more, and about more topics, I want to thank everyone who read my blog, which are way more people than I could have imagined, with the hope of seeing you again on the new one. And the promise of writing about what happened around my life, work, KDE and more over the next week, and after the Solid sprint.

This blog will, of course, stay up forever in case anyone needs to crawl back in my life. For what comes next, please head to http://freddi.me .

P.S.: I’ll be also writing in Italian on my new blog, from time to time. Scary, huh?

The solution – a proposed solution to improve our system, based on the previous posts.

This is, guess what, part 3.

Preamble about this post

First of all, an obvious apology for the delay. Unfortunately, I got sidetracked by many other things, and this post kept being delayed for any possible reason. But, what matters is the result, isn’t it?

Then, I’d like to clarify the following: this post is mostly about the concept itself and the way the user and the applications interact with the notifications – I am not the best person to talk about UIs, as you might know. So yes, you will see mockups, but please refrain from commenting on the UI aspect because I am not even trying to modify it – their purpose is merely to showcase the concept and the interaction.

Last but not least, you might find yourself saying “this can be done with the current API as well!”. It is in fact true – however, consider that what we are trying to do here is not to find out what is currently wrong with KNotification and friends (see part 1 for that), but to create a full new concept which goes beyond the API itself. Everything else is an implementation detail which will be eventually sorted, either with a KNotification replacement or extension.

Ah yes one last thing: I am assuming you are familiar with my previous blog posts – I won’t re-explain pieces of terminology such as transient and persistent.

That said…

Notifications as a living object

A new API is meant to be used for taking advantage of this new solution. We are used to have notifications be a one-shot mechanism after which we simply forget about them. This can and should still be possible for the most basic case, but what we really want to have is a living object, which exists during the lifetime of the notification. The reason why is quite simple, and it’s one of the things I can’t stand in the various notification systems we analyzed in “the status”.

Suppose you have a “1 unread mail” notification. Instead of clicking on the notification itself, you open KMail, and click on that unread mail. What should happen is that the notification reacts and solves itself after the event has been triggered. This is the basic preamble for the rest: a persistent (transient notifications of course are just a one-shot trigger) notification should be made persistent inside the code of the application itself, and the application must actively interact with the notification.

Grouping for efficiency

Grouping is one of my favorite topics and of course it had to be in. At the moment, grouping is a massive fail and can be solved only in a single way: on the server side. Relying on application for grouping is not a great idea, and kills the concept of being consistent – especially because we can afford to group on the other side.

This kind of grouping I am about to discuss applies only to persistent notifications – a separate section for transient notifications will follow, since the rationale behind both is quite different.

There is one single thing the application has to declare: the types of notifications it will be able to spawn. And this is already there in KDE, in the form of notifyrc files. This allows our server to detect how many events of a specific kind we are going to get. In this regard, we are going to get a notification like:

The main question one could ask himself would be: how do I detect the text then? This is a problem which KDE already solved with i18np, for example, which allows you to give two options for a string, depending if the occurrence the string is referring to is plural or singular. An hypotetical API call could be:

The drill is quite simple though – this not only allows our server to stack and group the events efficiently, but also to display the right “singular” message if all notifications but one resolve.

Grouping for spamming

This applies to transient notifications instead. The “hypotetical API” and result would be pretty much the same, but the rationale would be completely different. Suppose 40 of your contacts come online at the same time, or your application fails 40 times in a row – I guess you don’t want to be notified forever. The main difference is that in this case we would group only if we detect spamming. For example, we would refrain from grouping if 2 contacts come online in 5 seconds, even if one notification has not resolved yet. The main purpose of this would be to avoid clutter.

Grouping for activities

Some of you already predicted this – yes, I believe activities can really help in the way we perceive and interact with notifications. Let’s get back to our previous API call:

Now, imagine CoolNotification was smart enough to tell the main server that the application sending that particular event belongs to a particular activity. Or, let’s try even harder – suppose your application does not belong to an activity but your contact is. Maybe the API call might look something more like

Now, let’s assume you are working hard on a project you have to deliver tonight. And contact happens to be your girlfriend/boyfriend sending you some “<3<3<3<3<3<3” over Facebook. Ok, maybe not now. BUT. Your partner is actually associated with your “Leisure” activity, while you’re hard at work in your “Work” activity. What if you got something like that:

Not only – you would get a “reminder” just once. What happens when you click on the notification then? Your context is switched to the “Leisure” activity and the notification is expanded onto the grouping you would instead expect and we described before. And what about transient notifications? In this case, we would simply discard all the transient notifications which have spawned on other activities, as Facebook taught us in the previous post. In fact, I doubt you’d be interested in one of your friends coming online, but you might be in case your boss logs in onto your company’s jabber.

Grouping for backlogs

One of my favorites. Just like any other social network does, we want to keep a backlog of events. As such, we can easily “roll back” to an action we wanted to undertake before (or we actually undertook) and revise it, or do it again – such as reading a mail or talking with somebody. This requires some work in designing the API and for enabling application, but for sure it would be desirable to have something like this:

Integration with the outer world

Aren’t you tired of having your notifications scattered around your browsers, desktops, and whatevers? What if your backlog looked something like:

A big challenge would be trying to integrate all of your events into a single source – your notification area. Is this another step towards the “social desktop” and web integration? You betcha.

Integration with the inner world

Of course, it is important to integrate the other way round. Up to now, my mockups might have tricked you into believing that notification == bubble in some corner of the screen. But that’s very far from my plan.

If you follow my various work in the open source realm, you also know my commitment and passion to the Telepathy project. Telepathy has the peculiarity of being completely modular, by having a channel dispatcher (mission control) and a set of channel handlers. This means that whenever a specific channel request is received, mission control takes care of choosing the most suitable handler between those available.

Why is this relevant? Because I plan on porting the concept of dispatcher+handlers to the notification world. Let’s suppose for a moment that we have 2 main components: the notification server, as our dispatcher, and the notification applet, as the “fallback” handler. Now, every application can register itself to the server via DBus as a handler for a specific set of notifications:

Why setHandlerActive? For example, we might want to have our application acting as a handler only when it grabs focus (this could be and actually should be automatic in the final API. But we are just trying to expose the concept here). Now, whenever our server detects a new notification of some kind, it will check if a specific handler is available before falling back to the default one (the applet). If so, the notification will instead be forwarded to the application instead of the applet, BUT it will still feed the backlog. This means, for example, that KMail could display a neat animation upon a new mail whenever it has focus, and save the user from a (in this case) useless bubble.

But there is more: what if rekonq or any other web browser could act as a handler for social notifications (see previous paragraph)? For sure new interesting means of interaction can be discovered here!

Interaction

I saved it for last due to the highly controversial topic. Before we start with this, let me do a preamble: as a clever friend of mine uses to say, there is no way to satisfy everyone, there is instead a way for pissing off the less possible people. And more than this, there is no right solution, but in the specific case there is a solution which in the end might integrate better than others.

That said, I strongly believe our future notifications should have no buttons, which means one single action: Interact (like we have seen in Google+). This because 90% of the cases we want to cover are satisfied by this specific paradigm. What about the rest, you might ask? It is true that some of the notifications we know (incoming call) require more than 1 action – the challenge is to find a way to make this irrelevant by having the application itself (call ui in this case) be able to cope up with a single action.

But there is more – think Active. In an environment like Active (or a mobile shell) we cannot afford to have a notification with more than 1 action, given that pushing a small button is out of discussion. As such, we want to find a mean of interaction which works well on any platform.

We might find out during the road that we were wrong, but up to know we really want to strive for having a single mean of interaction for every action.

What’s next?

Code! Of course all of this should be shaped into something real, possibly into a new framework. You might have more news shortly… who knows 😉

…and it’s over!

I hope you enjoyed this little series. Of course, your feedback, ideas and suggestions are much more than welcome in the comment box below. I will keep you updated on what is going to follow and when you’ll (maybe) be able to see all of this on your desktop, tablet and more!

The solution – a proposed solution to improve our system, based on the previous posts.

This is, guess what, part 2.

About the previous post

It was great to see interested comments and most of all actual replies to my questions. I want to clarify a couple things before moving on:

Some of you mentioned the existence of indicators, Colibrì and such. No worries: I know about them and of course they played a big role in my analysis. Though, I intentionally left them out of my problem analysis since they’re not a part of the stock KDE framework, and we want to aim for a solution which somehow “integrates” everything in one single place and API

I got some great answers to the “more than one action question”. Especially, several people agree on the “invitation” (I really like the name, credits to TheBlackCat) to A/V calls. We’ll see how they scale as we go 🙂

Those of you who might have come here getting ready to read a comparison between GNOME, Windows, Mac OS, etc. will probably be partially disappointed in seeing that my primary case studies actually do not belong to a desktop environment. Why, would you say, since this is what we’re trying to address? The first and obvious answer is that KDE is no longer “only” desktop, and needs a concept which scales. The second one is that (not even that) surprisingly, completely different appliances have the same needs and the same problems to address. After all, when you come to think about it, a notification is just… a notification.

WARNING: Long post is long.

Facebook

We will start by analyzing Facebook first. It is a great example in many ways, and a bad example in other ways, and we will now see why. First of all, let’s take a look at the basics. I guess all of you know the system fairly well, but I found a couple pictures which are especially valid for showing you what I want to show you:

Let’s start analyzing the picture. First thing we notice, Facebook is split in 3 areas: friend requests, messages, and other. First question – why the heck do I have a friend confirmation on my “other” stream? I’d expect all friendship-related activities would go in the “friend” area. There is a reason for that, though, and it makes sense to me. Also, you might have noticed that this screenshot is from an old version of the system – intentionally. I want to try to focus on the differences and on the evolution.

Now, notice the left bar. We see that we have Messages and Friends again. Does it make sense? Why is that? To be honest this is a part I don’t like, since it’s a duplication of information, but it helps in proving a point: friends and messages are stuff on which you want to take an action, which might be delayed, but still needs to be undertaken. On the other hand, you can disregard and not be reminded of the fact that $GUY is stalking your pictures.

This is a child of the “transient vs. persistent” issue. In the web world, the concept of transient notifications almost doesn’t exist after all, but here we stepped over a similar principle: prioritization. Facebook clearly tells us that some events are more important than others, and should be considered in a different way. Coming to think about it, isn’t that also partly true for your desktop?

But the reader might now think: then maybe the whole transient deal is just bul^Wcrap. Not really – the reason is that a web application such as Facebook cannot really have such a concept since it acts in a disconnected way most of the time. But in that list, for example, I’d rather not have a persistent notification everytime someone “likes” my post. Ok, it sets my ego on fire, but it can become annoying. That’s a case where probably a transient notification would have cut it better.

But, let’s move on with our analysis.

Ok, that’s something more recent. What changed? The first impact would say “The picture on the left”, which is correct. But to me there is something much more important: grouping. Notice how before we had a notification about “X commented Y”, whereas now we have “X,Y,Z and other stalkers commented W”. There is also something else which gives grouping even more sense, you can notice it on your account: a small “x” icon on the top right of every notification. I understand it’s not really discoverable, and also its purpose is weird: if you hover on it, you’ll see a label “Unfollow”. In fact, clicking that button will simply stop giving you notifications about that specific post.

This is quite awesome in my opinion – not really for the feature itself, which I consider quite undiscoverable and barely useful for most of the audience (probably the reason of its discoverability), but for showcasing the power of grouping. Not only I will get one single notification for any event happened in a particular stream, but I also have a single entry point for deciding not to be notified of a particular stream anymore. In particular, there is something really significant here if you compare this approach with messaging: we are now used (thanks to mobile phones which now find fancy to arrange SMSs by conversation [yes I know threads existed before that but I’m considering what IMHO made them mainstream</hipsterism>]) to consider messages in the context of a thread.

Slowly, we are starting to consider events in a thread as well, where a starting point (in this case, a post) leads to a chain of events belonging to the same thread. To counter the obvious “posts can be considered behaving as messages”, sharing notifications and like notifications work in the very same (threaded, grouped) way.

Also, this leads to a MUCH lower number of notifications, and *uh oh* introduced somehow transient notifications in Facebook! If you notice, now everytime a notification enters your stream, you get a nice bubble on the bottom left, sitting there a couple seconds. The behavior of this thing is really interesting and worth a study.

This picture is good enough for showing you what I am talking about, but not for proving my point in its entirety. Suppose a new event happens, $GUY comments a picture of yours. The bubble will appear and a notification stacked. You can directly take the action by clicking on the bubble itself, including discarding (the X is much more discoverable here, imho). In this case, the notification will disappear. But there’s more to that, and here comes the concept of a transient notification.

Suppose you weren’t at your PC, you come back and you see a “1” in your “other stream”. Now, another guy comments. The same bubble appears, the notification is grouped, but “1” remains “1”. This is as close as a transient notification can get, since you will just notice 1 notification if you weren’t in front at your PC, but you would have witnessed a whole stream of comments if you were sitting right there, and you could have taken action on any of them. Instead, the “root” notification will just bring you to the first unread comment.

Also, the “x” in the bubble behaves in a very different way: instead of unfollowing the related stream of events, it simply “silences” the notification.

Enough with Facebook? Not yet, there is one last thing.

I am sorry I couldn’t find a better picture, but as you know the notification area looks exactly the same as this screen. What is weird? Yes, interaction. We’ve seen how Facebook is keen on having us clicking the notification to pursue an action, but here we have 3 choices:

Look at his profile

Accept

Reject

I think it’s bad. It’s really inconsistent with the rest of the interface, and kind of breaks the paradigm we’ve seen in the rest of the system, which in my opinion remains really good.

Google+

Google+ notifications are a very good case study for tackling the two weird things we found in Facebook: the separation between events (G+ has a single notification area) and the interaction. Let’s see why.

First of all we notice two obvious things: the grouping is even more aggressive: the “Friend” area of Facebook has been shrinked to a single grouped notification (this is closely related to how interaction works). Secondly, the layout helps the impression of grouping by showing a visual feedback of roughly how many events the notification refers to (by showing a set of pictures, or a “stacked” set of pictures). But the way one interacts with notifications is probably the most interesting part of G+:

Clicking on a notification brings up a full interface to the event that notification would have led to. This solves in a very interesting way the issue with interaction. Usually, the chain of arguments is that you need more than one action, you need a lot of them since otherwise the problem would be made worse, as instead of having one clear thing to do, you would have to cope with a downscaled interface for making your choice. There I fixed it: now you simply have your whole interface to deal with. But when we port this to our case (KDE), we should ask ourselves: is this that much different than opening a new window?

My answer is: not that much. The reason why people like this approach is that their workflow is not interrupted in any way – they can check out the event, maybe even reply to a message, then they can close the notification area and – bang – back to where they were. In a way, we can say that every G+ notification has one single action: “interact”.

Bored with all this social crap? Time for…

The N9, or: the mobile world

I am intentionally considering only the N9 since it’s the only smartphone I know really well (since I use it daily). I won’t be as long as before, since many things are just the same as before:

The N9 groups events: you get a single notification about having 5 sms incoming

The N9 does something very close to Facebook about transient/persistent notifications: you get the equivalent of the “bubble” which is instead a small banner on the top of the screen. The behavior upon clicking/stacking is exactly the same

The N9 allows a single action a-la-G+: when you act on a notification, a full interface is brought up for you to choose how to interact with it.

There are, though, a couple really interesting things in the N9. Let’s have a look at them.

Oh, how much I love this. The notifications on the lock screen really just cut it when I check my phone for events. And what about swiping on them to activate the notification itself? Just amazing. This really shows how it is possible to make notifications an integral part of your experience when you are “offline”.

I am really sorry I couldn’t really find a picture for the next thing I want to show you. Some of you might know the N9 integrates its notifications with Facebook ones, basically showing notifications from Facebook as native. The interesting part here is that the grouping happens in a completely different way. A typical example of notification you might get is:

3 new notifications

4 new messages

15 new friend requests

Whereas for the “global notifications” it doesn’t really make sense, it is really interesting to see that the “new friend requests” grouping is incredibly close to G+ as a concept, and acts in the same way.

Differences

Those three cases quite cut it in my opinion, and really help in showing mutual similarities and differences. In particular, we’ve seen how G+ tackled the concept of notifications in a way which is really close to the mobile world: a notification opens an application. Sure, the interface is different, but the principle remains – instead of giving the choice of taking a stock action, it leads you to a richer interface in case it’s obvious that you might want to undertake more than one choice. Facebook does this when it comes to messages and posts, but fails in applying this concept to friend requests – probably on purpose.

Recap

So what did we learn today? That the outer world already found several possible solutions to the problems we have previously outlined, and somehow faced most of the challenges we are up to. The circle is about to close with the next blog post, where I’ll try to gather what we learned up to now and try to come up with a concept which might, eventually, become the guideline for a new notification system in KDE. While you’re waiting, are there any other existing notification examples you’d like to point out? And thanks for reading until here, that was indeed a long run.

I will skip the obligatory wrap-up with where I’ve been and what I did, since it would be random boilerplate you are probably not interested in. Instead, I want to start a small series of blog posts about the status of notifications.

Why?

I didn’t wake up this morning with the idea – I am cooking this since several months instead. I’ve been talking extensively about this during the Workspace sprint in Barcelona, had some quick chats at Akademy, some others with some of the Ubuntu Designers at UDS, and more. Let me get this straight from the beginning: this is not really about the appearance or the technical implementation: this is mostly about the concept of notifications itself. But let’s start analyzing the problem.

Preamble about this series

This series will be structured in 3 posts:

The problem – outlining what currently we don’t have or doesn’t work (all of this in my opinion) in KDE.

The status – what have been others up to in this topic.

The solution – a proposed solution to improve our system, based on the previous posts.

This is, guess what, part 1.

Preamble about this post

Some readers might say: “hey, you’re outlining problems which we have in KDE that $STUFF already solved”, and in fact they’re right. I’m not ranting even here, I am just trying to approach the issue one step at a time. The solution I want to propose is a mixture of my own ideas and already existent solutions – this is why I want to try to be as clear as possible starting from the very beginning, which is finding out why we need something better.

What is wrong about notifications?

This question probably has a gazillion answers which might all be right or wrong, but I want to try and focus on a specific thing before anything: purpose. Let’s consider a number of use cases:

A file transfer finished

I received a new mail

A friend got online

Somebody sent me a message on IM

My battery is running short

An application encountered a non-critical error

What is the question here? Hypothetically, the first one which might come to one’s mind might be “Do I want to be notified?”, which is sensible – I have been asking myself this question quite a number of times. But we’ll get to that later. Another question, which is the one which bothers me the most, is “How do I want to be notified?”. I didn’t mention those use cases by chance – in my opinion (but I think this might be applied to many of my kind readers) there are very different ways in which those events should be displayed. I often get very annoyed by the fact I don’t have a way for interacting sensibly with my events.

Transient vs. Persistent

This is what I usually call the “transient vs. persistent” issue. Supposing I’m away from my laptop, if a friend of mine goes online or an application warns me about, let’s say, “connection dropped”, I sure don’t want to have a reminder about this when I get back to my PC. Although, I’d like to have a way for knowing that I got mail and a friend contacted me. At the moment, this is something we completely lack.

In my view, a notification should ease the workflow, not interrupt it. Easing the workflow means allowing me to quickly reach to the actions I need to undertake (such as reading an [hopefully] important mail or message) and not being bothered by stuff I don’t care about. Persistent notifications are probably the most obvious way to separate “todos” from “stuff that happened”. Which somehow links us to another problem…

Spam

Yes, spam. When an application goes totally crazy and starts spawning a number of notifications bothering the user and possibly your CPU as well. When I’ve been talking about this problem with some people, one of the first answers I got was “well, fix the application then”. Here’s why, in my opinion, this won’t work:

You cannot fix every application out there

At the same time, an application can be designed in a way such an event happens due to some unforeseen circumstances. Implementing a “spam control” on an application basis means introducing complexity just for the sake of notifying the user.

The definition of “spam” itself is quite tricky: having a serious HIG saying “you cannot stream more than x notifications every y” is very hard to follow for everyone, and applications might decide to go for their own “spam control” with their custom rules.

In general, this could be summarized with: “Letting the application handle that means introducing new complexity at the risk of sacrificing consistency”

This is why I strongly believe the notification system itself should be capable of handling correctly this case.

Interaction

There, I know you’ve been waiting for this. It’s likely the most controversial topic when talking about notifications, on which everyone has his own ideas. The very reason why I’ve not been talking about this before is that I wanted to show that this issue is strictly linked to what I said above. You might in fact find out that in most cases, persistent notifications require interaction, some transient might suggest an interaction, some transient can’t even do that. Let’s analyze our previous use cases in this light:

An application encountered a non-critical error (transient) – Same as above

As you see, there is a pattern there – it’s not by chance that interaction is required specifically by persistent notifications – as I said before referring to persistent notifications, they need to “reach to the actions I need to undertake”. But besides that, there is another interesting story here – you might notice that every notification only allows for one obvious action (apart from “discard”, which is a different business). Exercise to the reader: can you think about a concrete case (not a weird corner case) in which a notification might need to suggest more than one action? (as I said before, discard doesn’t count as such).

Context

It’s quite hard to find out if a notification has a context or not. If I’m working hard and I don’t want to be distracted, I sure don’t want that friend of mine telling me “OMG LOOK AT DIZ VID LOL”. My fault in the first place for leaving my IM open, but this happens so many times. This part of the problem is not really specific to notifications, which is just a small part to the bigger issue. But it is true indeed that the next step after solving the persistency of notifications would be solving the conflict of notifications not belonging to your current context.

Wrap up

There is indeed room for improvements. Where do we go from here then? If you’ve been following me, we need a system which is capable of bothering us as less as possible, while “remembering” us what we need to do, and allowing us to interact in a sensible way. Does such a system already exist? Yes and no. I guess this will be food for part 2, though.

In the meanwhile, why not dropping a comment about how you like the initiative, and what are your feelings towards the problems I explained? Maybe I missed something obvious? Discussions welcome. Until then, see you for the next part.

Some of you are surely aware of my work with PolicyKit and my efforts on making privilege escalation in KDE/Linux easy and accessible. The final result of my efforts was KAuth, now part of kdelibs. Although, since quite a lot of time I have been wondering on how to improve the whole escalation/trust experience, also covering a part of our middleware which is still not quite there.

One of the main issues in a Linux system at the moment is that we are not capable of identifying and ensuring that a client application *is* actually the application we are expecting. Anyone can fake a DBus service on the session bus, same goes for the process name and much more. This is also one of the big pitfalls of Polkit – as much as the authorization is guaranteed to be unique for each client, there is no way to determine if a specific client is *actually* supposed to execute a specific action or not.

These days I am at UDS, and I have been talking about the subject with Alex (Fiestas) and others quite extensively, thinking about a potential way of fixing it. It is not an easy topic at all and the solution is anything but obvious. We came to consider the following points:

A client application should be “signed” somehow against a central trusted entity

This trusted entity should be managing the authorization towards both privileged and unprivileged actions

This design aims to solve several problems beyond privilege escalation – namely, API access restriction. A very good example is inhibition. At the moment, any application can decide independently to prevent suspension on your system, making your laptop fry if it persists throughout the session. In an ideal world, we would like just a set of “trusted” applications to be able to execute that API. Of course, the concept of a trusted application can either come from the distribution or the user – we don’t really care about this. What we really care about is determining that a specific application IS actually the application we expect it to be, and that it has a set of specific privileges.

So our central “trusted” entity, ideally a daemon started in a way in which it could not be easily faked (I guess systemd might help here), would take care of being a central policy handler for several userspace features and applications. The main problem in this design is how to implement the signature check for each application, and how to make sure the application only can advertise its own signature. This is the solution which seems the most sensible to us at the moment:

The application gets installed through a package management system

A post-installation hook creates a user named after the executable of the application itself, or in a way which is easily identifiable by the application.

The same hook takes care of generating a key pair for the application. One key gets stored in a location accessible only by the newly created user, the other is stored in the database of the central trusted entity and is associated uniquely with the application (inside the central daemon)

The application would be a setuid executable. This way, it can escalate back to its original user for the signature handshake process, and get back down to the caller for everything else. This should not be a treat to security as the only privilege of the “special” user would be accessing that specific directory.

This way any malicious application without root access would not be able to fake its identity towards a “trusted” client application

Of course, this implies that only the package management tool and a developer tool should be able to create new certificates inside the central entity. Which would be guaranteed via the very same mechanism. Of course we start from the assumption that the OS installation is not compromised, which is sensible.

Before you complain about the bootstrapping phase, here is how it works. We assume that the package manager will be always installed first. Upon package manager’s installation, the package manager installs its own key (no need for its user, since it always runs as root anyways) into a known path. When the central trusted entity is installed, during the installation phase it self-installs the specific certificate into its database, trusting only the package manager in the first place. This way the system is ready to perform other certificate installations.

I would love to hear opinions on this before we can start working on a proof of concept approach and see if all that we said is somehow feasible. Do you see any flaws? Any obvious things we’ve missed? Any ideas for doing what we planned in a better/simpler way? Please discuss and let us know.

Howdy,
at KDE, we’re always busy on several things – this is the time of the year where we are putting most of our organizational efforts into Akademy. In particular, a couple weeks ago me and Claudia joined Laur in advertising Akademy in Tallinn, and I held a workshop at the IT college about KDE/Qt development. Everything is shaping up nicely and the location seems really cool – you can indeed look forward to one of the best Akademy events ever! The three of us also did a quick interview for the local community, which is on YouTube, if you want to take a look at it.

Are you attending Akademy?

Hopefully you are, in case you are not, you definitely should. Supposing you are, PLEASE REGISTER SOON! The conference seems to be far away, but July is much closer than it seems. We need to know how many are we to plan all of the events efficiently and to avoid running out of space and resources. So register soon, register early, register here. As always, the registration is free of charge – if you are a professional attendee though, please consider registering as a professional. The registration fee you’d pay in this case will help us in organizing the event and add resources to our pool.

Book your accommodation!

July is going to be a busy month, and Tallinn is going to be the place to be for its first week. This means there is a shortage of rooms already, so don’t miss out in booking your accommodation quickly to secure your bed. There are several suggestions here, you can spot the option which suits you better. Same goes for the flights – most of them will be packed during those days, and prices are going to rise very soon. So book early, book now!

What about you?

Unfortunately, this year I won’t attend the weekend because I have another commitment during those two days, so I won’t even be giving a talk, and unfortunately will miss out on some of the awesome keynotes which have just been announced :(. But this doesn’t mean I won’t be there – I plan to crash the party on Monday, so I can proudly say:

Have you heard the last news from Aleix? We are aiming towards finding a new, concrete vision for our beloved KDE workspace. We already gathered a team of KDE superstars, we have had some preliminary discussion at Plasma Active sprint; there’s just one thing missing: YOU.

Thanks to Luca, Ben, and all the amazing guys behind the KDE Forums, I am honored and pleased to introduce you to:

What is it? As Luca explains in the forum announcement, a new vision requires new ideas and new people. Do you think you have the best idea ever for our desktop environment? Is KDE4 perfect for you, but there’s that little something you can’t stand? Do you think you have got what it takes to show the world how YOU see the desktop environment of the future? Then indulge no further and start posting: developers will jump through this new forum frequently to take a look at your creations, comment on them and – why not – make them real.

This forum will hold posts, mockups and explanation of any new idea you could have. It doesn’t necessarily need to be over something new, or over something existing: just let your fantasy guide you – the more innovative your idea is, the better. Mockups are of course very welcome, and so is artwork: but if you just have a great idea for a new concept, we will be also happy to read through it thoroughly even if there are no nice pictures.

This project has just started, so don’t miss the chance to be between the first in posting your ideas. Are you ready to make KDE rock even more? We are, and we are just waiting for you.