Plasma Mobile Roadmap

In the past weeks, we have noticed an increased interest in Plasma Mobile from different sides. Slowly, but surely, hardware vendors have discovered that Plasma Mobile is an entirely different software platform to build products on top of. For people or companies who want to work or invest into Plasma Mobile, it’s always useful to know where upstream is heading, so let me give an overview of what our plans are, what areas of work we’re planning to tackle in the coming months and years, where our focus will be and how it will shift. Let’s talk about Plasma Mobile’s roadmap.

Our development strategy is to build a basic system and platform around our core values first and then extend this. Having a stable base of essentials allows us to focus on an achievable subset first and then extend functionality for more and more possible target groups. It avoids pie-in-the-sky system engineering something that will never be useful and designed for a unicorn market that never existed. Get the basics right first, then take it to the next levels. These levels are:

  1. Prototype (already finished)
  2. Feature Phone
  3. Basic Smartphone
  4. Featured Smartphone

Plasma Mobile Roadmap
Plasma Mobile Roadmap

Let’s look at these steps in detail.

Prototype and Product Vision

The first public release of Plasma Mobile was this prototype. It showed a very basic and incomplete-for-daily-use system on actual, modern smartphone hardware. You could make phone calls, start and manage apps, and manipulate some basic system functionality. It showed a smartphone system based on Plasma could be done, and more importantly, it taught us a lot about where we want to take things on a technical level.
Along with the prototype, we developed a product vision for Plasma Mobile, a direction where we want to take it (emphasis added by yours truly):

“Plasma Mobile aims to become a complete software system for mobile devices. It is designed to give privacy-aware users back the full-control over their information and communication. Plasma Mobile takes a pragmatic approach and is inclusive to 3rd party software, allowing the user to choose which applications and services to use. It provides a seamless experience across multiple devices. Plasma Mobile implements open standards and it is developed in a transparent process that is open for the community to participate in.”

Feature Phone

The feature phone milestone is what we’re working on right now. This involves taking the prototype and fixing all the basic things to turn it into something usable. Usable doesn’t mean “usable for everyone”, but it should at least be workable for a subset of people that only rely on basic features — “simple” things.
Core features should work flawlessly once this milestone is achieved. With core features, we’re thinking along the lines of making phone calls, using the address book, manage hardware functions such as network connectivity, volume, screen, time, language, etc.. Aside from these very core things for a phone, we want to provide decent integration with a webbrowser (or provide our own), app store integration likely using store.kde.org, so you can get apps on and off the device, taking photos, recording videos and watching these media. Finally, we want to settle for an SDK which allows third party developers to build apps to run on Plasma Mobile devices.
Getting this to work is no small feat, but it allows us to receive real-world feedback and provide a stable base for third-party products. It makes Plasma Mobile a viable target for future product development.

Basic Smartphone

The basic smartphone extends the feature set of Plasma Mobile to a wider group of target users. The plan is to add personal information management features, such as reading and sending emails, calendaring and reminders. We also want to add file management capabilities in this milestone, because we think that the user should be able to deal with the data in her phone in the most transparant way, and file management is something that allows users to look into the fabric of their data, and that of the phone itself. Another big topic for the Basic Smartphone milestone is extending the app ecosystem through third-party and original applications to allow the user to do more things with the device.

Featured Smartphone

For the featured smartphone, we want to add more system-level integration features such as deeply integrated private cloud storage and have grown our own ecosystem with more apps and of course games. An often requested feature is support for Android apps. Supporting Android apps could give Plasma Mobile a huge boost in terms of possible target groups, since it allows users to switch away from Android more easily, even when they are requiring a few apps and can’t really live without these. Being able to run Android apps on a Plasma Mobile device can ease the transition considerably and it allows us to capture potential target user groups that rely on proprietary services which Plasma Mobile, at first, cannot serve simply because as a smaller player, it’s not an attractive enough platform to have the likes of WhatsApp develop native clients for.

When it’s ready!?

On purpose, we did not add a specific timeline to this roadmap for two reasons: First, Plasma Mobile is a participative project, if you want to see something done, get involved. We’re not running the show all by ourselves. We want to create an open eco system where people who do the work decide on its direction. This means if you get involved, you can help us shape the future of mobile computing instead of being just a code monkey that does what someone else has decided. Secondly, we don’t want to deliver half-assed software just because we set a timeline. We want to create quality software to build products upon. If you or your company want to ship on a specific date, work with us and we’ll plan together. We won’t make promises when something is ready beforehand, but as an upstream project, we want to ship “when it’s ready”. This “when” depends on all our input and hard work. So don’t sit in your armchairs and wait for someone else to do the heavy lifting, but let’s get cracking!

4 reasons why the librem 5 got funded

Librem 5 Plasma Mobile
Librem 5 Plasma Mobile
In the past days, the campaign to crowd-fund a privacy-focused smartphone built on top of Free software and in collaboration with its community reached its funding goal of 1.5 million US dollars. While many people doubted that the crowdfunding campaign would succeed, it is actually hardly surprising if we look what the librem 5 promises to bring to the table.

1. Unique Privacy Features: Kill-switches and auditable code

Neither Apple nor Android have convincing stories when it comes to privacy. Ultimately, they’re both under the thumbs of a restrictive government, which, to put it mildly doesn’t give a shit about privacy and has created the most intrusive global spying system in the history of mankind. Thanks to the U.S., we now live in the dystopian future of Orwell’s 1984. It’s time to put an end to this with hardware kill switches that cut off power to the radio, microphone and camera, so phones can’t be hacked into anymore to listen in on your conversations, take photos you never know were taken and send them to people you definitely would never voluntarily share them with. All that comes with auditable code, which is something that we as citizens should demand from our government. With a product on the market supplying these features, it becomes very hard for your government to argue that they really need their staff to use iphones or Android devices. We can and we should demand this level of privacy from those who govern us and handle with our data. It’s a matter of trust.
Companies will find this out first, since they’re driven by the same challenges but usually much quicker to adopt technology.

2. Hackable software means choice

The librem 5 will run a mostly standard Debian system with a kernel that you can actually upgrade. The system will be fully hackable, so it will be easy for others to create modified phone systems based on the librem. This is so far unparalleled and brings the freedom the Free software world has long waited for, it will enable friendly competition and collaboration. All this leads to choice for the users.

3. Support promise

Can a small company such as Purism actually guarantee support for a whole mobile software stack for years into the future? Perhaps. The point is, even in case they fail (and I don’t see why they would!), the device isn’t unsupported. With the librem, you’re not locked into a single vendor’s eco system, but you buy into the support from the whole Free software community. This means that there is a very credible support story, as device doesn’t have to come from a single vendor, and the workload is relatively limited in the first place. Debian (which is the base for PureOS) will be maintained anyway, and so will Plasma as tens of millions of users already rely on it. The relatively small part of the code that is unique to Plasma Mobile (and thus isn’t used on the desktop) is not that hard to maintain, so support is manageable, even for a small team of developers. (And if you’re not happy with it, and think it can be done better, you can even take part.)

4. It builds and enables a new ecosystem

The Free software community has long waited for this hackable device. Many developers just love to see a platform they can build software for that follows their goals, that allows development with a proven stack. Moreover, convergence allows users to blur the lines between their devices, and advancing that goal hasn’t been on the agenda with the current duopoly.
The librem 5 will put Matrix on the map as a serious contender for communication. Matrix has rallied quite a bit of momentum to bring more modern mobile-friendly communication, chat and voice to the Free software eco-system.
Overall, I expect the librem 5 to make Free software (not just open-source-licensed, but openly developed Free software) a serious player also on mobile devices. The Free software world needs such a device, and now is the time to create it. With this huge success comes the next big challenge, actually creating the device and software.

The unique selling points of the librem 5 definitely strike a chord with a number of target groups. If you’re doubtful that its first version can fully replace your current smart phone, that may be justified, but don’t forget that there’s a large number of people and organisations that can live with a more limited feature set just fine, given the huge advantages that private communication and knowing-what’s-going-on in your device brings with it.
The librem 5 really brings something very compelling to the table and those are the reasons why it got funded. It is going to be a viable alternative to Android and iOS devices that allows users to enjoy their digital life privately. To switch off tracking, and to sleep comfortably.
Are you convinced this is a good idea? Don’t hesitate to support the campaign and help us reach its stretch goals!

Plasma Mobile and Convergence

Convergence, or the ability the serve different form factors from the same code base, is an often discussed concept. Convergence is at the heart of Plasma‘s design philosophy, but what does this actually mean to how apps are developed? What’s in it for the user? Let’s have a look!

Plasma -- same code, different devices
Plasma — same code, different devices

First, let’s have a look at different angles of “Convergence”. It can actually mean different things, and there is overlap between these. Depending on who you ask, convergence could mean any of the following:

  • Being able to plug a monitor, keyboard and mouse into smartphone and use it as a full-fledged desktop replacement
  • Develop an application that works on a phone as well as on a desktop
  • Create different device user interfaces from the same code base

Convergence, in the broadest sense, has been one of the design goals of Plasma when we started creating it. When we work on Plasma, we ultimately expect components to run on a wide variety of target devices, we refer to that concept as the device spectrum.

Alex, one of Plasma’s designers has created a visual concept for a convergent user interface, that gives an impression how a fully convergent Plasma could look like to the user:

Input Methods and Screen Characteristics

Technically, there are a few aspects of convergence, the most important being: input methods, for example mouse, keyboard, touchscreens or combinations of those, and screen size (both physical dimensions, portrait vs. landscape layout and pixel density).

Touchscreen support is one aspect when it comes to run KDE software on a mobile device or within Plasma Mobile. Touchscreens are not specific to phones any more however, so making an app, or a Plasma component ready for touchscreen usage also benefits people who run Plasma on their convertible laptops, for example. Another big factor is that the app needs to work well on the screen of a smartphone, this means support for high dpi screens as well as a layout that presents the necessary controls in a way that is functional, attractive and user-friendly. With the Kirigami toolkit, which builds on top of QtQuick, we develop apps that work well on both target devices. From a more general point of view, KDE has always developed apps in a cross- platform way, so portability to other platforms is very much at the heart of our codebase.

The Kirigami toolkit, which offers a set of high-level application flow-controls for QtQuick applications achieves exactly that: it allows to built responsive apps that adapt to screen characteristics and input method.

(As an aside, there’s the case for Kirigami also supporting Android. Developing an app specifically for usage in Plasma may be easier, but it is also limiting its reach. Imagine an app running fine on your laptop, but also on your smartphone, be it Android or drive by Plasma Mobile (in the future). That would totally rock, and it would mean a target audience in the billions, not millions. Conversely, providing the technology to create such apps decreases the relative investment compared to the target audience, making technologies such as QtQuick and Kirigami an excellent choice for developers that want to maximize their target audience.)

Plasma Mobile vs. Plasma Desktop

Plasma Mobile is being developed in tandem with the popular Plasma desktop, in fact it shares more then 90% of the code with it. This means that work done on either of the two, mobile and desktop often benefits the other, and that there’s a large degree of compatibility between the two. The result is a system that feels the same across different devices, but makes use of the special capabilities of a given device, and supports different ways of using the software. On the development side, this means huge gains in terms of productivity and quality: A wider set of usage scenarios and having the code running on more machines means that it gets more real-world testing and bugs get shaken out quicker.

Who cares, anyway?

Whether or not convergence is something that users want, I think so. It takes a learning curve for users, and I think advancements in technology to bring this to the market, you need rather powerful hardware, the right connectors, and the right hardware components, so it’s not an easy end-goal. The path to convergence already bears huge benefits, as it means more efficient development, more consistency across different form factors and higher quality code.

Whether or not users care is only relevant to a certain point. Arguably, the biggest benefit of convergence lies in the efficiency of the development process, especially when multiple devices are involved. It doesn’t actually matter all that much if users are going to plug their mouse and keyboard into a phone and use it as a desktop device. Already today, users expect touchscreen to just work, even on laptops, users already expect the convertible being usable when the keyboard is flipped away or unplugged, users already expect to plug a 4K into their 1024×768 resolution laptop and the UI neither becoming unreadable or comically large.

In short: There really is no way around a large degree of convergence in Plasma (and similar products).

Plasma’s road ahead

My Plasma Desktop in 2016
My Plasma Desktop in 2016
On Monday, KDE’s Plasma team held its traditional kickoff meeting for the new development cycle. We took this opportunity to also look and plan ahead a bit further into the future. In what areas are we lacking, where do we want or need to improve? Where do we want to take Plasma in the next two years?

Our general direction points towards professional use-cases. We want Plasma to be a solid tool, a reliable work-horse that gets out of the way, allowing to get the job done quickly and elegantly. We want it to be faster and of better quality than the competition.

With these big words out there, let’s have a look at some specifics we talked about.

Release schedule until 2018

Our plan is to move from 4 to 3 yearly releases in 2017 and 2018, which we think strikes a nice balance between our pace of development, and stabilization periods around that. Our discussion of the release schedule resulted in the following plan:

  • Plasma 5.9: 31 January 2017
  • Plasma 5.10: May 2017
  • Plasma 5.11: September 2017
  • Plasma 5.12: December 2017
  • Plasma 5.13: April 2018
  • Plasma 5.14 LTS: August 2018

A cautionary note, we can’t know if everything exactly plays out like this, as this schedule, to a degree depends on external factors, such as Qt’s release schedule. Here’s what we intend to do, it is really our “best guess”. Still, this aligns with Qt’s plans, who are also looking at an LTS release in summer 2018. So, what will these upcoming releases bring?

Breeze Look and Feel

Breeze Look and Feel

UI and Theming

The Breeze icon theme will see further completion work and refinements in its existing icons details. Icon usage over the whole UI will see more streamlining work as well. We also plan to tweak the Breeze-themed scrollbars a bit, so watch out for changes in that area. A Breeze-themed Firefox theme is planned, as well as more refinement in the widget themes for Qt, GTK, etc.. We do not plan any radical changes in the overall look and feel of our Breeze theme, but will further improve and evolve it, both in its light and dark flavors.

Feature back-log

The menu button is a first sign of the global menu returning to Plasma
The menu button is a first sign of the global menu returning to Plasma
One thing that many of our users are missing is support for a global menu similar to how MacOS displays application menus outside of the app’s window (for example at the top of the screen). We’re currently working on bringing this feature, which was well-supported in Plasma 4 back in Plasma 5, modernized and updated to current standards. This may land as soon as the upcoming 5.9 release, at least for X11.

Better support for customizing the locale (the system which shows things like time, currencies, numbers in the way the user expects them) is on our radar as well. In this area, we lost some features due to the transition to Frameworks 5, or rather QLocale, away from kdelibs’ custom, but sometimes incompatible locale handling classes.

Wayland

The next releases overall will bring further improvements to our Wayland session. Currently, Plasma’s KWin brings an almost feature-complete Wayland display server, which already works for many use-cases. It hasn’t seen the real-world testing it needs, and it is lacking certain features that our users expect from their X11 session, or new features which we want to offer to support modern hardware better.
We plan to improve multi-screen rendering on Wayland and the input stack in areas such as relative pointers, pointer confinement, touchpad gestures, wacom tablet support, clipboard management (for example, Klipper). X11 dependencies in KWin will be further reduced with the goal to make it possible to start up KWin entirely without hard X11 dependencies.
One new feature which we want to offer in our Wayland session is support for scaling the contents of each output individually, which allows users to use multiple displays with vastly varying pixel densities more seamlessly.
There are also improvements planned around virtual desktops under Wayland, as well as their relation to Plasma’s Activities features. Output configuration as of now is also not complete, and needs more work in the coming months. Some features we plan will also need changes in QtWayland, so there’s some upstream bug-fixing needed, as well.

One thing we’d like to see to improve our users’ experience under Wayland is to have application developers test their apps under Wayland. It happens still a bit too often that an application ends up running into a code-path that makes assumptions that X11 is used as display server protocol. While we can run applications in backwards-compatible XWayland mode, applications can benefit from the better rendering quality under Wayland only when actually using the Wayland protocol. (This is mostly handled transparantly by Qt, but applications do their thing, so unless it’s tested, it will contain bugs.)

Mobile

Plasma’s Mobile flavor will be further stabilized, and its stack cleaned up, we are further reducing the stack’s footprint without losing important functionality. The recently-released Kirigami framework, which allows developers to create convergent applications that work on both mobile and desktop form-factors, will be adjusted to use the new, more light-weight QtQuick Controls 2. This makes Kirigami a more attractive technology to create powerful, yet lean applications that work across a number of mobile and desktop operating systems, such as Plasma Mobile, Android, iOS, and others.

Plasma Discover
Discover, Plasma’s software center integrates online content from the KDE Store, its convergent user-interface is provided by the Kirigami framework

Online Services

Planned improvements in our integration of online services are dependency handling for assets installed from the store. This will allow us to support installation of meta-themes directly from the KDE Store. We want to also improve our support for online data storage, prioritizing Free services, but also offer support for proprietary services, such as the GDrive support we recently added to Plasma’s feature-set.

Developer Recruitment

We want to further increase our contributor base. We plan to work towards an easier on-boarding experience, through better documentation, mentoring and communication in general. KDE is recruiting, so if you are looking for a challenging and worthwhile way to work as part of a team, or on your individual project, join our ranks of developers, artists, sysadmins, translators, documentation writers, evangelists, media experts and free culture activists and let us help each other.

Plasma Components on Android: Accelerating Subsurface Mobile Development

Marco has come over to the Netherlands to pay me a visit, and to hack a little bit together, in person. So with the weather clearly suggesting to stay inside, that’s what we did over the weekend, and how better to entertain yourself than to work on mobile software?

Marco has been working for a while on components that follow Plasma’s human interface guidelines and make it easy to implement applications with a common navigation pattern and look and feel. Obviously, these components use a lot of Plasma under the hood, so they get excellent integration at a visual and at a technical level. This high integration, however, comes at the price of having a non-trivial chain of dependencies. That’s not a problem in Plasma Mobile, or other Plasma workspaces, since all that is already there, anyway.
We thought that an interesting exercise would be to find out what really defines a “Plasma application”, and how we can make the concepts we engrained in their design available to application developers more easily. How hard could it be to use Plasma components in an Android app, for example? The answer is, not entirely trivial, but it just became a whole lot easier. So what did we do?

For those reading this article via a feed aggregator, hop over to youtube to watch the demo video.
We took Subsurface, which is a piece of Free software used for logging and analysing scuba dives. Subsurface has a mobile version, which is still in its infancy, so it’s an excellent candidate to experiment with. We also took Marco’s set of Plasma components that provide a reduced set of functionality, in fact, just enough to create what most applications will need. These components extend QtQuick components where we found them lacking. They’re very light weight, carry no dependencies other than QtQuick, and they’re entirely written in QML, so basically, you add a bunch of QML files to your app and concentrate on what makes your app great, not on overall navigation components or re-implementing for the n-th time a set of widgets.

So after solving some deployment issues, on Saturday night, we had the Plasma mobile components loading in an Android app. A first success. Running the app did show a number of problems, however, so we spent most of the Sunday to look into each problem one by one and trying to solve them. By early Monday morning, we had all of the glaring issues we found during our testing solved, and we got Subsurface mobile to a pretty solid appearance (pretty solid given its early state of development, not bug free by any means).

So, what to take a away from this? In a reduced form, Plasma can be a huge help to create also Android applications. The mobile components which we’re developing with Plasma Mobile as target in mind have had their first real world exposure and a lot of fixes, we got very useful feedback from the Subsurface community which we’re directly feeding back into our components.

A big thanks goes out to the Subsurface team and especially Dirk Hohndel for giving us excellent and timely feedback, for being open to our ideas and for willing to play guinea pig for the Plasma HIG and our components. The state you can see in the above video has already been reviewed and merged into Subsurface’s master tree, so divers around the world will be able to enjoy it when the app becomes available for a wider audience.

screen config victory!

kscreen wayland backend in action
kscreen wayland backend in action
That moment when the application “just works” after all your unit tests pass…

A really nice experience after working on these low-level bits was firing up the kscreen systemsettings module configured to use my wayland test server. I hadn’t done so in a while, so I didn’t expect much at all. The whole thing just worked right out of the box, however. Every single change I’ve tried had exactly the expected effect.
This screenshot shows Plasma’s screen configuration settings (“kscreen”). The settings module uses the new kwayland backend to communicate with a wayland server (which you can see “running” on the left hand side). That means that another big chunk of getting Plasma Wayland-ready for multi-display use-cases is falling nicely into place.

testing

I’m working on this part of the stack using test-driven development methods, so I write unit tests for every bit of functionality, and then implement and polish the library parts. Something is done when all units tests pass reliably, when others have reviewed the code, when everything works in on the application side, and when I am happy with it.
The unit tests stay in place and are from then on compiled and run through our continuous integration system automatically on every code change. This system yells at us as soon as any of the unit tests breaks or shows problems, so we can fix it right away.

Interestingly, we run the unit tests live against a real wayland server. This test server is implemented using the KWayland library. The server runs headless, so it doesn’t do any rendering of windows, and it just implements the bits interesting for screen management. It’s sort of a mini kwin_wayland, the real kwin will use this exact same library on the server side, so our tests are not entirely synthetical. This wasn’t really possible for X11-based systems, because you can’t just fire up an X server that supports XRandR in automated tests — the machine running the test may not allow you to use its graphics card, if it even has one. It’s very easy to do, however, when using wayland.
Our autotests fire up a wayland server from one of many example configurations. We have a whole set of example configurations that we run tests against, and it’s easy to add more that we want to make sure work correctly. (I’m also thinking about user support, where we can ask to send us a problematic configuration written out to a json file, that we can then add to our unit tests, fix, and ensure that it never breaks again.
The wayland test server is only about 500 lines of relatively simple code, but it provides full functionality for setting up screens using the wayland protocol.

Next steps…

The real kwin_wayland will use the exact same library, on the server as we do in our tests, but instead of using “virtual screens”, it does actually interact with the hardware, for example through libdrm on more sensible system or through libhybris on ones less so.
Kwin takes a more central role in our wayland story, as we move initial mode-setting there, it just makes to have it do run-time mode setting as well.

The next steps are to hook the server side of the protocol up in kwin_wayland’s hardware backends.

In the back of my head are a few new features, which so far had a lower priority — first the core feature set needed to be made stable. There are three things which I’d like to see us doing:

  • per-display scaling — This is an interesting one. I’d love to be able to specify a floating point scaling factor. Wayland’s wl_output interface, which represents the application clients, only provides int-precision. I think that sucks since there is a lot of hardware around where a scaling factor of 1 is to small, and 2 is too high. That’s pretty much everything between 140 and 190 DPI according to my eyesight, your mileage may vary here. I’m wondering if I should go ahead and add the necessary API’s at least on our end of the stack to allow better than integer precision.
    Also, of course we want the scaling be controlled per display (and not globally for all displays, as it is on X11), but that’s in fact already solved by just using wayland semantics — it needs to be fixed on the rendering side now.
  • pre-apply checks — at least the drm backend will allow us to ask it if it will be able to apply a new configuration to the hardware. I’d love to hook that up to the UI, so we can do things like enable or disable the apply button, and warn the user of something that the hardware is not going to like doing.
    The low-level bits have arrived with the new drm infrastructure in the kernel, so we can hook it up in the libraries and the user interface.
  • configuration profiles — it would make sense to allow the user to save configurations for different situations and pick between them. It would be quite easy to allow the user to switch between setups not just through the systemsettings ui, but also for example when connecting or disabling a screen. I an imagine that this could be presented very nicely, and in tune with graphical effects that get their timing juuuuust right when switching between graphics setups. Let’s see how glitch-free we can make it.

Getting Email Done: The Stack and the Heap of Lion Mail

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.

In the panel, you can quickly see if there are new emailsComplex 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 popup shows a list of the new emailsThe 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

Important emails are accessible in a separate listThis 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.

In the setup you can specify which folders to monitor and wether or not to show important emails

Email Items

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.

Emails can be sorted using flags directly from the popup

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?

Otherwise, I wonder if "the other Sebastian"’s recent Nepomuk accomplishments in excerpting documents play into our collective hands, or we’re in his of course. :-)

Emails as first-class citizens in your workspace

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.Email lists can be put on the desktop, and switched depending on your activity

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.Single emails can be put on the desktop as well, for quick reference

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.

Up’ed to wordpress 3.0

I’ve upgraded my weblog to WordPress 3.0, if you encounter anything weird or wrong, please let me know in the comments. Thanks!

To make this blog entry slightly more useful, I’ve found the Android WordPress application pretty handy. In order to prevent spam, I’ve enabled moderation for the first comment of a person. This way I can more easily keep moderation times down and make that necessity a bit less annoying by quickly approving non-spam comments on my blog. The Akismet spam filter is already pretty good with 99.8% accuracy, the overall ratio spam vs. comments being roughly 50/50. Comment spam that slips through Akismet is caught in moderation, that way I can make sure that no spam shows up at all. WordPress on Android makes the approval process rather handy. It would be nice if the app could automatically check for comments and notify of new ones that need moderation though. If you don’t like web browsers to manage your wordpress blog, I find Blogilo as a desktop client and wordpress on Android app a very nice combo.