Re: [pgadmin-hackers] [Design update] Style guide for pgAdmin4

[Dave Page]

On 20 Jul 2017, at 23:02, Shirley Wang  wrote:

>> 
>> Iirc, we did some back and forth over that about 18 months ago, as dialogues 
>> didn't look quite right without the bold - and I do think that it looks a 
>> little light on your mockup. I don't think there's a hard requirement they 
>> match table headers; they are distinct types of header.
>> 
>> Happy to try out change though if you can workup one or more suggested 
>> patches.
>> 
> 
> Two more things we're going to add to the style guide are the dialog labels 
> and buttons within the dialog.
> 
> Dialog text fields:
> These will have 14px bold labels, and the text field box will be 36px in 
> height 
> 
> 
> 
> Larger text fields should be set to 360px in height and have a draggable 
> corner to adjust height if needed
> 
> 
> 
> Buttons in dialog:
> The should be one solid color to help them stay consistent with the aesthetic 
> of the rest of the application (ex. alerts styling). 
> 
> enabled and disabled versions of buttons:
> 
> 
> In terms of usability, having the most common action in the corner makes it 
> easier to find and click. Rearranging the buttons so that 'save' is at the 
> end would accomplish this.

There are OS conventions for the positioning of those buttons, which I believe 
we should follow. Unfortunately Mac and Windows are exactly opposite which 
complicates things. Iirc, we follow Windows as its more widely used.

I'm hesitant to change that to something we invent, as I've seen people get 
confused by the difference a number of times when moving from Windows to Mac. 
If anything, we should make our behaviour dynamically follow the OS standard of 
whatever the client is running on.

Re: [pgadmin-hackers] [Design update] Style guide for pgAdmin4

[Shirley Wang]

>
>
> Iirc, we did some back and forth over that about 18 months ago, as
> dialogues didn't look quite right without the bold - and I do think that it
> looks a little light on your mockup. I don't think there's a hard
> requirement they match table headers; they are distinct types of header.
>
> Happy to try out change though if you can workup one or more suggested
> patches.
>
>
Two more things we're going to add to the style guide are the dialog labels
and buttons within the dialog.

*Dialog text fields:*
These will have 14px bold labels, and the text field box will be 36px in
height

[image: label.png]

Larger text fields should be set to 360px in height and have a draggable
corner to adjust height if needed
[image: Comments.png]


*Buttons in dialog:*
The should be one solid color to help them stay consistent with the
aesthetic of the rest of the application (ex. alerts styling).

enabled and disabled versions of buttons:
[image: Screen Shot 2017-07-20 at 11.30.24 AM.png]

In terms of usability, having the most common action in the corner makes it
easier to find and click. Rearranging the buttons so that 'save' is at the
end would accomplish this.

Re: [pgadmin-hackers] [Design update] Style guide for pgAdmin4

[Shirley Wang]

I noticed that the default font, Menlo, was disabled in favor of Monospace.
Was there a specific reason why Monospace was used in favor of Menlo?

I find that Menlo is an easier font to read, especially for uppercase
letters. For web apps, sans-serif fonts are used (fonts without the little
notch, or serifs, at the end of each stroke of a letter) so it's easier to
read on a display. Serif fonts are better for print.


*Menlo:*
[image: Screen Shot 2017-07-10 at 4.38.11 PM.png]

Re: [pgadmin-hackers] [Design update] Style guide for pgAdmin4

[Robert Eckhardt]

On Mon, Jul 3, 2017 at 5:36 AM, Dave Page  wrote:

>
>
> On Fri, Jun 30, 2017 at 12:19 PM, Shirley Wang  wrote:
>
>> Hello!
>>
>> Currently the app uses 'monospace' to define the font family for SQL
>> queries and messages, which looks a little squished when in uppercase. PT
>> mono is another monospaced font (available on Google fonts) that looks
>> similar to 'monospace' but is more legible for uppercase.
>>
>> *PT Mono:*
>> [image: Screen Shot 2017-06-30 at 12.09.15 PM.png]
>>
>> *Monospace*
>> *[image: Screen Shot 2017-06-30 at 12.09.20 PM.png]*
>> Thoughts?
>>
>
> I'm not sure I like it. It looks a little like the old-school "digital"
> font; the sort of thing they used in the movie War Games.
>

As an aside, font used in the movie War Games actually kinda seels it to me
in my book.

Looking at the two the other day, it seemed like the lower case fonts are
pretty much the same but the Capital letters of PT Mono are spaced out a
bit more making it easier to read.

-- Rob


>
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>

Re: [pgadmin-hackers] [Design update] Style guide for pgAdmin4

[Dave Page]

On Fri, Jun 30, 2017 at 12:19 PM, Shirley Wang  wrote:

> Hello!
>
> Currently the app uses 'monospace' to define the font family for SQL
> queries and messages, which looks a little squished when in uppercase. PT
> mono is another monospaced font (available on Google fonts) that looks
> similar to 'monospace' but is more legible for uppercase.
>
> *PT Mono:*
> [image: Screen Shot 2017-06-30 at 12.09.15 PM.png]
>
> *Monospace*
> *[image: Screen Shot 2017-06-30 at 12.09.20 PM.png]*
> Thoughts?
>

I'm not sure I like it. It looks a little like the old-school "digital"
font; the sort of thing they used in the movie War Games.

-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Re: [pgadmin-hackers] [Design update] Style guide for pgAdmin4

[Shirley Wang]

Hi all,

We've updated the borders around alerts so that they are more prominent.

[image: error alert (1).png]
[image: success alert (2).png]
[image: Neutral alert.png]
Everything else stays the same. Let me know your thoughts if any.

Shirley & Shruti

On Wed, May 31, 2017 at 3:02 PM Shirley Wang  wrote:

> On Wed, May 31, 2017 at 11:55 AM Dave Page  wrote:
>
>> On Wed, May 31, 2017 at 2:27 PM, Shirley Wang  wrote:
>>
>>>
 When you say "icon" here, are you talking about the combo box arrow, or
 icons on the items themselves? The latter are often useful if you have
 items of different types in the same list.

 I think we should have the combo box arrow, to show the user they don't
 have to type if they don't want to.

>>>
>>> I'm talking about the combo box arrow. I think that's fine, but in that
>>> case users shouldn't be able type, they should only be able to select from
>>> a group of options, like this:
>>>
>>> [image: options.png]
>>> From what I understand, the text field where a user can type in is for
>>> searching through options available to them. If we know that people tend to
>>> search by typing more than scrolling, we should use the precedent for type
>>> ahead dropdowns .
>>>
>>
>> We are using a much older precedent - one used in Windows for 20+ years
>> (possibly other OSs too).
>>
>> Remember that some of these combo boxes contain values that are specific
>> to the database object - the user may not know what to start typing, so the
>> arrow gives them a hint that they can get a list by clicking - or they can
>> type.
>>
>> The real difference here is that we also include the x to allow the box
>> to be cleared, where Windows would add a blank option as the first thing in
>> the list typically.
>>
>>
> I see. It feels like we're at a standstill as to which precedent to use
> and neither of us is wrong. This might be a good candidate for user
> testing. We can see how people are using the x as well as learn more about
> typing / selecting an option behavior.
>
> I believe there are some dropdowns in the partition design we can use to
> test. If it doesn't make sense there, I'm fine putting this in the back
> burner until there is a good workflow to test it.
>