Heads-down transaction-processing apps on Django
Michael Hipp
Is anyone using Django web apps as heads-down transaction processing
applications that are heavy in the areas of:
- Lots of data entry
- Lots of "instant, right now" demands like POS
A few - slightly more specific - issues:
- 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.
- Data entry people use lots of F-keys, Ctrl-keys and Alt-keys to make
things happen on the screen.
- Screens need to save and return *fast*. Instantaneous response is
expected.
- Printouts need precise on-paper placement and instant delivery (no
pop-ups to select printer or preview).
- Screens are dense with lots of tightly-packed fields.
- 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.
Is anyone running apps like this?
Can the above issues be dealt-with?
Can a browser provide the right kind of UI for these demanding but
unexciting applications?
Any insight appreciated,
Michael
Tim Chase
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
Michael Hipp
Tim, thanks for taking time to respond in so much depth. You've given me
enough encouragement to think we can move forward.
I'm *really* tired of thick-client GUI development.
>> - 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).
This is perhaps the only disappointing news from your experiences.
> 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.
Ug. This would be disastrous to a clerk on a tight queue. In the very
least it looks like I may have to make Firefox a requirement as there
appear to be fewer push-here-to-explode opportunities.
>> - 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).
Would that be ReportLab perchance? Print solutions in Python seems to be
a scarce species. I've used ReportLab with mixed success. If you know of
another one to look at I'd sure be eager.
> 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.
Yes. Yes it does. Thanks.
Michael
Tim Chase
>> keys which are browser-specific (sometimes Alt+letter, sometimes
>> control+letter, or other combos).
>
> This is perhaps the only disappointing news from your experiences.
I've found this isn't quite so important as long as the form-flow
tab-order makes sense to the DE person.
>> 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.
>
> Ug. This would be disastrous to a clerk on a tight queue. In the very
> least it looks like I may have to make Firefox a requirement as there
> appear to be fewer push-here-to-explode opportunities.
The best way to prevent this is to make AJAX'y submissions in the
background as they work, basically writing the application
interface in JavaScript. It's an ugly job to code, but it can
help save page-fulls of lossage. FireFox has similar behavior
with control+W, but I believe if it's something you really want
to prevent, you can bind it to a NOP to prevent it from
occurring. I've not gone hacking FF configs/chrome to such a degree.
> Would that be ReportLab perchance? Print solutions in Python seems to be
> a scarce species. I've used ReportLab with mixed success. If you know of
> another one to look at I'd sure be eager.
A short dig in the c.p.l archives found the link I had seen:
http://wiki.wxpython.org/Printing
Again, that was for printing to a printer attached to the server,
rather than a printer attached to the web-client.
Another option is to send the direct PCL yourself. I've
hand-cranked printer drivers for a couple thermal printers (Zebra
and Oneil) that had some basic page-layout functions that I could
use. I just sent the printer-specific codes over the wire (IrDA,
BlueTooth serial-profile, or serial-port in case) for fast and
simple printing. If you just need a text dump that you can do
via simple escape codes, this isn't a bad way to go. A bit of a
pain to decipher printer manuals to get those codes...but
feasible. At least for those two printers, the PCL is pretty
straight-forward and well documented.
-tim
Jon Atkinson
> >> 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).
>
> This is perhaps the only disappointing news from your experiences.
>
> > 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.
>
> Ug. This would be disastrous to a clerk on a tight queue. In the very
> least it looks like I may have to make Firefox a requirement as there
> appear to be fewer push-here-to-explode opportunities.
Depending on how much control you have over your deployment, remember
that is it pretty much trivial to modify the Firefox XUL files which
define the keyboard shortcuts browser-wide. Turning off certain
shortcut combinations would take a few minutes at the most, once ou
knew where to look. Then just distribute the XUL files to the clients
(I think you do it via Firefox profiles, so you would have a profile
on each client called 'Data Entry' or similar).
--Jon
BALIBEY
Michael Hipp
Thanks, that's an excellent idea. And could be readily implemented only
for the stations that really need it.
Michael
Michael Hipp
>>> 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.
>> Ug. This would be disastrous to a clerk on a tight queue. In the very
>> least it looks like I may have to make Firefox a requirement as there
>> appear to be fewer push-here-to-explode opportunities.
>
> The best way to prevent this is to make AJAX'y submissions in the
> background as they work, basically writing the application
> interface in JavaScript. It's an ugly job to code, but it can
> help save page-fulls of lossage. FireFox has similar behavior
> with control+W, but I believe if it's something you really want
> to prevent, you can bind it to a NOP to prevent it from
> occurring. I've not gone hacking FF configs/chrome to such a degree.
That's probably way more JavaScript than I'm likely to do anytime soon
but it's good to know that such techniques can be made to work.
>> Would that be ReportLab perchance? Print solutions in Python seems to be
>> a scarce species. I've used ReportLab with mixed success. If you know of
>> another one to look at I'd sure be eager.
>
> A short dig in the c.p.l archives found the link I had seen:
>
> http://wiki.wxpython.org/Printing
>
> Again, that was for printing to a printer attached to the server,
> rather than a printer attached to the web-client.
Ok. I've done printing from the two methods described in wxPython. The
HTML variety is good for very simple cases but quickly runs out of power
even long before full HTML would. The full wxPrint is a bit like coding
in Assembler and has some bugs.
> Another option is to send the direct PCL yourself. I've
> hand-cranked printer drivers for a couple thermal printers (Zebra
> and Oneil) that had some basic page-layout functions that I could
> use. I just sent the printer-specific codes over the wire (IrDA,
> BlueTooth serial-profile, or serial-port in case) for fast and
> simple printing. If you just need a text dump that you can do
> via simple escape codes, this isn't a bad way to go. A bit of a
> pain to decipher printer manuals to get those codes...but
> feasible. At least for those two printers, the PCL is pretty
> straight-forward and well documented.
Yes. This is really easy for stuff like Zebra printers. Hadn't thought
of it for the bigger ones needing lots of PCL but it could be done
easily enough with a little work to abstract some of the basic drawing.
Thanks,
Michael
Tim Chase
> of it for the bigger ones needing lots of PCL but it could be done
> easily enough with a little work to abstract some of the basic drawing.
There are some other add-on Python libraries that, as long as
your printer supports PostScript, you can use them as your
rendering target. A couple that came up in a quick Google search:
http://pyx.sf.net
http://sping.sf.net
http://www.nongnu.org/pypsg/
I believe each of them has a way of outputting PS (or PDF or GIF
or PNG or other media formats), which can in turn be fired off to
the printer.
And since Django is just Python, anything you can do in Python,
you can do in Django.
-tim
(hoping to get his company to spring for PyCon again this year)