[Kde-pim] A new class of "Personal Information Manager"

[Janne Ojaniemi]

>
> I am not negative, rather, I am trying to encourage you to present
> your ideas in a form that can be translated into code because I am
> optimistic about your ideas. If you cannot visualize an "alternative
> UI" then don't mention it. Let's get working on a UI that you can
> visualize and take it from there.


The point I was trying to make is that I can see several different ways of
approaching this thing. Had I only mentioned the "email-like" UI, I would
have left the impression that that is the only way of doing this.


> What is a wikipedia-like interface? You assume that the developer
> knows what design elements distinguish Wikipedia for you. Don't assume
> that. State exactly what you like about Wikipedia's interface without
> ever mentioning Wikipedia..


The biggest difference when compared to the other UI is that it would be
less structured. In this approach, the content is at the foreground, while
the structure (dates, categories etc.) is in the background. This would be
more of a "custom" UI, since the initial view would be a "front page" of
sorts, that would contains links to various sections. The UI would be more
defined by the user than by the app. Think of it like a summary-view in
Kontact that would be more or less ttally customizable by the user. But
since I have less tangible examples to mention about this, let's just move
on.

In many ways I think that the different approachs presented here would mean
two separate apps. One of the approaches might be served by Basket, while
the other would need a whole different approach and a brand-new app.


>
> Yes, that was very comprehensible and easy to understand. In fact, I
> think that Basket meets 90% of your stated goals.


Basket seems to be the closest thing we have at the moment, but it needs a
dose of "magic" in it. That is, Nepomuk and Akonadi, combined with extensive
tagging-support, links to other articles and the like. I would also like to
see the timeline and dating, so you could really use it for journaling. In
the "nice to have"-category would be Krunner-support and a plasmoid for
quick note-taking.

The UI could be streamlined as well (for example: instead of filling the
sidebar with all the articles (which could number in the hundreds after
extensive long-term use), the sidebar could be used for just
tags/categories, and the articles could be listed in another text-area. But,
the current UI of Basket has it's benefits as well, namely it has more space
for the actual article. So there are pro's and cons to think of here. I like
the idea of having such a large space for the article, but I would like to
see some kind of solution if the user has lots and lots of articles (which
could make the sidebar very crowded). Maybe if th sidebar lists
tags/categories by default, so then the only area that would get "busy" is
the "All articles"-section which would list (as you guessed it) all
articles. But usually the user would browse the tags or the timeline
(clicking on the timeline would only show the articles from that time-period
for example).

>
>
> Basket, or another application. I don't think that BKO is the place to
> suggest new applications, but I actually have done that once.


Well, presenting (for example) the abovementioned features to Basket-devels
as individual bugreports would be quite complicated. I might do it, but I
think that what might be more straightforward is to mail them first, and see
what they think about it.
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/