|Re: New HP-35s ranking|
Message #21 Posted by Howard Owen on 4 June 2007, 9:23 p.m.,
in response to message #20 by DaveJ
That's not an excuse, it is just lazy engineering that makes them larger, and/or lack of a specification to keep it small.
I hear what you are saying, but I disagree, in part.
The HP Journal article than introduced the 41C began with a discussion about the problem of proliferating functions. The then current top-of-the line pocket calculator was the HP-67. That machine has quite a "busy" keyboard, with two shift keys, and labels on the key top, key face and keyboard background. The problem was that each function had to be accessible via simple combinations of keystrokes - there was no menu capability for less frequently used functions.
But that isn't what the HP engineers came up with for a solution on the HP-41C. Instead, they used the alphanumeric capability to invoke functions by spelling out their names. This allowed them to greatly expand the CATalog of functions. One problem with this approach was that each decision made about which function to leave on the keyboard , and which to relegate to the CATalog was likely to annoy somebody. However, they apparently were aware of this problem, because they implemented a completely redefineable keyboard. This allowed users to get around the annoyance by defining their own set of trade offs between completeness and keyboard accessibility. (I know that USER mode on the 41 had other reasons to exist besides this.) I remember that despite nice features like programmatic redefinition of the keys , which became fully general with synthetic programming, and later with the CX and Xfunctions module, it was still a hassle for me to juggle between different keyboard modes with the various ROM modules and programs I had written. But I was grateful on balance for the rich feature set, and accepted the hassle as an inevitable consequence of that abundance.
With the 42S, having a two line display, HP moved to using menus with redefineable soft keys. This was more convenient because it grouped related functions together under a single menu key. This made the functions more "discoverable," and less a matter of wading through a long CATalog listing (or six!) to find that obscure function you had forgotten the name of.
But of course, things didn't stop with the 42s. The high end calculator line moved on to the 28c, with its double keyboard allowing even more functions on the keyboard combined with menus. The feature set continued to explode through the 48s, 48g, 49g and 49g+ machines, with each nw machine offering expanded feature sets, and a new take on how to access all that functionality. The current top of the line is the HP-50g. This machine has added hardly any features to those offered by the 49g+, but it hardly needed to. Between the Metakernal and the CAS, the machine has an enormous vocabulary of built in words.
It's interesting to compare the 50g side by side with the 67, to see how the keyboard has come full circle since 1979. The 50g is much larger, of course. it's something under an inch taller than the 67, but most of that comes from the comparatively huge display. The keyboards of the two machines are actually about the same height. The Y axis height of the keys and their spacings on the 50g are less, on average, than those on the 67, so the former squeezes in 10 rows where the latter has only 8. Remarkably, the calculators are about the same width. But the same factors that pack the vertical dimension are also at work in the horizontal, allowing for an extra column on the 50g as compared to the 67. But then the 50g adds cursor keys (and makes very good use of them throughout the implementation, btw) which subtracts from the number of columns in the upper half. But in total, the 50g sports 51 keys while the 67 has 35, just like its progenitor, the HP-35. So much for the differences. On the similarity side, both calculators have two shift keys, and both crowd an enormous number of functions into the available space. But the 50g adds the alpha key as a third shift key. For that reason, and because there are more keys, and their labels are smaller and closer together to fit, the 50g's keyboard looks a lot more cluttered than the 67s. One last difference: the 50g has tons of menus, too.
The menu implementation on the 50g is pretty good. It provides soft labels that can be left or right shifted, providing three functions per soft key. With the addition of KeyMan, you can also assign long hold and double press actions to any key, including a soft key. Speaking of redefining keys, the 50g, like the 48 and 49s before it, has a completely redefineable keyboard like the 41C had. So your options for accessing the mind bogglingly large feature set of the HP-50g combines bright ideas from practically the entire heritage of HP calculators - and boy, do you need them!
Let's see. I want to debug this user RPL program I'm working on. I have the code saved to a soft key in the VAR menu. So first, I set up the stack with my input parameters, Then I hit:
VAR ' A LSHIFT EVAL UP ENTER A B B B
That translates to "Go to the VAR menu, (VAR) hit the single quote key (') which actually enters two single quotes and leaves your cursor sitting between them. Hit the first soft key (A). Ordinarily, pressing A when in the VAR menu would execute the function assigned to that key. But since I'm between those single quotes, the name of the function gets entered instead. So now I go to the PRG menu (LSHIFT EVAL) where I select the DEBUG entry (UP). DEBUG is the last entry in the PRG menu, so UP wraps around and selects it in the list box) Now pressing ENTER activates the DEBUG menu. Now I press the DEBUG soft key (A) and the debugger starts. It uses the program name on level one (X for us RPN types) as input, so that's the program I'm now debugging. I can now single step (SST - the B soft key) and try to figure out what's not working.
So that is complicated. Of course, I've memorized the sequence, so it takes much more time to describe than to actually perform it. But the calculator has hundreds upon hundreds of such sequences. If I have to do something I don't have memorized, it's likely to take me a while to get to the actual thing I need. This is the main drawback of a menu system traversing a tree hierarchy. You can only see the local structure, so its hard to navigate to separated parts of the tree. You run into the same problems with a windowing file manager, but since there is lots of screen real estate on a PC, you can get more of the global view. On Unix, I just use find.
So this started out as a partial refutation of the idea that complexity in a calculator interface is due just to laziness on the part of the designers. I think that far from being lazy, those designers are straining mightily to balance usability with the demands of the specs they are given for features on the calculator. I think that these two items have an inverse relationship to one another, and that the genius of HP over the years has been to find ways to fudge the balance. I think that result is less than ideal*, as my example above should show, but I think it may be nearly optimal in a real device. I, for one, am not willing to give up features in a high end machine like the 50g in order to improve the balance.
On a machine that doesn't aspire to be the "all singing, all dancing" top-of-the-line mega-calculator, I don't mind dropping features to achieve a better balance with usability. But the laughing devil in the details is this: my optimal compromise doesn't match yours. This is the conundrum that makes those "lazy" designers work overtime.
* I've written elsewhere that I would prefer a brainwave connection as my ideal interface to a computing device. for me, this is ideal, but not optimal, since such a thing doesn't exist - yet. 8)