Обсуждение: Forms for entering data into postgresql‏

On 10/09/2013 07:05 PM, Sudhir P.B. wrote:
> I have developed an application using MS SQL. I have used MS Access for
> creating forms to enter data into the database. I am thinking of
> changing over to postgresql and would also like to use any other
> available open source tool for creating forms. Are there any free
> applications available for creating forms similar to the ones I have
> made in MS Access?. Any alternative suggestions will be appreciated.

There are tools available, as mentioned in a previous post. There are
good tools in the list and I have tried quite a few of them. Just know
they will require a bit more effort then Access to get a finished form.
I am not the biggest fan of Access, but it does shine in getting fairly
involved forms up quickly. FYI, you can use it with Postgres, which may
be the way to go until you have completed the change over to Postgres.
Welcome to the Postgres community.


--
Adrian Klaver
adrian.klaver@gmail.com

On Wed, Oct 9, 2013 at 9:24 PM, Adrian Klaver <adrian.klaver@gmail.com> wrote:
> On 10/09/2013 07:05 PM, Sudhir P.B. wrote:
>>
>> I have developed an application using MS SQL. I have used MS Access for
>> creating forms to enter data into the database. I am thinking of
>> changing over to postgresql and would also like to use any other
>> available open source tool for creating forms. Are there any free
>> applications available for creating forms similar to the ones I have
>> made in MS Access?. Any alternative suggestions will be appreciated.
>
>
> There are tools available, as mentioned in a previous post. There are good
> tools in the list and I have tried quite a few of them. Just know they will
> require a bit more effort then Access to get a finished form. I am not the
> biggest fan of Access, but it does shine in getting fairly involved forms up
> quickly. FYI, you can use it with Postgres, which may be the way to go until
> you have completed the change over to Postgres. Welcome to the Postgres
> community.

Most of the "90's era" application stacks (vb, access, delphi, etc)
will work just fine with postgres over ODBC although an already
written application would need some changes if it's built against the
internall jet database.  If you're writing a new application though,
it's should be clear that investing in a more modern environment is a
good idea.  Forms these days are written in HTML.

merlin

> I have developed an application using MS SQL. I have used MS Access
> for creating forms to enter data into the database. I am thinking of
> changing over to postgresql and would also like to use any other
> available open source tool for creating forms. Are there any free
> applications available for creating forms similar to the ones I have
> made in MS Access?. Any alternative suggestions will be appreciated.

Without Programming:

LO/OO Base
Kexi might get usable one day as well.
Rekall is apparently dead, unfortunately.

Using Python (far easier and more powerful than any dialect of "Basic"):

With PyQt (& Sqlalchemy):
Qtalchemy: www.qtalchemy.org
Camelot: www.python-camelot.com
Pypapi: www.pypapi.org

With PyGTK:
Sqlkit: sqlkit.argolinux.org (also uses Sqlalchemy)
Kiwi: www.async.com.br/projects/kiwi

With wxPython:
Gui2Py: code.google.com/p/gui2py/
Dabo: www.dabodev.com
Defis: sourceforge.net/projects/defis (Russian only)
GNUe: www.gnuenterprise.org

Sincerely,

Wolfgang

> Forms these days are written in HTML.

Only by clueless/careless morons.

HTML has never been, is not and will never be a usable GUI framework.

And "web apps" are unusable garbage.

Sincerely,

Wolfgang

----- Original Message -----
From: "Wolfgang Keller" <feliphil@gmx.net>
To: pgsql-general@postgresql.org
Sent: Friday, October 11, 2013 1:45:10 PM
Subject: Re: [GENERAL] Forms for entering data into postgresql‏

> I have developed an application using MS SQL. I have used MS Access
> for creating forms to enter data into the database. I am thinking of
> changing over to postgresql and would also like to use any other
> available open source tool for creating forms. Are there any free
> applications available for creating forms similar to the ones I have
> made in MS Access?. Any alternative suggestions will be appreciated.

Without Programming:

LO/OO Base
Kexi might get usable one day as well.
Rekall is apparently dead, unfortunately.

Using Python (far easier and more powerful than any dialect of "Basic"):

With PyQt (& Sqlalchemy):
Qtalchemy: www.qtalchemy.org
Camelot: www.python-camelot.com
Pypapi: www.pypapi.org

With PyGTK:
Sqlkit: sqlkit.argolinux.org (also uses Sqlalchemy)
Kiwi: www.async.com.br/projects/kiwi

With wxPython:
Gui2Py: code.google.com/p/gui2py/
Dabo: www.dabodev.com
Defis: sourceforge.net/projects/defis (Russian only)
GNUe: www.gnuenterprise.org

Sincerely,

Wolfgang


Try Libreoffice Base

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Try Libreoffice Base


Thanks,

Sunday Olutayo



----- Original Message -----
From: "Wolfgang Keller" <feliphil@gmx.net>
To: pgsql-general@postgresql.org
Sent: Friday, October 11, 2013 1:45:10 PM
Subject: Re: [GENERAL] Forms for entering data into postgresql‏

> I have developed an application using MS SQL. I have used MS Access
> for creating forms to enter data into the database. I am thinking of
> changing over to postgresql and would also like to use any other
> available open source tool for creating forms. Are there any free
> applications available for creating forms similar to the ones I have
> made in MS Access?. Any alternative suggestions will be appreciated.

Without Programming:

LO/OO Base
Kexi might get usable one day as well.
Rekall is apparently dead, unfortunately.

Using Python (far easier and more powerful than any dialect of "Basic"):

With PyQt (& Sqlalchemy):
Qtalchemy: www.qtalchemy.org
Camelot: www.python-camelot.com
Pypapi: www.pypapi.org

With PyGTK:
Sqlkit: sqlkit.argolinux.org (also uses Sqlalchemy)
Kiwi: www.async.com.br/projects/kiwi

With wxPython:
Gui2Py: code.google.com/p/gui2py/
Dabo: www.dabodev.com
Defis: sourceforge.net/projects/defis (Russian only)
GNUe: www.gnuenterprise.org

Sincerely,

Wolfgang


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

On Fri, Oct 11, 2013 at 7:47 AM, Wolfgang Keller <feliphil@gmx.net> wrote:
>> Forms these days are written in HTML.
>
> Only by clueless/careless morons.
>
> HTML has never been, is not and will never be a usable GUI framework.
>
> And "web apps" are unusable garbage.

Look -- I appreciate people with strong unorthodox beliefs but your
statement above is just reflecting a blatant disregard for reality.
Just about all software people use for everyday tasks anymore is
targeted for the web, including the email client I'm typing this in.
The vast majority of enterprise SaaS apps are web deployed and so so
are intranet applications.   It's just the way things are and if you
know your technologies you can settle on a stack that approaches the
RAD platforms of old in terms of programming efficiency.

merlin

With a brief look at the last 15 years of programming for the web, your
comments are a little harsh. Only a short time ago perl and cgi
was the rage.

I've been programming for 30 years...and still have clients who use
Lotus 123 (MS-DOS) based. It's a big world out there, and lots of
solutions....for a lot of problems.

PS. I wrote my first Postgresql Trigger the other day. Awesome stuff.

On Fri, 2013-10-11 at 14:47 +0200, Wolfgang Keller wrote:
> > Forms these days are written in HTML.
>
> Only by clueless/careless morons.
>
> HTML has never been, is not and will never be a usable GUI framework.
>
> And "web apps" are unusable garbage.
>
> Sincerely,
>
> Wolfgang
>
>

My interpretation of "Forms these days are written in HTML" means
most interfaces are web front ends to the cloud. Not a GUI framework.

On Fri, 2013-10-11 at 14:47 +0200, Wolfgang Keller wrote:
> > Forms these days are written in HTML.
>
> Only by clueless/careless morons.
>
> HTML has never been, is not and will never be a usable GUI framework.
>
> And "web apps" are unusable garbage.
>
> Sincerely,
>
> Wolfgang
>
>

On Oct 11, 2013, at 8:57 AM, Bret Stern <bret_stern@machinemanagement.com> wrote:

> My interpretation of "Forms these days are written in HTML" means
> most interfaces are web front ends to the cloud. Not a GUI framework.


Yup.

But embedding an HTML renderer in your desktop app does allow you to
use HTML where it's appropriate - and it works really well for dynamically
generated forms and tabular output.

The IBM 3270 wasn't the crowning achievement of data entry technology.

Cheers,
  Steve

Agreed.
On Fri, 2013-10-11 at 09:06 -0700, Steve Atkins wrote:
> On Oct 11, 2013, at 8:57 AM, Bret Stern <bret_stern@machinemanagement.com> wrote:
>
> > My interpretation of "Forms these days are written in HTML" means
> > most interfaces are web front ends to the cloud. Not a GUI framework.
>
>
> Yup.
>
> But embedding an HTML renderer in your desktop app does allow you to
> use HTML where it's appropriate - and it works really well for dynamically
> generated forms and tabular output.
>
> The IBM 3270 wasn't the crowning achievement of data entry technology.
>
> Cheers,
>   Steve
>
>
>

On Oct 11, 2013, at 8:57 AM, Bret Stern <bret_stern@machinemanagement.com> wrote:

My interpretation of "Forms these days are written in HTML" means
most interfaces are web front ends to the cloud. Not a GUI framework.

Yup.

But embedding an HTML renderer in your desktop app does allow you to
use HTML where it's appropriate - and it works really well for dynamically
generated forms and tabular output.

The IBM 3270 wasn't the crowning achievement of data entry technology.

Cheers, Steve

Wolfgang Keller-2 wrote
>> Forms these days are written in HTML.
>
> Only by clueless/careless morons.
>
> HTML has never been, is not and will never be a usable GUI framework.
>
> And "web apps" are unusable garbage.

Yet you have not stated what it is that you find works better.

Lots of software is unusable garbage but that generally reflects the
abilities of the coder and not the generic concept of "web apps" or any
other programming language.

That said if your starting point is Access GUIs then making the switch to
pretty much any other programming framework is going to be a large jump -
but one ultimately worthwhile given the vast applicability that "web app"
programming has in today's world.

Using HTML instead of a pixel-perfect or traditional container application
GUI (e.g., Java Swing) trades off some degree of user-experience for many
favorable deployment capabilities.  I can make a half-ass UI in either
platform but the HTML/JS one will be easier to deploy and the skills learned
more broadly applicable in today's world.

David J.



--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Forms-for-entering-data-into-postgresql-tp5773952p5774324.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.

> My interpretation of "Forms these days are written in HTML" means
> most interfaces are web front ends to the cloud. Not a GUI framework.

"Cloud", "web apps", yet more fashionable trendslang buzzwords.

I am talking about worktools that actually help productive "information
workers" to get useful work done with at least some efficiency.

Sincerely,

Wolfgang

> >> Forms these days are written in HTML.
> >
> > Only by clueless/careless morons.
> >
> > HTML has never been, is not and will never be a usable GUI
> > framework.
> >
> > And "web apps" are unusable garbage.
>
> Look -- I appreciate people with strong unorthodox beliefs but your
> statement above is just reflecting a blatant disregard for reality.

I don't disregard reality at all.

I just try to at least make an effort to not confuse blind herd instinct
with cognitive intelligence, not to mention technical competence.

> Just about all software people use for everyday tasks anymore is
> targeted for the web, including the email client I'm typing this in.

"Web mailers" are a particularly illustrative example why "web apps" are
ridiculous garbage. Just like "web forums" or "Google Apps".

If I had to use those, I would cease to use computers at all.

And I have started to use email and usenet with PINE on a Unix text
console.

> The vast majority of enterprise SaaS apps are web deployed and so so
> are intranet applications.

And they are totally unusable crap.

> It's just the way things are and if you know your technologies you
> can settle on a stack that approaches the RAD platforms of old in
> terms of programming efficiency.

Certainly not. Not to mention the issue of end-user productivity. Not
to mention the deployment mess, both server- *and* client-side, with
"web apps". Etc. and so on...

Sincerely,

Wolfgang

On 10/12/2013 06:39 AM, Wolfgang Keller wrote:

>
> Certainly not. Not to mention the issue of end-user productivity. Not
> to mention the deployment mess, both server- *and* client-side, with
> "web apps". Etc. and so on...

Five years ago I would have agreed with you totally. Web applications
where useless for serious data entry. Today I am on the fence for two
reasons.

1) My primary career for many years has involved
construction/maintenance work. In the course of said work I have spent
many hours at the counters of wholesale vendors placing orders. My
observation has been that as the vendors moved from text --> GUI --> Web
applications the counter personnel productivity has decreased. With the
old text applications I could rattle off a list of items and quantities
and the data person could enter them in real time. At the end I would
say 'done', they would hit print, I would take a few sips of coffee
while the order printed, we would go pick the order. The only
improvement I see with the new software is I get to drink more coffee as
I often get to sip between items as latency has increased.

2) Per previous comments in this thread the market is demanding Web
competency in app development. To that end I have been pushing myself up
that learning curve. Just this morning I finished a form driven by
Django using javascript/JQuery and backed by Postgres. In that form I
have an autocomplete field that derives its values from an array
populated by a database query. On selection of an entry in that field I
use the id associated with that entry to pull more information from the
database and populate other fields in the form. I quite pleased with the
snappiness of the response, granted this all done locally, though it is
going through the Django development server which makes no claims to
being speedy.

Development of said Web form involved quite a few moving parts. Learning
the parts was time consuming, learning to get them to exchange
information correctly even more so. The whole process would have taken
even longer where I not standing on the shoulders of better developers
them me, i.e Django for a database driven Web framework, JQuery to take
some of the ugliness out of Javascript.


Conclusion:

I agree with you to an extent that Web development is oversold.
I disagree that it is totally useless, there is promise.

P.S:

As to your examples of Web apps, web mailers, forums, etc, I would say
Caveat emptor . There is no such thing as 'free'. Most of the apps you
mention serve a dual purpose, one to provide the service specified, read
email for example, second to provide a source of customers to the
provider from which they can derive some monetary benefit. To serve that
second purpose they are cluttered with code, screen elements that really
do not have anything to do with the first purpose.

>
> Sincerely,
>
> Wolfgang
>
>


--
Adrian Klaver
adrian.klaver@gmail.com

Le samedi 12 octobre 2013 à 15:39 +0200, Wolfgang Keller a écrit :

> "Web mailers" are a particularly illustrative example why "web apps" are
> ridiculous garbage. Just like "web forums" or "Google Apps".
>
> If I had to use those, I would cease to use computers at all.
>

Sure, they suck, but I doubt you'll revert to cave dwelling if you ever
have to send an email from some remote location where you have no email
relay?

> > The vast majority of enterprise SaaS apps are web deployed and so so
> > are intranet applications.
>
> And they are totally unusable crap.
>
> > It's just the way things are and if you know your technologies you
> > can settle on a stack that approaches the RAD platforms of old in
> > terms of programming efficiency.
>
> Certainly not. Not to mention the issue of end-user productivity. Not
> to mention the deployment mess, both server- *and* client-side, with
> "web apps". Etc. and so on...

Crappy applications have been written long before the web was born, the
technology used makes no difference whatsoever.

I find that html is extremely well suited to the display of tabular
data, so I'm curious to know what kind of client-side problems you
experience with standard-compliant web forms?


--
Salutations, Vincent Veyron
http://marica.fr/site/demonstration
Gestion des contentieux et des dossiers de sinistres assurance pour le service juridique

On 10/12/2013 12:19 PM, Chuck Davis wrote:
> Browsers are fine for displaying informaiton that is already in a
> database.  They are the ultimate crap for entering data that has to be
> typed into a "form" and processed for persistence.  It will be a long
> time before I ask my users to enter data into a browser.
>
> Just for an example:  If you have 500 clients placing one order a
> browser is an "ok" tool -- probably the tool of choice.  If you have one
> accounts payable clerk entering 500 orders a browser is a very mean
> thing to do the your employee unless the entry is simply making
> selections from a drop down populated from the database; that scenario
> is not too real-worldish for AP.
>
> And with today's auto-updating of application platforms it pretty well
> eliminates any advantages the browser provides for internal
> applications.   Applications developed on the current application
> platforms are not only more efficient for data entry, they're just as
> easily kept up to date once installed.  And installation is nearly
> automatic with the current platforms like Netbeans Platform and Eclipse
> Platform (for Java).  I'm sure other languages have similar.
>
> Ultimately, it's a matter of choosing the right tool for the task.
> Unfortunately, too often these days there is a somewhat ignorant
> perception that a browser is always the right tool.
>

+1


--
Adrian Klaver
adrian.klaver@gmail.com

Le samedi 12 octobre 2013 à 12:19 -0700, Chuck Davis a écrit :

> Just for an example:  If you have 500 clients placing one order a
> browser is an "ok" tool -- probably the tool of choice.  If you have
> one accounts payable clerk entering 500 orders a browser is a very
> mean thing to do the your employee unless the entry is simply making
> selections from a drop down populated from the database; that scenario
> is not too real-worldish for AP.
>

Hi Chuck,

Could you explain the acronym AP?

I understand that there are lots of situations I have not met yet, so
this might explain my ignorance, but I don't see what you get from using
a client-side app over a browser for most databases uses; after all,
from the user's point of view, it's always tabbing from one field to the
next (providing the web form is correctly designed, of course)

Also, I would think most data in the form _should_ come from dropdowns
populated from the database, for obvious reasons of data integrity? It
certainly is the case in my apps.



--
                                        Salutations, Vincent Veyron

http://marica.fr/site/demonstration
Gestion des contentieux juridiques, des contrats et des sinistres d'assurance

On 10/12/2013 01:14 PM, Vincent Veyron wrote:
> Le samedi 12 octobre 2013 à 12:19 -0700, Chuck Davis a écrit :
>
>> Just for an example:  If you have 500 clients placing one order a
>> browser is an "ok" tool -- probably the tool of choice.  If you have
>> one accounts payable clerk entering 500 orders a browser is a very
>> mean thing to do the your employee unless the entry is simply making
>> selections from a drop down populated from the database; that scenario
>> is not too real-worldish for AP.
>>
>
> Hi Chuck,
>
> Could you explain the acronym AP?

Accounts Payable.
>
> I understand that there are lots of situations I have not met yet, so
> this might explain my ignorance, but I don't see what you get from using
> a client-side app over a browser for most databases uses; after all,
> from the user's point of view, it's always tabbing from one field to the
> next (providing the web form is correctly designed, of course)

In the text based systems I am familiar with their where keyboard
shortcuts that took you directly to fields and coding conventions that
allowed direct entry of data. For example at a plumbing supply house I
went to the convention was something like:

pv150el90 = PVC 1.5" ell 90 degree
abs150el90 = ABS 1.5" ell 90 degree

It looks cumbersome, but in the hands of someone experienced in the
system, data entry was very fast. Faster then in any of the newer
software that replaced it.

>
> Also, I would think most data in the form _should_ come from dropdowns
> populated from the database, for obvious reasons of data integrity? It
> certainly is the case in my apps.
>
>
>


--
Adrian Klaver
adrian.klaver@gmail.com

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.

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.

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.

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.

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

On 12/10/2013 23:15, Chuck Davis wrote:
> For those of us who grew up on real computers the only appropriate way
> to get from one input field to the next is hitting the enter key.  You
> know what that does in a browser...makes efficient data input
> impossible.  NOBODY should have to hit the tab key to move the cursor
> to the next field.

This doesn't seem to me like a fundamental limitation, but simply a
matter of having to re-train muscle memory. Not that's a trivial thing,
but it's a cost to "anything other than what you're used to" rather than
a cost of web UI per se.

It's also perfectly possible for a web app to capture the enter key and
make it go to next field, and quite common for GUI dialogs to treat
enter as "accept form", and use tab for "next field".

> Stuff gets to the database by being input by somebody. For Accounts
> Payable (AP) that is usually a clerk who enters orders/invoices all
> day.  There are many input fields involved for item, rate, units,
> etc., etc. including sometimes lengthy descriptions.  That's how stuff
> gets into the database and doing that in a browser is extremely
> tedious and VERY inefficient.

This claim has been repeated many times in this thread with very little
detail on what it is that is fundamentally more efficient in a non-web
UI. Adrian Klaver gave one alternative, which is to ditch not just the
web app concept, but much of the GUI. But if your input looks basically
like a set of form controls, a well-thought-out web app can look and
feel much the same as a well-thought-out Windows app.

I do still think native GUI apps, and maybe even some script-oriented
ones, have their place, but with the right toolkit, it's not necessarily
cut and dried where one ends and the next begins.

--
Rowan Collins
[IMSoP]

On 13/10/2013, at 9:15 AM, Chuck Davis <cjgunzel@gmail.com> wrote:

> the only appropriate way to get from one input field to the next is hitting the enter key.

Ha, I remember how blazing fast entry could be on old terminals with a field exit key on the numeric keypad -
particularlywhen standardised on 4-6 digit numeric identifiers. I do feel sorry for people who have to do data entry in
poorlydesigned apps, but it's also easier these days to pre-populate data and use an ajax hybrid search/select box to
seriouslyminimise the number of keystrokes. 

Cheers,

Tony

On 10/12/2013 6:15 PM, Chuck Davis wrote:
> For those of us who grew up on real computers the only appropriate way
> to get from one input field to the next is hitting the enter key.  You

Well, I grew up with a real computer.  There was no enter key on the 029
key punch; that only came along later for those spoiled kids who wanted
to use a C-R-T.  But using keyboards and CRTs would hardly constitute
real computer use.  Punch cards.

> know what that does in a browser...makes efficient data input
> impossible.  NOBODY should have to hit the tab key to move the cursor to
> the next field.  Using the mouse is insulting enough to move from one

That's a curious contention.  The earliest 3270 had both dedicated tab
and back tab keys.

> drop down to the next (which can also be done by hitting the enter key
> in a real application).  If you are a hunt-and-peck typist, of course,
> it probably doesn't make any difference.
>
> Stuff gets to the database by being input by somebody.  For Accounts
> Payable (AP) that is usually a clerk who enters orders/invoices all
> day.  There are many input fields involved for item, rate, units, etc.,
> etc. including sometimes lengthy descriptions.  That's how stuff gets
> into the database and doing that in a browser is extremely tedious and
> VERY inefficient.

That's very one-dimensional thinking.  A browser-based app can do
anything that a desktop app can do, especially with Ajax eliminating
round trip requirements.

If you want short hand command-line data entry like the Sabre system,
that can be provided in a browser app.  But as others have pointed out,
browser apps have traditionally been targeted at broader audiences.

> For people who are only checking inventory, checking invoice status,
> order status, credit status, etc. a browswer interface is superb.  Why
> bother writing a real application for something that trivial?
>
> The point is, use the right tool for the task.  It's not always a
> browser and those who think so are showing their ignorance of a huge and
> varied technology world.

On that we agree.

--
Guy Rouillier

On 10/12/2013 01:57 PM, Adrian Klaver wrote:
> ...
> In the text based systems I am familiar with their where keyboard
> shortcuts that took you directly to fields and coding conventions that
> allowed direct entry of data. For example at a plumbing supply house I
> went to the convention was something like:
>
> pv150el90 = PVC 1.5" ell 90 degree
> abs150el90 = ABS 1.5" ell 90 degree
>
> It looks cumbersome, but in the hands of someone experienced in the
> system, data entry was very fast.
Actually it looks like a Unix command-line. :) Very fast and easy to use
but not necessarily intuitive and easy to learn for the newbie.

I recall a former co-worker telling me about a friend who had started
work at a large accounting firm. He said that employees were not allowed
to have a mouse at their computer for the first few months of
employement which forced them to learn to use the computer by keyboard
alone. When they got the mouse back it was rarely used and the speedy
and effortless way they nagivated spreadsheets at audits repaid the time
spent learning the shortcuts many times over.

Cheers,
Steve