This blog post is based on the blog post The Future of Kontact. You are welcome to discuss the proposals and present own ideas.

Once again the requirements and figures:

• Receive/update: core > auto push or swipe down
• Overview as well as details view and the complete email: core/performance > selection and touch again
• Distinguish read from unread messages: core > grey out
• Reply/reply all/forward: performance (reading is preferred on mobiles) > context drawer / handle (reply to all only for mobiles)
• Compose: performance > global drawer
• Delete: performance > context drawer
• Move to folder (archive): buzz > context drawer
• Save/add attachment: buzz > context drawer
• Link item (add sender to/from address book, add appointment etc.): performance > context drawer
• Toggle html on/off: exotic / buzz > context drawer
• Show full header info: exotic / buzz > link
• Handle long lists of receivers: exotic (at overview)/ performance wrt. to security > cut by default
• Search for items: exotic > not implemented
• Sort items by property (time, sender, receiver...): exotic > not implemented
• Import/Export emails: exotic > not implemented

Figure 1: Several level of detail in order to support both a fast overview as well as having a preview and a full-size read mode. The figures also illustrate the idea to add graphical guidance a la GitHub.


Figure 2: Context functions with the selected item and global interactions with the app. In the right mockup the idea of dynamic filters is shown.


Figure 3: Horizontal orientation.


Figure 4: Desktop or tablet size version of Kontact+.


Figure 5: Alternate, even more simple version.

Edit: Fixed image storage; share.kde.org leads to internal server error when I try to share there

Salut.

My use case: I neither own nor wish to own a mobile device. Thus my interest is limited to the use of Kontact on the KDE desktop. I am no longer a part of a work organisation, so group facilities are not of interest to me. My use of KDE is as a private individual using a desktop.

I suggest that Kontact is one of the most important motivations in choosing KDE as one's desktop. KDE does many things very well, but few of them are unique. Widgets are great, but are available in many guises to other desktops. Excellent screen handling and memory management are not confined to KDE. This leaves KDE with its own great advantage: its integration of the desktop services with the data requirements of the user. There are several outstanding elements of such integration. The provision of tools to vary and control one's working environment to suit current activities is one. The intelligent maximisation of the use of those cues such as colour and shape available to the designer to enable the user to interact quickly and usefully with those working environments is a factor. The provision of tools to integrate and organise the user's data so that facts are presented in a timely and accessible fashion is another. These can be features of any desktop environment, and their provision certainly reached a high point in KDE 4. For me, however, the overriding need of a working environment is the provision of a reliable, well integrated and easily usable personal information manager.

From all of this you may infer that I am sad about the deliberate rejection of visual cues in the design of widgets and icons in the "flat" design paradigm (and note the complaints from those with visual acuity problems), that I am disappointed by regressions like the loss of differentiation possibilities between virtual desktops - I had hoped for movement in the opposite direction. You may also deduce that I regret the loss of momentum towards the semantic desktop. But my main interest here is in the area of desktop personal information management (PIM).

So I apologise if your interest is in screen design or mobile applications, but I do believe that Kontact on the desktop is important, at least to me and, more importantly, to the adoption of KDE. PIM is the main reason that I, and presumably others, chose and continue to use KDE.

Is Kontact moving forward? A few thoughts:

1. KJots has disappeared. My solution has been to install the excellent (but no longer maintained) BasKet application to import and present my KJots notes. BasKet can no longer be integrated into Kontact.

2. Akregator can no longer display web pages. Actually, it can, but only sometimes. On all other occasions it crashes the whole of Kontact. To avoid that I have to use the external browser to complement Akregator.

3. When I run Kontact I have two icons displayed in the system tray. The mail icon is always there. The Akregator icon only shows when I have unread articles. (That is a regression which appeared some time ago.) When I click on either of these icons I am presented with Kontact open at the last facility I used, not necessarily the one I just chose. The work-around for this is to open KMail and Akregator separately. But that means not using Kontact at all!

4. KOrganiser seems to have regressed badly. Its data are not available in Calendar widgets - which is probably a problem with those widgets. Its use of tags seems to have fallen in a heap. It does not remember how I like to see my calendar.

5. Kontact itself seems incapable of starting with the left hand (icon) pane displayed at the correct width, nor can its width be adjusted other than by maximising, then de-maximising the application. (This seems to be slightly different from the long-standing problem with Rekonq.)

6. I cannot detect any forward progress in any part of Kontact as it affects my use case. The address book still has no provision for dealing with the details of couples. There is no integration between the journal and the diary functions. Closing KMail as part of the shutdown of KDE does not empty the wastebin. I still have virtually no management control over the sent-mail folder. I cannot execute remote functions of one element from within another, such as ordering a mail check while I am in Akregator. Just a few thoughts.

All this sounds fairly negative. But I ask you to remember that I use KDE primarily because of Kontact and its components. It is the one overriding reason that I do not change my desktop. Yes, there are others, but it is Kontact which swings it for me.

So I thank you all for you efforts to create and maintain Kontact, and I wish you every success in driving it forward to even better things. And yes, we do all understand that the changes to QT5, Plasma5 and Wayland, as well as the requirements of mobile devices, are presenting a very complex working environment. Bon Courage!

Bob

Kontact (& email) is one of my most used applications. Currently (Version 4.14.10), the Kontact applications work fine, and I discover nifty things every once in a while...the latest being the message bar for showing plain or HTML format. I appreciate the thought and work that has gone into making Kontact and its pieces so useful.

The ideas for the Future of Kontact fit with my current needs and planned uses. I encourage you in these efforts. Sounds really good.

Thanks for replies, kallecarl and owdbob. @owdbob You mention a lot of very specific tools that are surely part of the KDE PIM umbrella but do you really need to integrate them into Kontact. Or would it be okay to have just the most relevant there?

I agree that I have not generally attempted to differentiate the elements of Kontact (KMail, Akregator etc) from Kontact itself. As a user I have at times loaded KMail and Akregator separately at startup, accessing other elements (such as KOrganiser) as required. Recently I have moved back to using Konact as a co-ordinated whole. Frankly I find this a more sensible approach.

While I am writing emails, for instance, I am likely to refer to my calendar, my address book or other personal Information. Doing so from within the same main window seems less disruptive than temporarily exiting one running application to activate another for reference before coming back to my start point. The tiny decisions and actions required to switch to another application, then decide whether or not to leave it running, revert to the first, then go to a third (etc...!) are certainly trivial, but they are also distracting and, surely, unnecessary.

In order to work effectively within one umbrella program is faster, less distracting and just plain more satisfying.

I have previously mentioned a couple of improvements which would (for me!) serve to increase that satisfaction. I might also suggest that the selection part of Kontact might also be considered. Perhaps a Thunderbird-like approach, using tabs, might be worth consideration. Certainly I would NOT suggest to the maintainers of Thunderbird that they split it into separate entities at run time.

I am sure that smarter people than me could find more potent ways of improving, rather than dumping, Kontact.

And you will, won't you?

Regards

Funnily enough, my workflow went the other way.

The history of my Kontact use goes like this:
1) KMail & KOrganizer as separate windows
2) Kontact – all in one
3) KMail as a separate window, plus KOrganizer & Zanshin as two tabs in a window
4) KMail & KOrganizer & Zanshin as separate windows (with even KMail being most of the time in a separate activity as the other two)

The mean reason why I moved from the all-in-one approach is two fold: 1) Kontact’s extra bar took too much space on my new 13" laptop; 2) when I need to refer to a calendar, I found it a lot easier to have mails open in one virtual desktop and the calendar in another – that way I can write an email undistracted while having calendar for reference near-by.

That being said, I do see the benefit of Kontact. I really liked its overview page, but for most of that (and maybe even nicer) I can achieve by using the EventList plasmoid. I have separate EventList plasmoids on my main desktop for events and tasks I have to do a) in the office, b) outside, c) deadlines of tasks that I delegated to someone else, d) other. Such a fine-grained distinction was not possible the last time I checked the Kontact overview page.

Anyway, I’m very much looking forward to see progress in KDEPIM again!

Another question: The thread-indicator graph takes a lot of precious horizontal space (wrt. phones). I'm surprised that nobody complained about that - or praised the feature. Opinions?

Heiko Tietze wrote:Another question: The thread-indicator graph takes a lot of precious horizontal space (wrt. phones). I'm surprised that nobody complained about that - or praised the feature. Opinions?

I deal with many long, very branched threads and that is a concern for me.

Currently I use the three-column layout (in full screen on a 13" display) and already the current threading/branching display at some point becomes tedious. I kinda like the new git-like idea, but could we have a way to flatten a thread, if it’s too long, while still having the information available? e.g. by having just one line going out from the first post indicating that everything below is part of this thread and then have some other visual clue to indicate the depth of the message in the thread (e.g. by more saturated/darker colour, a number indicating the depth). Alternatively, it could be useful to have such a thread ordered simply by timestamp.

Also I saw a mock-up one day (I’m not 100% it was on this forum or KDE) that suggested just one panel which was *either* the folder-view or the thread-view and thought that was pretty smart. That would mean that you can simplify the layout to two columns.

Hi everyone,

It is great to read that KMail / Kontact suite is alive. I have been using this software for many many years now and I would like to say that it has been a great piece of software!

However, I feel there is an important issue with KDEPIM and I need to say this because I like KDEPIM a lot and I'd like to see it used actively in the corporate world in future as well. If I may, please; from my experience KDEPIM needs proper Microsoft Exchange support. I mean, complete and full support of all protocols, calendar, calender sharing, fully compatible invites handling, votings, addressbook, resource handling, autoreply settings, todo lists, etc. I hate to say it but Microsoft Outlook is soo much advanced in terms of user experience. I would like to see KDEPIM again being the technological AND user experience leader!

Being an IT affiliate in different large corporations for many years now, I'd like to say that the true corporate e-mail standard is Exchange and not SMTP, IMAP or anything else. Is it about ideological reasons that Exchange has been completely ignored or that involved developers themselves lack experience in the corporate world? I don't know. But I would love to see KDEPIM putting full Exchange support as its highest priority.

Best Wishes,
Johannes

jfichtinger wrote:...Microsoft Outlook is soo much advanced in terms of user experience...

Disagreed, not only because of the generalization. Of course there is room for improvements.
About Exchange I'm not so sure about its promising future. But what I understand from the Wikipedia page (I'm not a dev) is that the proprietary protocal MAPI is, or rather can be, extended by the standards such as POP3, IMAP. So isn't it up to the admins to provide sane communication?

mapi is not a specified protocol but a (loosely) documented api under sole and proprietary control of ms.
there's the openchange project which tries to provide support "somehow" and is not very good.

suck it: exchange/outlook is a proprietary ms infrastructure and there seems little interest on their side to transform it into a protocol.
there's only one real exchange client (possible) and that is outlook.

and exchange sucks. badly.