> > IOW I suspect a browser-based frontend (as intended by the > > tool mentioned) would slow (me) down as opposed to a dedicated > > client largely because a web interface is not > > tailored/intended for rapid data entry. > > > > What I want to say is that I don't think a browser is the best > > choice for a prescribing client. > > Karsten, > Looking at specific differences between web-browser and custom > client-programs as interface, I think they will all eventually disappear. No.
> In the meantime, I wonder what are the critical differences that > impede your efficiency? A browser cannot access card readers unless quite sophisticated add-on code is installed locally. A browser does not offer sophisticated entry tools without requiring a lot of add-on code being installed locally. A browser most of the time makes using screen real estate efficiently and consistently hard for the programmer (unless add-on code is installed locally). Then, why not install a "conventional" application if one has to install code locally anyways ? > Would new browser features such as "access keys" > (http://www.cs.tut.fi/~jkorpela/forms/accesskey.html) change your > opinion? No. If they are under the control of the "application" running inside a browser they can potentially conceptually compromise browser security. If they are under the control of the browser executing the "application" assignment of key to action is arbitrary. Pick your poison. Something a browser interface IS suited for is *displaying* drug information for perusal. Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
