> - Lots of data entry yes...we've got some data-entry folks that are using one of the apps I've written, pulling information off paper phone-bills (for those we can't get electronically)
> - What about data entry into a web form. Data entry people use 'Enter' > to move between fields, not Tab. And they won't touch a mouse. This may be a training issue...our DE folks use <tab> with no problems. However, if needed, you can use JavaScript to intercept <enter> and treat it as a tab. Several of the following answers can be resolved with a little JavaScript in the browser. > - Data entry people use lots of F-keys, Ctrl-keys and Alt-keys to make > things happen on the screen. Not quite as much flexibility here. HTML defines accelerator keys which are browser-specific (sometimes Alt+letter, sometimes control+letter, or other combos). > - Screens need to save and return *fast*. Instantaneous response is > expected. Depending on the source data, there are a couple options, and there are also issues with latency: - use AJAX to queue up DE, submitting the form in the background while allowing the user to continue with a new form. This gives you the best UI, but is more complex - if you're on a LAN you have different latency issues than if you're on a GSM aircard, dialup, or a satellite connection - you can create a form with subforms that can gather large batches of data and them submit them all at once. This one's fairly easy, but comes with the risk that an unsubmitted form can cause more data-loss if the user accidentally browses elsewhere or closes the window. As a vi/vim user, my fingers occasionally try to use control+W to delete the previous word while I'm typing in IE, only to have it close my whole window. Minutes of sotto voce oaths usually follow. > - Printouts need precise on-paper placement and instant delivery (no > pop-ups to select printer or preview). printing from the web is a peculiar issue. If you're printing to a local printer (attached/accessible to the browsing machine), you pretty much always have to go through a print dialog. If the printer is attached to the web-server, you have more control over the immediacy of printing. You'd have to use a python printing module (there was a recent post on comp.lang.python on this that pointed at a popular library, though I don't have it on hand). > - Screens are dense with lots of tightly-packed fields. This is a design issue... > - There may be requirements to interface with barcode scanners and > magstripe scanners (probably USB connected). Is it possible to integrate > these with a web app. Depends on how much data is coming off the barcode/magstripe scanner. Often the readers can be configured as a "keyboard wedge" which often means that the act as a virtual keyboard. For 1-d barcode scanners, this is pretty simple: read the barcode, send the data as keystrokes, and optionally send an <enter> or <tab> afterwards. Excellent for web. For mag-stripes such as credit-cards and loyalty cards, there are usually 2 tracks, of which usually only one is used for data. Much the same as a 1-d barcode reader, they send the data as keystrokes and optionally send a termination enter/tab character. This data being visible is usually not a problem. For 2-d barcodes and mag-stripes with 2 or 3 tracks of data (such as AMX credit-cards or US drivers'-licenses, most of which follow the 3-track AAMVA standard) on them, things get a little more complex. They send the data like keystrokes, including field and track/line delimiters and optionally a tab/enter afterwards. You'd have to have a text-box, click/tab into it, scan the card, get the data, and then parse the contents of that textbox (whether in JS or on the server-side). Scattering sub-fields of this data to the right places is...uh...an adventure :) You might look at Koha, OpenBiblio or Evergreen (three open-source library web OPAC systems, most of which at least deal with 1-d barcodes) for examples of how they treat barcode input. > Is anyone running apps like this? Yep :) > Can the above issues be dealt-with? Most of them, yes. > Can a browser provide the right kind of UI for these demanding but > unexciting applications? You don't give a lot of details on the characteristics of the data which may make a difference. Are there logical groupings in the data (in our instance, each phone is data-entered, each of which is usually on its own page, so there's a need to flip pages regularly, so they do a phone at a time, with 20-30 fields of data associated with each). Or, you can use AJAX something like Google Spreadsheets to dynamically add rows for DE use, submitting the row-content in the background. Django+Python+JavaScript can handle most of the requirements. Demand-printing on the web-client is the largest hurdle. And as a web-user, I'd want it that way, as I wouldn't want arbitrary websites to be able to send stuff to my printer unsolicited without giving me an option to cancel. Hope my time in the trenches on the above gives you some pointers. -tim --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
