Designing A Point of Sales App
Volume Number: 13
Issue Number: 11
Column Tag: Custom Applications
Designing a Point of Sales Application
by Evan Trent
Finding the hardware and writing the software to set up a
Macintosh as a cash register
A Brief Introduction
"If this thing beeps again, I want you to throw it out the window," I remember one of
my mother's employees murmuring through his teeth. This was hardly the first
indication that the cash register system we were using was eventually going to be
replaced. Yet, I really hadn't expected that I would be responsible for creating the new
system.
A Unique Solution
I realized that several of the flaws inherent in a terminal-based cash register are
related to its such poor user interface. On other side of that spectrum lies the
Macintosh, providing a graphical user interface which enables even the novice user to
perform a variety of tasks with great ease. The Mac is the ultimate "idiot proof
machine, that was exactly what we needed: a system that could provide a simple user
interface but wouldn't let the user do something illogical. As I thought more about it, I
came to the conclusion that I could write a point-of-sales (POS) application for the
Macintosh that would provide all of the features we needed and at the same time make
use of the Macintosh GUI. It was to be a match made in custom application heaven.
A Journey Into POS
While the software I wrote is an essential element in the point-of-sales system we
currently use, MacTech readers certainly have little difficulty writing their own
software. What is arguably of more importance is the hardware, and I intend to discuss
the issues I encountered in dealing with the hardware in great depth. However, to
better understand how the hardware functions, it makes sense to discuss the software
design. As is the case with many applications, but especially in the case of a POS
application, of foremost importance is the user interface.
Designing the User Interface
While the user interface is fairly simple, it is exactly this simplicity which makes it
so flexible. We had previously been using a programmable keyboard with a Panasonic
5000 cash register system. You've probably seen similar systems in supermarkets or
cafeterias. To charge a customer for an item, the employee presses the button on the
keyboard corresponding to that item. Nearly all such systems then proceed by beeping
loudly for some unknown reason. (The customer doesn't think much of this, but the
employee is either going deaf, or insane, or both.) To prevent an awkward transition
from occurring between our old system and the new Macintosh based system, I decided
to place the programmable keyboard in a window on the Macintosh screen (Figure
1). This may seem odd, but it works very well for a variety of reasons.
Figure 1. The on-screen programmable keyboard.
The biggest advantage over the old "physical" programmable keyboard approach is the
increased ease of changing item attributes. No longer does the employee have to reprint
a keyboard template and tape it down. (This proved to be absolutely impossible on the
old system, because the little boxes on the template never properly overlapped the
buttons on the keyboard; don't ask me why.) The "virtual" (on-screen) programmable
keyboard is comprised of 100 square buttons, arranged in a 10x10 grid. Each row is
color coded to ease strain on the eyes when searching for a particular item. Typically
items are placed in rows with other items in their respective, colored subgroups
(sandwiches on one row, beverages on another) and thus the employee associates each
type of item with a color. This reduces the time it takes to find any given item on the
screen.
To the right of the on screen keyboard, there is a scrollable list. This list provides a
running queue of items in the pending sale. The first column contains the quantity of
the item, the second column contains the name of the item, and the third column
contains the net price of the item. This list proved to be the most applauded
enhancement over the old system.
Underneath the programmable keyboard there are two rows of buttons. The first
button, labeled "Void", removes an item from the queue, or if there is a quantity
greater than one of that item, it decreases the quantity by one. "Void Many" removes
the item from the queue regardless of quantity. "Void All" removes all items from the
queue. "Return", which is intended to be used when a customer brings back damaged or
lame goods, will negate the price of the selected item. "Tax" will tax an item, or
"untax" an item if it already has been taxed. "Drawer" simply opens the cash drawer.
"Print Receipt" will print a receipt for the last sale, even if it has already been
processed. The user can define which payment methods automatically print receipts
and which don't. For example, most customers don't want a receipt for cash or check
transactions, but do for credit cards. If the customer does want a receipt for a cash or
check transaction, the user simply can press the Print Receipt button. This saves a lot
of paper.
Underneath the queue of items, there is a running total, and underneath that is an edit
text box labeled "Quantity". This text field will only accept numbers, and will set the
quantity for the next item to that number it contains. For example, to add 99 Espressos
to the queue, the user would type 99 (which would be entered into the edit text field)
and then press the Espresso button. After an item is added to the queue the quantity text
field is automatically reset to 1 and the text is selected such that any number typed
will replace the 1. This proved to be an efficient method of entering multiple items
with a minimum of fuss.
Form Follows Function
There were several other employee interaction problems with the previous system,
but the most serious design flaws occurred within the managerial functions of the cash
register. To change an item's attributes, the employee had to retrieve the "manager's
key" and turn the register into "manager" mode. This also only could be done from one
register (the master register, as opposed to the other slave registers). From this
point on the English language ceased to exist. There were code numbers for everything.
Why is an employee (or manager) supposed to know that to add meals tax to an item, he
must set "Special Flag 2" to 0010? This was completely absurd. Our employees invest
their time in learning about food, not special code numbers. When items needed to be
changed, I was the only person who could change them, and it took forever because the
items had to be changed one at a time.
I disposed of the old approach to editing item attributes and decided upon a better
method. Because the employees were already familiar with the on screen keyboard,
why not have that be preserved throughout the editing mode? When the employee
selects "Change Item Attributes" from the "Register Functions" menu, a new dialog box
appears (Figure 2) presenting the on screen keyboard.
Figure 2. A similar interface is used for editing item attributes.
Where the item list used to be, there is a new set of dialog items accepting input for
the item's name, price, subgroup and other options. Three checkboxes are visible. The
first toggles the "open" status of an item. If an item is "open," it does not have an
assigned price, rather it asks for a price every time it is added to the queue. An
example of an "open" item is a cheese which is weighed on the scale. After the scale
prints a label, the user presses "Open Fromage" and types in the price which appears
on the label. If the "open" checkbox is checked, no item price may be entered. Likewise
if an item has a price and the user checks the "open" checkbox, the price is removed.
The old system allowed a price to exist even if an item was an "open" item. This created
a lot of confusion. Additionally, there are two checkboxes, one for sales tax and one for
meals tax. While an item can be taxed at any time, certain items always carry a tax
with them (sandwiches for example) and thus it saves time to pre-tax them. Any item
which has the meals or sales tax checkbox checked will automatically add the
appropriate tax to its price.
Changing an Item's Attributes
Changing an item's attributes is a trivial task. The employee clicks an item's button,
and then edits the content of each of the dialog items containing the appropriate
attributes. He can then click another item's button to go on changing that items'
attributes, or simply click the Okay button to save changes for that one item (or
Cancel to revert to the previous attributes). This allows items to be edited very
quickly, and in a batch manner. The user will always know what item he is editing
because the name of the item is displayed in the window's title bar. Thus if a user
changes an item's name and forgets which item he is editing, he can glance up at the
title bar. This proved to be very well received.
Let Me Speak to the Manager
Additional managerial functions were improved. Tracking, polling and report
generation were preserved but were executed in more logical manners. The production
staff wanted to check on how many sandwiches had been sold, for example, at 3:00 PM
without closing out for the day. The old system required a key and a slew of codes to
acquire this information. The new system made this simple. Closing out for the day on
the old system took an eternity because the system was printing all kinds of ridiculous
reports that were uninformative and essentially useless. About half of the reports
generated were of use to us. Those were the reports I carried over to the new system.
Additionally, new reports were added to the system. One such report was the price
range report, which breaks down the number of sales by total. For example, it might
inform us that ten sales were between $0 and $5 and fifty were between $5 and $10.
Other reports provide information on totals by item, subgroup, tax, and hour of the
day (as well as day of the month when closing out a month). The new system takes
about ten seconds to close (probably because it's PowerPC native) and for each day
saves a report in a file named after the date. The old system printed one report, and
that was it. You couldn't print it ever again.
Put That On My Tab
A feature we added from scratch was house accounts. We wanted the ability to run up a
tab for each of our regular customers, keeping track of what they had purchased. Here
we used the List Manager to list accounts in alphabetical order by last name. (Figure
3.)
Figure 3. This dialog lists house accounts in alphabetical order.
From the dialog shown in Figure 3, the user can "Add" a new account, or "Delete" or
"Modify" an existing account. Of course, the user cannot delete an account with an
outstanding balance. Clicking the "Print BTD" button will print a "Balance to Date
report, which contains a list of every item purchased in reverse chronological order
since the balance was last paid. Thus, a customer can at any time ask for their balance
and will receive a full statement. Clicking the "Pay Out" button will print two copies of
that statement, with the words "Balance Paid in Full" at the bottom. This serves as the
customer's proof of payment. The account balance is reset to $0.00 and the drawer
opens to accept payment. Clicking the "Done" button simply dismisses the dialog.