[MuEta]

I've worked as a server and I thought this was going to focus on POS systems and how horribly they are (often) implemented. Talk about a design nightmare, with at least 5 clicks to put in one person's order (x2-4 for a typical table). And items were almost always in a random configuration with little reasoning for placement of, for instance, extra mayonnaise versus no lettuce. I'm not sure if the new mobile POS systems are any better, but I will never forget how bad restaurant POSs are when designing UIs.

[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.

[iolothebard]

I worked at restaurants with id based POS systems (pre touch screen, you just typed in numbers for every item).

Then the touch screens came out, so slow in comparison. The learning curve was faster but the operations were terrible in comparison.

I still remember Red Lobster POS codes from the 1990s. 2411, 2443, 901, ... Good times :-)

[wycx]

7" 4:3 monochrome CRT screens; membrane keyboard covers; 286 in a desktop case on its side on the floor, gummed up with spilled soda...

[toomanybeersies]

I currently work for a company that does iPad based SASS POS, and I'd like to think our app is a lot better than the old POS systems out there.

One of the problems you always have to deal with though, is that no matter how good the app is, the person programming in the menu can still be completely useless and make it annoying to use, so the challenge is to make programming in the menu as easy as possible.

Being iPad based means that we can actually utilise touch-screen actions, e.g. you can swipe items into a tab, rather than having to tap the item, and then tap again and tap some more, like you're describing.

[wallyhs]

We use an iPad based SASS POS, and editing the menu is a pain. Every time I start to edit something, I have to wait 60 seconds while it pulls in the list of every item on the menu. If I want to edit five specific menu items, I don't want to wait for the entire list of items to load five times. Updating prices or costs on our menu literally takes three of us an entire day to pull off. We've been meaning to clean out some discontinued items from the menu, but... that would take three of us an entire day to do.

We do retail alcohol in addition to restaurant food, so we have a lot of items on our menu. I don't like how the menu is organized, but it would be too slow and painful to reorganize at this point.

I would kill for an API so that I could make mass numbers of menu edits by script. I would require some sort of a testing environment for that, though.

[btbuildem]

They're called POS for a reason..

[will_pseudonym]

If you want to know if it's better, use apps like Postmates or Starbucks to order food. It's slightly better, but there's so far to go.

[roymurdock]

Why hasn't the POS problem been solved yet? I'm assuming there's either some blindingly complex/simple reason because it's a large problem that frustrates a lot of people.

[dikaiosune]

In my (limited and anecdotal) experience, many people who have the purchasing power for these systems just go with something that their payment processor recommends (or sells themselves). They see it as a cost rather than as an opportunity for efficiency (read: more money).

There's also this kind of "blood sweat and tears" attitude with a lot of food service management, and so things they see as conveniences are a sign of weakness.

There's also the fact that switching POS/ordering systems requires re-entering the entire menu and all options, and it's often management who's expected to do that.

All of these things (again, in my observations) add up to a much smaller actual market for selling such devices than one might think at first blush.

[will_pseudonym]

I've viewed it in the same light as all other enterprise software development & purchases--neither the developers nor purchasers of POS software are going to be using it, so bad things are built and bought, with some exceptions. It just takes a long time for the tide to change in the industry.

[toomanybeersies]

There are good solutions out there. I'm currently working for a startup that's doing iPad based POS.

Without trying to toot our horn, it's a lot better than any of the legacy systems out there.

So no, there ins't really a reason why there isn't a solution except that nobody has made one yet (except for us and a couple of other tablet based POS systems).

[MuEta]

I don't know if this is kosher or not on HN (still relatively new to posting here), but what is your startup? I think that would be a space I am interested in and would love to learn more.

[will_pseudonym]

FYI, the green usernames are brand new, usually because they wanted to talk pseudononymously about stuff.

[dawnbreez]

Their system is, most likely, running on Win 98. Their servers were built pre-9/11. The cat5 was laid before wifi existed.

It's a massive cost to upgrade, because they'd have to upgrade everything.

[vitd]

This is my experience, having worked in POS systems for a few years. The customers - especially huge ones like Walmart, Target, USPS - buy these systems on the order of once every 10-20 years for any given store. They don't want to upgrade them because they're expensive. Also, the companies that make the traditional ones were not very innovative when I worked there (20 years ago). Windows 98 had shipped and they were still using DOS on new systems.