[jasim]

On Keyboard Centricity: POS system in DOS.

      1. C:\> a                                    {enter}
      (a.bat starts c:\pos\pos.exe)
      
      2. Pull-down menu: Transactions -> Sales     {enter}
      (Sales is the default selection)

      3. Bill no: <last + 1>                       {enter}
      (new id starts a new bill)

      4. Item code: <4823>                         {4-digits+enter}
      5. Quantity: <2>                             {2-digits+enter}

      6. Item code: <blank>                        {enter}
      (just one item; give blank to exit)

      7. Menu: [Print, Next Bill]                  {enter}
      (Print is default selection)

      (loops back to 4, keying in a new bill)
    

Without a barcode scanner, a keyboard-centric interface takes the minimum possible number of keystrokes for a POS system. This efficiency was the norm in DOS-based text-centric systems, but with today's GUI interfaces, developers have to put extra effort to make things keyboard friendly. This is not done well enough in many cases, and is an instance of how the forced-advancement of technology makes things worse.

[coldcode]

(4) understates the problem, the user is required to memorize 4823 items without having a way to find the item they are looking for. If you try to solve the memory issue, the system must become more complex.

[jasim]

It does. The way it works is you can either type in the item-code if you know it, or you can type in search letters which will prompt a browse screen (which is again highly keyboard-friendly).

The way it happens in places with low number of SKUs (< 10k) is people who're new typically search a lot in the beginning, but over time, they'll learn the most frequently used item-codes without any deliberate learning. They also get really fast at the keyboard. This was my experience building DOS-based POS software for small supermarkets and grocery stores.

If there are a much larger number of SKUs, or if the item-codes are provided by the manufacturer (like in the automobile spare parts business with 16-digit alphanumeric item-codes), you have to key in them manually.

A paint store I built software for had a huge number of SKUs, but they were renowned for their customer experience. This was made possible by putting new employees through a training whose qualifying test is to key-in a bill of materials at a really fast pace. They also chunked item codes into well-defined easily-learnable categories. This was the grouping: [Manufacturer, Product, Packing, Color, Code]. There would be < 20 manufacturers, of which only 4 or 5 are frequently used. Same for product. Packing and Color were more of attributes, but were easily learnable and helped uniquely identify a product.

[asmdb]

I used to work at a very busy pub/pizzeria. Customers could order from the standard menu of about 45 items, order a modified standard menu pizza, or they could completely build their own custom pizza. Custom pizzas could be half and half, and have almost any number of sauce, crust, or topping choices. There were at least 75 toppings/sauces to choose from, in addition to the rotating ingredients every two weeks. I can't say that I loved the touch-screen POS system utilized by this restaurant, but the GUI it provided was designed specifically for pizzerias.

I am having trouble imagining how a keyboard-centric interface would require less key strokes than the number of screen-taps for a POS system designed for a pizzeria. For instance, to add or remove a single ingredient to a pizza in the touch-screen POS system it required a single tap. In a keyboard-centric POS system, assuming the ingredients are identified by id starting at 1 through 75, most ingredients would require two keystrokes plus the enter key. My personal experience leads me to believe that specialized touch-screen POS systems certainly work well for some of the more complex restaurant menus.