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

[Dotan Cohen]

2008/11/29 Janne Ojaniemi <janne.ojaniemi at gmail.com>:
>>
>> 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.
>

With the addition of a timeline and a tag hierarchy Basket would match
this description perfectly.

> What about the "other" UI?
[snip]
> This approach is harder to describe, since it's more
> free-form. But Wikipedia could give you a rough idea :).

If you cannot describe it, then no one can write it. Actually,
Einstein had a good quote for this but I'd rather not be so blunt.

Like I said earlier, if you take the time to write a list of
improvements / ideas, where each list item is completely
self-contained (no references to "like wikipedia" or "like application
XYZ") then I will be happy to file bugs and feature requests. But you
need to structure your own ideas before you can expect developers to
implement them.

-- 
Dotan Cohen

http://what-is-what.com
http://gibberish.co.il

א-ב-ג-ד-ה-ו-ז-ח-ט-י-ך-כ-ל-ם-מ-ן-נ-ס-ע-ף-פ-ץ-צ-ק-ר-ש-ת
ا-ب-ت-ث-ج-ح-خ-د-ذ-ر-ز-س-ش-ص-ض-ط-ظ-ع-غ-ف-ق-ك-ل-م-ن-ه‍-و-ي
А-Б-В-Г-Д-Е-Ё-Ж-З-И-Й-К-Л-М-Н-О-П-Р-С-Т-У-Ф-Х-Ц-Ч-Ш-Щ-Ъ-Ы-Ь-Э-Ю-Я
а-б-в-г-д-е-ё-ж-з-и-й-к-л-м-н-о-п-р-с-т-у-ф-х-ц-ч-ш-щ-ъ-ы-ь-э-ю-я
ä-ö-ü-ß-Ä-Ö-Ü
_______________________________________________
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/