“Kube is a modern communication and collaboration client built with QtQuick on top of a high performance, low resource usage core. It provides online and offline access to all your mail, contacts, calendars, notes, todo’s and more. With a strong focus on usability, the team works with designers and UX experts from the ground up, to build a product that is not only visually appealing but also a joy to use.”
For more info, head over to: kube.kde.org
Ever since we started working on Kube we faced the conundrum of how to allow Kube to innovate and to provide actual additional value to whatever is already existing out there, while not ending up being a completely theoretical exercise of what could be done, but doesn’t really work in practice. In other words, we want to solve actual problems, but do so in “better” ways than what’s already out there, because otherwise, why bother?
I put “better” into quotes because this is of course subjective, but let me elaborate a bit on what I mean by that.
Traditionally, communication and organization has been dealt with using fairly disjoint tools, that we as users then combine in whatever arbitrary fashion that is useful to us.
- Voice/Video Chat
However, these are just tools that may help us work towards a goal, but often don’t support us directly in what we’re actually trying to accomplish.
My goto example; Jane wants to have a meeting with Jim and Bob:
- Jane tries to find a timeslot that works for all of them (by mail, phone, personally…)
- She then creates an event in her calendar and invites Jim and Bob, who can in turn accept or decline (scheduling)
- The meeting will probably have an Agenda that is perhaps distributed over email, or within the event description
- A meeting room might need to be booked, or an online service might need to be decided.
- Once the meeting takes place the agenda needs to be followed and notes need to be taken.
- Meeting minutes and some actionable items come out of the meeting, that then, depending on the type of meeting, may need to be approved by all participants.
- So finally the approved meeting minutes are distributed and the actionable items are assigned, and perhaps the whole thing is archived somewhere for posterity.
As you can see, a seemingly simple task can actually become a fairly complex workflow, and while we do have a toolbox that helps with some of those steps, nothing really ties the whole thing together.
And that’s precisely where I think we can improve.
Instead of trying to do yet another IMAP client, or yet another calendaring application a far more interesting aspect is how can we improve our workflows, whatever tools that might involve.
Will that involve some email, and some calendaring and some notetaking? Probably, but it’s just a means to and end and not an end by itself.
So if we think about the meeting scheduling workflow there is a variety of ways how we can support Jane:
- The scheduling can be supported by:
- Traditional iCal based scheduling
- An email message to invite someone by text.
- Some external service like doodle.com
- The agenda can be structured as a todo-list that you can check off during the meeting (perhaps with time limits assigend for each agenda item)
- An online meeting space can be integrated, directly offering the agenda and collaborative note-taking.
- The distribution and approval of meeting minutes can be automated, resulting in a timeline of past meetings, including meeting minutes and actionable items (tasks) that fell out of it.
That means however that rather than building disjoint views for email, calendar and chat, perhaps we would help Jane more if we built and actual UI for that specific purpose, and other UI’s for other purposes.
So in an ideal world we’d have an ideal tool for every task the user ever has to execute which would mean we fully understand each individual user and all his responsibilities and favorite workflows….
Probably not going to happen anytime soon.
While there are absolutely reachable goals like Jane’s meeting workflow above, they all come at significant implementation cost and we can’t hope to implement enough of them right off the bat in adequate quality.
What we can do however is keeping that mindset of building workflows rather than IMAP/iCal/… clients and setting a target somewhere far off on the horizon and try to build useful stuff along the way.
For us that means that we’ve now set the basic structure of Kube as a set of “Views” that are used as containers for those workflows.
This is a purposefully loose concept that will allow us to transition gradually from fairly traditional and generic views to more purposeful and specific views because we can introduce new views and phase out old ones, once their purpose is helped better by a more specific view.
Some of our initial view ideas are drafted up here: https://phabricator.kde.org/T6029
What we’re starting out with is this:
- A Conversations view:
While this initially is a fairly standard email view, it will eventually become a conversation centric view where you can follow and pick up on ongoing conversations no matter on what medium (email, chat, …).
- A People view:
While also serving the purpose of an addressbook it is first and foremost a people centric way to interact with Kube.
Perhaps you just want to start a conversation that way, or perhaps you want to lookup past interactions you had with the person.
- A composer view:
Initially a fairly standard email composer but eventually this will be much more about content creation and less about email specifically.
The idea is that what you actually want to do if you’re opening the composer is to write some content. Perhaps this content will end up as email,
or perhaps it will just end up on a note that will eventually be turned into a blogpost, chances are you don’t even know before you’re done writing.
This is why the composer implements a workflow that starts with the starting point (your drafts) then goes over to the actual composer to create the content, and finally allows you to do something with the content, i.e. publish or store it somewhere (for now that only supports sending it by email or saving it as draft, but a note/blog/… could be equally viable goals).
The idea of all this is that we can initially build fairly standard and battle-tested layouts and over time work our way towards more specialized, better solutions. It also allows us to offload some perhaps necessary, but not central features to a secondary view, keeping us from having to stuff all available features into the single “email” view, and allowing us to specialize the views for the usecases they’re built for.