Re: [Design Update] Visual design of query editor and results table

On Thu, Apr 13, 2017 at 4:19 AM Dave Page <dpage(at)pgadmin(dot)org> wrote:

> On Wed, Apr 12, 2017 at 9:02 PM, Shirley Wang <swang(at)pivotal(dot)io> wrote:
>
>> On Wed, Apr 12, 2017 at 11:26 AM Dave Page <dpage(at)pgadmin(dot)org> wrote:
>>
>>> Hi
>>>
>>> On Wed, Apr 12, 2017 at 4:20 PM, Shirley Wang <swang(at)pivotal(dot)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*
>>
>> *[image: results table wcurrent nav.png]*
>> *select columns and rows*
>> [image: results table wcurrent nav - selected.png]
>>
>> *Right click on tables in browser > view all data*
>> [image: results table _view-all-data.png]
>>
>> *Right click on tables in browser > view all data, select columns and
>> rows*
>> [image: results table_ view-all-data-selected.png]
>>
>>
>>> 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
>