Re: Schema

On 14 Feb 2002 16:13:39 +0000
Owen Cliffe <occ@cs.bath.ac.uk> wrote:
[...]
> > It's certainly true that we as the developers of the app could
> enumerate all
> > of the possible contact types that we foresee. I'm always in favor of
> > providing advanced functionality, as long as it doesn't complicate the
> user
> > experience. Providing this table allows the user to create their own
> contact
> > types which we as developers may not think of. We could pre-populate
> this
> > table with what we expect they might need (just like your enumeration)
> and
> > then give them a pull-down list to select from the available choices
> when
> > their entering a new person (or editing a person). The option to add
> contact
> > types could be in an "advanced" tab so normally the user doesn't need
> to worry
> > about it. I can foresee some reasonable subset of our users having a
> desire
> > to create their own contact types, thus my arguing for this
> capability. It
> > adds one more query for us as developers (and adds the "advanced" tab
> to the
> > UI -- which can be put off to version 0.02) but shouldn't complicate
> the user
> > experience at all.
>
> i agree that it is perfectly valid feature, but the basic types _have_
> to be there, and by making them extensible you open up the need for all
> GPE applications to support then, I don't think you are going to be
> severely dis-advantaging users by limiting them to a fixed list and one
> or more "other" options.
>
> sorry i could be wrong and i don't want to troll on as it is really just
> a small thing.
>
> what does everybody else think?

OK, then let me throw my $0.02 into the jar ;)
I dont't know about the others but I have experience with PDAs since their
early beginnings, like the very old Casio Pocket Diaries. And ever since
that time with almost all the devices I ever had (and I bought many of
them!) I always felt limited. Either there was not enough room for certain
entries, or special categories were missing or a certain field was missing
or ... almost always something was missing or at least very limited.
The only device I know of that started to lift those limitations was the
Apple Newton. There you could define at least some of the fields for
yourself. The empty and undefined fields were also handled very smart. I
liked that very much!

The problem I see is that if we start counting up what we think a user
could need we will for sure miss at least one thing. Doesn't matter what
it is, but there will for sure be a Joe User that misses something; call
it a variant of Murphy's law.

With a proper relational database which we have with SQLite (it's probably
not the best but at least it's a start) we can overcome those limitations.
It is a great chance and could be a very unique feature to our GPE
applications.
And not only for feature-ism. I also think that it can be very handy if
not necessary to do so. For example name suffix was mentioned. We cannot
think of all suffixes in all languages now. We will for sure miss many of
them. So we create a table for them! Internationalization would become
much easier.
We should really only fix what is really fix.
A person has a first name, a given name and maybe additional names that
can be accumulated in one field. Any person can be addressed somehow, i.e.
Mr, Mrs, Dr., etc. But also those addressing fields should go into an
extra table! Here in Germany it would be Herr, Frau, Dr. so we would just
exchange the table. And even the user could add new ones on the fly. I
hope you get the picture of what I mean.

So on the buttomline: I would vote for abstraction. This gives flexibility
and finally freedom for the user. It will make the apps a little more
complex but with a RDBMS we have a good helper.

Then for the synchronization part.
This is really a problem and will persist for quite seme time. There is no
real standard especially not on the fields and datatypes. VCard is a de
facto standard and we should closely follow it as far as possible. But it
should not limit us or the user. We should support it in a way so that
data exchange is possible. But if we can have more flexibility on top of
it we should go for it!
We could for example create a default set of tables that contain the
settings that are proposed by VCard. We could even make those
"unchangeable" for the user so that the user will always be able to
exchange data with other devices. But there should be room for the user's
creativity.

So, how can we proceed to come to a final conclusion and decision?
Should we have some kind of a vote?

> owen
CU
  nils faerber

-- 
kernel concepts          Tel: +49-271-771091-12
Dreisbachstr. 24         Fax: +49-271-771091-19
D-57250 Netphen          D1 : +49-170-2729106
--