Обсуждение: Re: [pgadmin-hackers] [Design Update] Visual design of query editor and results table

> 3. right-justified numbers come from precedents like excel or other
> spreadsheet type tools and muddles the distinction between editable and
> un-editable tables (at least data output in from query results is
> un-editable, I know right clicking on a table in the browser to "view ...
> data/rows" outputs an editable table)

When we first released pgAdmin 4 we forgot to right-justify numbers.
Users complained. Lots. They need to stay right justified.

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

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

--
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers

Hello!

Our team is starting to work on changes to the results table, including:

1. changing unselected columns and row colors to grey

2. changing selected columns and rows to blue

3. differentiating header text so that field name is bold and datatype is in brackets

4. text is white when columns are selected

5. removing checkboxes in each cell

6. adding a triangle indicator for select all (top left corner)

Clicking a single cell inside the table will unselect everything else and only select that cell.

Here is an updated version of the table:

Please review these changes and provide feedback. We would like to implement them this week.

Thanks!

On Thu, Apr 6, 2017 at 11:27 AM Shirley Wang <swang@pivotal.io> wrote:

Ok! Right justified it is 

On Thu, Apr 6, 2017 at 11:22 AM Anthony DeBarros <adebarros@gmail.com> wrote:

Agreed on all the responses thus far. The ability to distinguish values ranging from thousands to tens of thousands to millions, etc., is substantially harder if numbers are left-justified. 

On Thu, Apr 6, 2017 at 10:41 AM, Robert Eckhardt <reckhardt@pivotal.io> wrote:

> 3. right-justified numbers come from precedents like excel or other
> spreadsheet type tools and muddles the distinction between editable and
> un-editable tables (at least data output in from query results is
> un-editable, I know right clicking on a table in the browser to "view ...
> data/rows" outputs an editable table)

When we first released pgAdmin 4 we forgot to right-justify numbers.
Users complained. Lots. They need to stay right justified.

Right justifying makes it substantially easier to understand magnitude and makes it easier to get decimal alignment. 

-- Rob

 

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

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

--
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers

On Wed, Apr 12, 2017 at 11:26 AM Dave Page <dpage@pgadmin.org> wrote:

Hi

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

Hello!

Our team is starting to work on changes to the results table, including:

1. changing unselected columns and row colors to grey

I'd like to see the entire window to see if that seems to make things too flat, but no objection to a colour change in principal. 

We're still working on styling the top navigation and also the bar with data output, explain, messages, and history, but here's what it looks like now with the current navigation styling. Because styles for the results table isn't impacting other modules or dialogs (exception being 'view data' options), we can come to a conclusion about styling for the table first, and take the results table into consideration when it comes to styling other parts of the editor. 

I think that the table styling patch can be merged independently from top navigation styles (this way we're not held up by design and we can release and gather feedback on the results table).

Here's what it would look like with the current navigation in pgAdmin4.

open query tool and see results

select columns and rows

Right click on tables in browser > view all data

Right click on tables in browser > view all data, select columns and rows

3. differentiating header text so that field name is bold and datatype is in brackets

Not sure about the brackets - for example, it might look weird with array types, e.g.

[character varying(50)[]]

Given that the column name is in bold, and the type isn't, perhaps the brackets should be omitted?

Oh good point. It seems like there are a few datatypes that require brackets. I think having font size for datatypes be slightly smaller than field name also works in establishing some visual hierarchy within the text. 

Just a note about the screens with highlighting - the selection implies that using the shift (or command or control) key to select a group of cells will work. This keyboard shortcut does not exist now, but is future work. The screens are done that way to show what highlighted columns and rows would look like. 

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

On Wed, Apr 12, 2017 at 9:02 PM, Shirley Wang <swang@pivotal.io> wrote:

On Wed, Apr 12, 2017 at 11:26 AM Dave Page <dpage@pgadmin.org> wrote:

Hi

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

Hello!

Our team is starting to work on changes to the results table, including:

1. changing unselected columns and row colors to grey

I'd like to see the entire window to see if that seems to make things too flat, but no objection to a colour change in principal. 

We're still working on styling the top navigation and also the bar with data output, explain, messages, and history, but here's what it looks like now with the current navigation styling. Because styles for the results table isn't impacting other modules or dialogs (exception being 'view data' options), we can come to a conclusion about styling for the table first, and take the results table into consideration when it comes to styling other parts of the editor. 

I think that the table styling patch can be merged independently from top navigation styles (this way we're not held up by design and we can release and gather feedback on the results table).

Sure.

 

Here's what it would look like with the current navigation in pgAdmin4.

Is that a new shade of gray? How many do we have now? It looks to me like it's starting to get messy, with too many different variations of gray plus the light blues used for the codemirror gutter and alternate rows in the grid.

Yes, it is a darker shade of gray. Are you concerned with the number of variations on gray, or that the grays are not used appropriately? 

 

Before we make this change, I think we should come up with the palette we discussed on Tuesday, and make sure we're all on the same page about what colours should be used for what in the main UI (I'm assuming we won't include icons and syntax colouring in this).

E.g. 

- A light and dark gray for UI elements such as button bars and grid headers.

- A light blue for highlighting data items, e.g. the codemirror gutter and alternate grid lines.

- A darker blue for highlighted text and emphasised UI elements, e.g. selections, dialogue headers

- Standard colours for OK/Cancel/Save buttons etc, which can also (potentially) be reused for graph series.

What do you think?

I think this is a good idea, and can be done in a separate track from the table styling. I feel that the cost of changing gray in the table later on is less than waiting on implementing until we determine the color palette (since this might take some time and it'd be good to get some feedback). For now, we can use the same shade of dark gray as the one in the toolbar menu. I'm going to prioritize creating the style guide above working on additional features after the table.

 

 

open query tool and see results

select columns and rows

Right click on tables in browser > view all data

Right click on tables in browser > view all data, select columns and rows

3. differentiating header text so that field name is bold and datatype is in brackets

Not sure about the brackets - for example, it might look weird with array types, e.g.

[character varying(50)[]]

Given that the column name is in bold, and the type isn't, perhaps the brackets should be omitted?

Oh good point. It seems like there are a few datatypes that require brackets. I think having font size for datatypes be slightly smaller than field name also works in establishing some visual hierarchy within the text. 

Just a note about the screens with highlighting - the selection implies that using the shift (or command or control) key to select a group of cells will work. This keyboard shortcut does not exist now, but is future work. The screens are done that way to show what highlighted columns and rows would look like. 

--

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

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

Is that a new shade of gray? How many do we have now? It looks to me like it's starting to get messy, with too many different variations of gray plus the light blues used for the codemirror gutter and alternate rows in the grid.

Yes, it is a darker shade of gray. Are you concerned with the number of variations on gray, or that the grays are not used appropriately? 

Both really.

> The shade of gray, I think, doesn't really matter that much and remaining
> consistent within the app is fine as long as there is sufficient contrast.

I disagree. There should be a defined set of colours, otherwise the
application will look haphazard and random. The use of different
contrasts can help focus the user on the appropriate part (or parts,
which are also often important) of the screen.

Yes - the last point above for example; the info bar has been made
gray so it a) flattens the look and b) stops it standing out. I would
argue that absolutely needs to be a prominent colour; maybe not the
blue it currently is, but certainly something that makes it clearly
visible. Pastel colours are easy on the eye, so maybe the soft blue we
use, or a soft yellow would work.

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

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