From: | Shirley Wang <swang(at)pivotal(dot)io> |
---|---|
To: | pgadmin-hackers <pgadmin-hackers(at)postgresql(dot)org> |
Subject: | [PlumAdmin][Weekly Design Update] |
Date: | 2017-02-22 16:29:35 |
Message-ID: | CAPG3WN7YxVO+n3qbDOWQBWY0rkscq1ar-5V-PJBSEPPZNsT_qw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgadmin-hackers |
Hello all!
This is the first design weekly update from the Plumadmin team at Pivotal.
Our goal with these emails is to share out what the design/product team is
working on and gather your feedback before we begin development. We'll send
these out roughly every Wednesday.
Our process is iterative, meaning we start with assumptions about user
behavior and continue to validate those assumptions. This is done through
conversations or with feedback on wireframes. Typically, design work runs
ahead of development work to minimize the risk of building the wrong thing
for users. In this period, we also work closely with engineers to make sure
the designs are feasible and lean. We want to do the smallest amount of
work that leads to the largest value for users.
The structure of the email includes our current work, future work, and
blockers we are facing. *We'd love to get your input on the designs, as
well as suggestions on how to unblock us.*
All weekly updates will be documented in google docs as well:
https://docs.google.com/document/d/1J_GhsL0nR4dbTI6F-XlxspvXutghzj-3UGjDWf8MtVA/edit?usp=sharing
Shirley
2.22.17 Weekly UpdateCurrent Work
History : Enabling users to be able to see their full queries within the
history panel
What we know
-
Users want to reuse queries when they are iterating upon previously run
queries
-
When the changes are small, retyping queries is a painful and time
consuming process
-
Users tend to use the text editor as their history, choosing not to
delete each query after running it, or type out full queries in another
application and copy/paste it into pgAdmin when they need to run it.
Current Design [WORK IN PROGRESS]
1. See history after running query
Columns should be fixed width. Red highlight indicates if query was able to
run Users can click on each row to see details.
2. Expand history v1
Users expand/collapse each row by clicking on the drop down arrow to the
left. Full query should appear, with the ability to scroll to see entire
query.
Questions:
-
Is the drop down arrow affordance enough for users to know how to
collapse/expand?
-
What happens if users scroll down a very long query and want to go back
up?
3. Expand history v2
Panel slides to the left to show query details.
Questions:
-
Do users need to see query details in context of the other queries?
What we’re working to validate
-
Do users need to compare two previously run queries? (Is this an edge
case we need to account for?)
-
What value does seeing time offer? If it’s to see how long ago I ran
this query, how might we better display time to enable this?
-
What is the best way for displaying a 1000+ line query?
Autoformat: Enabling users to quickly organize unformatted code into
something readable
What we know
-
Users need to quickly be able to organize it for scanning and reading.
Current Design [WORK IN PROGRESS]
1. Place unformatted query into editor
2. Autoformat tip appears after highlighting text v1
Highlight would appear below selection of text. Users have option of
clicking ‘Autoformat SQL’ or using the keyboard shortcut. If they no longer
want to see the tip, they can select ‘Don’t show again’.
Yellow was chosen because it is differentiated enough from purple and blue
to be noticeable by users. We wanted to introduce a new color to indicate
that this pop up was different from the other notifications that appear.
3. Autoformat tip appears after highlighting text v2
Same notification as v1, with the placement being in the bottom right
corner.
What we’re working to validate
-
Users need to see how to autoformat after they highlight a section of
text
-
Where autoformat function can be placed to be useful with minimal
distraction
_______________________
Future work [Needs User Validation]
Redesign Dashboard: Enable Greenplum users to see only relevant info
What we know:
-
We assume that the graphs on the dashboard are not necessary for users
of Greenplum to see
-
Dashboard elements are useful for other users and they need to view it
What we’re working to validate
-
If removing the graph will impact the experience negatively for
Greenplum users
Starting up on pgAdmin: Upon opening pgAdmin, enable users to quickly get
set up to begin querying databases
What we know
-
The current process for getting to the query editor tool is a multi-step
task that involves the user clicking into the browser for the right table.
-
Most users have said their purpose for using pgAdmin is to write
queries, so we want to get users to that point as fast as possible.
How we will validate
-
Interviews with pgAdmin users on their needs when opening pgAdmin
-
Testing wireframes
____________________Potential Blockers
-
No established pool of users to talk to, very ad hoc
-
Unknown technical feasibility + constraints
Attachment | Content-Type | Size |
---|---|---|
02 autoformat v1.png | image/png | 221.5 KB |
01- unformatted query.png | image/png | 212.1 KB |
03 autoformat v2.png | image/png | 222.7 KB |
01 history v1.png | image/png | 193.9 KB |
03 history v1.png | image/png | 273.3 KB |
02 history v1.png | image/png | 361.1 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Atira Odhner | 2017-02-22 21:23:42 | Re: SlickGrid |
Previous Message | Dave Page | 2017-02-22 12:42:28 | Re: Acceptance Tests against a browser (WIP) |