43s status

[Bit]

(01-01-2015 07:38 PM)brouhaha Wrote:  

(01-01-2015 04:47 PM)Bit Wrote:  I think it'd make sense to name and label the menu keys (M1-6 perhaps?) so they can be more easily referred to.

There's an existing calculator documentation convention (since 1986) that the soft menu keys are referred to by the name of the function they perform at the time, typographically represented as an image of the the dot-matrix legend as it appears on the display.

I have a strong preference for NOT having any legends on those keys. IMO, such legends don't add anything but clutter and confusion. The actual position of the key isn't helpful in documentation, as that can shift from one firmware version to another, or when certain programs are loaded. Also referring to a menu function by name rather than e.g. F4 is better because F4 won't do the right thing unless you're at the right menu. The documentation can give a sequence like "TRIG g ACOSH" (with ACOSH shown as a soft menu item), and that is much more useful than stating it as "TRIG g F4".

That convention makes perfect sense in those contexts where there's no uncertainty about the menus that are or can be displayed, e.g. in some finished documentation. However, some nomenclature is required in order to refer to the keyboard or to the menus themselves, in a meta context if you like.

Having labels on those keys wouldn't prevent the documentation from using the sensible method you described. Nor would it prevent anyone, who knows what they're doing, from understanding that "TRIG g ACOSH" means push e.g. F4 once in the TRIG menu. But if they're confused and you're trying to help, it's useful if you can simply tell them it's F4, rather than having to say something like "the third unlabeled key from the right in the top row". If there are no labels on the keys, people will come up with ad-hoc and inconsistent names whenever there's a practical need to refer to a physical key instead of a soft function.

[walter b]

(01-01-2015 09:35 PM)Gene Wrote:  I also ask the question Paul did. The operators in the 2nd column looks most un-natural to me. IMO, they should be on the right ala HP 41 style if you have the column of keys on the left ala HP 42S style as shown.

And this is a very strong dislike.

Would the alternative I mentioned above be acceptable for you?

d:-?

[rprosperi]

(01-01-2015 09:35 PM)Gene Wrote:  The operators in the 2nd column looks most un-natural to me. IMO, they should be on the right ala HP 41 style if you have the column of keys on the left ala HP 42S style as shown.

And this is a very strong dislike. On a scale of 1 to 10 where 1 is my favorite and 10 is a TI-1200, this is a 9. Ugh, again IMO. :-)

Strongly agree, which is also consistent with virtually all Pioneers.

Decorum and Robert's rules of order prevent me from comparing the proposed layout of the operators to something as frightening as a TI-1200, but since Gene already did, Yeah! Damn.

(01-01-2015 09:55 PM)Bit Wrote:  Having labels on those keys wouldn't prevent the documentation from using the sensible method you described. Nor would it prevent anyone, who knows what they're doing, from understanding that "TRIG g ACOSH" means push e.g. F4 once in the TRIG menu. But if they're confused and you're trying to help, it's useful if you can simply tell them it's F4, rather than having to say something like "the third unlabeled key from the right in the top row". If there are no labels on the keys, people will come up with ad-hoc and inconsistent names whenever there's a practical need to refer to a physical key instead of a soft function.

I also agree with Bit's comments. Having labels will allow unambiguous references to specific fixed keys, regardles of the current display (e.g. to invoke diagnostics menus, reset or similar non-modal functions); I've no strong preference for which labels are printed (F1 vs M1, etc.) but lean towards F1-F6). That said, I also agree with Eric that all documentation referring to functionality should indeed use the label shown in the LCD bit-map for that function such as the "ACOSH" in the example, which is clear to even new users, and also allows for s/w updates which could move an item, without needing documentation updates.

[walter b]

I strongly dislike repeating polls. The community wanted the arithmetic operators going to the left below ENTER. So either the navigation keys will go to the right - then I suggest moving <= for avoiding inadvertent deletions where XEQ was meant to be pressed - or they will go to the far left.

d:-I

[Massimo Gnerucci]

(01-02-2015 09:10 AM)walter b Wrote:  So either the navigation keys will go to the right

go for it

(01-02-2015 09:10 AM)walter b Wrote:  - then I suggest moving <= for avoiding inadvertent deletions where XEQ was meant to be pressed

I don't think this is needed. I have EEX and 9 around ← on my 41s, and I can't remember missing the target...
Then it is NULLable, isn't it? And what about Undo? :)

[Gene]

Perhaps the poll should be one of three:

1) As you have shown with two columns of keys on the left before the digit keys to the right.

2) Column of operators on the left, then the digit keys, then a column of navigation keys / XEQ on the right.

3) Column of navigation keys / XEQ on the left, the digit keys, then the column of operators on the right.

?

[Marcus von Cube]

(01-02-2015 12:39 PM)Gene Wrote:  1) As you have shown with two columns of keys on the left before the digit keys to the right.

2) Column of operators on the left, then the digit keys, then a column of navigation keys / XEQ on the right.

3) Column of navigation keys / XEQ on the left, the digit keys, then the column of operators on the right.

I think 3 has already been ruled out by previous polls. I vote for option 2. With slighly wider numeric keys we even would get some additional esthetics and usability.

[matthiaspaul]

(01-01-2015 09:35 PM)Gene Wrote:  The operators in the 2nd column looks most un-natural to me. IMO, they should be on the right ala HP 41 style if you have the column of keys on the left ala HP 42S style as shown.

And this is a very strong dislike.

I agree with Gene here.

I very much appreciate the WP 43s and 34s projects (actually, having learnt about them only recently, I am quite excited about them and might even help in their further development at a later stage (no time for it right now, unfortunately). I also like much about the WP 34s keyboard layout, although having some background in user-interface-design as well, I think, that there's some room for further improvement without adding clutter. However, I'm afraid, I don't particularly like the current (early?) proposal for the WP 43s keyboard layout (except for the softkeys idea).

IMHO, the highly important numeric keypad should be in the center of the lower section of the keyboard (sort of in the center of "gravity"), with the main operator keys to the right and the modifier/navigation keys to the left. After all, if this project should become a success beyond the group of die-hard-fans of old HP calculators, we should IMHO try to keep some of the true benefits of HP calculators (f.e. ENTER key), but we certainly don't need to deliberately deviate from the basic layouts found on most any modern calculators, including HP ones, just to be different... People might be willing to "cope" (in their view) with RPN and an ENTER key rather than having brackets and "=", if the "product" is otherwise convincing enough to give it a try (and they might thereby become RPN supporters as well), but I doubt anyone not already used to it (including many who do love RPN already) would be willing to accept the operation keys on the left side of the digits.

Deviating from most HP calculator keyboard layouts, I would rename the [EEX] key into [EXP] and move it to the current position of the [R/S] key (that is, right next to the [.] key). This is where the key is found on many other calculators, and given that, like [.], it is directly related to numeric input (and at least in theory could also be used in other bases than 10) it is also a "natural" place for this key (even more so than "+/-" which is also found in this location on many calculators). "pi" and "e" should be located on shifted positions of the [EXP] key, as seen on many other calculators. In alpha mode, [EXP] in this position should possibly return a space (" ").

(On the WP 34s I very much like the location of the [f]+[IP] and [g]+[FP] shifted functions on the [.] key, but the rarely needed [h]+[./,] toggle could be replaced by a toggle between "ab/c" and "d/c" modes, thereby freeing up two positions in the top section of the WP 34s keyboard. In alpha mode, [.] could return a "," (perhaps swapped with "." depending on the status of the [./,] flag).)

Like the [R/S] key, I would move the [XEQ] key out of this area of the keyboard, as IMO it does belong there more by tradition than by function - both keys would just as well fit nicely into the upper half of the keys. The former [XEQ] position combined with the two up/down arrow keys could become three modifier keys, which combine the functionality of up/down with the [f]/[g] modifiers (and possibly more), so that we no longer need the [f]/[g] (and [h] on the WP 34s) modifiers in the upper part of the keyboard, thereby freeing up two (three) keys.

(On the WP 34s, [CPX] could move into the now free position of the [EEX] key in the ENTER row.)

The [A]/[B]/[C]/[D]/[E]/[F] keys, which are also digits in alternative bases, are important enough not to be split over several rows, they should therefore be located in a single row. In order to avoid confusion, they should match the corresponding character positions in alpha mode.

(Sidenote regarding WP 34s: As far I as see it, on the WP 34s, the [f]+[HYP] and [g]+[HYP] assignments are unnecessary, as the [>] prefix key could also function as a "HYP" prefix for them (by [>]+[f]+[SIN], [>]+[f]+[COS], [>]+[f]+[TAN], and ASINH/ACOSH/ATANH could also be reached by [>]+[g]+[SIN], [>]+[g]+[COS], [>]+[g]+[TAN]). This would allow us to move the SIN/COS/TAN functions leftwards by one - as it's a bit odd to not start the SIN/COS/TAN sequence in column 1 or 4. With [CPX] moved into the ENTER row to the position of the former [EEX] key, and the [f]/[g]/[h] keys combined into the three up/down-keys column, the [>] key could move to the former position of the [h] key, so that the whole top row could become function keys, and we could possibly add [A]SEC[H]/[A]CSC[H]/[A]COT[H] or have room for often needed x^3 and 3rd_root(x) functions. Perhaps, [>] could even have multiple prefix states, so that we could make missing trigonometric functions VSIN/CVS, VCOS/CVC, HVS/HCVS, HVC/HCVC, EXSEC, EXCSC, and CRD available as well.)

Greetings,

Matthias

[walter b]

Hallo Matthias,

Thanks for sharing your thoughts. I'll need more time to analyze them. Just two quick suggestions:

1. Take your time and please read some of the older threads about the 43S. It all started in November 2012. And there were several polls concerning the layout.
2. For your ideas about the 34S, a little picture would tell a thousand words.
   

d:-)

[matthiaspaul]

Hi Walter.

(01-18-2015 09:50 PM)walter b Wrote:  Take your time and please read some of the older threads about the 43S. It all started in November 2012. And there were several polls concerning the layout.

Yes, I already read a few, but it will take some time to catch up...

Quote:For your ideas about the 34S, a little picture would tell a thousand words.

Unfortunately, I don't have any graphics applications (except for PCB layout software). I could possible use ASCII arts (but the forum software would most probably destroy it - does it support BBCodes for tables?), or I may use a spreadsheet. What software are you using to design the keyboard overlays?

Greetings,

Matthias

[Marcus von Cube]

(01-18-2015 10:26 PM)matthiaspaul Wrote:  I could possible use ASCII arts (but the forum software would most probably destroy it

Not if you embed them CODE tags.

[Bit]

(01-18-2015 09:20 PM)matthiaspaul Wrote:  ...
The former [XEQ] position combined with the two up/down arrow keys could become three modifier keys, which combine the functionality of up/down with the [f]/[g] modifiers (and possibly more), so that we no longer need the [f]/[g] (and [h] on the WP 34s) modifiers in the upper part of the keyboard, thereby freeing up two (three) keys.
...

Very interesting ideas!

How would the combined modifier/arrow keys work specifically?

[walter b]

Hallo Matthias,

(01-18-2015 10:26 PM)matthiaspaul Wrote:  I don't have any graphics applications ... What software are you using to design the keyboard overlays?

There's a little application called "Paint" included in every Windows OS for decades. Not very comfortable but allows doing what's necessary.

d:-)

[John R]

(01-02-2015 09:10 AM)walter b Wrote:  I strongly dislike repeating polls. The community wanted the arithmetic operators going to the left below ENTER. So either the navigation keys will go to the right - then I suggest moving <= for avoiding inadvertent deletions where XEQ was meant to be pressed - or they will go to the far left.

d:-I

Respectfully -- I realize this is a religious issue for many here, and possibly a sore point for the developers -- this thread from the old forum seems to indicate that the community preference was to have the arithmetic operators on the right, but that a private caucus among the developers eventually resulted in the opposite decision. Ultimately the placement of these keys is (and should be) up to those who are actually developing the product, of course. But unless I am misreading the earlier thread, or unless some of the posters in that thread are misrepresenting the earlier facts, it seems to imply that the placement of the arithmetic keys on the left was a developer decision that overruled the community preference to have them on the right.

[walter b]

Hi John,

(01-24-2015 04:35 AM)John R Wrote:  I realize (1) this is a religious issue for many here, and possibly (2) a sore point for the developers -- (3) this thread from the old forum seems to indicate that the community preference was to have the arithmetic operators on the right, but that a private caucus among the developers eventually resulted in the opposite decision. (4) Ultimately the placement of these keys is (and should be) up to those who are actually developing the product, of course.

(Numbers inserted by me.)

1. Certainly.
2. I'm pretty neutral in that matter still. I only hate swapping these two columns every fortnight.
3. I took the time and read that old thread again. There were people with very firm opinions but - in my view - no clear majority among those who participated. And there were earlier threads, too. So, a decision had to be made at that time in 2013, and we (Eric, Richard, Pauli, Marcus, and me) decided per our votes as developers (4) we'd go with the operators on the left ...
   

... though we repeated our market research later on this forum, but there's next to no progress in that matter for many months. After all, let me repeat FYI that the 43S will have a customizable keyboard: so anybody not content with the startup default layout may reassign the functions in the way the arithmetic and navigation keys are swapped, for example. One press on [USER] will then switch to that person's user layout and a suitable overlay will modify the surface accordingly, so even the people feeling overruled should be happy.

I hope this explains a bit. And I'm convinced we won't talk about that again and again as soon as we had some real 43S stuff to play with. But alas ...

d:-)

[John R]

(01-24-2015 06:18 AM)walter b Wrote:  I hope this explains a bit. And I'm convinced we won't talk about that again and again as soon as we had some real 43S stuff to play with. But alas ...

Thanks for the elaboration. I did try to track down the earlier threads that supposedly established a clear majority preference, and while my search was not exhaustive, it did seem like the forum was relatively evenly split. (I will hypothesize that this is because people on this forum are relatively evenly split between those whose first HP was a Coconut or earlier, and those whose first HP was a Voyager or later.) In any case, I'm looking forward to the final product, wherever the arithmetic operators end up.

[anetzer]

(01-24-2015 06:58 AM)John R Wrote:  those whose first HP was a Coconut or earlier, and those whose first HP was a Voyager or later

I guess that this is it exactly. Being of the coconut tribe myself I never really got handy with the latter designs and am quite happy with the - possibly preliminary – state of the 43S.

That said - and really without wanting to start a discussion, but here it is – I always felt that the left hand operators felt natural because of the Enter key right above them. Entering to one side of the keyboard and operating on the other always feels weird for me.

a.

[Massimo Gnerucci]

(01-24-2015 04:27 PM)anetzer Wrote:  That said - and really without wanting to start a discussion, but here it is – I always felt that the left hand operators felt natural because of the Enter key right above them. Entering to one side of the keyboard and operating on the other always feels weird for me.

Right. As already stated many times here, operators and ENTER need to be on the same side.

[rprosperi]

(01-24-2015 05:09 PM)Massimo Gnerucci Wrote:  Right. As already stated many times here, operators and ENTER need to be on the same side.

Even if it's the wrong side? (sorry, couldn't help myself Massimo...)

edit - thx Walter

[walter b]

(01-24-2015 06:07 PM)rprosperi Wrote:  ... couldn't myself Massimo...

What was it what you wanted to write?

d:-?

[rant] Life would be a lot easier if people would proofread their very own posts. [/rant]