On Jul 24, 10:00 pm, Zoubidoo <Stanc...@gmail .comwrote:
On Jul 24, 3:30 pm, slebetman <slebet...@gmai l.comwrote:
On Jul 24, 6:11 pm, Zoubidoo <Stanc...@gmail .comwrote:
Many applications require a high-speed interface such as supermarket
checkouts, busy points of sale, doctors' surgeries etc. The problem
with graphical interfaces is that they are too slow for this kind of
environment. Imagine a web interface at the supermarket checkout -
just not viable.
<snip>
A text-based interface would allow all those point-of-sale
applications to become web-applications.
Actually, a lot of newer POS systems have moved away from keyboards to
purely graphical touch screens. Like the POS systems used by Pizza Hut
and Starbucks for example.
That's true.
Such interfaces are perfectly doable as a
web interface. But even when you can't use touch screens, you can
still use keypress events to trigger actions - just clearly label the
on-screen buttons so that the user knows what key to press to activate
what button.
Do you know of any web-based examples?
I'm hitting sites like thishttp://www.merchantos. com/merchantos_com_ demo.php
which would be totally unworkable for busy environments.
I just had a look at merchantOs and found it to be quite fast -- once
you have all the images loaded. Also, I found that a lot of actions
trigger full screen refresh. For big actions like inventory queries
that may be acceptable but for small and common actions like entering
items or committing a transaction could be done with ajax to avoid
full screen refresh. If you do decide to go with a web based solution
for high throughput POS here's my suggestions:
1. Don't use images (the one exception is the store/company logo if
necessary). Instead go old-school with the layout/design and implement
it using large buttons/divs. This is a POS system after all, remind
the customer that the web app is not trying to be the next flickr or
facebook or yahoo. Emulate curses interfaces without emulating curses
itself which would be terribly slow and have much higher overhead than
plain and simple html.
2. This is a POS system so presumably you have full control what
browser the client will use to run it. So there's no excuse not to use
AJAX, especially for smaller transactions. The difference between
local DOM manipulation and full page refresh can be in the range of a
couple hundred milliseconds. Normally for a web app this is acceptable
but in your environment the difference would be noticeable.
3. If you are brave & competent enough implement smaller calculations
like totals in javascript on the front end to minimise communication
with the server.
4. It may not be worth implementing this as a web app. The only places
I've seen graphical POS being successfull are restaurants - which are
inherently not high-throughput. Supermarkets tend to stick to text
based HP, Siemens or IBM terminals for the reason you stated: high-
throughput sites need high speed POS.
