[Kde-pim] Korganizer: The Next Generation

Janne Ojaniemi janne.ojaniemi at gmail.com
Thu Nov 27 12:38:26 GMT 2008

Hello everybody

First of all, I'm not 100% sure that should this go to kdepim-users or
kde-pim. I chose the latter, and I apologize if I chose wrong.

In this post I hope to give my my impressions as to what I think is wrong
with the calendar in Kontact, and what I would to do fix the issues. I am in
no position to make demands, so I'm not making any :). But I hope that some
of these ideas will be found to be interesting and worthwhile of looking in

The mockups I have are made in Qt Designer. They should not be looked at the
definite idea of what the calendar should look like. The UI-elements in my
mockups are more like placeholders for actual artwork. But they should give
you an idea what I mean.

The discussion about the calendar started in the KDE Forums, and you can
read that discussion here: http://forum.kde.org/showthread.php?tid=12436

Yeah, my initial post is pretty negative, But it does get better. I promise

Anyway, on to business.

Calendar in KDE4 looks like this:

There are five windows inside the app all shouting for the users attention.
The actual calendar (the most important part of.... well, calendar) has only
about 25% of the window to itself. And the various windows are not aligned
with each other, making the UI look "messy". There are also confusing
things, like "Default Korganizer resource" that is listed twice (and both
being checked by default). Just by looking at it, the user have no idea what
those "resources" are (apparently they are different calendars, but
shouldn't they be called calendars then, and not "resources"?). If you
actually enter a calendar-entry, it gets added twice to the calendar (since
the two "default resources" are both checked by default).

How would I go about fixing all that? Well, here is my mockup:


The mockup is missing the menubar and the Kontact-sidebar. And the tabs are
(obviously) named wrong. But it gives you an idea. To explain the mockup
(I'll just C&P from my forum-post):

The problem with current calendar is the there are too many thing demanding
attention from the user. The most important part of the calendar (the
calendar itself) only has about 25% of the UI to itself, rest being split on
other competing textboxes. The task of actually using the calendar is buried
under all that clutter. Of course it could be configured, but the user
should not have to do that.

In my suggestion, the calendar has most of the app-window to itself. And
there's a lot less stuff in the actual UI. There's the calendar that shows
your appointments, there's a minicalendar that can be used to choose the
date and there's a textbox for to-do's and other things. Yes, in my
suggestion, calendar would also handle to-do's, removing one component from

Notice the four tabs above the calendar? Those would take user to
month-view, week-view, day-view and tasklist. Tasklist would show a list of
tasks/appointments, starting from today, and going on as long as user has
calendar-entries. This setup would reduce the clutter in the toolbar (since
those views would not require a button in the toolbar), and the different
views would be immediately accessible right next to the calendar.

The user could tag calendar-entries, just like he could tag files in
Dolphin. All this would of course be tied to Nepomuk and Akonadi. And it
seems that there is such an idea presented here as well:


If user clicks or hovers on an calendar-entry, he gets a popup that gives
further details about the entry. Alternatively, this information could also
be shown in the textbox besides the calendar (there could be a tab to change
between "To-do" and "details"-view.

There are some views that would be accessed through the toolbar, like
timeline and time spent. List of different calendars would also be selected
from elsewhere, as opposed to cluttering the UI by constantly showing a list
of calendars.

Of course the calendar would be completely searchable, and entries could be

During the initial discussion I received comments that instead of using tabs
to switch views, buttons should be used instead. I have an alternative
mockup with such an UI here:


OK, that's my suggestion. I hope you find it at least remotely interesting
and useful. I do have two other things to discuss about as well (one being
about the address book, the other being about a whole new app), but those
can wait.

Yours respectfully
KDE PIM mailing list kde-pim at kde.org
KDE PIM home page at http://pim.kde.org/

More information about the kde-pim mailing list