[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-pim
Subject:    Re: [Kde-pim] KABC Addresses
From:       Anders Lund <temp_and () tiscali ! dk>
Date:       2002-10-01 22:40:01
[Download RAW message or body]

On Tirsdag den 1. oktober 2002 23:29, Tobias Koenig wrote:
> On Mon, Sep 30, 2002 at 11:54:22PM +0200, Anders Lund wrote:
> > On Mandag den 30. september 2002 00:44, Tobias Koenig wrote:
>
> Hi Anders,

> Ok, than we'll add it to the Field class.

Good:)

> > I don't think you understand the purpose/possibilities of the card view.
> > The idear (and yes, the card view was written by Mike originally on my
> > suggestion and after we discussed it) is that you can display _any_
> > addressbook data in any order you want to, for any user that you wish, as
> > a "rodolex card" in one scrollable widget.
> >
> > There is a screenshot below, which clearly shows that formatted addresses
> > would be nice btw.
>
> It looks really nice, but I've a problem with the code duplication.
> We decided that the views give a overview of all available addresses
> together with short informations. All formatted or additional informations
> should be presented in the details page. That is a clear concept and the
> card view tries to break it now. :(

I don't get where the code duplication comes in. The card view allows you to 
select from the fields available in the Fields lists, and renders them as 
good as it can. 

I'd found it unclear and confusing that I couldn't find _all_ available 
strings - including formatted ones - in the Fields lists, and that some views 
were denied the option of displaying some data. So you and I think different, 
and flexibility is to allow for configurations suitable for both of us, as I 
see it.

> > In the end, the card view will somehow support selecting and copying
> > text, so I can copy for example formatted addresses, account numbers etc
> > directly into where I need it.
>
> IMHO implementing it in details page is better. If somebody likes the icon
> view more than the card view he can even so use this feature.

The card view supporting selections, or any feature at all, will prevent 
anyone from using the icon view - any view - along with the details panel.

> > If you dislike the idear of a flexible view and decides to prevent it, it
> > also means that you don't want KAddressBook to be a flexible application
> > providing choices for us all,
>
> That's not flexible, thats confusing...
> We should present the user a clear concept:
>   - views provides overview
>   - details page provides more (readable) informations
>   - quickedit provides editing facilities
>   - ditributionlist/categorymanager provides grouping of contacts

That will still be the case. The overviews just gets more accurate and 
flexible. Better.

> If now every view tries to get a i18n('eierlegendewollmilchsau') (a thing
> that tries to provides everything) we get lots of duplicated code => bugs,
> and the useability decrease.
> Flexibility would be a clear API to extend the 'Views', 'DetailsPage' and
> the other main components.

:-\ [I still don't get where there will be duplicate code]

> > and I will need once more to think of writing another KABC client -
> > something that we all wanted to avoid some time ago when Mike,
> > Andrew and I caused some debate of the KAddressBook user interface.
>
> Features are nice, but they have to be consistent with the rest of the
> program.

Well, it is - the improved card view provides the feature the rest of the 
featurerich application lacks, as I see it.

Apart from that, this was - at least not entirely - meant to be a discussion 
about the card view. Other applications will also benefit from all available 
fields beeing available through Addressee, an upcoming kword mailmerge plugin 
for kabc is still a good example: using the standard field selector a user 
could choose "home adress" and not have to fight with scripting to get rid of 
empty postbox lines, for example.

> > I still think working togeather on making KAddressBook a good and
> > flexible tool is much better, how about you?
>
> I agree, but a reasonable discussion results in a better design. And a
> good design provides flexibility and extensibility.

I sure enjoy the discussion. I also realize that debating has been my main 
contribution so far, though I hope that will change...

-anders



_______________________________________________
kde-pim mailing list
kde-pim@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-pim
kde-pim home page at http://pim.kde.org/
[prev in list] [next in list] [prev in thread] [next in thread]