Thread: PATCH: Improve status bar in Edit Data window
Hello Dave!
Monday, December 16, 2013, 7:39:52 PM, Dave Page wrote:
>> I'd suggest adding a setting in Options dialogue, say "Default rows
>> limit", defaulting itself to "No limit" to retain current behaviour.
>> Please let me know if it is worth trying to implement this proposal.
DP> Iirc, that's exactly why we added the Top/Last 100 rows feature. The
DP> problem with the modification as you suggest is that we're bound to
DP> end up with confused users that don't realise a limit was set (because
DP> a colleague did it, or they did it and then forgot) who then mail us
DP> asking why they only see 1000 rows. We'd need to make it very clear
DP> that some rows were omitted somehow. If you can figure out a clear,
DP> but non-intrusive way to do that, it might make sense.
1. I suggest to append a well-visible label ("LIMIT") to rows counter in
the status bar if the limit was set and (possibly) worked. Also it
is handy to see if any filter expression was set. For example:
1000 rows LIMIT
1000 rows LIMIT, FILTER
797 rows, FILTER
Will that help distracted users?
2. Here is another useful feature (and most wanted personally by me :) ).
Second part of status bar now shows description for currently selected
column. After playing a while with it's format I ended up with
following (seems most helpful and easily readable):
isLocked, boolean (NOT NULL, DEFAULT)
id, integer (PK)
id, integer (PK, DEFAULT)
name, character varying(80) (NOT NULL): Person's full name
According to docs, pg_catalog.col_description() is available in
PostgreSQL 7.3, hope it wouldn't cause compatibility issues.
I can't figure out if all those labels (LIMIT, DEFAULT etc) are to be
translated, so the usage of _() and wxT() is possibly wrong.
3. And by the way, I want to ask to loosen restriction on minimal size
for Edit Data window. Sometimes a user has to look at just a few
records in several reference tables, but they hardly fit the screen
because of their min height.
--
Best regards,
J.F.
Attachment
Hi
On Sat, Dec 28, 2013 at 12:32 PM, J.F. Oster <jinfroster@mail.ru> wrote:
> Hello Dave!
>
> Monday, December 16, 2013, 7:39:52 PM, Dave Page wrote:
>
>>> I'd suggest adding a setting in Options dialogue, say "Default rows
>>> limit", defaulting itself to "No limit" to retain current behaviour.
>>> Please let me know if it is worth trying to implement this proposal.
>
> DP> Iirc, that's exactly why we added the Top/Last 100 rows feature. The
> DP> problem with the modification as you suggest is that we're bound to
> DP> end up with confused users that don't realise a limit was set (because
> DP> a colleague did it, or they did it and then forgot) who then mail us
> DP> asking why they only see 1000 rows. We'd need to make it very clear
> DP> that some rows were omitted somehow. If you can figure out a clear,
> DP> but non-intrusive way to do that, it might make sense.
>
>
> 1. I suggest to append a well-visible label ("LIMIT") to rows counter in
> the status bar if the limit was set and (possibly) worked. Also it
> is handy to see if any filter expression was set. For example:
>
> 1000 rows LIMIT
> 1000 rows LIMIT, FILTER
> 797 rows, FILTER
>
> Will that help distracted users?
I think adding a bright yellow warning exclamation would be a good
idea too. Something like:
/!\ Data filtered
or
/!\ Rows limited
> 2. Here is another useful feature (and most wanted personally by me :) ).
> Second part of status bar now shows description for currently selected
> column. After playing a while with it's format I ended up with
> following (seems most helpful and easily readable):
>
> isLocked, boolean (NOT NULL, DEFAULT)
> id, integer (PK)
> id, integer (PK, DEFAULT)
> name, character varying(80) (NOT NULL): Person's full name
Not entirely sure I like that. It at least partially duplicates what's
already in the header row (and gets it wrong, in the case of a serial
column). I would be inclined to display just the column description in
the status bar, and extend the markers in the header to include "NN",
and "DEF" as they currently do for "PK". Or something like that.
> According to docs, pg_catalog.col_description() is available in
> PostgreSQL 7.3, hope it wouldn't cause compatibility issues.
No problem there.
> I can't figure out if all those labels (LIMIT, DEFAULT etc) are to be
> translated, so the usage of _() and wxT() is possibly wrong.
They shouldn't be translated, and should only be capitalised, if they
are SQL keywords.
> 3. And by the way, I want to ask to loosen restriction on minimal size
> for Edit Data window. Sometimes a user has to look at just a few
> records in several reference tables, but they hardly fit the screen
> because of their min height.
I have no problem with that, but it needs to take into account whether
or not the scratch pane is visible, and be able to deal with it
properly if the user turns the scratch pane back on, when the window
is small.
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Hello Dave, Thursday, January 2, 2014, 4:01:47 PM, Dave Page wrote: >> 1000 rows LIMIT >> 1000 rows LIMIT, FILTER >> 797 rows, FILTER >> Will that help distracted users? DP> I think adding a bright yellow warning exclamation would be a good DP> idea too. Something like: DP> /!\ Data filtered DP> or DP> /!\ Rows limited Trying to imagine,.. that is a bitmap? Would it appear in "rows" pane in the status bar or in a new pane (how would it relate to "rows" and "description" panes)? >> name, character varying(80) (NOT NULL): Person's full name DP> Not entirely sure I like that. It at least partially duplicates what's DP> already in the header row (and gets it wrong, in the case of a serial DP> column). I would be inclined to display just the column description in DP> the status bar, and extend the markers in the header to include "NN", DP> and "DEF" as they currently do for "PK". Or something like that. Sure, "serial" will be fixed. I've done a quick screenshot-based search on how this looks in some popular DBMS-related tools: Oracle SQL Developer AllroundAutomations PL/SQL Developer EMS SQL Manager PostgreSQL Maestro MS SQL Server Management Studio Quest Software Toad for Oracle Embarcadero DBArtisan Sequel Pro Navicat SQLBuddy I haven't found any one (except PgAdmin) to have some column metadata shown in the column header when viewing/editing table data. Everyone shows nothing but the column name in the header! Also I recall my first experience with PgAdmin in 2006 - this distinction was noticed. So possibly, many UI designers of the products above came to similar conclusions: 1. Column header is too small and can't present much information without distracting the user. 2. Further column metadata (even data type) is less significant to most users and can be placed to some "background" location (status bar) or even totally removed. May be it's not so bad to duplicate column name & datatype, as a first step to introduce new feature and hopefully get some user's feedback? That area in the status bar is unused anyway... >> 3. And by the way, I want to ask to loosen restriction on minimal size >> for Edit Data window. Sometimes a user has to look at just a few >> records in several reference tables, but they hardly fit the screen >> because of their min height. DP> I have no problem with that, but it needs to take into account whether DP> or not the scratch pane is visible, and be able to deal with it DP> properly if the user turns the scratch pane back on, when the window DP> is small. Ok, I'll check this. -- Best regards, J.F.
On Tue, Jan 7, 2014 at 7:02 AM, J.F. Oster <jinfroster@mail.ru> wrote: > Hello Dave, > > Thursday, January 2, 2014, 4:01:47 PM, Dave Page wrote: > >>> 1000 rows LIMIT >>> 1000 rows LIMIT, FILTER >>> 797 rows, FILTER >>> Will that help distracted users? > > DP> I think adding a bright yellow warning exclamation would be a good > DP> idea too. Something like: > > DP> /!\ Data filtered > DP> or > DP> /!\ Rows limited > > Trying to imagine,.. that is a bitmap? Would it appear in "rows" pane > in the status bar or in a new pane (how would it relate to "rows" and > "description" panes)? A bitmap, similar (perhaps) to the attached. It could appear in the rows panel (or at least, the text could - the image might need it's own panel so you have something to draw on) - I haven't given it a huge amount of thought, and without trying it out, it's hard to visualise exactly what it would look like. > I've done a quick screenshot-based search on how this looks in some > popular DBMS-related tools: > Oracle SQL Developer > AllroundAutomations PL/SQL Developer > EMS SQL Manager > PostgreSQL Maestro > MS SQL Server Management Studio > Quest Software Toad for Oracle > Embarcadero DBArtisan > Sequel Pro > Navicat > SQLBuddy > I haven't found any one (except PgAdmin) to have some column metadata > shown in the column header when viewing/editing table data. Everyone > shows nothing but the column name in the header! > Also I recall my first experience with PgAdmin in 2006 - this > distinction was noticed. > > So possibly, many UI designers of the products above came to similar > conclusions: > 1. Column header is too small and can't present much information without > distracting the user. > 2. Further column metadata (even data type) is less significant > to most users and can be placed to some "background" location (status > bar) or even totally removed. > > May be it's not so bad to duplicate column name & datatype, as a first > step to introduce new feature and hopefully get some user's feedback? > That area in the status bar is unused anyway... That kinda depends on the size of your window doesn't it? The problem with the status bar is that it's detached from the actual object you're looking at. You cannot see at a glance what it refers to so easily - using the column header gives you a visual clue that doesn't require you to check which cell is selected. It also allows you to see everything at once (and in 10+ years of using this design, I've never heard anyone complain about using the column headers in this way). There have been heated discussions here in the past (admittedly a long time ago) about not cluttering the status bars with too much information - and I'm normally on the "more is better" side of the argument, but I'm not convinced this time. Other opinions from the peanut gallery would be useful :-) Cheers, Dave. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company