Re: [Design Update][History]

On Tue, Mar 7, 2017 at 4:01 AM Dave Page <dpage(at)pgadmin(dot)org> wrote:

> On Mon, Mar 6, 2017 at 9:19 PM, Shirley Wang <swang(at)pivotal(dot)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.
>

I see. We're looking into messages for storage procedures now and how that
should be solved. Are there other types of messages we should be aware of?

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