At your fingertips


There are two features that define a classic hand held calculator. One is a small display capable of displaying one (very rarely more than one) number. Second is a more or less rectangular panel of buttons which lets user enter numbers and execute functions. That was a hardware available at the time and the user interface and operating system desing was driven by this available hardware.

Modern Android calculator apps follow this same pattern: they dedicate fixed portion of a screen to numeric display and the rest to fixed on-screen keyboard.

Following this tradition grossly underuses UI abilities granted by touch screen and results in products that are not as efficient problem solvers as they could have been.


The following is a set of statements I believe are true. To save space, I am not writing caveat "in my opinion" before every such statement, but it is strongly implied. I would like to design a hand held calculating device based on the outlined principles and see if it actually makes it better then classic.


The notion of spreadsheet is among the most important inventions of computer industry. It put the ability to perform calculations of unfathomable complexity in the hands of normal people (that is, people who are not programmers). The hand-held calculating device should use a spreadsheet as its main mechanism of presenting data.

More structured form of a spreadsheet -- fixed width table with named columns -- can be used as an element of relational model, or simply as an easily lookuppable reference data storage.

Keyboard vs menus

Some sort of virtual keyboard seems to be inevitable. There is simply no better way of entering numbers then touching well defined and labeled spots on a screen with a finger. However, there is no reason the virtual keyboard has to remain fixed all the time and there is no reason it should always be a rectangular-ish array of rectangular buttons.

Classic calculators usually have one or more "shift" keys -- pressing such keys temporary redefines the rest of the keyboard to have different meaning. This alternative meaning is eather spelled on each button with alternative color, or sometimes is implied and it is up to a user to memorize this meaning.

In this situations the shift key acts as a menu invocator and the rest of the keyboard as menu items. Touchscreen keyboard should simply present menu elements as such. Furthermore, the menu items do not have to be simple rectangles in a grid. They may be arranged in a way that is mnemonic to a menu function and accompanied by notes and diagrams to assist with recollection.


Programming should not be required to successfully use a calculator to solve many meaningful problems. But if user chooses to program, programming environment should be adapted to the realities of a handheld device.

If a terminal (fullsize keyboard+large user facing screen) is available, then the best way to program is to use a programming language and compose a program as a set of text files. This conjecture is supported by the fact that numerous systems of so called "graphic programming" are not doing so well and occupy only marginal niches in programming industry, despite decades of hype and aggressive marketing by their vendors.

Handheld device presents different challenges. Typing long text is easy on a full size keyboard, but hard on a handheld virtual keyboard. Different approaches involving elements of "graphic programming" may be tried to reduce typing. This includes drag-and-drop, selecting blocks from menus, representing control flow or data flow as a directed graph, etc.

I believe that ability to program on-device (as opposed to programming in a desktop environment and then uploading complete "applet" to a caclulator) significantly improves its capacity as a problem solving tool.



Spreadsheet cells may hold number, text of formula. Selecting a cell activates numeric keyboard, text keyboard or formula editor respectively.

Numeric cells and numeric keyboard

When activated, numeric cell and its value becomes rX of an RPN calculator. The rest of the stack is intrinsic to OS and follows the keyboard to whatever cell it is attached to. The keyboard provides facilites for number entry, basic arithmetic, stack manipulation and one or more menu buttons to access advanced functions and extensions. RCL and STO commands allow data exchange with other cells or with named variables.

When user leaves the cell, the current value of rX becomes the new value of the cell. At this point the cell is considered "updated" which triggers dependent recalculation if any.

Here is where I've got so far with these ideas. The following is a prototype intended to run in chrome on a smartphone.

Handheld RPN spreadsheet prototype