▼
Posts: 76
Threads: 6
Joined: Sep 2011
I was looking at the WP34S picture (I'm planning on getting one :P), and its three shift keys caught my attention. Would it not be worthwhile to save at least one of these keys for function implementation? The fact is that, with three keys, we can represent at least eight shift states (more, if we're willing to allow for key repetition, of course) which is far more than needed. There seems to be, thus, room for some optimization.
One of the many possible ways to save one key, while maintaining the present YELLOW, BLUE and GREEN shift states, would be to use only two shift keys (say a blue and a yellow), and activating the GREEN shift by pressing "blue" and "yellow" shifts in succession, possibly in any order. The blue+yellow=green is intuitive, and the scheme woukd (hopefully) quickly become second nature, even for color blind people. And, of course, we would have saved a full key, which could then be used for whatnot additional functions.
Sorry if this type of scheme has been discussed and discarded before (I searched and could not find it) and/or if I'm overlooking something important (which may well be the case, since I still don't own and never used a WP34S)
Best
Paulo
▼
Posts: 384
Threads: 18
Joined: Sep 2010
Quote:
One of the many possible ways to save one key, while maintaining the present YELLOW, BLUE and GREEN shift states, would be to use only two shift keys (say a blue and a yellow), and activating the GREEN shift by pressing "blue" and "yellow" shifts in succession, possibly in any order.
I've experimented with such time and sequence encoding of key
input toward the goal of overloading functionality into available
keycaps. The end result didn't impress as terribly ergonomic
in actual usage as the operator needs to learn the sequence/timing,
the UI must feedback to the operator where it thinks they are
headed, and eventually keying errors will be made which ideally
the UI will provide some way to unwind.
Personally I believe drill down menus are the lesser evil
given a thoughtfully designed approach.
Posts: 4,587
Threads: 105
Joined: Jul 2005
Quote:
One of the many possible ways to save one key, while maintaining the present YELLOW, BLUE and GREEN shift states, would be to use only two shift keys (say a blue and a yellow), and activating the GREEN shift by pressing "blue" and "yellow" shifts in succession, possibly in any order. The blue+yellow=green is intuitive, and the scheme woukd (hopefully) quickly become second nature, even for color blind people. And, of course, we would have saved a full key, which could then be used for whatnot additional functions.
Nice theoretical concept ;-) So you gain one full key but need one keystroke more for 34. IMHO, that totals to a loss :-/
▼
Posts: 34
Threads: 4
Joined: May 2009
Quote:
Nice theoretical concept ;-) So you gain one full key but need one keystroke more for 34. IMHO, that totals to a loss :-/
Has to be a philosophical difference. For me, the need to press more keys is not as important as having ease of use insofar as finding functions you want easily. For me, it's a menu driven system every time, only three keys needed (up/down/select). You can add on top of that with quick-keys and re-definable keys. I just think it's silly using three keys on your keyboard to give you shifted functions. You could do it with one. F, FF and FFF. A *majority* of the functions on the keyboard will never or very rarely be used by a *majority* of owners. IMHO the optimal solution is redefinable keys. The next best is menus, and the worst is F/G/H reserved to allow four functions per key as per current design. I'm aware this is probably not a view shared by most.
EDIT: So sorry about the really odd title-change every post I make. For some reason the browser is caching my first-ever post from months ago and I fail to notice when I reply to stuff.
EDIT2: The problem was LastPass auto form-fill. fixed.
Edited: 27 July 2012, 7:40 a.m. after one or more responses were posted
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
Let us know how to properly implement a menu system in 43 by 6 pixels....
That is the primary reason the 34S has so many shift keys.
- Pauli
▼
Posts: 34
Threads: 4
Joined: May 2009
Quote:
Let us know how to properly implement a menu system in 43 by 6 pixels....
That is the primary reason the 34S has so many shift keys.
- Pauli
The uWatch has NO shift key.
It has a very limited character-graphics single line menu system that works really well. Have you ever checked out how it works?
I think you're just stuck in thinking it's not possible.
Edited: 27 July 2012, 6:09 a.m.
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
I have one of the first run uWatches. The uWatch has a better display for this kind of thing -- two lines for a start and way more pixels wide.
We did consider a menu system.
- Pauli
Edited: 27 July 2012, 6:25 a.m.
Posts: 1,216
Threads: 75
Joined: Jun 2011
Quote:
Let us know how to properly implement a menu system in 43 by 6 pixels....
Well, in principle it would be possible:
Of course you can't display 5 or 6 different menu options in this short alpha line, but you could display them one after each other, i.e. pressing a [MENU] key would show the first menu name, e.g. MATH> (the ">" at the end distinguishes it from commands).
Then you could switch to different menus e.g. by pressing [MENU] again (or with [->] and [<-]), and when you've reached the wanted menu you can scroll through the single items (i.e. commands) with the down/up arrow keys and execute the command with [ENTER].
So in fact a complete menu tree could be accessed with only one single word/name entry in the alpha dsiplay - but I agree that this won't be very comfortable at all. :-(
Franz
▼
Posts: 34
Threads: 4
Joined: May 2009
Quote:
So in fact a complete menu tree could be accessed with only one single word/name entry in the alpha dsiplay - but I agree that this won't be very comfortable at all. :-(
Franz
Quite so. But there are advantages. A menu system allows you to put more functions on the machine than there are available keys (including shifted keys). It also allows you to group like functions together much more readily than trying to find areas of similar functionality on the keyboard. Combine a menu system with redefinable keys, so you CAN put your preferred keys on a single keypress, that's pretty comfortable.
▼
Posts: 1,216
Threads: 75
Joined: Jun 2011
Quote:
A menu system allows you to put more functions on the machine than there are available keys (including shifted keys). It also allows you to group like functions together much more readily than trying to find areas of similar functionality on the keyboard.
Well, the WP34s has all this already - just look at the 'menu' keys like TEST, P.FCN, X.FCN, MATRIX etc. ...
The only difference is that these menus are not called from any other (top-level) menu in the display but just from different keys.
▼
Posts: 34
Threads: 4
Joined: May 2009
Quote:
Well, the WP34s has all this already - just look at the 'menu' keys like TEST, P.FCN, X.FCN, MATRIX etc. ...
The only difference is that these menus are not called from any other (top-level) menu in the display but just from different keys.
No, it doesn't have all of this. The WP34S does not have re-definable keys, not can it handle a heirarchy of menus (i.e., sub-menus). These are the fundamental things I was arguing for.
I don't particularly want to argue what the WP34S can do with you. You like a cluttered keyboard, I like a clean one. I can make the changes for myself, so as I said it's a philosophical preference.
But you don't seem to understand the advantage of allowing the user to put what they *most use* on their keyboard via redefinable keys. I don't particularly want functions on my keyboard that I will never use. I'd rather have them buried out of the way in a submenu.
Adding redefinable keys to the existing WP34S would allow all of that. I've made a start. Further, changing the menu system to allow submenus and you have the complete package. Doesn't have to be a big argument; this approach will allow everyone to have what they want.
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
Andrew, we know you want a redefinable keyboard. And we know you like menus. Please let me quote our welcome statement (p.7 of the manual):
Quote:
WP 34S is our humble approach – within the constraints of HP’s hardware – to a future 43S we can only dream of becoming the successor of the HP-42S.
Let me emphasize "our" and "within ... hardware" :-) Feel free to design some alternative using your approach. Please return when you've your layout laid out ;-)
Good luck!
▼
Posts: 34
Threads: 4
Joined: May 2009
Quote:
Please return when you've your layout laid out ;-)
Yes, fair point. You've actually built it and so far I'm all talk.
I think the WP34S is a fabulous achievement, and thank you for that.
Posts: 76
Threads: 6
Joined: Sep 2011
Yes. That is true, I know :-(.
But I feel that the advantage of having 4 extra functions accessible on the keyboard far outweigths the downside of sometimes having to thumb an extra key, as long as:
1. It is a neighboring key (and, hence, does not force us to jump around in the keyboard);
2. It comes natural to do so (and, hence, there is no additional mental effort at all in doing so);
3. It does not imply less efficient programming.
Sequences like, for example, "f.Lbl.A" on a 15C are typical: they map your mental image of the action, they do not force you to jump around, and, hence, they are three-key sequences which are not penalizing to the user.
I believe that thumbing the yellow and blue neighboring keys to get a green shift would also be a very natural, easy, non time consuming and, hence, non-penalizing, thing; and, of course, it did not need to impact on programming efficiency at all.
But I will gladly manage even six shift keys, if needed, to have the joy of owning a WP34S. Shift keys are not the problem; my wife may be :-)
Best
Paulo
Edited: 27 July 2012, 9:16 a.m.
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
Just a minor remark: How do you plan getting rid of an erroneous prefix pressed in your "green" case? Compare p.33 of the manual. Just curious :-)
▼
Posts: 76
Threads: 6
Joined: Sep 2011
That is a trick question. Whathever I may suggest you will have already considered :-). But here I go, nevertheless:
Assumptions:
B - Blue shift;
Y - Yellow shift;
Assume that Y is to the left of B (as is the present case in the WP34S).
Rule: "Business as usual. Just one additional rule: yellow+blue = green"
Y - Yellow mode (toggle);
B - Blue mode (toggle);
(YB - Green mode).
To exit "green" mode, you can either go BB, or YY (please see state diagram in http://dl.dropbox.com/u/5923066/state%20machine.jpg).
If I'm not mistaken, the only inconvenience would be the fact that direct transition from "yellow" mode to "blue" mode is lost, because YB means "green".
Best
Paulo
Edited: 27 July 2012, 2:12 p.m.
▼
Posts: 384
Threads: 18
Joined: Sep 2010
Quote:
Y - Yellow mode (toggle);
B - Blue mode (toggle);
(YB - Green mode).
To exit "green" mode, you can either go BB, or YY (please see state diagram in http://dl.dropbox.com/u/5923066/state%20machine.jpg).
Frankly for this limited scenario, I think the above would
be reasonable.
Although I don't think it would scale/generalize beyond a
2-key 3-shift scenario very intuitively for the user.
Posts: 40
Threads: 12
Joined: Feb 2009
The question of menus vs. shift keys is a fundamental design issue, and for some almost a religious issue. There are going to be passionate people on either side no matter what is done.
I must say that when I first started playing with the 34s emulator a couple of days ago, my first reaction was, "What? THREE shift keys? Too complicated!" But once I got to know the layout and conventions of the calculator, I found myself liking it more and more. It's kind of like learning to play the bassoon, which I do :-) Some fingerings don't make any sense when you start. But after a while most of them "get into your fingers," and all's well.
It probably helps that I've used a 25c, 11c, 32s, 32sII, 42s and 33s. So I could take mental shortcuts: "Oh--that's like my 11c. OK. This is more like the 32sII. That's OK, too."
I've used, documented, tested and compared much software in my lifetime. I've come to the conclusion that discrete key commands are best for things that you do every day. Menus are better for things that you don't do every day. With the keystrokes, you employ less physical motion than menus. Muscle memory takes over, and you can do familiar things quickly and easily. But with menus, if they are logical, you spend much less time hunting for the right key. So even though they usually mean an extra keystroke or two, they can save you time overall for things you don't do all the time.
Ideally, you have both and can choose--which is why most software has both menus and keyboard shortcuts. That would be nice in a calculator, but we are limited by the display and available memory. It would be nice for the 34s to have a two-line x-y display. And 42s-style menus with hierarchy so we could quickly find less-used functions. But the physical display is the limiting factor here.
Another thing to remember is that the more advanced calculators have so much math stuffed into them that some people are bound to be less happy with the interface than others. If your favorite functions require less keystrokes to get to, you'll be happier. If not, not so happy. And (my opinion here) if we start down the road of combining the shift keys, I think we've crossed the line where the complexity becomes great enought that few would be happy in the long run.
Finally, we have to remember that with the most advanced calculators, we are bumping up against the point where it might be better to use a computer. :-) Most people in the 1970s didn't have that choice. Now we do.
▼
Posts: 1,253
Threads: 117
Joined: Nov 2005
Quote:
I've come to the conclusion that discrete key commands are best for things that you do every day. Menus are better for things that you don't do every day. With the keystrokes, you employ less physical motion than menus. Muscle memory takes over, and you can do familiar things quickly and easily. But with menus, if they are logical, you spend much less time hunting for the right key. So even though they usually mean an extra keystroke or two, they can save you time overall for things you don't do all the time.
I can hear the musician talking, maybe because I´m too (sax :=) So I agree completely with that assessment in favor of shift keys vs. menus.
I also think the B+Y=G has a lot of merit, and it's not "one free key vs. 34" - at the very least it'd be THREE free keys, and that's if you're keeping the score which isn't the point.
This is an interesting discussion and as Peter says almost every idea generates lots of detractors and lots of followers, so if one is looking for consensous... you\ll never win :-)
A couple of examples I experimented, which *personally* I'm fond of:
- On the 41Z I used repeat-shifts to access second-layer "sub-menus" (for the lack of a better word), or "alternate keyboards" if you wish. The dependency is a decoder ring beyond the obvious choices, which must be color-coded on the overlay (so the double-shift would be a different color).
- On the CLUTILS (and POWERCL) I use prompting functions that include cues (initials of action/function) in the prompt, effectively a sub-memu of the allowed options. Some of them trigger yet new prompted menus...
Cheers,
'AM
Posts: 1,083
Threads: 126
Joined: Sep 2006
On the lighter side, I want "COLOUR coded key confusion". It stops any one from borrowing my calc; dead in their tracks.
d:-D
That and no = key!
Edited: 27 July 2012, 3:50 p.m.
▼
Posts: 76
Threads: 6
Joined: Sep 2011
Point taken. I can't argue with that. :-)
Paulo
Edited: 27 July 2012, 5:09 p.m.
|