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.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.
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.
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 :-)
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.
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.
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.
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).
It's a massive cost to upgrade, because they'd have to upgrade everything.