Notes From the PIM Sprint: A Vision for the KDE PIM Framework
I know I know, the PIM sprint has already been last November, but in my defence (@David: !!!), the VDG and KDE as a whole has been so buzzing with activity in the meantime that I didn’t find the time to write the blog post I had meant to write about it. So here it is, better late than never.
Now, what did I do at the KDE PIM sprint?
There were two topics I brought to the table:
- Developing a project vision for KDE PIM in general and/or Kontact in particular
- Making KMail’s search useful again
In this post I’ll cover the first topic.
A project vision is something that has proven to be useful in product design and development in general, and maybe even more so in Free Software projects. The KDE Human Interface Guidelines define a project vision this way:
A vision describes the goal of the project. It can be emotive and a source of inspiration, for instance by outlining how the final product makes the world a better place. Describe the project’s final goals. Explain who will use the product, and how he or she will take advantage of it. Make sure the vision is shared between all project stakeholders. Leave room in the vision for creativity. Keep it short.
The reason why I (and others) think a project vision is especially useful for FOSS projects is that since the typical FOSS project community is a bunch of quite diverse individuals, each with their own goals and ideas. This is of course one of the great strengths of Free Software, but it also means that, without communicating about those goals and ideas, the members of the community might all march in different directions without even noticing. That is what can lead to what users perceive as a lack of consistency and a lack of common direction.
A project vision can help make the individual ideas and goals explicit, and allow the community to agree on a common goal and direction. That does not mean people are not allowed to add features which are not consistent with the vision, but that the community should think carefully why such a feature should be added anyway. It also helps telling users who keep asking for features which are not consistent with the vision why those features won’t be implemented.
So, I suggested to the KDE PIM community to come up with a vision for their project. Since the KDE PIM project actually produces a whole range of products, the group decided to have specific visions, at least one for the KDE PIM Framework and one for its desktop client Kontact. The time at the sprint was not sufficient for a draft vision for Kontact, but for the framework, we now have a vision draft:
The KDE PIM Framework allows to easily create personal information management applications ranging from personal to large enterprise use, for any target device and major platform.
It seamlessly integrates data from multiple sources, while aiming to be rock-solid and lightning-fast.
The PIM framework focuses on supporting open groupware servers like Kolab, but can be extended to access information from various sources.
Now there are some very important points in there. First is a commitment to broad applicability (it’s a framework, after all!) across usecases and target platforms, as well as a commitment to speed and stability. If the community at large (i.e. also those whop were not present at the sprint) agrees on this vision, this means, for example, that if someone wants to use the framework to create an enterprise application but finds that it currently lacks for example scalability to do so, the team cannot say “But it was never meant for enterprise use!”.
The second part is a commitment to the current driving forces between the PIM Framework: It makes clear that Kolab and similar open groupware servers are what the team cares about most, without excluding other backends. In practice, that means that if someone for example wants the framework to support Microsoft Exchange, the team can say “Please refer to our vision: Exchange is not our focus. So, if you want to integrate support for it in the KDE PIM Framework, you will have to find someone to do it. We’re open to it, but we have other priorities.”
Now as a next step, this vision draft will have to be presented to the whole KDE PIM community, perhaps iterated upon, and finally agreed upon and published officially.
In the same vein, a vision for Kontact should be created. Some input for this formulated by Aaron Seigo:
Now I’d like to see the idea of creating project visions spread to other projects (for example Krita already has one, KDE Telepathy also has a draft which awaits publishing, and the KDE Visual Design Group has committed to creating a vision as a first step when designing or fundamentally redesigning applications). If your project would like to create a vision, feel free to ask any VDG member of your choice or start a thread on the VDG forum.
So, what’s your take on this? Do you think a project vision can be helpful? What do you think about the proposed vision of the KDE PIM Frameworks? Let’s hear your opinion in the comments!
Thomas, I evaluate every addressbook program based on how easy it is to use addressbook data in shell scipts. I consider my addressbook a data source from which I can create various html pages, reminder scripts, etc which I can run in crontab. I also import the data into sqlite for report writing. If I can’t get the data out of the addressbook with a shell script, I move on.
Okay, so thought experiment: Would you see that requirement as consistent with the proposed vision?
> Do you think a project vision can be helpful?
Yes! Of course, if there’s a goal, people can know where to walk to instead of wasting efforts.
It depends on how “provides unified access to groupware data” is implemented. The ability to export data via a shell script is one implementation.
Indeed. And command-line access might be an important feature especially for the enterprise context, where automation is much more widespread than in personal use.
Enterprise usage does not rely, in the least, on shell scripting on the client side.
The % of people who use applications like Kontact who also rely on shell scripting to manage the data -> extremely low.
It’s a valid use case, it’s just not a common one. Designing for valid but unusual use cases is one thing that has gotten Kontact / Akonadi into troublesome spots in the past.
That said, if you want address books that can be maniuplated from the command line, use a local address book file. Or store it in ldap and use any of the numerous ldap tools out there. Akonadi / Kontact does not enforce storage format. That’s kind of the point of the design.
“create various html pages”
Not a use case for any groupware *client* anytime, anywhere. This is a storage-side issue.
“reminder scripts, etc which I can run in crontab”
Calendars with reminders serve this purpose for just about everyone.
It’s nice that you are so definitive. Bottom line: If you can export data to a csv/ldif/vcard file via the gui, some people would like to do that without manually envoking gui. .
The vision does not include ‘standards compliant”
KMail search started to work for me (Debian jessie). What needs improvement?
My biggest issue is currently sync with owncloud and an outbox in kmail, which disappeared:
The biggest challenge KDE PIM team is winning the KDE camp itself. I know a huge number of KDE users use Thunderbird or other email clients.
please make searching in kmail without accent. Lot of languages have diacritics and users don’t know, if mail was written with or withouth accent. I know that kmail search rely on baloo (https://bugs.kde.org/show_bug.cgi?id=333866), but if you changing this, please consider this behaviour.
Please, integrate KDE PIM with the Plasma Desktop at full scale. The Facebook backend needs only a timer (yes, a timer, to sync every 15 min) and a pair of bugfixes to notify posts from the Facebook timeline. OTOH, the KOrganizer reminder daemon makes no sense with Akonadi, KAlarm should be gone and Akregator 2 should be released, so, there’s space to remove programs and remove massive amounts of code without removing functionality,
I’m “just“ a user, but couldn’t Kontact be described as (i.e. have a vision of being):
The integrator of all KDE PIM Framework applications, which works so well that users prefer Kontact to using applications separately.
I am not saying there is anything wrong with the goals in the existing draft, but this is an alternative type of vision (less focus on technical aspects).
At least that’s what Kontact is to me. I can use each application separately, or I can use Kontact to have them all integrated into one workspace (or application, or whatever one would like to call it). The only application I sometimes start separately is KMail, and that is on my laptop since I want to use the whole screen for KMail.
This is great input for the Kontact vision! Keep in mind that the vision draft presented in the middle of the post is the one for the PIM Framework. For a vision for Kontact itself so far we have some input from Aaron (presented near the end of the post) and now yours as well.
Getting input for visions form users is always useful because it’s inetresting to see how users perceive a product as opposed to its creators.
[…] on which Plasma Mobile is built: Its vision. As I’ve already laid out in my blog post about creating a vision for the KDE PIM Framework, a vision is very important to align the work in a project towards a common goal, and to inspire […]