OCT
1
2015
|
The Future of KontactSupplemental to what we reported previously about the work in Randa [1, 2] there was a session on the future of Kontact, KDE’s personal information manager (PIM). Over the years this tool has evolved into a monster making both development as well as usage sometimes tricky. It’s time to cut hydra’s arms. TL;DR: Sorry for the long posting. This blog post is about requirements for Kontact mobile. It also shows a couple of mockups based on the preliminary mobile HIG that illustrate what the requirements mean. Vision “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....” (read more at Thomas Pfeiffer's blog and the new KDE PIM wiki page) In addition the generic “simple by default and powerful on demand” should be true. That means among others to drop all non-core features. Since KDE software will run on mobile and touch devices the next version of Kontact has to runs smoothly on all devices and form factors. And the special aim of the developers is that Kontact will become the first tool when privacy and security is of primary interest. Persona and Scenario There shouldn’t be much to clarify about the desktop scenario. In respect to mobiles we have to consider first phones with ~4 to 5” in both vertical and horizontal orientation. For instance, the phone can be used vertically to get an overview of incoming emails and provide details on the selected item when rotated. Additionally we have to take tablets with 10-12” and wearables into account. The latter might be a small wrist watch but also a head-mounted display with a larger visualization. Requirements
KMail
UI relevant features with relevance and suggested realization:
core/basic features = program does not work without, performance = not absolutely necessary, but create the impression of a good product, buzz = not expected by default, exotic = not really needed Calendar & Addressbook Mockups Multiple level of details
The probably most shining feature is the graph supporting the orientation. It is inspired by GitHub with the idea to flatten the current system of reply indention. If Alice communicates with Bob there would be a straight line. And if John joins and “branches” the discussion this would be illustrated respectively. Interactions
Context relevant functions are located in the right drawer. It opens when the user swipes from right to left offering all functions with the current list as well as the selected item. If the user wants to have quick access to a particular function, such as reply (reply to all in case of mobiles) and delete, these features may be selected for having them at the handle, which is shown on slid sideways. The user can decide what he or she wants to have there but with a limit to a few functions only (here two). Normal email programs work with a couple of fix folders like inbox, sent, and trash plus user-defined folders. But reading an email in a conversation without reference to own contributions is weird. And using predefined folders is also somewhat outdated. The idea is to have filters like “all incoming unread messages” (replacing the inbox), “emails with reference to KDE in the header or sent from *@kde.org” (replacing personal folders). The creation of those filters (like smart folders in the Mac OS world and also similar to the stored search in the current KMail) could be done on the desktop for convenience. The mobile app provides checkboxes to have any combination of those filters. Form factors and orientation
Different form factors like in rotated orientation or in case of a larger displays have to be taken into consideration. While the number of shown emails is reduced it is possible to read the content of the selected item, at least in terms of the preview.
With more size the screen may get organized like in conventional email applications. The left, global drawer (aka sidebar in desktop apps) offers navigational and global features (still providing access to dynamic filters), there is an overview of all emails (here with more information compared to the mobile version), and the details below. Large screens makes it also possible to show a toolbar with labeled buttons instead of the right context drawer. It should be kept in mind that users may want to switch to the mobile version on the desktop, for example in order to have a small app running on a secondary screen. Alternative version
Of course you can (and should) refuse requirements that make no sense to you. For instance, if threading is less important and if the major focus is not on as many items as possible at once, the user interface may look like in figure 5. Colors can be added to support navigation and orientation, but must not be used as primary indicator. That means, similar to existing apps the items may have a small indicator bar, or the like, for the respective filter. Configuration
Conclusion / Participation Finally kodus go to Michael Bohlender, Christian Mollekopf, Andreas Kainz, Uri Herrera, and Jens Reuterberg who discussed the topic at Randa. Also big hugs to the mobile HIG team with Thomas Pfeiffer and Alex L. |
![]() |