Converging Kubes

Kube, our PIM-Client in the making, is supposed to run on a variety of platforms and form-factors. We aim to provide a consistent look and feel across them all. If you know how to use Kube on your desktop machine, you will know how to use it on your Android phone or tablet as well. So what we are going to do, is building a UI for the phone, allowing it to display multiple pages on the tablet and in the end serving it on the desktop as well. Good idea, right?

Not quite. While consistency is our goal, we don’t believe in “one UI to rule them all”, at least not in the sense of just getting an enlarged version of your tablet app as a desktop application. Instead, what you will get with Kube is a specifically optimized user interface for each form-factor you are running it on. Thanks to QtQuick, the only difference will be “a little” UI code, the core will stay the same.

To achieve our UI goals, we are employing Kirigami UI. It offers us:

1) A set of UI Components that seamlessly integrate with QtQuick Controls to build a pretty UIs for Kube.

2) but more importantly: UI/UX patterns, that make the UI not only pretty but usable and bring us closer to our goal of convergence, despite beeng specially tailored for the form-factor.

No good blogpost without a picture. So here it is: A first look at Kube on mobile, build with Kirigami.

Kube Mail Mobile Mockup

A little Kube says “Hi!”

During the Randa Meetings in Switzerland this year, the KDE PIM team decided to do an experiment. We wanted to see how modern QtQuick based PIM applications could look like. So we started to develop Kube Mail, an email client build with QtQuickControls on top of Akonadi-Next. We reached our first milestone this week. It is about time to show it to a broader audience. This milestone includes a read-only client, that loads and displays emails from a mail resource from Akoandi-Next. Here it is:

What you see is a bunch of QML on top of Akonadi-Next with the data being provided by a maildir backend. The mail list doesn’t do any partial loading so far, so we end up with ~4000 mails getting loaded, respectively the fields we’re interested in thereof. So what this nicely showcases IMO is the performance you get. Every click on a folder executes a fresh query and the list view is populated almost instantly. Of course this is still far from ideal with many parts to improve, but we’re rather happy with the result given that we just hooked up the UI for the first time.

We are working on a docker container for easy building and testing Kube but is not quite there yet. So if you want to try it, you need to build it by hand. You can find the source code in playground (akonadi-next; kube)

For now this is still an experiment but it is looking promising so far. We will continue working on Kube and build it into a small but functional email client over the next year. Drop by on our weekly hangout (every Wednesday 16:00 CEST) or write a comment below if you are interested in joining us. People from the VDG already showed  interest, namely Alex L, Andrea Del Sarto and Jens Reuterberg. It is great to have their feedback in this early stage and we will work with them to ensure a great User Experience from the start.

Stay tuned for more updates. 

Mobile PIM at Randa

  I am sure you heard about Plasma Mobile by now. Plasma Active was the reason I joined KDE three years ago and I am happy that the journey to Free Software on multiple form factors and devices continues. Checking my mail is among the most common things I do on my phone. Plasma Mobile needs a kick ass mail application if it wants to be a viable alternative. I do mail stuff with QML. There was really only one conclusion. 🙂

folder

mails

mail

What you see in those pictures is a UI written with QtQuick Components that gets dummy data from a QML plugin. It is the first draft of what is to become a mail application for phones based on a future iteration of Akonadi (Akonadi Next).  I will attend the Randa meeting next month and hope to push this project forward while I am there.

On my list of things to do are:

  • getting this on a Plasma Phone
  • hooking the qml plugin into AkonadiNext
  • working on the visual and interaction design with the VDG
  • creating a vision and a name for the baby

Developer sprints like the one in Randa are massively important for KDE. They enable us developers to get lots of work done and coordinate things for the future. The most important aspect of it is probably the boost of motivation one gets from attending a sprint and meeting fellow developers in person. We would like to hold more sprints in the future, but we need the funds for it. As developers we already donate our free time and skills to produce something you probably enjoy. Please consider donating a little money to our fundraiser so we can push KDE Software to the world of mobile devices and more.

People of KDE – Mario Fux

Remember People behind KDE? It was an interview series with members of  the community. I always enjoyed reading it because it showed, that KDE is software produced by dedicated and enthusiastic people and that it is possible to become one of them. So eventually I did.

I have to do some interviews for an anthropology class this year and I decided to take the chance and revitalize the series. Instead of written interviews I will do video sessions. The idea is to have two parts. One is about the person and the other one is about a topic that is related to that person. KDE is no longer the product, but the name for the community so I decided to rename the series as well.

Let me present to you:

People of KDE – Episode 0

This is my very first interview. I will try to improve over time and I need your help for this.

  • was it interesting to you?
  • how do you like the format? Is 35~ minutes a good length for you?
  • how is the quality of the video/audio?
  • anything else that I can improve or that you wish I had done differently?

Thanks for watching.
And consider donationg for the Randa Meeting.

A glimpse at the future of Kontact Touch Mail

Kontact Touch was the one application that stood out when I tried Plasma Active for the first time. But not in a good way. It looked alien, the interaction was different from the other touch optimized applications and it just felt flawed. Custom buttons and other UI components, slide out context menus, widget based dialogs and a weird bar at the top show clearly that this application was not designed for Plasma Active.


Kontact Touch was written at a time when QtQuick was brand new which explains the custom UI elements that had to be build because there were no standard components. The target was an N900 like device with a small 3.5 ” screen compared to Plasma Actives minimal target of 7 “. It was designed to offer all the features of the desktop version on this small touchscreen and it does, which is its biggest problem.

My (GSoC) job this summer is to make Kontact Touch Mail a true Plasma Active application by reworking the user experience and porting it to Plasma Components in the process.

I believe it is nearly impossible to take all the features of a complex application suite like Kontact and support them equally on a (small) touchscreen without getting a flawed user experience. Therefore I will “reduce” features.

This is more about prioritizing and prominently supporting workflows, that are likely to occur on tablets/mobile devices while other workflows can still be possible but will not be as convenient. Some other features that don’t make sense on a mobile device might also have to go. Take a look at this wiki page if you want to know what’s planed in detail. I guess you want to see how it is going to look so here is a little mockup for you:

Reducing features for a better user experience is not really what one would expect to happen with a KDE application. What’s your take on this?

Hello Planet KDE!

Hey there,

this is my first blog and it will appear on Planet KDE if I did everything right.  My name is Mike and I am one of the lucky ones who made it into GSoC this year. I will work on Kontact Touch Mail but more about my project in another post.

I want to thank the organizers of GSoC in KDE and everyone who helped with my proposal. The whole application process was well structured, the documentation was great and I got a tone of helpful and constructive feedback. So to everyone involved: You rock!

Let’s have a great and productive summer (of code)

Mike