Re: [pgadmin-hackers] [Design Update][History] - Mailing list pgadmin-hackers

On Mon, Mar 6, 2017 at 9:19 PM, Shirley Wang <swang@pivotal.io> wrote:

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

That makes it impossible any details from the initial grid view.

 

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. 

It'll also show (in the correct order) any notices or other messages raised by stored functions. It's critical that these remain easy to read as they're used for debugging as well as conveying non-result info to the user.

 

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.

No, error messages need to be shown properly ordered amongst any other messages. The output is intentionally sequential - if it weren't, it would be useless for debugging.

 

 

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

Sure, but you're missing the point. The query text isn't the only thing we want to see in the history; there is additional meta data that will help the user locate the query they want that is no longer visible unless they select each row individually.

 

 

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

You'd need to ask for volunteers on the mailing list. 

--

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

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