Gauging interest in a DM48 or DM50?

[c3d]

(10-24-2024 12:00 AM)Eric Rechlin Wrote:  

(10-01-2024 10:14 PM)c3d Wrote:  Can you think of anything I could do to make it easier? Do you remember the things that annoyed you the most?

This started out as me trying to write a response to what you could change to make it easier, but after thinking a bit I realized there really isn't anything you need to change! Instead I will just give you a brain dump on some of my thoughts about DM48X and my perceptions coming from the 50g (and its predecessors).

Thanks a lot for the long writeup, which I only noticed today, after focusing on the Stuttgart video and the release of 0.8.4. Pretty impressive writeup.

Quote:First, I will qualify this by saying that all my testing so far has been with the web version of DB48X, and that surely has some limitations compared to the real thing. For example, I've noticed the "hold down" functionality does not work, so I can't test the hold-key-for-help or hold-shift-for-alpha features, and I probably am missing other things also.

Mostly anything requiring file access. This includes the new reconfigurable keyboard feature.

Quote:Second, I want to say I am so incredibly impressed with the functionality you have implemented. From native H:M objects, to improved SI prefix support, to the extremely flexible number display formats (the configurable point of when to switch to scientific notation is great!), to the flexibility of different alpha modes, it's just amazing all the new ideas you have, compared to what is in the HP RPL machines.

Coming from you, this is deeply appreciated. I had 30 years to think about it ;-)

Quote: The hierarchical CHAR menu is just so useful too (though the Cyrillic menu is missing some Ukrainian letters, as well as some other Cyrillic letters from languages other than Russian...).

Does it? It's a bug. If you can spend the time listing them, I'll make sure to fix it.

Quote: The base functionality (with automatic alpha entry which helps for HEX mode -- and also with arbitrary base sizes!) is much better implemented as well.

I don't think there is necessarily anything *wrong* with the UI, it's just that a lot of things follow a different paradigm which makes it feel foreign to someone who's been using the 48/49/50 models for 30 years.

For example, when you first turn it on, there is no softkey menu visible so the top row of keys can’t do anything. This isn’t a problem, because there’s not much you can do on an empty stack, but it was somewhat disconcerting at first to me.

I wanted to make more room for the stack for simple calculations, and to have the calculator be a bit less "intimidating".

Quote:Similarly, not showing any stack level numbers when those levels are empty actually probably does make more sense than past calculators showing 1-4 or even 1-7 (because those stack levels don't actually exist yet, so why show them?), but it just feels different. Here I prefer how you did it, even if it seems like a surprise at first. Maybe keeping the vertical dotted line (that otherwise separates the stack labels from the values) would make it a little less empty.

The choice here was explicitly to let you "detect" if the stack was empty. I could easily make it configurable.

Quote:Also, the way the softkey menus change which row is highlighted each time you press the shift key is a really good touch, but at the same time it might also seem a little disconcerting to a 48/49/50 user who hits a shift key just to do a shifted operation on another key without caring about the softkey menu. Again, this is a case where what you did is great and makes sense, but it's unexpected for a 48/49/50 user. At least I was surprised when I saw the whole menu shifting colors when pressing the shift key for something else — even if there is nothing wrong with that.

In practice, it's a much more visible indicator of the shift state than the icons, so I like it for that. That being said, you can try the flat menus mode in the user interface to return to a more HP48-like experience.

Quote:Getting to things that are a bit more substantive and not just cosmetic surprises, the total lack of a RCL key seems like a problem at first, but once I started using it I didn't really miss it, especially since the VAR menu makes the store/recall shifted softkeys very clear.

This was a really tough decision. So few keys, so many functions!

Quote: I was similarly concerned when I saw the command was actually called "Recall", which would be annoying to type both with the length and also with using lower-case letters, but then I realized RCL worked just fine too.

I don't know if you noticed that you can configure the rendering to show RCL in your programs (or rcl or Rcl).

Quote:The lack of an EVAL key sometimes bothers me (for removing a tag from an object or executing a program on the stack) but maybe there's an easy workaround, and maybe it wasn't all that important after all.

EVAL is the key at the bottom left of +. Because I have so few keys to play with, I had to overload some of them with features I saw as related. That key serves multiple purposes depending on context:

- When you are not editing, it is EVAL (it was RUN/STOP on the DM42, so its position preserves muscle memory. This is one of the reasons there is a little = sign on it: when you evaluate an algebraic object, it plays the role of the = key on TI calculators, which is to complete the computation.

- When you are editing, it inserts a space (which in RPL is "evaluate the previous thing", so in my mind it made sense to connect the two).

- When you are inside an algebraic but not inside parentheses, it inserts "=" (my mental shortcut was that as long as I meant it as "=" to terminate computations, I could as well use it as "=" for equations).

- When you are inside an algebraic and inside parentheses, it inserts a ; to separate arguments (my mental logic here is that it terminates something jut like a space in RPL terminates something).

This is illustrated at 39:50 in the Stuttgard video.

Quote: Relatedly I haven't even found a simple way to make tagged objects other than →Tag and Tag→, but honestly that's something I use rarely enough that it doesn't matter.

When you are in ALPHA mode, unshifted zero inserts ::, except when you are inside text, where it inserts a single :

Also note that DB48X uses "assignment objects" for some cases where the HP calculators would have used tagged objects. For example where the HP solver would emit something like x:1.5, DB48X will emit x=1.5, which is an assignment object. If you have x=1.5 and x=2.5 on the stack, you can easily switch between the two values by selecting the one you want with the interactive stack and hitting the Evaluate key.

Quote:I guess there are a couple places where I don't fully understand the design decisions, however, and maybe those are places where there could be room for improvement or else places where maybe I would better understand the decisions if I knew the philosophy behind the design. For example, when you press [TRIG], the default options are |sin| |cos| |tan| (which are already unshifted keys on the keyboard) and |sin-1| |cos-1| |tan-1| which are already shifted keys on the keyboard. So this softkey menu seems totally useless unless I further press the shift key again to get at the |sec| |csc| |cot| etc.

Some of the initial menu and key layout was designed before things were advanced enough to get a good feel of the "weight" of each menu. I decided to postpone keyboard and menu reorganization until I had a way to make the keyboard fully configurable (not just with user mode), which happened in 0.8.4, released today. And we finally have y^x back as an unshifted key ;-)

Quote: But those functions seem rare enough that they could instead get buried under the Math menu somehow with no direct key. I wonder if maybe [HYP] and [TRIG] could be consolidated. I'd be surprised if either one is frequently used.

Menu consolidation can only happen once I know how many things there are in each menu. In 0.8.4, I consolidated integration and differentiation menus, for example. In earlier releases, I removed the I/O menu to make room for the more useful List menu, because I noticed that the Files menu was empty (and may remain that way on SwissMicros devices if David does not give me access to basic programmatic features such as listing files ;-).

Quote:Now, maybe you have bigger plans for this somehow -- like perhaps that menu will eventually be used for CAS functionality like the [TRIG] key on the 50g.

Yes, that's the idea, but circular or hyperbolic rewrites CAS functions do not exist yet.

Quote: Or maybe this is all part of a cohesive submenu system under the [MAIN] menu, where all commands will eventually reside, and different keyboard layouts (which may not even have [SIN] [COS] [TAN] keys) will have to be accommodated,

That too. My thinking was to remove friction against someone using SIN COS and TAN keys in user mode, among other things.

Quote: but if so I wonder if it may be better to still try to optimize the limited keyboard we have to not have too many redundancies. Especially when we have such a shortage of keys, I am not sure if it makes sense to have something that would see such infrequent use on a hard key.

To be honest, I'm glad to have a shifted key I think I can remove if I need to :-)

Quote:Similarly, everything in the unshifted [MAIN] menu already exists as a separate (shifted) key on the actual keyboard, so although it does show a cohesive single place with perhaps the main functionality, it just ensures everything else under [MAIN] is yet another keystroke away — but again, many of the [Shift] and [Shift][Shift] options on [MAIN] are already on shifted keys on the main keyboard too.

The same rationale as above: remove the friction to reassigning the shifted menu keys for the menus you need the most, whether it's globally by having your own keymap file or on a per-directory basis with user mode key assignments.

Also, redundancy of menu access paths is by design. It facilitates discovery of related features. One of the things that frustrates me with the HP48 or HP50 is that you have to remember the exact menu where something is. When you don't use the calculator daily, that memory fades out pretty quickly. Not to mention when you alternate between HP48 and HP50 which do not put them in the same spot.

Quote: I think everything but |UI| (which is also under [MODES], and double-shifted under [DISP]) has a dedicated key on the physical keyboard, making [MAIN] seem nearly redundant. Maybe get rid of [MAIN] entirely and just replace it with [UI] so everything is handled?

By default, [UI] is now on the right shift of [MODES] (where [OBJ] was, which was moved next to [LIST]).

[MAIN] is where a newcomer can start exploring. To me, it's a very important entry point into the calculator, and I don't mind redundancy at all, on the contrary. And also, same rationale as above: redefine menu keys the way you want because you know that [MAIN] is another way to access everything you rarely use.

Quote: But this just makes me wonder if maybe menus should be reorganized in such a way that even if you want to have redundances with things in menus that are also on the keyboard itself (which makes sense if everything under [HOME] is supposed to be a hierarchically-organized list of all commands available just like [CAT] is an alphabetically-organized list of all commands), perhaps menus should prioritize commands that are *not* already on the keyboard as the first 6 (available unshifted in the menu), and then leave the redundant ones on the double-shifted or single-shifted planes in that menu.

Menu layout optimization is something that I am doing incrementally, but it's far from finished. That being said, given the philosophy / design rationale of allowing people to customize the calculator to their needs, the current menu layout may make a little more sense.

Quote:Maybe I haven't found it yet, but I'd also like to see a shortcut for switching between real and approximate mode.

While there is a compatiblity mode for numerical results (flag -2), it's indeed not easily accessible. Real and approximate are not intended to be "modes" in DB48X, but different object representations. Some values are exact, some are approximate. 1/3 is a true fraction (exact), 0.33333 is a decimal value (approximate).

You switch between them using the `Cycle` command bound on [EEX] (or [x10^x] on my keyboard images). Like the space / EVAL key, its role is different when editing and when you are just looking at the stack.

- When you are editing and are after a number, it enters the exponents separator, e.g. type [1] [EEX] [3] [2] to enter 1E32.

- When you are editing and are in a unit, it changes the scale for the unit. So if you entered [3] [UNITS][LENGTH][m], the command line is now showing 3_m, and if you type [EEX] you get 3_km, then 3_Mm, then it cycles though other scales like mm, cm, etc.

- When you are not editing, the Cycle command applies to objects on the stack. For decimal numbers and fractions, it cycles between the two. so [1][.][2][ENTER][EEX] gives you 1 1/5, and [3][ENTER][2][/] gives you 1 1/2, which [EEX] converts to 1.5.

- The Cycle commands has other important cycles, like polar <-> rectangular, or changing the scale of a unit value while preserving its absolute value (unlike during data entry), so if you have 1.5_m on the stack and hit [EEX] you get 15._dm, then 150._cm, and so on.

This is shown at 41:09 in the Stuttgart video.

Quote: It seems like it's buried quite deep in the menus. I really like this feature in the 49/50 where switching between the modes (RightShiftHold-Enter) is as easy as converting a number from a fraction to a decimal (RightShift-Enter). But I guess the lack of a [→NUM] key makes it less obvious where this would go.

[→NUM] is [Shift][1]. The mnemonic way coming from the HP42 / DM42 is to remember "ASN" as "As Number" instead of "Assign" :-)

Quote:The alpha plane has no accent-keys like the 48/49/50 (at least not that I have yet discovered) making it not possible to type letters with diacritical marks without using the [CHAR] menu, but maybe in the real world that really isn't relevant since it seems unlikely anyone would be trying to type long strings of text in here (like one might have in the 48) anyway.

Hey, I'm French, you don't think I would have left accents out, do you? :-)

I found it hard to remember where the accents were on the 48/49/50, plus it did not scale well to other languages, so the approach taken in DB48X for diacritics is the "character catalog".

Say that you want to enter text "L'été où être naïf, ça m'a couté", the key sequence is

[Shift][Shift][ENTER] @ Text entry
[L][Shift][Shift]['()] @ L'
[Shift][ENTER] @ Shift to lowercase
[E] @ L'e
[+] @ Show character catalog
[F5] @ Select é
[T][E][F5] @ L'été
[SPC][O][U][F4] @ L'été où
[E][Shift][F1] @ L'été où ê
[T][R][E][SPC][N][A] @ L'été où être na
[I][Shift][F2] @ L'été où être naï
[F][.][SPC][C][F4] @ L'été où être naïf, ç

and so on.

Quote:I think it would be more useful in the header to show the status of various modes in the place of where it currently just says "DB50X".

It only says DB50X if you have not loaded a state file, otherwise the name of the state file shows up there.

Quote: For example, the current angle mode (degrees/radians), along with an indicator of exact vs approximate.

The 'Header' special variable can be used for that.

Code:

«
    'ANGLEMODE' RCL " " +
    IF -3 FS? THEN "Approx" ELSE "Exact" END +
»

It is per-directory, so you can have different headers based on where you are in the hierarchy.

Quote: I see there is a “not yet implemented” for the rectangular/polar/spherical mode, so when that is implemented maybe that could be indicated, too, though I’m not sure the necessity of that when you already distinguish between them with different object types (which is also a nice touch).

After implementing different object types for polar and rectangular, I have not yet found an operation where the result could not be deduced from inputs alone, so at the moment it looks like these modes will be dropped entirely, much like the polar / rectangular modes for complex numbers.

Quote:I completely agree with your abandonment of 48/49/50 source code compatibility in favor of trying to do things the "right" way this time around. Honestly there are very few programs written for the 48/49/50 that I would probably want to run on the DB50X — most of the best programs there were either to reimplement what the 48 did poorly/slowly, to add functionality that nowadays would be better served by a phone (like PIM functionality or games), or are already implemented better (or presumably will eventually be implemented better) in DB50X. Your planned future functionality (MatrixWriter, EquationWriter, some CAS features) would pretty much remove any need for things I relied on third-party programs (like MetaKernel) on the 48 for.

I'm sure I'll come up with more, but that's probably enough for now! DB48X really excites me and i can't wait to have it in a more convenient format than just a web app. All in all, I am extremely amazed with what you have put together, and so far it's really turning out to what the 48SX (HP's most elegant calculator IMHO) should have been when it first came out, had technology been advanced enough at the time.

Thanks a lot for the feedback.