Thread: Re: About pgAdmin III

Re: About pgAdmin III

From
"Dave Page"
Date:

> -----Original Message-----
> From: Andreas Pflug [mailto:pgadmin@pse-consulting.de]
> Sent: 07 September 2003 19:11
> To: Dave Page
> Cc: l15e@mtx.ru; pgadmin-hackers@postgresql.org
> Subject: Re: [pgadmin-hackers] About pgAdmin III
>
> >So what you're saying is, if you want to develop complex
> >views/functions, don't use the nice tools we provide, do it the hard
> >way? If so, then you've completely missed the whole point of the
> >pgAdmin project :-(
> >
> What I say is that if view or function gets big, the wizard features
> become minor. I use the property dialog to create a skeleton,
> and fill
> it later in plain sql. The reengineered sql makes it quite easy...

Yes, but hardly friendly. I cannot see SQL Enterprise manager docs
saying 'if your stored proc becomes too large to edit easily, edit it by
hand in the query analyser instead'...

> >You should be able to edit any object through it's
> properties dialogue,
> >no matter how complex - you cannot start dismissing them
> because they
> >become too big - that's just ridiculous!!
> >
> Even a swiss army knife has more than one blade: different sizes for
> different objects.

Yes, but they normally only have one saw blade and don't tell you to
gnaw through the branch with your teeth if it's more than 1.5 inches in
diameter ;-)

> So how big do you need the editing window?
> I just checked under win32, I got 153x35 chars on the screen when
> maximizing the function dialog, and 156x47 in the view
> definition, on a
> 1152x864 screen. Is this really too small? Then I'd advise to use a
> 4096x3072 screen, and a 4pt font....

I didn't realise the windows were resizable - dialogues generally
aren't. In fact looking at them, most of ours aren't. From a good design
point of view, this is a bad thing because we have dialogues basically
performing the same function (ie showing object properties), that are
designed in an inconsistent manner.

Perhaps in the next version we should consider a different layout for
the dialogues - something that lends itself to resizing more that we can
use across the board, and something that is more visually appealing
(that's a criticism I've heard a couple of times in the past) as well as
functional.

> I certainly won't agree to screw up the window handling for
> getting some
> percent more usable screen size.

With resizable dialogues we won't need to.

Regards, Dave

Re: About pgAdmin III

From
Andreas Pflug
Date:
Dave Page wrote:

>I didn't realise the windows were resizable - dialogues generally
>aren't. In fact looking at them, most of ours aren't. From a good design
>point of view, this is a bad thing because we have dialogues basically
>performing the same function (ie showing object properties), that are
>designed in an inconsistent manner.
>
Oh Dave, what's the point?
Most dialogs don't have content that makes resizing senseful, so why
should they resize? To have plenty of white space?
Stacking modal dialogs is much worse design, and actually dialog design
*is* consistent regarding sizing: all dialogs resize in the ranges it
makes sense, i.e. not bigger than necessary, and not smaller to prevent
hiding of vital information.

>Perhaps in the next version we should consider a different layout for
>the dialogues - something that lends itself to resizing more that we can
>use across the board, and something that is more visually appealing
>(that's a criticism I've heard a couple of times in the past) as well as
>functional.
>
How "more visually appealing", more colors, fancy bitmaps? Can't
remember fundamental criticism about this, please state the details.

>>I certainly won't agree to screw up the window handling for
>>getting some
>>percent more usable screen size.
>>
>>
>
>With resizable dialogues we won't need to.
>
They are already, and they have been right from the start (for view) and
a few days after initial implementation (for function).
Especially when talking about functions, there are really other items
preventing fast development than shape and smell of a dialog, I'm
talking about the poor debugging (i.e. non-existent) debugging
facilities for plpgsql. I'm thinking about intelligent support for that
(not in a modal dialog of course)

Regards,
Andreas



Re: About pgAdmin III

From
Γιάννης Παΐλας
Date:
I don't agree,

there is a problem fitting greek translations in the
dialogs. The same occurs with some other languages
too.

Pgadmin has become a "global" tool, and it would be
nice if the designers considered the user's opinion
from the other part of world!

BTW, pgadmin's functionality is in the dialogs: FULL
of features.

Regards

Yiannis Pailas
--------------------

 --- Andreas Pflug <pgadmin@pse-consulting.de> έγραψε:
> Dave Page wrote:
>
> >I didn't realise the windows were resizable -
> dialogues generally
> >aren't. In fact looking at them, most of ours
> aren't. From a good design
> >point of view, this is a bad thing because we have
> dialogues basically
> >performing the same function (ie showing object
> properties), that are
> >designed in an inconsistent manner.
> >
> Oh Dave, what's the point?
> Most dialogs don't have content that makes resizing
> senseful, so why
> should they resize? To have plenty of white space?
> Stacking modal dialogs is much worse design, and
> actually dialog design
> *is* consistent regarding sizing: all dialogs resize
> in the ranges it
> makes sense, i.e. not bigger than necessary, and not
> smaller to prevent
> hiding of vital information.
>
> >Perhaps in the next version we should consider a
> different layout for
> >the dialogues - something that lends itself to
> resizing more that we can
> >use across the board, and something that is more
> visually appealing
> >(that's a criticism I've heard a couple of times in
> the past) as well as
> >functional.
> >
> How "more visually appealing", more colors, fancy
> bitmaps? Can't
> remember fundamental criticism about this, please
> state the details.
>
> >>I certainly won't agree to screw up the window
> handling for
> >>getting some
> >>percent more usable screen size.
> >>
> >>
> >
> >With resizable dialogues we won't need to.
> >
> They are already, and they have been right from the
> start (for view) and
> a few days after initial implementation (for
> function).
> Especially when talking about functions, there are
> really other items
> preventing fast development than shape and smell of
> a dialog, I'm
> talking about the poor debugging (i.e. non-existent)
> debugging
> facilities for plpgsql. I'm thinking about
> intelligent support for that
> (not in a modal dialog of course)
>
> Regards,
> Andreas
>
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 7: don't forget to increase your free space map
settings

____________________________________________________________
Do You Yahoo!?
Αποκτήστε τη δωρεάν @yahoo.gr διεύθυνση σας στο http://www.otenet.gr

Re: About pgAdmin III

From
Andreas Pflug
Date:
Γιάννης Παΐλας wrote:

>I don't agree,
>
>there is a problem fitting greek translations in the
>dialogs. The same occurs with some other languages
>too.
>
>
Translations not fitting can't be an argument for sizable dialogs, we
already had this discussion. There are fonts out there that are
corrupted (if we tried to have Arabian on such a system, the table
dialog would be about 1500 pixel in height!!!), and these have to be
corrected. We see fonting problems even with english if fonts don't fit.
We don't like accidential display, instead pgAdmin3 should look as
designed on *all* systems.

If your font doesn't fit, tell us about your system (and upload your
translation even if incomplete so we can see the problem), to give us
the opportunity to find the reason.


Regards,
Andreas



Re: About pgAdmin III

From
Jean-Michel POURE
Date:
Le Lundi 8 Septembre 2003 00:12, vous avez écrit :
> there is a problem fitting greek translations in the
> dialogs. The same occurs with some other languages
> too.

Dear Yannis,

Your translation was publised. Thanks for your fast delivery.

To answer your question from my point of view:

- Dialogs we designed with English text, with approx. 30% more space left. We
ask translators to shorten their messages in order to fit in the given space.
Sometimes it is difficult. We can only rely on the experience of translators
to tell a dialog is large enough or not.

- Here and there, problems may arise. In the case of French, I had problems
with the "Option" and "Export data to file" dialogs. These two dialogs
probably need enlargement.

Yiannis, could you outline the dialogs which were difficult to translate into
Greek after shortening messages?

Cheers,
Jean-Michel Pouré


Re: About pgAdmin III

From
Andreas Pflug
Date:
Jean-Michel POURE wrote:

>Le Lundi 8 Septembre 2003 00:12, vous avez écrit :
>
>
>>there is a problem fitting greek translations in the
>>dialogs. The same occurs with some other languages
>>too.
>>
>>
>
>Dear Yannis,
>
>Your translation was publised. Thanks for your fast delivery.
>
>To answer your question from my point of view:
>
>- Dialogs we designed with English text, with approx. 30% more space left.
>
There are place where 0 % is left, because the developer didn't care.
Who was that sloppy guy?!? Oops, me...

> We ask translators to shorten their messages in order to fit in the given space.
>Sometimes it is difficult. We can only rely on the experience of translators
>to tell a dialog is large enough or not.
>
I had a brief look at the greek texts and didn't find it really
horrible. Most cases are where even the english text is quite long, e.g.
"source encoding" for conversions. This can easily be abbrevated to
"source enc." without sacrificing meaning too much. Somebody who doesn't
understand what "source enc." might mean in this context probably won't
understand the long form either and should hit F1 to learn about it.

We have a style guide for property dialogs, reserving 90 units for the
explanation (actual pixel count depends on OS), which should be enough.
I really wouldn't like to deviate from the style guide case by case, and
enlarging this would make most dialogs look strange.

>
>- Here and there, problems may arise. In the case of French, I had problems
>with the "Option" and "Export data to file" dialogs. These two dialogs
>probably need enlargement.
>
I had a look at these two.
I really was a bit too mean with space in the export dialog. I just
enlarged it by 60 units.

Option is a different story. There's an awful lot of text in it, trying
to explain verbosely what each option means, which finally can't
succeed. We grew this dialog already several times, its proportions are
becoming ugly.
I'd suggest all translators to do their best to express what's going on
in the limited space, if still unclear the user needs to hit F1. The Log
Level radiobox resizes itself, I shifted it 25 units to the left so it
can grow a bit more.

Regards,
Andreas



Re: About pgAdmin III

From
"Dmitry A. Mordovin"
Date:
Hi for all

Found bug, then I try to create constraint, unique, you generate SQL
code to try to make primary key.

About Edit window. You are right, but may be button APPLY for apply my
changes in function text.. is it useful maybe?
Save window position/size, maybe too?

Thanks

Best regards

-----Original Message-----
From: Dave Page [mailto:dpage@vale-housing.co.uk]
Sent: Sunday, September 07, 2003 10:58 PM
To: Andreas Pflug
Cc: l15e@mtx.ru; pgadmin-hackers@postgresql.org
Subject: RE: [pgadmin-hackers] About pgAdmin III



> -----Original Message-----
> From: Andreas Pflug [mailto:pgadmin@pse-consulting.de]
> Sent: 07 September 2003 19:11
> To: Dave Page
> Cc: l15e@mtx.ru; pgadmin-hackers@postgresql.org
> Subject: Re: [pgadmin-hackers] About pgAdmin III
>
> >So what you're saying is, if you want to develop complex
> >views/functions, don't use the nice tools we provide, do it the hard
> >way? If so, then you've completely missed the whole point of the
> >pgAdmin project :-(
> >
> What I say is that if view or function gets big, the wizard features
> become minor. I use the property dialog to create a skeleton,
> and fill
> it later in plain sql. The reengineered sql makes it quite easy...

Yes, but hardly friendly. I cannot see SQL Enterprise manager docs
saying 'if your stored proc becomes too large to edit easily, edit it by
hand in the query analyser instead'...

> >You should be able to edit any object through it's
> properties dialogue,
> >no matter how complex - you cannot start dismissing them
> because they
> >become too big - that's just ridiculous!!
> >
> Even a swiss army knife has more than one blade: different sizes for
> different objects.

Yes, but they normally only have one saw blade and don't tell you to
gnaw through the branch with your teeth if it's more than 1.5 inches in
diameter ;-)

> So how big do you need the editing window?
> I just checked under win32, I got 153x35 chars on the screen when
> maximizing the function dialog, and 156x47 in the view
> definition, on a
> 1152x864 screen. Is this really too small? Then I'd advise to use a
> 4096x3072 screen, and a 4pt font....

I didn't realise the windows were resizable - dialogues generally
aren't. In fact looking at them, most of ours aren't. From a good design
point of view, this is a bad thing because we have dialogues basically
performing the same function (ie showing object properties), that are
designed in an inconsistent manner.

Perhaps in the next version we should consider a different layout for
the dialogues - something that lends itself to resizing more that we can
use across the board, and something that is more visually appealing
(that's a criticism I've heard a couple of times in the past) as well as
functional.

> I certainly won't agree to screw up the window handling for
> getting some
> percent more usable screen size.

With resizable dialogues we won't need to.

Regards, Dave




Re: About pgAdmin III

From
Andreas Pflug
Date:
Dmitry A. Mordovin wrote:

>Hi for all
>
>Found bug, then I try to create constraint, unique, you generate SQL
>code to try to make primary key.
>
>About Edit window. You are right, but may be button APPLY for apply my
>changes in function text.. is it useful maybe?
>
Added to TODO, but maybe this isn't implemented. Instead, there might be
a plpgsql debugger coming...

Regards,
Andreas