Re: Forms for entering data into postgresql

From: Adrian Klaver <adrian(dot)klaver(at)gmail(dot)com>
To: David Johnston <polobo(at)yahoo(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Forms for entering data into postgresql
Date: 2013-10-12 22:16:12
Message-ID: 5259CA2C.5060403@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(dot)klaver(at)gmail(dot)com

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2013-10-12 22:21:21 Re: like & optimization
Previous Message Chuck Davis 2013-10-12 22:15:45 Re: Forms for entering data into postgresql