Thread: 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.
On Wed, Oct 9, 2013 at 7:05 PM, Sudhir P.B. <pb_sudhir@hotmail.com> 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.
Here is a list of tools that has been more or less maintained over the past several years: http://wiki.postgresql.org/wiki/Community_Guide_to_PostgreSQL_GUI_Tools
I have no idea how many of them are still actively developed or used though.
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 12/10/13 05:06, Steve Atkins wrote:
Hmph! I am still using punched cards for data processing and data interchange...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
...like making shopping lists and giving people notes - for which purpose, I find a pen more convenient than a card punch!
Cheers,
Gavin
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
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.On Sat, Oct 12, 2013 at 11:11 AM, Vincent Veyron <vv.lists@wanadoo.fr> wrote:
Le samedi 12 octobre 2013 à 15:39 +0200, Wolfgang Keller a écrit :Sure, they suck, but I doubt you'll revert to cave dwelling if you ever
> "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.
>
have to send an email from some remote location where you have no email
relay?Crappy applications have been written long before the web was born, the
> > 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...
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
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
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.
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.
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. Using the mouse is insulting enough to move from one 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.
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 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