The discussion around including online search results in the workspace, and especially in the app starter, reminded me of a discussion we had some time ago about including online search in KRunner queries. First of all, I think the idea of including online search results directly in the shell is great. It’s not new by any means, but it serves value to the user, and in fact, I use it daily and would not want to miss it.
In KDE Plasma, we do that for a few years already. I recall sitting down during the Gran Canaria Desktop Summit in 2009 with Richard Moore and hacking on a KRunner plugin that includes results from Wikipedia and Wikitravel in the KRunner search results. We got that working pretty quickly, and the plugin is shipped on most installations of Plasma Desktop out in the wild nowadays, and nobody complained. How come?
Privacy by Default
First of all, we do it quite differently from the way Canonical does it in Ubuntu. Sending every search query to an online service forms a privacy problem. Especially when not using SSL encrypted HTTP requests, people around you can basically wiretap your traffic almost trivially, or intercept it using man-in-the-middle-attacks. Also, the service receives all your queries as well, not something I’d want in general. Even if I trust someone in principle doesn’t mean I have to tell them everything I do.
While we ship plugins that promote Free culture (in this case Wikipedia and Wikitravel), one could easily add support for Amazon as well, and of course for all kinds of search engines. (We do include a couple of proprietary web services in KDE, but we’d never silently send them data when it’s not clear to the user or explicitely asked for) What we, as Plasma maintainers will not accept however, is triggering these online requests on every query typed. Basically, we won’t send anything across the net without the user explicitely requesting us to do so.
Maybe we could raise some funds this way, but we think that our users are best served with a system that gets advertisement out of the way. I’m personally easily annoyed by commercial offerings which jump into my face without me asking for it, and I understand I’m not the only one.
Earning Money through affiliate programmes
A few months ago, David Faure, the maintainer of Konqueror, KIO and a lot of other important pieces in KDE got contactetd by the DuckDuckGo search engine. DuckDuckGo asked if KDE would be willing to take part in their affiliate programme. David passed this on to KDE e.V. and offered to do the necessary changes on the code side if we decide to go ahead with this. DDG offered us to receive 25% of their earnings per clicked ad when the user searched through Konqueror (or in fact through the webshortcut). As we have already been shipping a search provider for DuckDuckGo for quite some time, it was enough to add KDE to the search query and sign a form with KDE e.V.’s banking details. That’s some free money, maybe not much, but who knows and every bit helps. The impact technically and to the user is minimal, and it didn’t require any changes to our privacy principles and setting, so ahead we went. That means, if you feel like supporting KDE through your online search, that’s easy: Use the ddg: search provider (see below). This works starting with 4.9.0.
Online, but respecting privacy
So, offline and private by default, but how can we still include all the goodness from the Internet in your local search results, so we save you a trip to your webbrowser when we can? There are a few ways you can easily query online services from your desktop:
Wikipedia, Wikitravel (and other MediaWiki-based services): ALT+F2, enter “wiki $YOURQUERY”
Videos on Youtube: ALT+F2, enter “videos $YOURQUERY”
Google search: ALT+F2, enter “gg:$YOURQUERY” (use ggi: for google images, dd: for DuckDuckGo, amz: for Amazon, qt: for Qt API documentation, php: for PHP docs, many, many more are available as well, have a look at Konqueror’s webshortcuts for a full list, all of those are transparantly supported in KRunner as well)
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 firstname.lastname@example.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.
After Marco had added initial support for WAC apps to Plasma, at open-slx, we spent a few cycles on taking this to a next level. WAC apps are apps written in HTML5 which are shipped as packaged websites with everything needed included in the package. On top of the normal webbrowser APIs, WAC apps can access a set of API calls that allow access to various aspects of the underlying system, device and network information, contacts, hardware such as camera, accelerometer, location sensors, etc.).
Most of the hard work is already done by the excellent webkit. The parts needed in Plasma and KDE are support for loading the package format, and allowing access to certain system APIs. Marco has written an AppletScript Plugin, which basically wraps the WAC format into a Plasmoid so it can be loaded into any Plasma Shell (Plasma Desktop, Netbook, Active, MediaCenter, etc).
Implementing the WAC-specified APIs turns out to be quite a bit of work. I have started on the DeviceStatus API, and on my laptop, HTML5/WAC apps are now able to access system information such as software versions and battery status. The complete WAC API is quite big, so right now we only support a small subset. The basics are done, and with growing support in this API, we’re able to run more and more apps on Plasma devices.
Everything is running inside a sandbox (in our case a webkit container inside Plasma), so it is quite easy to restrict everything beyond the browser’s DOM API. When working on the permission model, I reflectd about how the user actually handles these permissions. Many people seem to complain that even if the app announces which APIs it wants to access, the user still does not really have a choice beyond all-or-nothing, so most people end up blindly OK’ing whatever the app wants. The code for WAC in Plasma is set up in a way that we can allow access only to certain bits of the API, disallow access or — and that’s the catch — fake access. Fake access means that we tell the app that we support certain APIs, but we will only deliver empty or bogus data, so the app still works, but our address book is not in jeopardy of being sent to some blackhat in a far away country.
Das Web-Scheibchen Widget ist in Plasma (in kdeplasma-addons, noch bis zum Git-Umzug am Wochenende) seit 4.4 enthalten. Ein Web-Scheibchen ist ein Teil einer Website auf dem Desktop. Das kann hilfreich sein, wenn man einen Ausschnitt einer Website im Auge behalten will, allerdings dafür aber keinen kompletten Browser starten will.
Richard Moore und ich haben das Webslice Applet auf der Akademy 2009 in Akademy geplant, richmoore hat dann einen Prototypen geschrieben, den ich in ein einfaches Plasma Widget umgesetzt habe. Seit dem ersten Release zusammen mit 4.4 hat sich allerdings wenig dran getan. Es funktioniert im Prinzip recht einfach: Wir laden eine Website in einem Webkit Widget (auf der Plasma Canvas), blenden die Scrollbalken aus, scrollen an die richtige Stelle (zur Geometrie einzelner Element kann man Webkit befragen) und zoomen soweit ein oder aus, dass der Ausschnitt in’s Widget passt. Das funktionierte so recht gut, allerdings blieben zwei Probleme: Das Vergrössern bzw. Verkleinern des Widgets war viel zu langsam, und dadurch nicht flüssig genug, und die Auswahl des Ausschnitts war alles andere als intuitiv — man musste den richtigen CSS2 Selector eingeben, diesen also erst aus dem Quellcode der Website puhlen.
Gestern abend habe ich eine Reihe Änderungen eingepflegt, die hier deutliche Verbesserung bringen. Nach Review auf der plasma-devel Mailingliste habe ich diese Änderungen auch in den 4.6 Zweig committet, d.h. dass sie mit 4.6.1 in ca. einem Monat zur Verfügung stehen werden. (Oder ihr besorgt euch den Code aus KDE’s SVN bzw. Git, unter kdeplasma-addons/applets/webslice.) Schau’n wir mal, was ich so geändert habe…
Vor allem das Vergrössern und Verkleinern des Widgets machte eigentlich kaum Spass. Das Web-Scheibchen Widget benutzt eine Webkit View, und zeigt die Seite an einer bestimmten Position an, mit einem zur Plasmoidgrösse passendem Zoomfaktor. Soweit, so gut. Dem Performanceproblem lag zugrunde, dass das Widget während dem Andern seiner Grösse so viele Resize Events abfing, dass es mit dem Zoomen und Positionieren nicht nachkam, und diese sich aufstauten. Dem habe ich Abhilfe verschafft erstmal die Codepfade, die zum diesen “resize events” führen aufgeräumt habe, sodass dieser Vorgang nur stattfindet, wenn es wirklich nötig ist. Dann habe ich mittels eines QTimers verschiedene, schnell aufeinanderfolgende Events zusammengefasst. Beim Zoomen des Widgets war auch noch so Einiges drin, wenn man die Backingstore zeitweise einfriert, und das komplette Neurendern der Seite dann um einige Millisekunden verzögert. Zusammen damit habe ich auch die Seitenverhältnisse flexibler gemacht, diese waren vorher fest eingestellt. (Man kann in Plasma immmer noch unabhängig von den Seitenverhältnissen verkleinern/vergrössern, indem man die CTRL Taste gedrückt hält.) Das erste Problem ist also gründlich gefixt.
Nächster Punkt: Ergonomie. Wie schon erwähnt, schränkt das notwendige extrahieren von CSS2 Selektoren aus Webseiten-Quellcode die Zielgruppe des Widgets gelinde gesagt etwas ein. (Eigentlich sind die recht einfach, was aber nicht heisst, dass ich es auch meinem “Resident non-Geek” zumuten würde — ich hab’s probiert und empfing einen recht leeren Blick als Dank). Ich habe einige Zeit drüber nachgedacht, wie man sowas elegant umsetzen kann. Erstmal wollen wir Quellcode-lesen während des Setup vermeiden, es sollte einfach sein, den gewünschten Ausschnitt auszuwählen, und das Feedback für den Anwender sollte so direkt wie möglich sein. Erster Streich: Die Eingabezeile für das CSS Element hat sich verwandelt in eine editierbare Combobox, über deren Dropdown-Menü man jetzt Elemente auswählen kann. Zweiter Streich: Die URL Eingabezeile hat einen Reload-Knopf zum Nachbarn bekommen, mit dem man eine neue Seite in die Voransicht laden kann (damit werden auch die Elemente in der Combobox erneuert). Dritter Streich: Das Widget zeigt jetzt während der Konfiguration eine Übersicht der ganzen Seite an, und markiert das gerade ausgewählte Element. (Mann kan, wie in allen Comboboxen dann auch mit Maus bzw. Pfeiltasten durch die Liste navigieren, gleichzeitig sieht man im Widget welcher Ausschnitt sich hinter dem kryptischen Namen des Elements (#myid, zum Beispiel) verbirgt. Sobald man bestätigt, zeigt das Widget dann den Ausschnitt passend gezoomt an.
Alles in allem nicht ganz so triviale Änderungen. Da das Widget allerdings bisher kaum benutzbar war, die Änderungen sich recht einfach ohne Änderungen an den Übersetzungen vornehmen liessen, und das Risiko auf Regressions in anderen Teilen sehr gering war, habe ich die Änderungen auch in den 4.6 Zweig eingepflegt. Damit werden sie mit 4.6.1 nächten Monat, und mit openSUSE im März mitgeliefert, und wir somit vielleicht dem ein oder anderen Anwender eine Freude bereiten können.
Hier und da gibt’s natürlich noch Verbesserungsmöglichkeiten. So kann ein erklärender Tooltip hier und da sicherlich nicht schaden, flexiblere Grössenoptionen, wie Proportion, Originalgrösse der Seite (interessant für “flüssige Layouts”), zum Beispiel. Ich habe dafür erstmal sinnvolle Voreinstellungen gewählt, abhängig vom Feedback auf’s jetzige Featureset sehen wir dann mal weiter.
4 Minuten Hobbychirurgie
Abschliessend noch unsere Mitmach-Runde im Mitmach-Web 2.0! Wir haben einen netten Mechanismus, mit dem man kinderleicht eigene Web-Scheibchen-Widgets erstellen kann. Dazu kopiert ihr einfach eine bereits existierende Web-Scheibchen .desktop Datei. Dateinamen ändern (wir wollen ja nichts anderes überschreiben), Namen, Kommentar, ev. auch Übersetzungen updaten (oder einfach löschen, falls nicht nötig), Autor, etc, Einträge die man nicht versteht, einfach drin lassen, auf jeden Fall aber die Plasma Library und Mimetype Einträge. Fügt dann eine Zeile wie diese hinzu, um das Web-Scheibchen auf das Element mit id=”myid” im Tag von der Frontpage von mysite.org läd:
Diese Datei muss man dann nur noch nach ~/.kde(4)/share/kde4/services/, kbuildsycoca4 ausführen, um die Plugins und Metadaten auf den neusten Stand zu bringen, und das Widget über den Widget Explorer zur Plasma Arbeitsfläche oder dem Netbook hinzufügen.
Eine mögliche Entwicklungsrichtung für die Zukunft wäre dann, diese selbsterstellten Web-Scheibchen über opendesktop.org mit anderen zu teilen, quasi “Social Desktop für Web-Metzger“…
The Webslice applet has been in Plasma (kdeplasma-addons, to be precise) since 4.4 already. It allows the user to display a part of a webpage on the desktop. This can be useful for monitoring only a specific part of a webpage, or just to display something nice.
The Webslice applet has been written by Richard Moore and me as a functional prototype, but didn’t see much love since it was added to Plasma for 4.4 in 2009. Its basic mechanism is that you specify a “slice” within a website, which is a rectangular region. This region then gets shown in the applet, and resizes dynamically with it, zooming the “slice” in and out. The widget basically worked, but had two significant problems: Resizing was very sluggish and bound to a kept aspect ratio, and you needed to know CSS2 selector syntax to actually use it.
Earlier tonight, I’ve committed a set of changes which address these problems, and backported them after review on the plasma-devel mailing list to the 4.6 branch, so these changes become part of Plasma 4.6.1, which will be the first service and translation update to 4.6.0, which we released yesterday.
First, the resize issue. The Webslice applet uses a webkit view, which displays the page and is positioned (basically scrolled with scrollbars switched off) and zoomed to fit into the area the applet covers — fairly simple in fact. The performance problem was caused by too much resizing which got passed down the stack (if you scroll and zoom a website every couple of milliseconds, it becomes quite heavy on the CPU easily. I’ve addressed this by cleaning up the codepathes that lead to resizing, so that it only causes the resize (and thus the repositioning and zoom of the webpage) when absolutely necessary. Resize events from the applet are now compressed a bit, so that we don’t get more than 10 resizes a second. That’s “good enough” for the user to see what effect his mouse-dragging has, but doesn’t have the sluggish effect. Then, while resizing, I’m freezing webkit’s tiled backing store, for an additional performance boost. The result is very noticeable, the lag and CPU-hogging while resizing is gone, and the sizing of the applet is much less unwieldy with these changes. In that process, I’ve also switched to a non-fixed aspect ratio. Bug #1 thoroughly fixed.
Next-up, slice selection. As I already mentioned, that was neither easy, nor user-friendly. (If you’re running, 4.4+, give it a shot, it really sucks ;-).) First off, you need to know CSS2 selectors (they’re quite easy, in most cases you want #myid for an element in the page being marked with id=”myid”), but still limit the utility of the widget to a rather select group. (Does this make the widget 1337?)I’ve been pondering how to best offer this to the user. It should be easy to pick a slice from all the elements that are there. The first thing I did was to turn the lineedit where you’d input the CSS selector (#myid or whatever) into an editable combobox, already containing elements to choose from. That made picking a slice much more “determistic”. Still, the #myid names are not always telling you what part of the page their actually displaying, so some more feedback is desirable. My approach there is the following: When the user opens the configuration dialog, the page is zoomed out and fully shown in the webslice applet, it switches to a preview mode. The user can now enter a different URL, and temporary load this in the slice applet. The combo box containing the elements is now updated to contain the elements of the new page. Website picked, now let’s pick a slice. By selecting a slice from the combobox, the preview mode highlights the position of the currently selected slice in the widget. You apply and it zooms in there. A nice touch is that you can “scroll” through the slice by hovering over the combobox, or flip through them using the arrow keys while focusing the combobox. All in all, not quite unintrusive changes, but considering the widget wasn’t of much use due to above described problems anyway (there was one bug filed against it — likely a bad sign, I’m not that good a hacker). Marco and Aaron were kind enough to review the patches and agreed that they won’t hurt much, but do provide a nice set of improvements we’d like our users to get fairly quickly, not just next summer with 4.7.
There are a couple of loose ends left for 4.7, though. As I wanted to keep the possibility of a backport open, I’ve not changed any strings in the widget, adding an explaining tooltip here or there might be useful, but also some more flexible sizing options (what proportions to use for the initial rendering — that matters for fluid layouts, how to clip if the size of the widget doesn’t match the aspect ratio of the slice, etc. I’ve chosen “sane defaults” for these things now, but it’ll probably be nice having that available as an option to the user.
Create your own webslice Plasma widgets in 4 minutes
There’s one neat thing left to tell about the webslice: You can easily create your own preconfigured slices. In order to do that, copy and rename the .desktop file, change name, comment, icon, if you wish, then add a line like
Copy the file to ~/.kde(4)/share/kde4/services/, run kbuildsycoca4 and add your newly created webslice to your Plasma using the widget explorer.
A possible direction we can take this is to add a webslice category to opendesktop.org, and start sharing our webslices with each other…
In my previous article on this subject, I have introduced Akonadi as the personal information beehive on your computer, explained how it works, how it is designed and what the migration process to an Akonadi-based Kontact looks like. (openSUSE users should also take a look here.) In this article, I will dive into the workspace parts we’re introducing on top of Akonadi, notably the new email notifier system in Plasma – Lion Mail. The Lion Mail email notifier is at its base your "you’ve got mail" icon in the panel. For users with more complex and high-traffic email habits, it offers a basic set of workflow tools to manage the daily stream of emails more efficiently and ergonomically. In this article, I’m describing some of the design concepts behind Lion Mail’s email notifier and its workflow features.
Complex email workflows are something I wanted Lion Mail to excel at. The idea is to make dealing with email as flexible as we can, so you can project your workflow onto it and have it make the daily flow of email more manageable, and less disturbing in the real work you want to get done. By default, the Lion Mail email notifier shows up in your panel when a new email arrived in your inbox, by clicking on it you can access the list of your latest unread emails in a small popup-window. The basic use-case is quickly checking if you’ve got new email. I will not dive too much into implementation details, as this article is all about work-flows and how it affects the user experience.
The idea is that, at all times you can see if there’s email to deal with. but not have it jump in your face. In order to be able to quickly dismiss something as "I’ll deal with that one later", or "ok, got it", there’s two queues in Lion Mail, the stack and the heap of Lion Mail.
The Stack — Incoming Emails
The stack is your incoming emails queue, it lists new emails in one or more folders. By default, that’s your inbox, but you can configure it to monitor any folders you like (yes, combining them from multiple folders is built-in). The incoming emails queue is a transient thing, it’s your stream of incoming emails, and the first time a new email gets your attention (but doesn’t shout for it). The stack allows you to dismiss new emails, or mark them as read or important. The idea is that new emails might fall into the following categories:
"Not right now" - A new email will get your attention later. You take notice of its existence now, but don’t have time right now to tend to it. It stays marked as unread, you’ll get back to it later.
"This I really have to deal with, later" — If you don’t respond to this email, the world implodes into dark matter, or your head gets torn off by zombie-chinchillas. You mark the email as important, for extra attention, you can leave it marked as unread.
"I am bored enough" — An email you deal with right away, either because it’s important or more interesting than what you’re currently doing, or maybe because it’s quicker to reply right now. In those cases, you open the email in your mail client to read it and possibly reply.
"OK" — You notice an email and know enough by peeking at it. It can drown in your inbox from here on, you mark it as read.
"v14gra on loan" – Something slipped the spam filters. You just want it gone. You hit the delete button and it won’t bother you again.
These are a couple of possible reactions to new emails. By offering the tools to deal with such situations at hand, in the context of these incoming emails, we can pre-sort the stream of mail while we receive it.
The Heap — Important Emails
This is where the heap comes in. The heap is an optional second list of emails you can show in the Lion Mail email notifier. It simply shows the important emails in your monitored folders. This way, it offers you a list of things you need to deal with, in essence your to-do list of emails. By putting them into a separate list, we have two overlapping categories of emails you want to deal with. Lion Mail can either display those important emails in a combined list, or using separate tabs for new and important emails. The latter is likely to appeal to David Allen fans, Lion Mail certainly is inspired by some of his ideas.
The individual email items in the heap or stack offer a couple of options to open emails in your mail client, for marking emails as read and as important, and for deleting it. Needless to say that these buttons operate directly on the email, so the moment you mark an email in Lion Mail, it’ll change in KMail (or any other Akonadi-based email client) as well. When an email doesn’t satisfy the criteria for the heap of stack anymore, it fades out over a period of 5 seconds, so you get some "undo grace-time" if you clicked wrongly. The emails themselves show by default subject, sender, date and flags, you can expand to show some of the body as well. Email items employ a hover interface, when you move the mouse over an email, it reveals three controls as an overlay which offer flagging and trashing an email. Clicking on the icon opens the email in your mail client, you can also drag an email from these lists into your email client or Plasma workspace. I’ve chosen for a hover interface mainly for two reasons: less clicks and more discoverability. The emails don’t have a context menu right now, but there are a couple of useful options we could add there, for example forwarding or replying.
Excerpts — NLP people, listen up!
If someone comes up with a clever and useful implementation for email excerpts, I’m all open. Right now, I’m just showing the first couple of hundred characters in order to not blow the size of the widget beyond what’s reasonable in a small popup. As you can deduct, I’m not the most inspired mind in the world of language processing. In the UI, I’d rather avoid having to use scroll bars inside the expanded email body, as the list already might have scroll-bars. Nested scroll-bars will lead to annoying behaviour for mouse-wheel and flick-scrolling, so that should be avoided. The most elegant thing to do here is excerpting the interesting parts of the email, by skipping empty lines and possibly line-breaks, by removing reply-quoted parts, and so on. K9-Mail (a really good email client for Android) does this quite well, it’s often possible even from one line to judge an email’s content. We can easily fit 5 lines into the expanded email widget, and possibly even more, so I’d expect that with the right algorithm, we could do excellent there. If you’re into that kind of stuff, send me a piece of code that turns an email body (as QString, if you want) into a 200-300 character long excerpt, it should be LGPLed code and you’ll be properly credited. Sounds like a nice small, self-contained hacking project for a fall evening, no?
There’s if course a lot more in the pipeline. In principle, Lion Mail can hold any email collection, existing folders, but also virtual collections, such as search folders or combinations of multiple folders. Lion Mail represents itself as an icon in the panel’s notification area, you can enable it in the notification area’s settings. It’s also possible to put Lion Mail widgets on the dashboard, desktop or netbook’s new page, you can of course add multiple Lion Mail applets holding different collections one one or different activities, and this way depending on what you are doing, think of showing your work’s inbox in your "work" activity, showing private emails in your "freetime" activity or showing neither in your hacking activity. In Lion Mail itself, that would be very easy to do, It’s built in mind with showing arbitrary sets of emails, the new email and important email queues are just specialized version of a generic email list.
Drag and drop is also one of the things that got a little bit of attention while developing Lion Mail. You can drag emails from Lion Mail into KMail for example to move or copy them to another folder. Plasma is also receptive to dropping mails (and in the future mail folders) onto the desktop. Lion Mail includes a Plasma widget showing an individual email. It can take different sizes, so you can either have a bunch of small emails floating around, or individual emails with full text on your desktop or dashboard for reference while working, as it often comes handy to have a related email available for a quick check if you’re looking into something.
Release plans and test-driving
In its current state, Lion Mail email notifier is already quite usable. The work to make it release-ready consists of completing some features, refreshing of monitored folders directly from the applet, and trashing emails. There’s also some smaller interaction glitches I’ll fix before it can make its way into Plasma cq. Kontact 4.6.0. There’s suspending removing items under your mouse (or finger) so you don’t accidentally click on the wrong email, some display funkiness here and there (spot the lack of space underneath emails in the screenshots), and the excerpts extraction I invited input to above. You’re already most welcome to try it and give feedback. It’s currently located in playground and will eventually move through the kdereview process into one of the released modules — I haven’t figured out which one would be the most suitable exactly. If you want to build it right now, I have to admit that it’s not completely trivial from scratch, as it requires kdelibs and kdepimlibs from trunk. If you have a reasonably recent 4.6 (trunk) snapshot installed, you should be good to go. Lion Mail does not offer the option to configure email accounts, you can do that from KMail2 or akonadiconsole.
Famous last words
The heap and the stack of Lion Mail offer the opportunity to create a more efficient workflow with your emails. By dealing with emails effectively as they come in, but without a context-switch to the full email application, it offers more workflow-based email management. The underlying idea behind Lion Mail is that emails become first-class object in your user experience, to integrate them as artifacts of your interesting information, rather than banning them into a monolithic application like traditional email clients. "Light-weight email work" can be done directly from the workspace, referencing emails in other tasks becomes a lot easier, the traditional email reader still serves as the work horse for most email reading (as opposed to noticing and referencing). Lion Mail provides the usual feature set in a more elegant and context-rich way. It is also heavily optimized for people with larger amounts of emails, and integration these streams of new and interesting emails deeper into the workflow of the user.
The exotic-sounding ‘Akonadi’ refers to both a mythological figure and the KDE platform’s central information framework. This article will dispel some of the mystery about how Akonadi will improve performance and integration, and how it is being rolled out into KDE applications. I’ll also provide some insight how the technology works, and what will become possible with this new PIM framework.
Many people have been asking what the status of the new, Akonadi-based Kontact Groupware suite is. As I’ve been working closely with the PIM hackers, I thought I’d give my readers a heads-up on what’s going on and what to expect. In this article, I will often take KMail as an example for the port, but similar things apply to the other PIM applications that form the Kontact suite as well.
The What & How?
I’m sure many of you haven’t heard the name Akonadi yet, so let me quickly explain what it is. Let’s get technical.
Akonadi is a groupware cache that runs on the local machine, a shared data store for all your personal informatio. Akonadi offers a unified API to receive and synchronise data with groupware, email servers or other online services. Agents called “resources” are responsible for communicating with the remote service, say your email server. These resources run out-of-process and communicate via separate control and data channels with the mothership (your local Akonadi). Resources are easy to implement and can interface any data source with Akonadi, be it your local calendar file, your companies groupware, email servers or address directories, or anything else you can come up with. More on that specifically later.
A common misunderstanding is that Akonadi is some sort of groupware server. In fact, Akonadi does not store any data itself, but just provides a common means to access data to your local applications.
So Akonadi does not store user data, it caches it. The user data is still stored in the traditional formats, be it on an online server (for example IMAP) or local files (ICAL calendar files). Locally, Akonadi provides a cache to speed up access and to make collections (email folders, for example) and their items available offline. To allow Akonadi to work on both powerful desktops and lean mobile devices, Akonadi can use different databases for its cache. Currently, the most complete backing store for Akonadi is MySQL, but PostGreSQL and sqlite backends are also available. In the case of MySQL, the database is started and handled by Akonadi itself, using a local socket, and no network access. This is intentional, for speed and security, since Akonadi’s database is really only a detail of the implementation.
The storage concept of Akonadi is straightforward. The team looked at many types of PIM data and found that items stored in folders are common to all of them. In Akonadi, Items represent mails, contacts or other individual pieces of data Folders are generally referred to as Collections, which can contain other Collections. Items themselves carry a type (using the freedesktop.org standard mimetype definitions), metadata and the actual data payload. Items can be identified by URLs. This URL is of course only valid locally, but it allows passing references to Akonadi items and collections around without copying the actual data. This makes Drag and Drop across applications (or in my favourite case, from the email notifier in Plasma into KMail) very easy. The receiving application can use any Akonadi client library to take the Akonadi URL and fetch its headers, or data. Akonadi Items may be retrieved partially, so if an app wants tod display a list of emails, it doesn’t have to copy around the whole inbox, attachments and all, but can just ask for a list of headers of those emails.
In order to access the Akonadi cache, and more importantly the underlying data, you can use one of the Akonadi access libraries. To my knowledge, there are Akonadi bindings for GTK+, Python and the Qt-style Akonadi classes already available. As you can see in the diagram, the design allows for different ways of accessing the Akonadi data, in the diagram the examples are called the “GNOME API” and “KDE API”.
As you’d expect, I’ve mostly worked with the KDE API, which you can find in kdepimlibs. This Qt-style library has been available for a couple of KDE Platform releases already, and is being further enhanced for more coding convenience, stability and performance all the time. There is a bunch of job classes, that allow for async access to Akonadi items. Relatively new are the MVC classes, notably EntityTreeModel and friends. The ETM and its friends and API sugar around it also provide async access to Akonadi data as well, and also allow for easier sorting, querying and filtering of all the data and metadata. Metadata handling is another very interesting aspect of Akonadi in itself, more on that later, as well.
Many people are interested in the current status of Kontact’s Akonadi port. Initially, KDE had planned to release the new Kontact along with the rest of the KDE Applications 4.5. This did not quite work out, so we pushed the release back a bit, and are planning to release it along with one of the 4.5.x updates. The current plan is to release the Akonadi port of Kontact still this year. In contrast to our usual releases, this step is a bit different. Since PIM data is critically important, we are extending the beta phase until the Akonadi port of Kontact passes a much wider range of QA tests. When we are able to release depends a lot on the feedback we get from users. We are therefore making available monthly beta releases of the new Kontact suite. Data loss in this late phase of the port is extremely unlikely, and we made sure that trying the new Kontact doesn’t mean you must now also do the switch. You can in fact just reinstall the old one and use that again, since separate configuration files are used.
The traditional Kontact, is of course still fully usable and we currently recommend this to end users. Kontact 4.4 is still actively maintained and supported, and is shipped by distributions along with KDE 4.5.0, so the current stable Kontact is 4.4.5. We did ship a new release of kdepimlibs, which are tested with Kontact 4.4.5 and are the basis for Kontact2 as well.
For normal workloads, KMail2 which is the heart of Kontact’s Mail component is already pretty usable. The focus of the stabilization and improvement efforts currently lies in the complex use cases common to hackers and email power users, such a different, high-volume email accounts, many large folders and a paranoid bunch of identities. Another area of focus is the migration of data, including the possibility to rollback to your “traditional” Kontact if you are not satisfied with the quality yet (please don’t forget to file bugs, so we can take proper care of those nasty insects).
Kontact2 only reads Kontact1′s configuration, but doesn’t change the original copy. Instead, a new configuration file derived from your old one will be used. So when first starting Kontact2, your “old” configuration, account setup, identities and filtering rules will be imported. KMail2 will also import locally cached emails, so you don’t have to download them all again. In the current state, user feedback from migration and usage is extremely valuable to the developers, so please give the next beta a whirl and report back to us, so we can improve on your experience. Of course, there are tools for importing and exporting data. During the migration, Kontact2 uses Kontact1′s existing downloaded email, so a lengthy re-download for offline reading is unnecessary.
If you’re not yet happy with the new Kontact, you can switch back to the old one, by re-installing the 4.4 Kontact.
What will KMail2 look like?
This might come as a little surprise to some, but in the initial version of KMail2, you won’t notice many differences to the traditional KMail1. This has a number of reasons: First of all, KMail’s UI is the result of years of polishing by the developers and a lot of feedback by the community. This won’t be thrown away for something that’s novel and cool, but might not satisfy most users. So KMail 2 will be a very straightforward port of KMail1, the UI will be mostly the same, while the underlying technology has changed completely. In the porting process to Akonadi, most of KMail1′s familiar UI has been kept.
You might have noticed the first parts of KMail1 being converted. That is to say that the Kontact developers have worked towards the Akonadi port of KMail. The first, and actually one of the most central parts of KMail has already been introduced a while ago: the new listview. This listview is a rework of KMail’s list of messages to use the underlying Model-View-Controller design patterns that match Akonadi well. In Kontact 4.4, Kontact’s address book has been switched to use Akonadi. This first step in the migration was a bit painful, since it involved introducing a new infrastructure below applications that you use daily, and which you rely upon. The new possibilities are already making their way to the end users’ systems, for example in the calendar integration with the Plasma Desktop, which you can see in the screenshot. By clicking on the clock, you get the Plasma calendar which shows you your daily events. In the sceenshot, you can see the new version of KMail. As I’m using a full-HD display, I’ve enabled the widescreen layout of KMail. This makes it possible to see the whole email and a long enough list of others at once. A nice touch, which has been available for ages in KMail — just in case you wondered.
… but why the port then?
Simply put, traditional email clients don’t satisfy today’s expectations and work flows around personal data. Well, this of course needs some explanation: Already in times when KDE 3 was state-of-the-art, we noticed that more and more applications became interested in PIM data. Popular examples are Kopete, the instant messenger which held its own list of contacts, data which is mostly duplicated, including the inefficiency and maintenance nightmare you’re facing when you duplicate frequently changing information. So you want some kind of interface for contacts, and it should be something service-like, after all, you don’t want to run a seemingly unrelated application(your address book), just to get some more rich information about your chat contacts. Then, there’s of course my favourite example: Email monitoring. In essence, a full-fledged email client is a bit of an overkill, if you just want to know if there’s new email in your inbox. On of those overkill aspects is performance, or rather resource consumption. The solution to this is of course to share all this data. By using one central storage, and an easy to use access layer we can share the data across applications, and enable applications to make use of already available personal data. Enter Akonadi.
Akonadi has been built with performance and memory consumption in mind. Will Stephenson has put this very nicely: “In the 2.0 <= KDE <= 4.4 days, each program loaded the entire address book, calendars, and more specialised stuff like email, RSS feeds, and IM chat logs into its memory, so memory usage for PIM data increased linearly with the number of PIM apps running. Same goes for non-PIM apps using PIM data (the Kickoff menu's contact search data, Konqueror's Copy To IM Contact feature). Because Kontact is just a shell for KMail, KAddressbook, KOrganizer etc, it caused the same memory multiplication even though it's all one process.
With the Akonadi design, only the Akonadi process loads all the data into memory. Each PIM app then displays a portion of that data as it needs it, so the amount of extra resources taken by each extra PIM app is smaller, and the initial amount of memory used by each app is less. It should also provide extra stability, because each app no longer has to maintain its own data storage infrastructure, with all the caching, integrity and performance gotchas that keep computing science graduates employed.”
Plasma’s new email notifier
During Akademy, I’ve picked up the work on Lion Mail again. It is not quite done yet, but already looking very good. I’m nearing feature completion for a first release now, so I’m almost sure it will become part of Plasma 4.6 in January, currently it’s in alpha state but quite fun already. Interested users can of course check out the source from SVN, it’s currently located in playground unti the code is ready for review by my eagle-eyed fellow hackers. Lion Mail is a set of Plasma widgets that can be used to display and manipulate emails in Plasma. In Tampere, Finland, during Akademy, I’ve discussed design and workflow of email notifications with a lot of people, after that I sat down for some serious hacking and have already implement most of what I would like to see, email-wise, in Plasma 4.6. The main goal is to be non-intrusive, and making it as easy as possible to manage your email in your daily workflow. The email notifier provides a queue of your emails, but does so without the need to switch to the full-blown KMail, so no full context / attention switch is needed if you just quickly want to see what’s going on in your inbox.
The new email notifier sits, as you might expect, in your panel’s notification area. It’s hidden by default, but becomes visible when there are new emails in your inbox. When you click on it, you get a list of your new messages. Those messages are expandable, so you can peek into the email to quickly judge if it’s something you want to act upon right away, or not. The individual messages are interactive. When hovered with the mouse, four buttons overlay the email. These buttons allow you to mark an email as read, or important (and of course remove those flags). Disappearing emails slowly fade out, so you have a couple of seconds to undo your action before the list is cleaned up.
Unfortunately, most normal email notifiers are pretty useless for high-volume emailers, especially if you use server-side filtering (which you should because it’s much more convenient when using multiple clients, especially mobile ones). In my case, I have about 60 folders, on3 different email accounts (work-work, private, gmail). Emails are filtered before they reach the client. I am personally far less interested in new emails in all folders called “inbox”. The Plasma email notifier allows you to choose the folder you want it to monitor. You can also set up multiple folders. As a nice extra, you can choose to also display emails marked as important, either merged or in a separate list (actually, the latter is not implemented yet, but on my short-term TODO list :-)). Emails are draggable, so you can drag an email from the email notifier into a folder in KMail2 if you want to copy or move it there. As I mentioned before, we’re not actually dragging the email around, but an Akonadi reference as a URL. This is fully transparent between applications, and even across toolkit and access libraries. I’ve also written a full-fledged single email Plasmoid, which allows you to put individual emails on your desktop (or dashboard) for quick reference. Just drag the email from the list onto your desktop, and it’ll appear as Plasma widget there, expandable, with HTML if you’re into that. The missing bits are rather overseeable at this point: clearing the list, separate list for important emails, refreshing logic for individual folders and queuing the re-jigging of the list until the mouse moves out, so items don’t change under your mouse while clicking on them. Not just minor bugfixes, but at the current pace, also not a lot of work left to do.
As you can imagine, the email notifier’s design suits itself very well for PUSH IMAP. PUSH IMAP means that instead of checking in intervals for new email, the server notifies your client when a new email comes in. This means less useless mail checks and more importantly instant notification when a new email arrives. With “instant” I mean within a couple of seconds. In my tests, it took between 3 and 17 seconds from pushing the “Send” button on one machine until the email showed up in the email notifier. That’s pretty neat compared to checking your email every 30 minutes or so. So it’s all the more important that new email notifications become too annoying, hence the non-intrusive approach to the UI. PUSH IMAP is currently only enabled for the inbox folder of a given IMAP account, and of course your server needs to support it.
The migration of the desktop version of Kontact is another big step in Akonadi’s existence. Akonadi has its uses outside of Kontact on the desktop as well. The new Kontact Mobile suite builds on top of Akonadi as well, but offers a completely different UI, optimized for smartphones and touch-screen devices. Kontact mobile is part of the upcoming Kontact suite as well. The infrastructure is this way shared across the device spectrum while the user interface is optimized for a certain device and use case. Akonadi does the hard work of talking to all kinds of groupware servers in the background, and caching of this data if you want to make it available on the go. The Dot has an excellent article about Kontact mobile, including a cool screencast.
Beyond Groupware – Akonadi and the Social-Semantic Desktop
The new email notifier is a good example what Akonadi makes possible in the near future, but there are more things brewing in the kitchen. As Akonadi is a generic cache, it comes handy in a much wider number of use cases. In the future, Akonadi can take care of managing and caching all kinds of interesting data, as you can stuff into it what you want. One interesting case is managing your online photo collection. Akonadi can provide standardised photo streams locally on your machine which are backed up by online services. In the same vain, microblogging can be handled through Akonadi, free caching, searchability and semantic linking to your contact are made very easy this way. There is actually already a microblog resource for Akonadi available, I’ve heard rumours of a FlickR one as well…
Akonadi plugs into the Nepomuk semantic framework for its indexing and searching needs. Items in Akonadi are therefore magically available for applications using Nepomuk to query and display data. Tags and other metadata is shared across the desktop, arbitrary items can be linked semantically (think emails and attachments linked to contacts in your address book). Akonadi in Kontact does not only mean that Akonadi is coming to full bloom, but also the semantic desktop built on top of Nepomuk. One nice example is shown in the screenshot, where the KRunner mini-commandline (hit ALT+F2!) also finds emails now. Part of the semantic desktop are also the Activities, which provide context to applications. You can think of ‘context’ as a project your working on, your current location, and many other “metadata” of your workflow. One features of Lion Mail which has been part of its idea from the beginning is showing different sets of emails per activity, the email notifier is built with activities in mind.
Plasma’s dataengines provide another fantastic opportunity for Akonadi to shine. The Plasma team is working on a generic cache for data supplied by dataengines, the idea is to transparently allow caching of arbitrary data from dataengines, so offline usage becomes completely transparent for many Plasma widgets. Akonadi forms one of the cornerstones of Project Silk which aims at deeper integration of online services and content into the user experience.
With all the above in mind, there’s little less than a revolution going on in the groupware area. Akonadi matures further and makes possible a full-fledged groupware client in the form of Kontact, with excellent scalability and extensibility. Akonadi is built with a whole spectrum of target devices in mind, which shows in the Kontact Mobile suite running successfully on a N900. With more applications being available in their Akonadi versions, Akonadi will become a lot more useful, and enhance many other applications in the process. Akonadi also allows for a better user experience around email and calendaring in the primary workspace. Groupware is becoming a generic service on the local client. The upcoming new Kontact groupware suite is only the tip of the iceberg of what’s coming thanks to Akonadi. Quite inspiring, isn’t it?
Special thanks go to Will Stephenson for proof-reading the article.
I’m on the first leg of my trip back to the Netherlands right now. I’ve spent a couple of days in Bretagne, France to celebrate the marriage of a close friend, who asked me to be his best man. The celebrations, which lasted for three days were terrific, but also pretty tiring as you don’t get to spend much time just by yourself. The main celebration was held in the "ridiculously beautiful" Chateau Domaine de la Bretesche, and in Pornichet, the home of the bride. I’m returning to the Netherlands right now, for three days of desk time (needed to prepare my Akademy talk and to get some last minute work done on the impending openSUSE 11.3 release). On Friday, I’ll be boarding a flight to Helsinki and then on to Tampere to take part in my fifth Akademy.
This year’s Akademy is significant to me for a number of reasons:
I’m running for a second term on the Board of Directors of the KDE e.V., the foundation backing KDE. I’ve taken this opportunity to re-focus on my activities there. I will be working towards improving the organisation’s transparency a bit more. Transparency of the of our activities sometimes falls behind a little, since we’re very much focused on getting things done, and there’s always something important to push a little further, at the same time, status information gets outdated rather quickly. With the launch of our Supporting Membership Programme, it’s even more important to get the word out what the KDE e.V. is doing, so that’ll be what I’m working on on that front.
Last year, Richard Moore and I started Project Silk, which has been silently tagging along. Silently doesn’t mean that we didn’t make progress, just that we didn’t talk about it as much as we could. We felt that we wanted to show results before talking a lot about it, so we sat down and wrote code, worked out concepts, talked to people in order to verify and improve on our ideas. I think we’re at a point now where we got some really compelling stuff to show, and to prove that what we have in mind is not only very viable, but also very important to move on. This year’s Akademy will in part be used to spread those ideas within the KDE team, and to get more people to think Silky. If you think that’s all too vague, attend my talk during Akademy. For the few of you, my dear readers who won’t make it, I’ll prepare some online resources over the next days, so you can catch up as well, and join the Silk bandwagon.
Meeting my fellow hackers from the KDE Plasma team. After our last meeting in February in Nuremberg, we’re getting together at Akademy next week to plan, hack, gather ideas talk and have fun. What I really enjoy about getting us together is the sparkling you can see above the table we’re working on after only shortly being together. I guess it’s the motivation, the friendliness, the shared love for beautiful, intuitive Free software but also the mutual respect that creates this atmosphere where we’re getting into hyper-creative mode. It puts us in the position to think about solutions for the really hard problems out there, which none of us could solve individually, and it has more than once been the start of exciting new features and sub-projects.
[break] So I just got home, into our hot top-floor appartment in Nijmegen, The Netherlands. Everything’s been taken care of by our terrific friends, the cat is better now after a bladder infection we had to leave it at home with last week. While I do like summery weather, temperatures beyond 30 degrees centigrade without a really cold room are a bit too much for me, and tend to have a bad effect on my productivity. Band-aid: Work at night as much as possible, keep the sleeping room as cool for as long as it lasts and stay in bed as long as I can to get the needed sleep. The laptop is already compiling an updated trunk, while I’m enjoying Brazil playing Chile (Robinho scores the 3:0 as we speak, so I guess my special friend Artur will be happy).
I’ve resigned my job at KDAB last month in a swift move towards more KDE-time. This all came pretty suddenly, but it felt like The Right Thing to do for me personally and for KDE, which I care a lot about. Since May, I’ve been working for Open-SLX, a German company that makes and supports the openSUSE boxed version. My focus in that work is the user experience of the product. The idea is to work upstream (in openSUSE and KDE / Plasma) as much as possible. While Open-SLX benefits directly from my work done in KDE, this is also a nice way to give back to the community, by making sure I get to spend enough time on things that are not directly related to the product. So now I’ve settled into my new job, and up until now, it’s been great. I’ve been able to catch up with a couple of areas in KDE, I didn’t get to spend as much time as I wanted in the past, and I have started working on some ideas I was dragging around in the back of my brain for a while). One of those things is Project Silk, which is a Project to boost and deeply integrate the web into KDE Plasma and applications. Its motto is no less ambitions than "Freeing the Web From the Browser", so there’s lots of work to do. ;-) Others have already shown off their coolcreations, so I’ve got some catching up to do. I’ll share more detailed information about Silk in the next weeks, so if you’re interested in that, hang on just a little bit longer.
With this new job, I’m also able to spend a bit more time on KDE e.V. things. I’m a Board Member for some time already. Being able to sneak in a bit more of that structured desk time for things that need doing in the near future is surely a good thing. Regarding the e.V., I’ll travel with Ade to Berlin on Friday to meet Celeste, Cornelius and Frank there for an extended weekend of board work (and fun).