Re: Forms for entering data into postgresql - Mailing list pgsql-general
From | Adrian Klaver |
---|---|
Subject | Re: Forms for entering data into postgresql |
Date | |
Msg-id | 5259CA2C.5060403@gmail.com Whole thread Raw |
In response to | Re: Forms for entering data into postgresql (David Johnston <polobo@yahoo.com>) |
List | pgsql-general |
On 10/12/2013 02:40 PM, David Johnston wrote: > Adrian Klaver-3 wrote >> pv150el90 = PVC 1.5" ell 90 degree >> abs150el90 = ABS 1.5" ell 90 degree > > You can code an interactive command line processor in pretty much any > language - html+javascript included. The issue is likely one generalized to > GUI in particular since now that people are used to having these verbose > forms if you ask them to perform command line type processing they are going > to think you are crazy. Not the people that I deal with. The GUI environments are slowing them down. This gets to the crux of an on going argument I have been having since the last 70s. The fact that 'suits' and developers do not actually pay attention to what the end user really wants. In the data entry environment that is software that is fast and stays out of the way. When said end users complain, they are informed that are not technically savvy enough or business trained enough to fully appreciate the neatness being thrust open them. So they end up resorting to the bigger hammer theory and beat the software into doing what they want and suffer the consequent impedance. This is not to be taken as me opposing all progress, just that progress for the sake of winning Buzzword Bingo is harmful. > > Many of the leading web app GUI developers are targeting a mass-market > audience with the goal of getting as many eyeballs as possible being able to > functional versus having a handful of power-users be as efficient as > possible. The designs reflect this fact. The lack of good designs in the > data-entry environment is due either (or both) to lack of visibility - these > implementation are generally in-house and proprietary - and lack of > creativity. No, actually the argument is the other way around. In house applications where often very creative. The new mantra though involves outsourcing using generalized platforms that mimic mass market applications under the guise of 'universal' usability. Unfortunately, that often fails miserably. This is my view is all part of a bigger problem, the desire to move from paying to train competent people to paying for software to replace them. So far my experience is that the software is failing in that mission and you have the worst of two worlds, untrained people using failed software. > > The biggest limitation that I can see currently with browser-based GUI is > the ability to coordinate amongst multiple top-level windows. You get some > ability with pop-up dialogs but a full multi-faceted GUI incorporating > multiple windows does not seem doable. I guess some of the websocket > functionality could coordinate two separate "pages" asynchronously but that > is still quite limiting. Agreed. With my vast experience in Web development of tens of hours, I beginning to appreciate that it is basically about message passing and that as you say is somewhat limited. > > David J. > > > > > -- > View this message in context: http://postgresql.1045698.n5.nabble.com/Forms-for-entering-data-into-postgresql-tp5773952p5774399.html > Sent from the PostgreSQL - general mailing list archive at Nabble.com. > > -- Adrian Klaver adrian.klaver@gmail.com
pgsql-general by date: