Alternate wp34s Keyboard Arrangement?



#18

I have yet to cut an overlay or otherwise attempt to re-label my 30b keys or keyboard for wp34s. I try to remember some function locations and keep a printed copy of the keyboard layout handy for reference. One thing that I keep doing is scrolling up when I meant to scroll down, or wondering why the display says “XEQ _ _” when I wanted to scroll up. This is of course due to the fact that the up/down scroll arrows of the wp34s keyboard arrangement are moved down one key from the up/down arrow keys on the 30b keyboard. I guess it is hard for my brain to remember to not press the keys labeled for the function I want to do since they are so close to the functional locations of the wp34s key arrangement. (Maybe sort of like when you see the word “yellow” printed in red and are asked what color the letters are.) So I found myself wishing that in this case, the wp34s primary functions could have been assigned to the keys on the 30b keyboard with the proper labels. This made me wonder if there were other “opportunities” for matching the wp34s functions to the keys with the proper label on the 30b keyboard. I came up with two more: RCL and +/-. (I considered x<>y and Rv, but in my opinion the 30b labels for these functions are not worth retaining.) Based on the above, I came up with the arrangement depicted below for the wp34s keyboard. I tried to keep it as close as possible to Walter’s arrangement. It would allow 20 of the standard primary key labels to be re-used, 21 if we can live with INPUT instead of ENTER, vs. 16 (or 17) for the current arrangement. Of course, in a perfect world, the key assignments for all functions could go in their absolute optimum locations without regard to the standard 20b/30b labeling, because some good solution to label the keyboard and re-label the keys will be developed. But until we get to that situation, perhaps something like the below could make it easier to use.

I did present my ideas privately to Walter prior to posting here. He noted (among other things) that he felt that EXIT and XEQ should not be adjacent and that in general if the hardware cannot be used as-is, then the layout should be controlled by ergonomic and/or logic reasons. I can certainly see his point, and as the developers, he, Paul and Marcus can do whatever they feel is best. With that said, I guess I feel that my changes are relatively mild, (and Walter said that I was free to propose anything I want) so I thought I would go ahead and present it and see what others might think. My guess is that it is relatively trivial for Marcus to assign the functions to the key locations, so perhaps he could create a version with this change for people to try out. But if everyone thinks that it is pointless, then, as Emily Litella used to say, “never mind.”

Jeff

...


#19

This arrangement looks good to me and I would like to try it out.

I too have had trouble with the placement of the arrow keys compared to the default 20b/30b locations.

Why make something difficult when there are just as good and easy alternatives?

I have other thoughts, but I will not share them yet.


#20

This is my preferred version of the standard overlay. I had it tweaked in photoshop to improve contrast and readability, IMO.


#21

Gene, I see your points. Just for comparison, the following is what's in the repository since build 757 (Tuesday morning your time):

Walter

Edited: 28 Apr 2011, 12:20 p.m.


#22

That is certainly better, but a printed overlay looks better (IMO), when the back is totally black.

Also, the yellow and blue shifted symbols are not as easily read off the keyboard unless brightened as in the overlay after it was "photoshopped".

And, I have also found that the shift keys read better when they are the full color.

And, the red letters are difficult to read unless you are in very bright light.

Again, all IMO.

So, for now, I will continue to modify the overlay file and make these changes.


#23

Quote:
So, for now, I will continue to modify the overlay file and make these changes.

Enjoy, whatever "the overlay file" may be!
#24

For those interested in, there is an updated layout for the WP34S Windows emulator. And in that course also the overlay was updated - well, actually it was done vice versa, but who cares ;-)

Enjoy,

Walter


#25

There's an update available for prints on whatever media you want to try:

It is less sharp than the emulator skin, thus better for many color printers out there IMO.

Walter

#26

Quote:
My guess is that it is relatively trivial for Marcus to assign the functions to the key locations

It would need an internal remap because the reference implementation shall not be changed. Internally, all keys are addressed by codes of the form K_rc, r and c being row and column. Shuffling keys will affect many places of the code if done natively.

I can, of course, add a conditional remapping but this will not change the key codes returned by KEY?, that is "f" will still return 9, not 6.


#27

Sounds like it is more work than I thought, although I could certainly live with KEY? returning the "original" location. Only try it if it is something you want to do.

Edited: 5 May 2011, 7:46 a.m.

#28

Jeff,

Thanks for presenting your proposal. It can be made this way for sure. Just allow four humble remarks:

  • SW-wise, it seems to be not as trivial as you thought.
  • Since you state it shall be a transitional solution, I doubt it's worth the hassle.
  • It breaks a number of groups you may have not recognized: +/- and NOT, H.MS and DEG, ! and COMB and PERM, and especially the stack and memory group with STO, RCL, Rv, ENTER, x<>y, +/-, and E. The latter has a long tradition and - as Karl Schneider would say - is carefully arranged and well thought out.
  • How about simply using the overlay with flaps and forgetting the old 20/30b labels? Saves extra work and reduces costs d:-)
Walter

#29

Quote:
It breaks a number of groups you may have not recognized: +/- and NOT, H.MS and DEG, ! and COMB and PERM...

Yes, I guess I did not pay close attention to those. Most could be set right, I think (except +/- and NOT, which I can sort of see, but could do without.)

Quote:
...and especially the stack and memory group with STO, RCL, Rv, ENTER, x<>y, +/-, and E. The latter has a long tradition and - as Karl Schneider would say - is carefully arranged and well thought out.

I see that your arrangement matches the 32S and 42S, but if you look at other models, these functions have moved around quite a bit. My proposal keeps them grouped petty closely, I think.

Quote:
How about simply using the overlay with flaps and forgetting the old 20/30b labels? Saves extra work and reduces costs d:-)

I'd love to use the overlay with flaps - where can I get one :) In any case, my concept did not get much traction, so, we move on.

Edited: 28 Apr 2011, 9:53 p.m.

#30

I think of x<>y, R^, Rv, and LastX as a "group" that works on the stack, with x<>mem and its buddies as being part of the STO/RCL group, and have always wondered why R^, Rv and LastX were not shifts of x<>y. And (while I'm whining) isn't there a LastY? I should really go read the manual, and will.


#31

You can RCL Y but it's not saved as part of an operation such as X is to LastX (L). We would need a Last Stack command for a complete undo. Being short of battery backed up memory gets in the way here.

#32

Quote:
... have always wondered why R^, Rv and LastX were not shifts of x<>y.

Many forumers will cry if/when Rv would become a shifted function {;-) I don't use it as much, and I can even live without R^ easily, but these two functions have very true friends here.

Concerning LASTx: if you did execute a complex operation (i.e. an operation on complex numbers) then CLASTx will recall both components of the complex argument, i.e. x and y. Else no way.

And yes, some reading may help d;-)

Walter


#33

The manual is very impressive. It's going to take a couple of hours, and I probably won't get to it until Sunday afternoon.

I understand the love of R^ and Rv. I'd prefer both X<>Y, R^, and Rv to be on keytops, myself, but there are so few of them (STO and RCL make more sense to me as shifted, they're used less from the keyboard) ... LastX and LastY should be shifts of ENTER, maybe, in some ideal world, along with LastEntry (which would be like LastX, but it reaches back in history to the LastX that was directly entered.)

Anyway, off to read more. Didn't mean to sound critical. FORTH may have corrupted my brain.

Edited: 29 Apr 2011, 5:12 p.m.

#34

I experienced these problems when I first flashed the hardware. With the overlay in place, they all disappeared. Don't let the existing decals trick your mind -- get a permanent marker and obscure the errant labels :-)


- Pauli


Possibly Related Threads...
Thread Author Replies Views Last Post
  HP30b to WP34S keyboard pretreatment Neil Hamilton (Ottawa) 4 698 12-15-2012, 01:13 PM
Last Post: Neil Hamilton (Ottawa)
  Alternate poll Paul Dale 14 1,435 11-29-2012, 01:29 PM
Last Post: Eddie W. Shore
  [WP34S] WP34S firmware on the AT91SAM7L-STK dev kit? jerome ibanes 1 503 10-04-2012, 04:59 PM
Last Post: Paul Dale
  Flashing of WP34S, entering SamBa via keyboard Harald 4 676 05-06-2012, 02:17 PM
Last Post: Harald
  [wp34s] Incomplete Gamma on the wp34s Les Wright 18 1,949 12-06-2011, 11:07 AM
Last Post: Namir
  [wp34s] Romberg Integration on the wp34s Les Wright 2 629 12-04-2011, 10:49 PM
Last Post: Les Wright
  alternate documentation for 50G Glenn Becker 1 370 11-14-2009, 02:47 PM
Last Post: P.Hart
  HP-35s simulator: Alternate skins? Dan Greil 0 279 07-04-2009, 11:41 AM
Last Post: Dan Greil
  Good alternate cases for the 50g? Bruce Bergman 14 1,183 09-09-2006, 02:14 PM
Last Post: Jeff
  Alternate link to bypass OpenRPN site problem Hugh Evans 11 1,135 04-05-2006, 10:17 AM
Last Post: Frank Boehm

Forum Jump: