Permanent CUSTOM

[Thomas Okken]

One feature request that comes up every now and then is permanent CUSTOM. Meaning: whenever the calculator would otherwise not be showing any menu, have it show the CUSTOM menu instead.

I have thought about how to implement this, quite a while ago in fact, and I came up with a clean approach, but also a usability issue. Let me explain from the start:

On the HP-42S, menus are organized in what I call "layers." These are unrelated to the menu hierarchy, but rather, they represent a stacking order, in which menus in the lower layers get hidden behind menus in the upper layers. And conversely, when a menu is dismissed, whatever menu was hidden behind it is revealed and becomes usable again.

The lowest layer is used for the application menus: SOLVER, ∫f(x), MATRIX, STAT, BASE, and VARMENU;

The next layer is used for the function menus: MODES, DISP, CLEAR, CONVERT, FLAGS, PROB, CUSTOM, PGM.FCN, PRINT, TOP.FCN, CATALOG, and MENU;

The next layer up is used for what I call the "transient" menu, which is the menu that is left behind when you do a global GTO or XEQ by selecting an item from the list of LBLs and ENDs, but don't let it execute, instead keeping it pressed until NULL;
Next comes a layer that is used for the ALPHA menu, specifically, when it is used for ALPHA mode, not ALPHA argument entry;
And finally, there is a layer that is used for the menus that are shown in the course of command entry, e.g. the menu of variables shown when you press RCL, or the stack menu that is shown when you press RCL <dot>.

My idea is to add a new level, below the application menu level, and use that for the permanent CUSTOM menu. That way, the CUSTOM menu would always show when no other menu would otherwise be showing, without interfering with the other menus at all. The amount of new code I'd have to write would be small, it would be simple, not much chance of introducing bugs.

There's just one problem: the ▲ and ▼ keys. In PRGM mode, you'll typically want to use SST and BST a lot, and having to use Shift all the time to reach them is going to be painful. And likewise, while debugging you'll also use SST a lot.

So there needs to be a quick and easy way to disable and re-enable the permanent CUSTOM menu.

I don't want to do this using a MODES setting, because that's not quick, it would require several keystrokes to get to the desired menu option.

Another option would be simply EXIT. The CUSTOM menu would live in the new, lower level, but it would be opened using the CUSTOM function, and closed using EXIT, like any other menu. I like this idea because it's very minimalistic as far as UI changes are concerned, but it does mean that people who are in the habit of getting out of menus by pressing EXIT a bunch of times rapidly are going to often end up overshooting and exiting CUSTOM without meaning to.

Still another option would be similar to the first, but would make Shift-2 (CUSTOM on the keyboard) a toggle, rather than only activating the CUSTOM menu, and would not let EXIT close the menu.

I'm sure there are ramifications to all of these choices. Like: what should Shift-2 do when some menu other than CUSTOM is active? Activate CUSTOM in the function menu layer, or exit all menus to return to CUSTOM in the lowest layer, or do nothing?

Thoughts?

[Thomas Okken]

Or maybe I'm overthinking this, and I should just keep it simple: add a setting in MODES to turn permanent CUSTOM in the new level on and off, and make that the only way to turn it on and off. It's simple, and people who want permanent CUSTOM and do a lot of programming will just have to put up with a few extra keystrokes every now and then.

[Vincent Weber]

Personally I would go for the EXIT solution. It is simple, does not break anything, and if you are too fast to press EXIT... too bad. You'll survive it. Not the end of the world :) 

[Paal Rasmussen]

My greatest fear with the Plus42 is that it becomes a beast with so many intricacies that the 48 seems streamlined by comparison. The ethos of the 42 is simplicity with power. So whatever solution you end up using, make it an option so as not to make things extra complicated.

[Vincent Weber]

So far Plus42 does not go on this slippery slope. It has all the features that makes sense, nothing more, save maybe for an alpha keyboard, side-by-side calculator and printer, and program protection. If you wish to hide all the extras and makes it behave like Free42, you still can. Indeed this should stay that way. I'm sure this is Thomas' will, it always has been. 

[Thomas Okken]

There is always a potential problem with new features that introduce different behaviors, even if those features are optional, and that is that users might enable those features by accident, without meaning to, and without understanding what they just did.

This is a problem even with some of the standard HP-42S behaviors. Someone does CLV "REGS" and sometime later they notice that STO nn no longer works. Or they activate the BASE menu, and sometime later they notice that arithmetic functions are all returning integer results.

That's a strong argument against adding such features. It's also the reason why Free42 has an "Allow Big Stack (NSTK) mode" setting in the app preferences: to avoid the situation that someone who simply wants an HP-42S-compatible calculator accidentally turns on NSTK mode in the MODES menu and then finds that the calculator is acting weird and all their programs are returning incorrect results for no obvious reason.

[Thomas Okken]

Until yesterday, when I thought about Permanent CUSTOM, all I thought about was how to implement it: the feature itself and how to control it. What I hadn't really considered was whether implementing it would actually be a good idea.

I know there are people who like this feature, because I've been asked for it more than once, and also because I know there are people who install alternate firmwares on their DM42 just to get it.

But as Paal pointed out, there is also a downside, and that is the increasing complexity and unpredictability when adding features that change the behavior of the UI. And that concern resonates strongly with me; in fact, I have rejected proposals for enhancements in the past, on multiple occasions, precisely because of this concern.

I'm not comfortable with the idea of a user accidentally turning on Permanent CUSTOM, and then becoming frustrated with the app no longer behaving like they expect. Of course they could then contact me, and I'd explain what happened and how to fix it, but the better scenario is for that never to happen in the first place.

So, I think it will be better, overall, if I don't implement Permanent CUSTOM. The familiar and predictable UI trumps all.

[Vincent Weber]

I have myself requested a lot of features over the past 20 years, as you are well aware :) 

Yet I, didn't ask for this one. I guess I never felt the need for it. But now that I see it, I think it might be good, to be a bit closer to the 41 USER mode. The issue only arises when you have the CUSTOM menu on and want to temporarily use another menu. When you exit this other menu, you exit everything, including the CUSTOM menu, while it may be convenient to just return to it. If you just use direct commands, you can make the CUSTOM menu sticky and have it stay. 

So, why not, as long as you can get SST and BST back for program writing and tracing? I don't see the arm, as long as you can disable the feature in the references If you don't want any possible trouble, and as long as you have a quick way to disable it temporarily (EXIT seems perfect). 

Cheers 

[Thomas Okken]

I think you missed my point. My concern isn't about the experience of users who want this feature; I'm sure I can come up with something they'll like. The concern I meant to express in my previous post is about the experience of users who don't want it, don't even know it exists, and enable it unintentionally. That's going to be a bad experience, and I'm inclined to think that avoiding that is more important than providing the feature to those who do want it.

[Vincent Weber]

But as you said about another feature, and as I also suggested, you could have a switch in the preferences to disable the feature altogether, and it should be disabled by default. This way, no accident for those who don't want the feature... 

[Thomas Okken]

True, with two levels of protection, like for NSTK mode in Free42, the chances of users accidentally turning on the feature would be negligible.

It does make everything significantly more complicated. But that's manageable.

[Thomas Okken]

Test versions for Windows and MacOS: https://thomasokken.com/plus42/download/test/

[Vincent Weber]

I have just tried it on Windows.

i enabled PCUSTOM in the preferences. 

I must be missing something, because I can't see any difference. If I enable the CUSTOM menu, then the MATRIX menu, EXIT does not only exit MATRIX, but CUSTOM as well... I thought EXIT would only exit CUSTOM if you are indeed in the CUSTOM menu ?  

[Thomas Okken]

Didn't you just take part in a discussion where we talked about using TWO switches to turn on this mode?

[Thomas Okken]

I posted a Linux test version as well, same URL as above.

I guess I should have mentioned that the setting to turn on Permanent CUSTOM mode is DISP -> PCUSTOM, and that setting will only work if "Allow Permanent CUSTOM (PCUSTOM) mode" is also turned on in Preferences.

[Vincent Weber]

Yes I did take part in this discussion, but I thought it meant just a setting in preferences as ONE extra security for those who type EXIT too fast. Didn't know there was a belt AND a parachute ;) 

[Vincent Weber]

And now that I tested it, I realize that I can't use EXIT to suppress the CUSTOM menu, so in program mode, no more direct access to SST and BST. Ouch... Not sure I like that ! 

[Thomas Okken]

This is exactly why I don't like this kind of feature. I put in a double safety so that people who don't want it won't turn it on by accident, but the next thing that will happen is that the people who do want it, or who think they want it, start complaining about it, because they discover that having a menu you can't EXIT out of actually kinda sucks. Messing with a good design rarely makes it better. 😄

[Vincent Weber]

I would have been happy with the preference setting plus EXIT to quit CUSTOM, as once proposed. 

[Thomas Okken]

If you can use EXIT to get out of CUSTOM, then what is the point?

[Thomas Okken]

I can already see this becoming a support headache. Permanent CUSTOM, but not really permanent CUSTOM, because that gets annoying (just as I expected). And how to work around that? By allowing EXIT to exit out of the "permanent" CUSTOM, which is then not permanent any more. And maybe it should also be disabled in PRGM mode, since that's when having a permanent menu is at its most annoying? Or maybe the behavior in PRGM mode should be controlled by another preference?

And all this to save pressing Shift-2 every now and then. Yuck, yuck, yuck.

I'm taking it out. It was an interesting experiment, but I don't like the result, and I don't like where this is headed.

[Vincent Weber]

What I thought you once suggested (maybe I got it wrong) is that EXIT would exit CUSTOM only when CUSTOM is shown. 

The normal 42S behaviour is that once you are in CUSTOM mode, it stays on, as long as you just use direct keys. But if you go to a menu while CUSTOM is on (say MATRIX) and then press EXIT just to exit MATRIX, EXIT actually exits everything, including CUSTOM. 

I thought you suggested that EXIT would now exit MATRIX but leaves CUSTOM on. And that if you press EXIT again (while CUSTOM is shown), only the permanent CUSTOM would be gone. Which was fine with me. 

[Thomas Okken]

What I thought you once suggested (maybe I got it wrong) is that EXIT would exit CUSTOM only when CUSTOM is shown. 

That sentence sounds wrong to me. First, EXIT only exits menus that are shown. Second, the whole point of permanent CUSTOM is that EXIT does not exit it. You can get out of arbitrarily deeply nested and/or stacked menus by pressing EXIT repeatedly, and you will end up on CUSTOM. That is what I understood people to want.

The normal 42S behaviour is that once you are in CUSTOM mode, it stays on, as long as you just use direct keys. But if you go to a menu while CUSTOM is on (say MATRIX) and then press EXIT just to exit MATRIX, EXIT actually exits everything, including CUSTOM. 

That is incorrect. If you open CUSTOM, and then open MATRIX, the CUSTOM menu is closed the moment you open MATRIX.

Whenever you open a menu in a certain layer, any menus that are already open in that layer and in any layers above it are closed.

I thought you suggested that EXIT would now exit MATRIX but leaves CUSTOM on. And that if you press EXIT again (while CUSTOM is shown), only the permanent CUSTOM would be gone. Which was fine with me. 

No, I added a layer below the application menu layer, and when Permanent CUSTOM mode was on, CUSTOM would be permanently open in that layer. In addition, EXIT would be disabled for that layer, so you could never overshoot it when pressing EXIT repeatedly to get out of deeply nested and/or stacked menus. (But EXIT would still get you out of PRGM mode.)

If you wanted to get out of CUSTOM in Permanent CUSTOM mode, you'd have to turn off Permanent CUSTOM mode. That was four keystrokes: Shift DISP ▲ PCUSTOM. That seemed reasonable to me for something people wouldn't want to do constantly -- the assumption being, of course, that people who want Permanent CUSTOM are people who either don't program a lot, or if they do, don't mind using Shift all the time for SST and BST.

Here's the problem: probably nobody wants "permanent" CUSTOM to be truly permanent. There are always scenarios where you want no menu, like when programming. So this new mode has to present CUSTOM in some situations where no menu would otherwise be shown... but not in all such situations. So now you have to get clever about when "permanent" CUSTOM actually does show up, when it doesn't, how to get it to disappear if the algorithm decides to do something you don't want, and how to get it back.

I'm sure algorithms could be devised that would make people happy, but I'm also sure that there wouldn't be one single algorithm that would fit everyone's needs. So it wouldn't be a simple PCUSTOM toggle, it would be a multi-valued setting.

And then it all ends up in my lap. People are going to complain about the UI. They're going to complain about the defaults. About the exceptions. People are going to be confused by the whole thing and they'll send me emails demanding answers. And I would like to stress that none of this is hyperbole; software development is my job and I have a lot of experience with the things that happen when something isn't obvious to users. Blaming the users for not understanding the brilliance of your work gets you nowhere. :-)

Given that all of this is just so some people will be saved from having to press Shift-2 every now and then, all of the above seems like an absurd amount of hassle. The only reason we even got to the point where we're at now is that I thought of this as a programming challenge first, and since I typically enjoy those, I jumped in the moment I figured out how it should work. If I had thought the user experience angle through first, I would have rejected the whole idea immediately and never even gone near the coding part.

[Vincent Weber]

Ok, I see! :)