Layouts again (a bit long - special regards to KS)



#29

Hi all,

In an earlier thread in June we saw Karl's very thorough explanation of HP15C's keyboard layout. He recommended to study this layout before posting any new proposals for advanced calculators. Since then I did this (just for fun, of course), and now I want to share my results with you.

My target was to design a surface integrating the best calculators I know so far, i.e. HP15C, 16C, and 42S, plus some features of 21S and 32SII. At the same time, some of today's technology should be reflected (e.g. better LCD resolution, more memory).

On any calc, there are certain constraints, most of them being pretty basic: For example, you want to see a compact number block, a column of elementary arithmetic functions, etc. It is convenient to find operations you already know from previous models. IMO as many functions as possible shall be visible immediately, the other ones must be put in menus.

Taking a Voyager keyboard and placing functions of 15C, 42S, and some of 32sii on it, I end up with this
”basic” calculator layout.

Taking the SAME keyboard and placing the functions of 16C, my result is
this “integer” layout.

Merging both and filling the remaining space with further (IMHO) useful operations, grouped in a reasonable way, leads me to this Landscape result.

This includes 8 keys which may be used as soft keys. Most labels are self explanatory (hopefully ;) ), since a detailed explanation of all of them would exceed the space available here.

Of course, one can make a similar attempt for a Pioneer-like layout (plus 6 soft keys). Transferring as many labels as possible to create a consistent pair of calculators, I end up with
this Portrait result.

Any comments, questions, proposals, or advises are most welcome :)(also if you know how to embed the pictures directly in this post - I forgot how I did it last time, and I don't bring the standard codes of my image hosting site to work here :( ).


#30

Hi Walter,

Very interesting. I like the three line display with menus in the Landscape Layout. You don't say whether the menu is only active at certain times or not. If so, then I'm guessing a 4-line display would be the norm - unless menu is active.

The problem with designing keyboard layouts, is that a lot depends on the ultimate user and how he makes use of the calculator. For example, I would make use of the Trig fuctions a lot and would want them as primary key functions. A person working in Stats would want the Stat functions as primary, and so it goes.

I notice a little inconsistentancy on your use of the F & G second function keys. For example, LOG uses the G key while SIN uses the F key. I think I understand what you are doing here - The F key is used where there are two logical complementary functions - SIN versus Inverse Sin. The problem I see is that during use, I would be constantly switching from F to G for similar primary second key functions. (F LOG then G SIN then G PI then F COS, etc). I think that this isn't very intutitive.


Quote:
IMO as many functions as possible shall be visible immediately, the other ones must be put in menus.

I'm afraid I have to disagree with this. This would lead to extremely "BUSY" keyboards, which is my main complaint with the current crop of calculators. I much perfer uncluttered keyboards - but the keys that are there must include a majority of the fuctions I do on a daily basis. (Of couse, what I use is not necessary what someone else uses).

This leads me back to Keyboard Layouts are largely determined by the proposed use of the calculator. Current calculators seem to have merged into a single calculator that can do all for all people leading very busy layouts.

I think that's why HP originally had so many different calculator models - each tailored to a specific field of work. Of couse, anyone working in multiple fields always ended up wishing "if only it had this additional function then it would be perfect".


Thanks for posting your layouts. I always enjoy the various layouts that have been posted. It always amazes me at the great quality that they have.

Thanks,

Bill

#31

I think you also took at least one design element from the HP-67: You placed the secondary-function labels below the corresponding keys. This always bothers me if I switch from a recent calc to the HP-67, but you also get used to that very fast.

Thank you for sharing your ideas!

#32

Maybe refer to 41c opt 001 , without any primary or secondary function ,all function key defined by user , as user convenience

Edited: 17 Aug 2006, 11:42 a.m.

#33

Numbers as soft menu keys may be problematic, since many soft menu key functions act on numbers. I made that mistake when creating my Voyager 42C Free42 skin for my PDA:

I cannot enter '7' with this menu up. The fix for my PDA was to bind ALT-1 - ALT-6 for the functions, but on a real calculator this will be a problem. HP had a similar problem with the 42S, hence the TOP.FCN menu. If a menu is up and you do not want to exit it and you need one of the functions tied to a menu key you need to use TOP.FCN. Not too bad for a few functions, but it would be inconvenience to call TOP.FCN to get the number 7. Perhaps your "MNU" keys solves this problem?

I like busy keyboards, less menus to use. I also like to see all "core" functions on the keys and not on the faceplate. This opens up the possibility for overlays for other applications without losing core calculator capability. IMHO, two functions on key needs to be revived.

I am used to having additional functions above the keys, not below. But the alpha below is nice.


#34

Can you give me some ideas how to create such a skin? It would be a good way to test some alternatives. Where's the interface to Thomas's Free42? I'm just a small user of Bill's software so far, but I may install Linux in a separate partition *if required*.

Edited: 21 Aug 2006, 2:21 a.m.


#35

The Free42 skin description format is described in free42/skins/README.txt, in the Free42 source package (which you can download from my web site).

You don't need Linux to tinker with Free42 skins; the Windows version uses the same format, with one exception: when defining skin-specific key bindings, the Windows version requires the keys to be specified using Windows numeric key codes, while the Unix versions use X11 keysyms for that purpose. Egan's 42ck and 42ct skins contain key mappings for j, p, u, and alt-1 to alt-6; these mappings are defined using X11 keysyms (or GDK keysyms, which amounts to the same thing), so those would have to be changed in order for them to work on Windows.


Feel free to contact me directly if you need help with this.

- Thomas

#36

Nice.

The main issue for me is the awkward alpha input on the 42S. I would prefer to have alpha letters on the keys like on the 41.

#37

Nice effort. I agree with you that as many functions as possible should be visible on the keyboard. This may somewhat clutter things, but I think its faster than scrolling through menus.

#38

Nice mostly. In fact I quite like it. It would be nice to have the trig functions unshifted, but there isn't any currently unshifted function I'd want to lose, let along three of them.


A couple of minor issues, nothing too serious though.

How to access the hyperbolic functions? Is the h-HYP a menu or a prefix for SIN/COS/TAN? I guess it must be a menu.

The integer "and/or/xor" key took me a bit by surrpise. ^ is the C operator for xor and it didn't click right away that this was the "and" operation. Does this mean no power operator when in integer mode? I know the 16c doesn't have this operation, but that doesn't mean it isn't useful for integers. Also no "not" operator on the keyboard which is at least as important as and/or/xor. Since there isn't space for all of these, why not drop them into a menu and put some other useful function here "x-th root of y" maybe (no saved keystroke over 1/x y^x so maybe not).

I also don't like the location of the "E" key in integer mode but I also don't see a way around it.


- Pauli


#39

Thanks to all of you for your feedback so far!

Obviously not everything was self explanatory, so please let me confirm and clarify:

  • Orange operations are menus (except ClearSigma).
  • The LCD shows 4 lines unless a menu is displayed (taking the lowest line). You were guessing right, Bill.
  • If a menu is displayed, MNU will hide the menu line, thus regaining the 4th data line and the default primary functions (DPF) of all menu keys, where applicable. To return to the menu, just press MNU again.
  • G-shifted functions invert f-shifted functions, where applicable (e.g. Trig, conversions). For the menu keys, I used g-shift only. Thus, you may access their DPF via f-shift. Together with MNU this may be belt and braces, but f-shifting saves one keystroke.
  • y^x becomes AND in Integer mode. Correct, Paul. In algebra, BTW, "v" stands for OR (from Latin “vel”= or), so “the opposite sign” represents AND, and XOR is "v" with "!" on top of it.
  • x-1 becomes NOT in Integer mode.
  • H-shifted functions are printed *below* of the keys because of 2 reasons: a) You’ll find each shifted function (f-, g- and h-) below of the DPF; b) Most people operate a calc looking to the keyboard from “below” at an angle of 60 to 80 degrees – so the keys will not hide parts of the orange print.
  • Yes, a Voyager has only 39 keys! ;) You may, however, assign your favourite functions to each and every orange operation and you may reassign any predefined menu element - only CAT and CLEAR are "tabu".

If I forgot to respond to a particular point, please remind me. I am looking forward to more comments etc.

Edited: 18 Aug 2006, 3:40 p.m.

#40

Walter --

Thank you for the acknowledgement and link to archived thread.

I see a number of good ideas in your concepts. The layouts don't quite measure up to the exquisite HP-15C's masterful one, but then again, nothing could... ;-)

The HP models with three shift keys (e.g., HP-34C and HP-67) and 7-segment displays put the yellow and blue side-by-side above (34) or below (67) the key, and the black on the lower beveled part of the key. Your concepts must consider the menus, of course...

-- KS


#41

Quote:
The layouts don't quite measure up to the exquisite HP-15C's masterful one, but then again, nothing could... ;-)

I hope you're kidding :-). The 15c has a very good layout but it is by no means perfect.

Why is x<> where it is? The other register operating keys (STO & RCL) are miles away. It also wouldn't be too hard to argue that ISG & DSE should be closer to STO & RCL since they are register based commands in addition to being conditionals.

In your earlier article you mention that ABS's placement is a carry over from the 12c. If this is true, then it is simply out of place. However, I think that ABS and CHS are sufficiently related to justify the placement chosen.

Why does the 15c's TEST insturction take a 0-9 argument? I would have thought taking 0-5 & .0-.5 would make more sense, be easier to remember and it would free up two other keyboard locations.

If you swap X<> and RND, swap DSE and INT and swap ISG and FRAC the register based commands are now located together; X<> is on the same key as X<>Y and INT, FRAC, RND and ABS are also fairly close together.

Of course I love my 15c just the way it is.


On rereading this it has a bit nastier tone than I intended ... sorry if this causes offense, none is intended.


- Pauli


#42

Thank for sharing your ideas with us, the concepts are very nice.

Of course it depends on the end user, but I do think that the LN/LOG functions should be less useful than SIN/COS/TAN. They shouldn't deserve 2 primary keys on your final portrait layout.
Besides, many keys in the upper half have no F- or G- functions.
If you choose to devote 3 keys for F- G- H-, then all keys should have 4 functions (unshifted+3 shifted).

Regarding alpha mode, do you mean that you need to press the D soft key 6 times to get an "R". If I enter a long message, I will end up with a finger stutter and I will kill all my soft keys...

Last, I don't see the square function. Is it hidden somewhere? (e.g. F-square root).


#43

Hi Bruno,

thanks for your kind response. The alpha mode is far easier than you guessed:

To reach "R" you press the D soft key (SK) once (bringing up a menu line "M N O P Q R") and then the F SK. So 2 keystrokes only to reach *any* letter :) All the best for your finger and the SK! Not every keyboard must work like the one of a cell phone ;)

For the Trig placement please see my earlier explanations in this thread. The portrait calc has only 37 keys (plus SK). OK, I "wasted" a bit because I didn't assign 4 functions to every key. But I did this for the benefit of functions grouping (see Karl's post in the thread I quoted in my first post) and clarity.

Nevertheless, I admit I like the landscape design more: there you need just 1 keystroke for a letter, and there are 2 keys more, allowing e.g. an unshifted x^2. IMHO, a shifted x^2 does make little sense, because ENTER * will do the same with 2 keystrokes as well. And I assumed my calcs featuring a settable fixed stack depth of up to 16 levels - which you couldn't know, of course ;)


#44

Quote:
The alpha mode is far easier than you guessed:

To reach "R" you press the D soft key (SK) once (bringing up a menu line "M N O P Q R") and then the F SK. So 2 keystrokes only to reach *any* letter :) All the best for your finger and the SK! Not every keyboard must work like the one of a cell phone ;)


That is definitely a very good idea! My God, I need a brain wash...

Quote:
Nevertheless, I admit I like the landscape design more: there you need just 1 keystroke for a letter, and there are 2 keys more, allowing e.g. an unshifted x^2. IMHO, a shifted x^2 does make little sense, because ENTER * will do the same with 2 keystrokes as well.

Yes, but ENTER * clears the last element is the stack, requires 2 programming steps instead of one, and is less clear when reviewing the programs. But if it saves one key, it's largely worth it.

Quote:
And I assumed my calcs featuring a settable fixed stack depth of up to 16 levels - which you couldn't know, of course ;)

This is a killer feature. 4 level stack is really what prevents me from using my 33s more. I so often end up with grabbing my 28s although I fear it is stolen...


#45

Quote: 1: Nevertheless, I admit I like the landscape design more: there you need just 1 keystroke for a letter, and there are 2 keys more, allowing e.g. an unshifted x^2. IMHO, a shifted x^2 does make little sense, because ENTER * will do the same with 2 keystrokes as well.

Quote 2: Yes, but ENTER * clears the last element is the stack, requires 2 programming steps instead of one, and is less clear when reviewing the programs. But if it saves one key, it's largely worth it.

Gene: What is important is that X^2 not be a shifted function. If a location on the keyboard is to be used for X^2 on an RPN machine, it needs to be a primary key or you really don't save much with x^2 on the keyboard. On an algebraic machine, it makes much less difference, FWIW.

#46

Hello, Paul --

My original statement in this thread:

Quote:

The layouts don't quite measure up to the exquisite HP-15C's masterful one, but then again, nothing could...

Your opening and closing responses:

Quote:
I hope you're kidding :-). The 15c has a very good layout but it is by no means perfect.

On rereading this it has a bit nastier tone than I intended ... sorry if this causes offense, none is intended.


No offense taken, but that won't stop me from addressing your comments. I ain't kidding -- of course I believe that near-perfection was achieved in the HP-15C keyboard layout! :-)

Quote:
Why is x<> where it is? The other register operating keys (STO & RCL) are miles away.

What's important is that x<> is used in conjunction with 0-9, .0-.9, I and (i), and A-E -- and most likely 0-9, I, or (i), which are nearby. STO and RCL require one of the same storage identifiers for completion, but are also used repeatedly in conjunction with A-E for matrix work.

Quote:
It also wouldn't be too hard to argue that ISG & DSE should be closer to STO & RCL since they are register based commands in addition to being conditionals.

I don't quite follow your logic. Sure, DSE, ISG, STO, and RCL are usually completed with a register number, but that doesn't make them a functional "family" that should be organized in a grouped location. DSE and ISG are shifted and seldom used; they should be placed where space allows. As program-control commands, they are actually more similar in function to the nearby SF, CF, F?, and the conditional-test functions.


Quote:
In your earlier article you mention that ABS's placement is a carry over from the 12c. If this is true, then it is simply out of place. However, I think that ABS and CHS are sufficiently related to justify the placement chosen.

Actually, it was the HP-11C (as stated in my post). ABS and MEM could be swapped to establish the functional grouping of "Scalar Parts and Values", but most users invoke MEM more than ABS, so keeping MEM closer to its shift key is better. CHS and ABS are functionally related, but ABS is useful only in programs and for taking the magnitude of a complex number. (Also, keeping CHS/ABS the same for the HP-15C allowed HP to use the same key for both the HP-11C and HP-15C.)

Quote:
Why does the 15c's TEST insturction take a 0-9 argument? I would have thought taking 0-5 & .0-.5 would make more sense, be easier to remember and it would free up two other keyboard locations.

Hmm, that's an idea to consider. I wouldn't say that using .0-.5 but not 6-9 is more intuitive, but here's the real problem: How would the codes .0-.5 be shown in the table on the back plate? If the codes aren't printed there, then the manual must be consulted.

Quote:
If you swap X<> and RND, swap DSE and INT and swap ISG and FRAC the register based commands are now located together; X<> is on the same key as X<>Y and INT, FRAC, RND and ABS are also fairly close together.

Yes indeed, but I'll stand by my responses above. True functional grouping is beneficial, but what is even more important are the following:

  1. Making the frequently-used functions more easily accessible by having them unshifted or close to the shift keys.
  2. Placing a function close to the keys that are used in order to complete the command.

x<>y and x<> are related, but different in several respects: x<>y is a frequently-used, complete one-stroke command. x<> is less commonly used and needs a register or matrix identifier to complete it.

INT, FRAC, and RND are useful for computational purposes and benefit from placement close to the shift keys. DSE and ISG are not very useful for interactive computations (but can be used to decrement or increment a stored value without disturbing the stack).

DSE and ISG are intended as programming functions; STO and RCL are data-access functions. They both utilize storage registers, but there the similarity ends.

So, in summary, I too like my HP-15C as it is. Certain things could have been done a little better (and I've posted elsewhere in the Forum about them), but the fixes would have entailed some cost in additional ROM space or less-consistent structure.

Best regards,

-- KS



Edited: 19 Aug 2006, 11:55 p.m.


#47

Quote:
Hmm, that's an idea to consider. I wouldn't say that using .0-.5 but not 6-9 is more intuitive, but here's the real problem: How would the codes .0-.5 be shown in the table on the back plate? If the codes aren't printed there, then the manual must be consulted.

I didn't explain things clearly enough. My intention here was for the 0-5 to be the tests x vs 0 and .0-.5 to be the tests x vs y. In either case, the ordering of the actual tests would be the same. For example, if x=0? is test 0 then x=y? is test .0 and so forth. This would require less space on the back panel to list than the 15c currently dedicates to the task.


- Pauli

#48

Quote:
Making the frequently-used functions more easily accessible by having them unshifted or close to the shift keys. (Emphasis mine -- ThO)

For hand-held use, some people prefer holding Voyager-style calcs in both hands, using both thumbs to type. For those users, placing frequently-used shifted functions close to the shift keys is not all that convenient; placing them on the right-hand side of the keyboard would be better.

For one-handed hand-held use, the Voyager layout sucks anyway, but that's a holy war in its own right. ;-)

- Thomas

#49

Here you see the comparison .
No further comment.

Edited: 21 Aug 2006, 2:01 a.m.

#50

Karl,

thanks for your kind response. I know I'll never reach HP15C-quality in your eyes, so I try to overtake it ;-)

You wrote:

Quote:
The HP models with three shift keys (e.g., HP-34C and HP-67) and 7-segment displays put the yellow and blue side-by-side above (34) or below (67) the key, and the black on the lower beveled part of the key. Your concepts must consider the menus, of course...

This exactly is the point! While I allow to redefine every orange operation (as stated in my earlier post), placing these operations on the keyplate permits personal overlays easily. The blue and golden are primarily for "core functions" (though less "core" than the keytop functions) and therefore must not be covered by overlays.

#51

Not a problem on the 15C, but I could never figure out how the roll-up command on the 42S got in a menu. It is one of the five important keys for programming.

tm


#52

Hi Trent, which are the remaining four on your list? Just for curiosity...


#53

Walter--

The four are: Enter, Roll-down, Swap, and Last x.

tm

#54

It's a holdover from the HP-41, where roll-down is on an unshifted key, but roll-up had to be spelled out with [XEQ][ALPHA]R[SHIFT][ENTER][ALPHA] unless it was assigned to a user key. With a four-level stack it was easy enough just to hit roll-down three times to get the same effect as roll-up.


#55

Thats fine on the 41C but hitting the roll-down key three times is a pain in the neck. Also I still like to play with my 25C at times which does't have a roll-up key so you lose two precious steps.

tm

#56

Quote:
I could never figure out how the roll-up command on the 42S got in a menu

Yes: I put it in the "custom" menu the first day...


Possibly Related Threads…
Thread Author Replies Views Last Post
  HP Prime: Long integers (continued) Helge Gabert 2 1,569 11-07-2013, 11:24 AM
Last Post: Helge Gabert
  HP Prime: Pass "Long" Integers to a Program Helge Gabert 6 2,542 11-03-2013, 01:12 PM
Last Post: Helge Gabert
  HP Prime polynomial long division bluesun08 13 3,817 10-30-2013, 03:29 AM
Last Post: parisse
  bit manips on WP 34S Kiyoshi Akima 8 2,578 10-06-2013, 06:25 AM
Last Post: Paul Dale
  Where to the 32-bit version of User Code Utiltiy for HP-41 ? Olivier (Wa) 2 1,571 09-26-2013, 01:55 AM
Last Post: Olivier (Wa)
  OT: Simulating a TI calculator with crazy 11-bit opcodes Egan Ford 8 2,754 08-13-2013, 12:06 AM
Last Post: Paul Dale
  WP-34S Overlay - making it a bit more permanent? Marcel Samek 1 1,143 07-05-2013, 09:02 PM
Last Post: htom trites jr
  A very long HP-17BII equation Gerson W. Barbosa 22 5,636 04-19-2013, 12:37 AM
Last Post: Gerson W. Barbosa
  A long WP-34S night Siegfried (Austria) 10 3,235 04-16-2013, 02:11 AM
Last Post: Siegfried (Austria)
  HP-25 left on for a long, long, while Matt Agajanian 12 3,793 04-10-2013, 11:33 PM
Last Post: Steve Leibson

Forum Jump: