At your fingertips
History
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.
Guidelines
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.
Spreadsheet
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
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.
Implementation
Cells
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