Re: [Design Update][History]

From: Shirley Wang <swang(at)pivotal(dot)io>
To: Dave Page <dpage(at)pgadmin(dot)org>
Cc: pgadmin-hackers <pgadmin-hackers(at)postgresql(dot)org>
Subject: Re: [Design Update][History]
Date: 2017-03-06 21:19:54
Message-ID: CAPG3WN4h7qaL_+g2+7iC7-T6PGx8s6bOx0oOKCsLCu0-4HVcKw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgadmin-hackers

Thanks, Dave

> I disagree. I use both the Explain and Messages tabs all the time, and
> rarely the History tab. You cannot easily merge the data output and EXPLAIN
> tabs because they show complementary information.
>

I see. It may be that we haven't heard about the full value of the Explain
tab (it also doesn't seem to be working on my version of pgAdmin
(w/Postgres, not Greenplum)). I see no problem with keeping it as is until
we learn more.

Here are the updated versions of History (Explain isn't included because we
were working with the assumption that the tab could be combined with
results, we can add it again unless we learn something new).

- Users are able to click or use the arrow keys on their keyboard to
navigate through the queries on the left.
- List of queries is expandable
- Copy all is fixed to the top right corner so it'll be present as users
vertically/horizontally scroll

[image: Query HIstory.png]
[image: Query HIstory Expanded.png][image: Query History - error.png]

[image: Query HIstory Expanded Copy.png]
To your points,

> The Messages tab is used to quickly show the full set of messages from the
> last executed query. Having that info only on the results tab is less
> useful for a number of reasons:
>
> - It shows the results from all queries, thus making the display more
> cluttered when you're only interested in the results of the last query
> (which is probably the majority of the time).
>
> In the messages tab, it seems like when the query ran successfully, the
message shows number of rows affected and total time, both which are shown
with your query history. It also seems like when there is an error message,
it duplicates the description and splits out line and character. We can
condense that into 3 groups of info : error code, a description, and
location within the query where the error was detected.

Immediate feedback on any errors should be displayed right after you run
the query. It appears there's already a pattern for feedback w/ the green
box that appears in the bottom right corner when you run a successful
query. Any sort of feedback on the query run (success/fail messages) should
be treated consistently. Persistent messages can live within the history.

> - It shows information above and beyond the messages, again, cluttering
> the display and detracting from the message info.
>

You're right that the error messages displays information at a higher level
than query history, which can be solved by establishing hierarchy - error
messages go at the top.

>
> - It shows only 1 line at a time, where messages are typically multi-line.
> This would mean that either the user has to expand the row to see the
> results, or we'd have to do it programmatically which could interfere with
> rows the user has intentionally expanded.
>

Because we learned that people generally remember what queries they ran
based on time, seeing one line of your previous query isn't incredibly
helpful, and having the ability to view the full query is valuable, we
moved to having side panels with an easy way to switch between which query
you want to view.

>
>
> -
>
> ‘Data Output’ and ‘History’ should be grouped together because the
> two tabs show results based off of what was typed in the query editor
> -
>
> Iterate on ‘History’ to have full query expand to side.
> -
>
> Enables quicker browsing through the ‘Query History’
> -
>
> Example whiteboard sketch
>
>
> If the user wants that, they can do it already. I would argue in most
> cases users likely want to have the entire width available for query
> results, which often need more space than is available at present as it is.
>

Totally, results should be shown under a separate tab. Data results would
remain unchanged.

>
> Please ensure you're talking not just to users that query data, but to
> those developing stored procedures as well - they likely have different
> needs (quite probably for which the Messages tab is even more important).
>
>

Yes! We've been having difficulty finding people like that. Do you have any
leads?

In response to

Responses

Browse pgadmin-hackers by date

  From Date Subject
Next Message Jonas Thelemann 2017-03-07 01:19:42 Three minor changes + GER
Previous Message Dave Page 2017-03-06 15:35:11 pgAdmin 4 commit: Bump version prior to release.