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

Janne Ojaniemi janne.ojaniemi at gmail.com
Sat Nov 29 18:25:52 GMT 2008


>
> Well, like you mentioned Basket would have been the closest to what
>
you want. I would suggest that you make a detailed list of
> _specific_features_ that you would like to see added to Basket and we
> can help develop those ideas into informative bug reports to request
> those features. If you are of the opinion that a new application is
> needed, then I suppose that a bug against kdelibs would be the closest
> that we would get but it would probably be a long time (1/x as x->0)
> until a dev picks up the project.


Basket does some of the things I would like to see. If you want specifics
what I'm looking for.... Well, I haven't thought of the details that much,
but I'm thinking of two different approaches, one being "email-like", one
being something different. The email-like would be like this:

On the outside, the app could look like an email-app. That is, there is a
sidebar that has "folders" (actually, tags) that contain all the entries. At
the top would be "all entries" that contain (you guessed it), all entries,
in chronological format. The other entries in the sidebar would be the
various tags that are being used. The user could also rate entries, so there
would be a "Top Rated"-category in there.

There would also be a timeline, something similar to what F-spot has (see
here: http://lwn.net/images/ns/grumpy/im/f-spot.png). This would give the
user a tool to get a quick idea when he has posted entries, and he could
quickly jump to certain timeperiods.

To follow the "email-layout", there would be a list of messages that match
the selected tag, and from there the user could select individual articles.

To add an article... If the user hits any key, it opens a compose-window
(alternatively, there could be no "sub-windows", but the composing of new
articles could happen in the mainwindows itsef. It would keep things simple,
since there would not be multitude of windows floating around). This means
that dataentry is very fast, since user does not have to hit any specific
button (or a convulted button-combo) to create an entry. When the yser
starts to type on the keyboard, he start to write an article. Of course the
app would have shortcuts, but those need a meta-key in any case.

Of course, everything would be perfecty searchable.

All in all, very familiar to email. But unlike in email, the user could jump
from article to article. When user reads an article, there would be a
"related articles"-field that the user could use to jump to other related
articles. And of course the article itself could contain links to tags or
individual articles. Articles could also contain images and other media as
well. User could also add emails from Kmail to the journal.

What about the "other" UI? Well.... It would retain the timeline, but it
would look different from the abovementioned suggestion. It would look more
like a wiki. There would be a start-page (like Wikipedia has) that would
display information about current articles and anniversaries ("on this
day...."). There would be links to tags, so user could view articles that
have certain tags. This approach is harder to describe, since it's more
free-form. But Wikipedia could give you a rough idea :). But the start-page
would offer more direct way to access individual articles that what
Wikipedia does, since Wikipedia relies more on searching. Adding new
articles would be very straightforward still, ideally user could just start
typing.

The main difference between the two is that the first is more structured,
whereas the latter is more free-form (and harder to describe).

I think an app of this sort offers two huge benefits:

a) it lets you write down things that are important to you. Depending on how
you use it, it could become a knowledge-base, a straight journal/diary, tool
or collecting data or all of those in the same time. It really depends on
the user. I would like to see the app be flexible and "open ended", that is,
it could be used in different ways.

b) Since the data and entries would be interlinked, the value of the data is
greater that the value of each individual piece of data added together. And
this is magnified by the fact that the data would be interlinked to/from
other apps as well. Knowing that "John Smith's address is xxxxxxxx" is
valuable. But also knowing that he's married to Susan, worked for companies
yyyyyy and zzzzzz and that while he was in zzzzzz he was responsible for
product A, the value of the data goes up. Each of those datapieces is
valuable. But if we combine it all, it becomes greater than the sum of it's
parts.

You know, as I typed that, I was reminded of an app I ran in to just
yesterday (this is related somewhat to my "personal assistant"-discussion,
since same company makes both products): http://www.stikkit.com/. Stikkit is
basically notepad. But when you add data to it, the data gets more detailed
and interlinked. It's a smart system that can pick uf data about certain
item from several pieces of text. So if you write in note A that "John
Smith's address is xxxxx", and then you write in note B that "John Smiths
phonenumber is YYYYYY", the system knows that it should combine that data.
The system also notifies you of other things you have written about "John
Smith", like upcoming meetings and the like. Of course this data could be
fed to/from Address Book and Korganizer as well.

I hope that I have given at least some more tangible examples of what I'm
looking for :).
_______________________________________________
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/



More information about the kde-pim mailing list