Re: PGadmin4

Hi Dave,
​
On Thu, Nov 16, 2017 at 7:51 AM, Dave Caughey <caugheyd(at)gmail(dot)com> wrote:

> And my input on the subject of workflow...
>
> For me, as a developer/maintainer/supporter, my number one points of
> interaction are via the Query Tool and the "View/Edit Data | Filtered
> Rows", the later of which is *the* most buried bit of functionality.
>
> I realize everyone's needs are slightly different, but I am having a hard
> time believing that many of the fixed-items (Dashboard, Properties, SQL,
> Statistics, Dependencies, Dependents) are very commonly used on a
> day-to-day basis. Maybe some people need to stay on top of the animated
> charts, but in my experience, once a DB is running on a suitable server, it
> doesn't require constant monitoring of Locks, Tuples in/out, etc. And once
> the database has been deployed, there's very little need to see its
> Dependencies or Dependents or SQL, on a day-to-day basis.
>
> But that functionality is actually the easiest to access... it's right
> there in the "toolbar". Indeed you don't have to do anything to see the
> "Tuples In" animated chart because it's on the dashboard. So, zero effort
> to get to infrequently-accessed functionality.
>
> But what does get done, day-after-day, by anyone maintaining/supporting a
> database-driven application is looking up and tweaking a customer's
> records, or fixing a ill-planned migration, or planning out what will be
> affected by a potential new product feature... and the primary point of
> interest is (for me) the query tool and being able to see individual
> records.
>
> But that's actually the most buried functionality. Nested menus are a
> usability efficiency killer. So, maximal effort to get to
> frequently-accessed functionality
>
> *My* view of a perfect workflow would be to drill down to a table, and
> then have the "Filter Rows" interface (for the selected table) appear
> *instead* of the Dashboard/properties/sql/statistics/dependencies/dependents,
> so all I have to do is start typing and click execute.
>
> I.e., make the frequently-accessed functionality as easy to access as
> possible, and let the infrequently-accessed functionality be a little less
> convenient to access.
>
> Of course, I understand that other people may feel that the dashboard is
> their finger-on-the-pulse of their database, but that feels like it should
> be an option, just like you let people control which nodes they see in the
> "browser".
>
​You can close the Dashboard at anytime, Select 'Dashboard' tab and click
on close button which on right side.
[image: Inline image 1]​

​Thanks,
Murtuza​

> Thanks for listening,
> Dave
>
> On Wed, Nov 15, 2017 at 8:57 PM, Mark Murawski <
> markm-lists(at)intellasoft(dot)net> wrote:
>
>> Hi Murtuza,
>>
>> This is in regards to pgadmin4 2.0 on Mac (I've been unable to use
>> pgadmin4 on linux for quite some time, the installation process is a bit of
>> a nightmare, and I'm not the only one who feel this way)
>>
>> I too have workflow issues that pgadmin4 does not meet. I continually
>> use pgadmin3 and put up with the bugs and constant crashes.
>>
>>
>> Cons and Major lacks of functionality:
>> - Metadata population is considerably slower than pgadmin3. For a DB on
>> the local lan it can take as many as 10 seconds to get into the database
>> list. Whereas on pgadmin3 this is nearly instant
>>
>> - Multiple windows?? This is a HUGE missing part of going from pgadmin3
>> -> pgadmin4. Each window can hold about 10 tabs without becoming a
>> management problem. 6 of those are fixed, the
>> 'Properties/Dashboard/SQL/etc' tabs. So you're left with 4 spaces for your
>> own tabs. What DBA only has 4 tables/functions/queries/etc open at a
>> time? Of course you can open more than 4 and then scroll, but who wants to
>> deal with that?
>>
>> - More on multiple windows... I haven't really looked at the pgadmin4
>> code at all, save for just trying to get it working on linux... but I have
>> a feeling that from the design of a web-shim, loading a web html/css type
>> application, building in multi-window support is going to be a major pain.
>>
>> - Tab management. Have more than two queries/tables/etc open as tabs and
>> then management becomes a complete nightmare and the program is just about
>> unusable. (Tabs are force-named to Query-1, Query-2, etc. Who knows what
>> is what?
>>
>> - More tab management. If you've connected to your databases, opened up
>> everything you need to work on, and then say, accidentally drag one of the
>> multi-tabbed ancillary windows, you're either in the situation where you
>> need to drag four tab-windows back to where you got them from, one by one,
>> or you might be in a situation where the interface wont let you drag them
>> back at all and they are left floating forever. So your stuck with either
>> working on a sub-optimal layout, or being forced to 'restore layout' which
>> restarts the app and you lose all your window management, connections, and
>> open queries that you've painstakingly set up.
>>
>> - More tab management. Unable to change text labels on tabs... Say you
>> have your 4 tabs open and you're working on four functions... which one is
>> which? So now I have to mentally keep track that the first 'Create script'
>> tab is function Z and the second 'Create Script' tab is function A. The
>> same goes for query windows. Which one of the 7 query windows is the query
>> for selecting * from foo? Who knows... you have to either remember them
>> all, or click through each one until you find it.
>>
>> - Table Data copy/paste... What happened to the ability to be able to
>> select a cell value and then paste it into another window? Or select a
>> whole group of rows/columns and then paste that somewhere?
>>
>> Pros and nice features:
>> The dashboard is pretty cool, to show you database activity. I'll
>> usually have my actual work being done in pgadmin3 and keep an eye on
>> databases with the dashboard.
>>
>> With pgadmin3-lts now supporting up to Postgres 10, there's absolutely no
>> reason to use pgadmin4. pgadmin3 is the clear winner in terms of usability
>> and functionality despite the crash-happy nature of the app.
>>
>> I remember a rant/post earlier in the year, or maybe it was last year by
>> another user and it listed out a good number of lackings of pgadmin4 that
>> limit its use of real-world workflow. I'm sure I'm missing dozens of other
>> missing items... but I think I got the major ones out of the way.
>>
>> More Cons:
>> I'm just frustrated and annoyed that I've probably spent about 20 hours
>> getting pgadmin4 2.0 going in linux just to try it out. I'm sure I'm not
>> the only one.
>>
>>
>> I completely understand that a *huge* amount of work... thousands of
>> man-hours went into pgadmin4 using the latest whizbang technology, but I
>> think it's a shame that it seems like it was developed for the sake of just
>> 'modernizing' it, versus providing a better user-experience and a better
>> application. It's a shame that those thousands of hours weren't focused on
>> pgadmin3 and improving the core, and even if major portions needed a
>> rewrite because it was "just that bad", it would have been more value added
>> to spend those thousands of hours doing just that versus a complete
>> from-scratch application that's a far cry in functionality from the
>> original it's supposed to replace.
>>
>>
>>
>> On 11/12/17 1:20 AM, Murtuza Zabuawala wrote:
>>
>>> Hi,
>>>
>>> Would you like to share what's not working in your environment?
>>> It might help us improve the product.
>>>
>>> Thanks,
>>> Murtuza
>>>
>>> On Wed, Nov 8, 2017 at 3:44 PM, Nicolas ROLLAND <NROLLAND(at)grandlyon(dot)com
>>> <mailto:NROLLAND(at)grandlyon(dot)com>> wrote:
>>>
>>> Just to inform that every task we could do with PGad3 do not work
>>> with PGad4.____
>>>
>>> Here at Metropole de Lyon we all uninstall version 4 to reinstall
>>> version 3 which work perfectly.____
>>>
>>> So please keep version 3 available.____
>>>
>>> Thanks____
>>>
>>> __ __
>>>
>>> Nicolas ROLLAND____
>>>
>>>
>>>
>>
>>
>