Hi Dave, On Thu, Nov 16, 2017 at 7:51 AM, Dave Caughey <caugh...@gmail.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-li...@intellasoft.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 <nroll...@grandlyon.com >>> <mailto:nroll...@grandlyon.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____ >>> >>> >>> >> >> >
