Orange-Shift extension

[Marco Polo]

I am using Plus42 since beta testing.

I find the single shift quite limiting in some activities, for example:

- quick update of a stored variable without using "STO" key (see HP48/50)

- quick conversion between UOMs without using the workaround of adding 0_newUOM (by the way, it does not work properly in °F<->°C conversion)

It would be possible to investigate the possibility to implement, limited to the top key row not to impact HP42 user paradigm, something like key longpress or shift-hold?

Thank you

Marco Polo

[Thomas Okken]

I don't like the idea of changing or extending the HP-42S user interface design. If I were to do it at all, it would be using a second shift key; I personally hate long-press or double-press. But the bigger issue is that any such change would either lead to visual clutter or to unintuitive behavior. I prefer keeping things tidy and predictable, even if that requires additional keystrokes for some operations.

What's the problem with the °C / °F conversions? I made them work like all the other conversions; for example, to convert 100°C to °F, you could do 100_°C 0_°F + → 212_°F.

[Vincent Weber]

Yes the design should remain faithful to the original. Though this idea to have shifted soft keyS with the new BASE fonctions was a nice touch - could be extended to other menus like CUSTOM ?

[Thomas Okken]

Shifted functions in menus weren't entirely new; even the HP-42S has a few (all the functions in TOP.FCN, STAT → Σ+/Σ-, PGM.FCN → XEQ/GTO, and CUSTOM in LCLBL mode), and I just ran with that idea and made it more visible. Also note that shift has an effect in the ALPHA menu, and also when units are assigned in CUSTOM.

Shifted assignments in CUSTOM are a possibility. And sub-menus. Not easy to implement, though, and doing it in a way that extends the existing functionality in an elegant way will be a challenge. It's something to think about... I'm not sure I'll actually end up doing it.

[Vincent Weber]

Yeah HP made a step in that direction but never bothered to change the soft menus dynamically when you press shift... You did 🙂

CUSTOM would be nice to have more favourite programs handy, but that is not critical, I think.

[Marco Polo]

I understand your point, anyway imho limiting the "user interface extension" to Plus42 improvements over Free42 would not compromise the original user interface concept.

Forget the temperature problem conversion: my mistake

[Paal Rasmussen]

"The road to hell is paved with good intentions" – namely, the road to a confusing user interface is paved with good suggestions of improvements from the very people who don't need a consistent interface because they already know all the functions and keypresses by heart. Please 'y'all take a moment and put yourself in the shoes of a novice user. Your favourite young boy or girl who's on the verge of discovering calculators. For them, simple and uncluttered AND consistent interface design is the key to acceptance. Keys that change behaviour, interface logic that's not consistent breaks the social contract with the user. The 42 is not designed for geeks but for beginners. Get a 48 if you want the overwhelming experience. And give one to a child if you want to wean them off calculators for ever. In fact, the demise of the scientific calculator was due to this fact. Python on a computer or Matlab turned out to be a much easier terrain. Keyboard was just alphanumeric keys. NO labels on keys! The HP Yellow Key is as far as it can go, as it's similar to SHIFT on a QUERTY keyboard.

The same argument goes for menu navigation, selecting and entering. Why have I given up on the Solver? Because i Watched the interview with the guy who made it. He's very proud that he managed to fit it in. I'm seeing a guy who nailed an intellectual challenge, NOT a guy who made something that people would find easy to use. Any Casio calculator from the supermarket does this job better. Yes, it WAS cool back then, but as a challenge, not as anything useful. The market has proven me right. Please avoid these pitfalls.

[Thomas Okken]

I agree about keeping the UI simple, and I've stated my design philosophy on multiple occasions: only add functionality if it fits within the existing UI and doesn't cause any existing UI behavior to change, and don't add modes that could cause existing behavior to change. I have made exceptions to these, like NSTK mode and BASE → MODES → WSIZE, but only if I find the use case very compelling and the potential for confusion is limited (which is a subjective judgment, to be sure).

I like the R47 / C47 because its designers don't constrain themselves the way I do, and are happy to add all kinds of functionality. It gives me something I can point people to when they ask me for features I don't want to implement. :-)

I'm not sure I understand your criticism of the solver, though. It seems rather elegant and effective to me, and I don't see how it could have been done significantly better.