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

List:       kde-usability
Subject:    Re: yet another usabillity question
From:       Lucijan Busch <lucijan () gmx ! at>
Date:       2003-01-11 16:48:54
[Download RAW message or body]

On Saturday 11 January 2003 17:22, Alan Chandler wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Saturday 11 Jan 2003 1:59 pm, Lucijan Busch wrote:
> > hi
> >
> > we are developing a database management tool for koffice which is called
> > kexi. for fother informations about it see
> > http://luci.bux.at/projects/kexi
> >
> > now we are at designing table altering (=change table structure). we are
> > not sure about how we should design the gui. i have attached 3 solutions
> > which could be possible. if you got a other solutions please report them.
>
> Rather than just present three solutions, why don't you explain YOUR logic
> behind why you have selected these three particular layouts.  Then we would
> have some clue as to your thought processes.  As it is, it looks like you
> haven't given much thought to it and just dropped them into this mailing
> list for us to do the work.
sorry. well i thought much, but i didn't write down my thoughts to you, i'm 
sorry :)

> > i attached .ui files and png files if there is someone who doesn't have
> > qt designer.
>
> I assume this is a dialog to create the fields within the a table.  If this
> is so, I am confused.
you are right, you can create/edit fields within a table

> Why are some of the parameters in the table and some others at the bottom. 
> It would seem to me that either they should all be columns within the
> table, or all fields at the bottom.
well first we had (and still have in cvs) all parameters in the table. but it 
didn't look very nice to have around 8 colums. the second advantage of doing 
only the two parameters in the table is, that you can see the 2 most 
importend ones with one look

> Given the fields you do have, then the following comments
>
> "Field Name" is not long enough - you need to encourage reasonable
> descriptive names to be entered.
hm... isn't it discriptive enough? what would you take as name?

> "Field Type" should be a drop down list - so the user can select from your
> predefined supported types
it is a drop down field, sorry my mail really seems a bit wrong :). The reason 
why it isn't one is, that i just created those solutions in ui without regard 
to the table...

> "Primary Key"  Is this a simple boolean - either the field is part of the
> key or isn't.  In that case a simple check box.
here the same thing :)

> "Length" Should be labelled "Field Length" the spin box can be much shorted
> (when is the field length going to be more than 3 digits long?) and should
> be set up so the default value is show (50)
i agree on the name, but we will make the default-value depending on the type. 
like integers will get 20 by default, varchar 50 and so on

> If this is a database, then there is some logic tying "empty field",
> "primary key" and "autoincrement" together.  Not sure exactly what without
> much more thought, but if this is a primary key, can empty field ever be
> true?
in most engines it is by default true, so kexi will make it by default true 
too.

> If auto-increment, it is probably likely that this field is the
> primary key and the only field that is a primary key.  It would be helpful
> to give some thought about how those rules could be layed out so that they
> immediately validate when the use us changing them, and its obvious to the
> user that they are related.
ok, i thought about graying out, if primary key is selected... and restoring 
the type-default if it won't be a primary key anymore

> Why isn't "unsigned" just one a variety of types shown in the Field Type
> drop down list that I mentioned above.
the probelm is, that i don't want more types in the drop down than already 
exist, user won't find anything anymore.

ok, now the thoughts to the 3 solutions:

solution 1:
the detailed settings are after kde-ui-guidlines
(checkbox is left and checkboxdescribtion right), the probelm on that one is, 
that there aren't virtual columns (property, value).

solution 2:
explains what i mean with virtual columns but isn't really after kde-guidlines

solution 3:
that would match kde-guidlines and meat the property, value "table". the 
problem on that is, that you nead more mouse-operations to set a value there, 
and i don't know if one even needs longer to see the current setting
(that is the solution ms access took, btw)


lucijan
>
> - --
> Alan Chandler
> alan@chandlerfamily.org.uk
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.1 (GNU/Linux)
>
> iD8DBQE+IETCuFHxcV2FFoIRAtQoAJsEYWkNFWuf40+7pBd/thrgCogX9wCfe4uG
> OdR9rIdUJ7hxCWQJIeiSg1M=
> =0loH
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> kde-usability mailing list
> kde-usability@mail.kde.org
> http://mail.kde.org/mailman/listinfo/kde-usability

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