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

On Thu, Apr 13, 2017 at 4:07 PM, Shirley Wang <swang(at)pivotal(dot)io> wrote:

>
>
> 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?
>

Both really.

>
>
>> 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
>>
>

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

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