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

Hello Hackers,

We've started to work on creating a style guide for pgAdmin4. 

Our goals with the style guide are to:

- have a single source of truth for visual design and workflows

- make it easier when adding or updating a section to the app to maintain consistency

How we'll know we're successful:

- conversations about design are more high level, driven by user needs and pains

- decreasing (or at least not adding to) current css bloat due to templating and overwrites

Process for creating a style guide

We're going to start from the smallest building blocks of the site and use that to define larger and larger components. Currently, we're taking inventory of current styles in the app, including colors, typography, buttons, dialogs etc. 

Given how the front end is currently structured, we were thinking that static documentation of styles would be a good MVP, at least until we determine what the best documentation for developers on the community would be. Attached is the inventory of styles as of now, including a Sketch file (a tool for creating design mockups, also where I've been keeping track of styles). You can also access files here on Google drive here: https://drive.google.com/drive/folders/0B7jMyxF3NH5lb2JxREUxclp1Unc?usp=sharing

Please feel free to edit the Sketch file- my only ask is new versions hare named accordingly. 

Hi!

On Thu, Apr 20, 2017 at 4:18 AM Dave Page <dpage@pgadmin.org> wrote:

Hi

On Tue, Apr 18, 2017 at 5:11 PM, Shirley Wang <swang@pivotal.io> wrote:

Hello Hackers,

We've started to work on creating a style guide for pgAdmin4. 

Our goals with the style guide are to:

- have a single source of truth for visual design and workflows

- make it easier when adding or updating a section to the app to maintain consistency

:-)

 

How we'll know we're successful:

- conversations about design are more high level, driven by user needs and pains

- decreasing (or at least not adding to) current css bloat due to templating and overwrites

Sounds good.

 

Process for creating a style guide

We're going to start from the smallest building blocks of the site and use that to define larger and larger components. Currently, we're taking inventory of current styles in the app, including colors, typography, buttons, dialogs etc. 

Given how the front end is currently structured, we were thinking that static documentation of styles would be a good MVP, at least until we determine what the best documentation for developers on the community would be. Attached is the inventory of styles as of now, including a Sketch file (a tool for creating design mockups, also where I've been keeping track of styles). You can also access files here on Google drive here: https://drive.google.com/drive/folders/0B7jMyxF3NH5lb2JxREUxclp1Unc?usp=sharing

Also sounds good.

 

Please feel free to edit the Sketch file- my only ask is new versions hare named accordingly. 

Is this the app you used? https://www.sketchapp.com/

Yes. Also, I recognize it's probably not the best tool, given that there's a 30 day free trial and then you need to purchase a license. I'm looking into other programs that are free.

 

 

Some initial thoughts on the inventory:

- Wow, that's a lot of colours. I didn't realise we had so many. I think we need to work that down to a set of a dozen or less primary colours.

Me neither! I'm not so concerned with the number of different colors, but with the number of similar shades of each color. 

I can distill those down and send another email shortly.

 

 

- I wouldn't worry about the button colour borders and gradients too much. Those are standard bootstrap colours, so we should document them in terms of bootstrap styles, not colour components.

Ok. But are they appropriate for this app?

- We should change the browser list font and standardise on Helvetica Neue.

Ok 

- Is Helvetica Neue the best font for us? Our previous designer wanted to use Droid Sans, which I wasn't so keen on, but is there a better option to standardise on?

By standardize, do you mean only Helvetica throughout the app? I like Helvetica because it's a very readable typeface, but I'm not sure it's appropriate as the only typeface to use throughout the app. 

The only other place I've noticed that uses a different typeface, ignoring query editor panel, is the data output panel (uses Verdana). I feel like in this case though, a distinction is useful since output data is different from body copy.

 

Oh, and an ironic side note: the one style that we have had for 20 years now is the formatting/capitalisation of the "pgAdmin" name. You might want to stop using pg_Admin :-p

Ha ok will do

Your other questions, copied and pasted here:

- Should icons have a dividing line between them? I think so.

I agree too. Makes it clear what the click area is. Or do you mean when there's a light blue shading and there should be a light blue line between icons?

- What determines the light blue shading of a row? I believe it should always be the one with focus (assuming there is one with focus)

Yes, the one that's in focus.

 

Hello

Please feel free to edit the Sketch file- my only ask is new versions hare named accordingly. 

Is this the app you used? https://www.sketchapp.com/

Yes. Also, I recognize it's probably not the best tool, given that there's a 30 day free trial and then you need to purchase a license. I'm looking into other programs that are free.

FYI, we use LucidCharts internally. It's a pretty good Google Apps integrated version of Microsoft Visio.

Ah ok. Do you have any files related to pgAdmin you can share (or put into Google drive folder)?

 

 

 

 

Some initial thoughts on the inventory:

- Wow, that's a lot of colours. I didn't realise we had so many. I think we need to work that down to a set of a dozen or less primary colours.

Me neither! I'm not so concerned with the number of different colors, but with the number of similar shades of each color. 

I can distill those down and send another email shortly.

 

 

- I wouldn't worry about the button colour borders and gradients too much. Those are standard bootstrap colours, so we should document them in terms of bootstrap styles, not colour components.

Ok. But are they appropriate for this app?

Personally I think they're fine.

They seem ok for buttons (cancel, save, reset, toolbar). I found the gradient is also on alerts when you click Dependencies, Dependents while selecting Server in the browser. 

I think those alerts should not have a gradient to match with the other types of alerts (notifiers and error messages). Since these specific alerts are not success / fail messages, the blue works because it's a neutral color.

Here is what the updated colors would look like in the app. 

Focus on text field in nodes

Browser

Highlight in dropdown menu

Alerts 

If this is ok, we will add these changes to our backlog as style changes.

One more thing: there are two very close greens between notifiers and toggle buttons in preferences menus

I recommend documenting the green for switches (#5cb85c), which would change notifiers from this:

to this:

On Fri, Apr 21, 2017 at 2:27 PM Shirley Wang <swang@pivotal.io> wrote:

Hello

Please feel free to edit the Sketch file- my only ask is new versions hare named accordingly. 

Is this the app you used? https://www.sketchapp.com/

Yes. Also, I recognize it's probably not the best tool, given that there's a 30 day free trial and then you need to purchase a license. I'm looking into other programs that are free.

FYI, we use LucidCharts internally. It's a pretty good Google Apps integrated version of Microsoft Visio.

Ah ok. Do you have any files related to pgAdmin you can share (or put into Google drive folder)?

 

 

 

 

Some initial thoughts on the inventory:

- Wow, that's a lot of colours. I didn't realise we had so many. I think we need to work that down to a set of a dozen or less primary colours.

Me neither! I'm not so concerned with the number of different colors, but with the number of similar shades of each color. 

I can distill those down and send another email shortly.

 

 

- I wouldn't worry about the button colour borders and gradients too much. Those are standard bootstrap colours, so we should document them in terms of bootstrap styles, not colour components.

Ok. But are they appropriate for this app?

Personally I think they're fine.

They seem ok for buttons (cancel, save, reset, toolbar). I found the gradient is also on alerts when you click Dependencies, Dependents while selecting Server in the browser. 

I think those alerts should not have a gradient to match with the other types of alerts (notifiers and error messages). Since these specific alerts are not success / fail messages, the blue works because it's a neutral color.

Here is what the updated colors would look like in the app. 

Focus on text field in nodes

Browser

Highlight in dropdown menu

Alerts 

If this is ok, we will add these changes to our backlog as style changes.

I recommend documenting the green for switches (#5cb85c), which would change notifiers from this:

to this:

Wouldn't it be better if it matched the (possibly-recoloured-by-us) Bootstrap alert-success class? I agree that it's silly having two closely matched colours, but I think it makes more sense to have the alerts and notifiers match, than to match the switches. 

Do you mean this?

If so, ok! If there's no good reason to keep the same colors, we should switch. 

Hello!

Update on alerts

Here are mockups of error and update alert styles, as modeled by bootstrap. 

Success messages appear 

- after running a query 

- adding a database (database connected)

Error messages appear

- after running query

- missing info in dialogs

Let me know if I'm missing any areas that have different styling.

Running a query

I've added rounded corners - it doesn't seem like there are any other areas where sharp corners are used so I think these should be round. 

Dialog messages

A note about 'connect to server' message. Currently the error appears above where you enter a password. I think all messages should live at the bottom of the dialog, above the buttons.

Update on tools

I played around with Lucidcharts and it seems like the only units available for drawing out shapes are inches or centimeters, neither of which is particularly useful for specifying sizes of buttons, menus etc. 

I found Figma, which is a fairly feature robust web app, similar to Sketch and designed for collaboration (it's also free!). Other pros:

- saved asset library for projects (perfect for mocking up future pgAdmin screens w/o the need to recreate assets)

- version control

- link for public access

- generates some CSS from the image

Here's the link to the project. https://www.figma.com/file/UjGekp34w6iBizjlGu2D4ccp/4.21pgAdmin-styles-Page-1

Let me know what you think.

I think the addition of icons and some copy would help:

On Wed, Apr 26, 2017 at 4:45 PM, Shirley Wang <swang@pivotal.io> wrote:

I think the addition of icons and some copy would help:

Agreed.

http://www.linkedin.com/in/asheshvashi 

--

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

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

Hello!

Update on colors

As of now, there are several greys are very similar, used across multiple areas of pgAdmin with no overlaps on color.

Here are the greys organized by scale, with the narrowed down greys underneath:

The palette of 6 greys is flexible enough to be used across all the areas within pgAdmin, and easier to map consistency.

Here's what it looks like with the 6 greys

Dropdown menus

Change from having white hover to dark grey, keeps text color the same

Query tool

I think some interesting things with color contrast are introduced once we look at the uneditable query editor as accessed through 'View all Data'. 

We can address this either by changing the greys in the results table, or changing the grey in the query editor. As of now, I think changing the query editor grey might work better to make sure that when columns are selected in the 'Data Output' panel, they stand out with the blue.

If we lighten the editor table and fade out the text in the editor, it would look like this:

Thoughts?

 

On Wed, Apr 26, 2017 at 11:24 PM Ashesh Vashi <ashesh.vashi@enterprisedb.com> wrote:

On Wed, Apr 26, 2017 at 9:56 PM, Dave Page <dpage@pgadmin.org> wrote:

On Wed, Apr 26, 2017 at 4:45 PM, Shirley Wang <swang@pivotal.io> wrote:

I think the addition of icons and some copy would help:

Agreed.

+1

--

Thanks & Regards,

Ashesh Vashi
EnterpriseDB INDIA: Enterprise PostgreSQL Company

http://www.linkedin.com/in/asheshvashi 

--

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

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

 

So to summarise:

- I'm happy to see the number of grays reduced as proposed.

- I don't like the dark gray column headers.

- I think the column and row headers should be the same colour.

- I think we should review the bluish-gray used for the codemirror gutter (though, it looks fine for the alternate rows)

- We should use a light-gray for the disabled codemirror, with slightly faded text.

What do you think?

 

Gotcha. Here's the query tool with the same grey as the row header. 

I quite like this grey as a header. 

And in the 'View all Data'

I made the codemirror and codemirror gutter the same color with a 50% opacity on the text. It looks like its lighter in the 'View all data' mockup, but that's because the codemirror being grey makes the gutter lose contrast.

I'm not sure why it looks bluish grey for you, it's a neutral grey both times (#f9f9f9). Perhaps try editing the color in Chrome Inspector to see if it makes a difference?  

Hello!

Update on style guide location

We're going to move the agreed upon styles from Figma onto a webpage that will be accessible by everyone. We've decided to have a static site, with the html and css available to copy and paste. We'll add components to the style guide after we update the current UI with new styles.

Dropdown styles

I noticed that some drop downs include a 'x' next to the current option in the text field:

The 'x' and the down arrow functionally do the same thing, and it seems redundant to have both. I would suggest removing the 'x' since selecting another option from the dropdown will automatically replace the current option.

Button toggles vs checkboxes

In some cases within dialogs, a toggle is used to define yes or no, while in other cases a radio button is used to define yes or no:

It does seem like 'Connect now?'  and 'Save password' (in 'Connection' tab within 'Create - Server') are the only places where checkboxes are used, is there a reason why these are different? I think we should just choose one, unless there was a specific reason as to why both check boxes and toggles are used.

In most cases where I've seen a text field with options, usually a drop down appears automagically without a need for a dropdown icon or x

Yes, I think that would be an improvement, if it can be done appropriately. I think the reason it's not done that way now is that unlike the examples you gave, in pgAdmin we're searching for one of the existing values in the list, rather than entering a free-type value that might be auto-completed.

That's what the Yelp example shows: they have a list of options (Restaurants, Bars, Food, Delivery, Pickup, and Reservations) that show as default when there are no options typed. There's just additional features included in the GIF, sorry for the confusion. We can ignore the auto-completed examples for free type values, and have auto-complete for values that exist in the list.

Mainly, if we're enabling users to type, I don't think we need icons within each field as the drop down appearing is enough context. However, if we are not enabling a user to type, then a drop down icon should appear to show that only clicking is allowed to select an option. Thoughts?

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:

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. 

If people don't typically type to search or there are usually only a few options, it can just be a dropdown.

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:

Monospace

Thoughts?

On Fri, Jun 30, 2017 at 12:19 PM, Shirley Wang <swang@pivotal.io> 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:

Monospace

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

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:

I'm not aware of a change to that font. The only commits I can find that reference either Menlo or monospace are these:

commit e2cbaaef7124b41be91bf34d704f0d3f61cf7b0c

Author: Matthew Kleiman <

 

@pivotal.io>

Date:   Thu Jul 6 13:08:29 2017 +0100

    UI tweaks for the query history.

commit 7f5541205936e32b08a2183f00173a0c64019c8e

Author: Joao Pedro De Almeida Pereira <jdealmeidapereira@pivotal.io>

Date:   Tue Jun 27 10:55:57 2017 -0400

    Overhaul the query history tab to allow browsing of the history and full query text. Fixes #2282

    

    Patch by Joao and the team at Pivotal.

commit 1208206bc0eca2d135469258e8a209b983e668be

Author: Shruti B Iyer <siyer@pivotal.io>

Date:   Tue Jun 13 09:50:41 2017 +0100

    Initial re-vamp of the History tab. 

Oh ok, it doesn't seem like the overwrites were intentional. I find Menlo an easier typeface to read and scan than monospace, but I'm hesitant to change it especially if there's no pain associated with Monospace. I'll send out a message on the mailing list and see what the feedback is on current typeface used. 

On another note, headers for tables (for example under statistics tab) are currently bolded and 12px. Headers for dialogs are 13px and bold. To keep it consistent with other typography in the app, both should be 13px and not bolded. By updating them, they will be consistent with the editor title in the query tool which is already 13px and not bolded.

Current:

Update (these are all 13px not bolded)

Editor title in query tool (currently 13px and not bolded)