Re: Looking for table design interface advice for pgAdmin Database Designer - Mailing list pgadmin-hackers

On 15 July 2010 16:10, Luis Ochoa <ziul1979@gmail.com> wrote:
> On Wed, Jul 14, 2010 at 5:46 PM, Guillaume Lelarge <guillaume@lelarge.info>
> wrote:
>>
>> Le 14/07/2010 17:56, Thom Brown a écrit :
>> > On 14 July 2010 16:38, Luis Ochoa <ziul1979@gmail.com> wrote:
>> ...
>> >> Regards, Luis.
>> >>
>> >
>> > Thanks for working on this.
>> >
>> > I'm wondering if it might be better if there wasn't a type selected
>> > automatically for a column so that the user doesn't accidently leave
>> > it and forget to change it.
>>
>> Yeah, I also think so. And there's a good chance people won't be happy
>> with our default choice for the datatype. So, it's better not to have one.
>
> That's a good point, and will be fixed soon.
>
>>
>>
>>
>> > Also, could the data types line up so it's easier to read?
>>
>>  I know
>
> I'm not sure about line up data types you can see other modeller like this:
>
> http://www.fabforce.net/dbdesigner4/images/ss/dbd4_ss_simplemodel.png
>
> and in fact they align at left table's columns. Probably line up datatypes
> won't get a better reading, because columns sizes differences, for example:
>
> id                                                                 :
> integer
> cmpy_emp_first_name_id                              :  integer
> id2                                                               :  integer
> id 3                                                              :  integer
> cmpy_emp_last_name_of_external_boss_id    :  integer
> id 5                                                              :  integer
>

In that case, could they be bold and a different colour too, just to
improve scanability?

>> > it's still under development, but clickable elements should probably
>> > be bigger and clearer to reduce the chance of clicking on the wrong
>> > thing.
>
> I'm not sure if clickable elements should be bigger that their current size
> (8x8), at first time I defined then like 16x16 but the look weird, but well
> this can be tested & changed if needed later :)   but as a comment: when you
> past over handles elements like the +, - and join, the mouse over action,
> can change the mouse pointer, right now I don't do that but later I'm going
> to do that.
>
>>
>> And anything the user has to squint at to see (like the F for
>> > foreign key and U for unique constraint) would be a problem.
>> >
>
> Right F and U where only temporary solutions, but I think that Guillaume
> comment about using standard icons of pgAdmin is the best way of create
> consistency at user interface between database designer and others parts of
> pgAdmin.
>
>>
>> > And tooltips for everything?  Many of those icons could be seen as
>> > cryptic.
>> >
>
> Yes I think about tooltips, and I'm going to add them in a future
>
>>
>> > Regarding the joins, will there be a clear indicator as to which
>> > column is linking to which?
>
> my idea for joins is this: When you select a join, columns from source table
> (always primary of that table) will change their color to the same color of
> the join  when is selected, and then destination table column (foreign keys
> to that primary keys) will change too theri color.

I like that idea, although it would also be worth thinking about
people who are colour-blind when designing this if you can too.

>
>>
>> > Would tables be renamable?
>> >
>
> Yes *1.  ;)
>
> *1 Some restrictions apply, if table is just in modeler (not implemented
> yet) it can be done, or if table accomplish with all requirements to be
> rename, it can be done too. Just remember if a table name is changed, is
> changed at modeler level, when you commit changes, modeler try to rename it,
> if not possible some kind of warning is raised and table name remains as
> started. +1 for the four comments.
>
>>
>> > And what's your Twitter handle?  I don't see it above. :)
>> >
>
> Sorry for that :$  but it was fixed yet by Guillaume (thanks)
>  http://twitter.com/xiul/
>>
>
> Thanks for your comments.
> Regards, Luis.
>

Thanks

Thom