Threaded Mode | Linear Mode

matthiaspaul · (This post was last modified: 09-20-2015 12:56 PM by matthiaspaul.)

Hi,

Playing with the HP Prime emulator, I identified a few repeating keystroke (or mouse-stroke) sequences which could be simplified in order to reduce finger movement for some frequent actions.

- The backspace button ("<x|") deletes the character to the left of the cursor in the input line. If there are no more characters left to the left of the cursor, pressing the button will have no function at present. The functionality could be improved by switching the function of the button to the behaviour of "DEL" under this condition, that is, start to delete the character on the right side of the cursor (if there is any).
Similar, but less commonly used, the shifted function of the "<x|" button ("DEL") should start to delete characters to the left of the cursor, if there are no more characters left on the right side of the cursor.
So, basically, whenever the "deleting" cursor hits the corresponding edge of the input line, its deletion direction should be reversed until the input line is empty. This would make it easier to edit the input line regardless of cursor position without affecting existing functionality.

- If the backspace button ("<x|") is pressed (shifted or normal) while the input line is completely empty already, it should recall previous contents of the input line and place the cursor at the end of that line (similar to what the HP 20b and HP 30b do in this situation). Again, this would not affect existing functionality at all, just extend behaviour.

- The "Shift" and "Alpha" keys already have some kind of toggle behaviour. This could be extended to a number of other keys as well:

-- Pressing "Home" invokes the "Home" screen.
-- Double-pressing "Home" should invoke "Home settings" (exactly like "Shift"+"Home", but with less finger or mouse travel)
-- While in "Home settings", pressing "Home" again closes the "Home settings" menu (like "ESC").

-- Pressing "CAS" invokes the "CAS" screen.
-- Double-pressing "CAS" should invoke "CAS settings" (exactly like "Shift"+"CAS", but with less finger or mouse travel)
-- While in "CAS settings", pressing "CAS" again closes the "CAS settings" menu (like "ESC").

-- Double-pressing "Apps" should invoke "Info". Pressing it again should switch to the "Apps" view again.

-- Double-pressing "Esc" should invoke "Clear" (perhaps with a pop-up "Are you sure?")

-- Double-pressing "Symb" should invoke "Symb Setup".

- Double-pressing "Plot" should invoke "Plot Setup".

- Double-pressing "Num" should invoke "Num Setup".

- Not sure if double-pressing "Help" and "View" keys should invoke their shifted functions, but otherwise double-pressing them could just close their views again (like "Esc").

- The "Menu/Paste", "Vars/Chars", "Toolbox/Mem" and "C/Unit" keys (normal and shifted) invoke either menus or special functions. When the key gets pressed again, they should close their corresponding menu or application again (like "Esc"). In addition to this, they should also close when one of the other keys is pressed, f.e. while you are in the "Vars" menu, pressing the "Toolbox/Mem" key should close the "Vars" menu and open the "Toolbox" menu, instead of requiring to press "Esc" first. Similar for the other combinations.

These enhancements should be very easy to implement (and they don't get in the way of existing functionality, so noone would need to be retrained or documentation be changed), but they would allow faster navigation via keyboard (and mouse in the emulator). The enhancements are intuitive and easy to memorize, and none of them invokes any "dangerous" functions (perhaps except for "Clear") on a double key press, which is important so that no problems emerge when someone accidently presses a key twice in succession (or because of some impairment).

Greetings,

Matthias

eried · 09-08-2015, 02:11 AM

(09-07-2015 11:04 PM)matthiaspaul Wrote: Hi,

Playing with the HP Prime emulator, I identified a few repeating keystroke (or mouse-stroke) sequences which could be simplified in order to reduce finger movement for some frequent actions.

- The "<x|" button deletes the character to the left of the cursor in the input line. If there are no more characters left left of the cursor, pressing the button will have no function at present. The functionality could be improved by switching the function of the button to the behaviour of "DEL" under this condition, that is, start to delete the character to the right of the cursor (if there is any).
Similar, but less commonly used, the shifted function of the "<x|" button ("DEL") should start to delete characters to the left of the cursor, if there are no more characters left to the right of the cursor.
So, basically, whenever the "deleting" cursor hits the corresponding edge of the input line, its deletion direction should be reversed until the input line is empty. This would make it easier to edit the input line regardless of cursor position without affecting existing functionality.

- If the "<x|" key is pressed (shifted or normal) while the input line is completely empty already, it should recall previous contents of the input line and place the cursor at the end of that line (similar to what the HP 30b does in this situation). Again, this would not affect existing functionality at all, just extend behaviour.

In my opinion this seems quite annoying and unnatural. Think of an user cleaning the first line of a paragraph, you don't usually count the chars you have to delete, just tap backspace several times (and this would end gobbling chars in front?, bad design...)

(09-07-2015 11:04 PM)matthiaspaul Wrote: - The "Shift" and "Alpha" keys already have some kind of toggle behaviour. This could be extended to a number of other keys as well:

-- Pressing "Home" invokes the "Home" screen.
-- Double-pressing "Home" should invoke "Home settings" (exactly like "Shift"+"Home", but with less finger or mouse travel)
-- While in "Home settings", pressing "Home" again closes the "Home settings" menu (like "ESC").

-- Pressing "CAS" invokes the "CAS" screen.
-- Double-pressing "CAS" should invoke "CAS settings" (exactly like "Shift"+"CAS", but with less finger or mouse travel)
-- While in "CAS settings", pressing "CAS" again closes the "CAS settings" menu (like "ESC").

-- Double-pressing "Apps" should invoke "Info". Pressing it again should switch to the "Apps" view again.

-- Double-pressing "Esc" should invoke "Clear" (perhaps with a pop-up "Are you sure?")

-- Double-pressing "Symb" should invoke "Symb Setup".

- Double-pressing "Plot" should invoke "Plot Setup".

- Double-pressing "Num" should invoke "Num Setup".

- Not sure if double-pressing "Help" and "View" keys should invoke there shifted functions, but otherwise double-pressing them could just close their views again (like "Esc").

Same with those, how about if double tapping space bar in your pc added a break line... it would drive users to madness. There is no double press for keyboards for a reason

(09-07-2015 11:04 PM)matthiaspaul Wrote: - The "Menu/Paste", "Vars/Chars", "CAS/Mem" and "C/Unit" keys (normal and shifted) invoke either menus or special functions. When the key gets pressed again, they should close their corresponding menu or application again (like "Esc"). In addition to this, they should also close when one of the other keys is pressed, f.e. while you are in the "Vars" menu, pressing the "CAS/Mem" key should close the "Vars" menu and open the "CAS" menu, instead of requiring to press "Esc" first. Similar for the other combinations.

I agree with this, sometimes is not as intuitive that everything needs to be ESCape, rather than switching directly...

(09-07-2015 11:04 PM)matthiaspaul Wrote: These enhancements should be very easy to implement (and they don't get in the way of existing functionality, so noone would need to be retrained or documentation be changed), but they would allow faster navigation via keyboard (and mouse in the emulator). The enhancements are intuitive and easy to memorize, and none of them invokes any "dangerous" functions (perhaps except for "Clear") on a double key press, which is important so that no problems emerge when someone accidently presses a key twice in succession (or because of some impairment).

Greetings,

Matthias

StephenG1CMZ · 09-08-2015, 05:38 AM

I am confused by the references to delete-left having no function a at the beginning of a line.

When I tap that key AT the beginning of a line, it begins to delete the previous line.

matthiaspaul · 09-08-2015, 07:49 AM

(09-08-2015 05:38 AM)StephenG1CMZ Wrote: I am confused by the references to delete-left having no function a at the beginning of a line.

When I tap that key AT the beginning of a line, it begins to delete the previous line.

Yes, but not when you are inside of an input line. The behaviour you describe should not be changed, of course, it should only affect the function while you are editing a line. Example:

- Type in 123456789
- Move the cursor back 4 times, so that is is located between 5 and 6
- If you now press "backspace" it will delete 5
- Next time you press "backspace", it will delete 4, then 3, 2, 1
- If you then press "backspace" again, it will do nothing
- My suggestion is that it should now work as "delete" and delete 6, then 7, 8, and 9, because it is inconvenient that you'd have to use "cursor right"+"delete" or "shift"+"delete" just to delete a few characters right to the cursor in the middle of some editing.
- Normally, you would correct the input and press "Enter", but if you'd continue to delete characters it would stop once the input line is empty. You would still have to press "Esc" to exit the line editing mode in order to go back to the behaviour your describe, so it possible to assign a "recall last input" function to this situation without affecting the functionality you described.

Greetings,

Matthias

matthiaspaul · 09-08-2015, 08:03 AM

(09-08-2015 02:11 AM)eried Wrote:
(09-07-2015 11:04 PM)matthiaspaul Wrote: - The "<x|" button deletes the character to the left of the cursor in the input line. If there are no more characters left left of the cursor, pressing the button will have no function at present. The functionality could be improved by switching the function of the button to the behaviour of "DEL" under this condition, that is, start to delete the character to the right of the cursor (if there is any).
Similar, but less commonly used, the shifted function of the "<x|" button ("DEL") should start to delete characters to the left of the cursor, if there are no more characters left to the right of the cursor.
So, basically, whenever the "deleting" cursor hits the corresponding edge of the input line, its deletion direction should be reversed until the input line is empty. This would make it easier to edit the input line regardless of cursor position without affecting existing functionality.

- If the "<x|" key is pressed (shifted or normal) while the input line is completely empty already, it should recall previous contents of the input line and place the cursor at the end of that line (similar to what the HP 30b does in this situation). Again, this would not affect existing functionality at all, just extend behaviour.
In my opinion this seems quite annoying and unnatural.

Not in mine. When I hit a key, I usually expect a function, and hitting "the key to delete characters" in a situation where the only characters left to delete are positioned on the right side of the cursor, I would not find it unnatural if it started to delete them rather than doing nothing at all. In fact, I find it annoying that you will have to press two keys to delete those characters (either "cursor right"+"backspace" or "shift"+"delete").

Quote:Think of an user cleaning the first line of a paragraph, you don't usually count the chars you have to delete, just tap backspace several times (and this would end gobbling chars in front?, bad design...)

I see the problem. While in an ideal world there should be a special function to "delete up to the beginning", there aren't enough keys (or modifiers) on a calculator for this. But the problem you describe is specific to typematic mode, so my suggestion could be narrowed down to not affect typematic mode and only work for individual keypresses.

Greetings,

Matthias

matthiaspaul · 09-08-2015, 08:31 AM

(09-08-2015 02:11 AM)eried Wrote:
(09-07-2015 11:04 PM)matthiaspaul Wrote: - The "Shift" and "Alpha" keys already have some kind of toggle behaviour. This could be extended to a number of other keys as well:

-- Pressing "Home" invokes the "Home" screen.
-- Double-pressing "Home" should invoke "Home settings" (exactly like "Shift"+"Home", but with less finger or mouse travel)
-- While in "Home settings", pressing "Home" again closes the "Home settings" menu (like "ESC").

-- Pressing "CAS" invokes the "CAS" screen.
-- Double-pressing "CAS" should invoke "CAS settings" (exactly like "Shift"+"CAS", but with less finger or mouse travel)
-- While in "CAS settings", pressing "CAS" again closes the "CAS settings" menu (like "ESC").

-- Double-pressing "Apps" should invoke "Info". Pressing it again should switch to the "Apps" view again.

-- Double-pressing "Esc" should invoke "Clear" (perhaps with a pop-up "Are you sure?")

-- Double-pressing "Symb" should invoke "Symb Setup".

- Double-pressing "Plot" should invoke "Plot Setup".

- Double-pressing "Num" should invoke "Num Setup".

- Not sure if double-pressing "Help" and "View" keys should invoke there shifted functions, but otherwise double-pressing them could just close their views again (like "Esc").
Same with those, how about if double tapping space bar in your pc added a break line... it would drive users to madness. There is no double press for keyboards for a reason

Hm, a keyboard for a PC and for a calculator are rather different applications. In fact, this is really operating system and application specific - I am aware of applications where keys opening some menus do in fact work as toggles, that is, they will close the menu again when the key is pressed again.

Your example of adding a line break or something similar on a double-keypress describes a different situation.
If you go through the list of keys for which I suggested this behaviour, there is only one ("Clear"), which directly invokes a function. In all other cases, it is just a matter of closing a menu just opened by the first press, or opening another menu or application instead - nothing that could cause any harm.

"Clear" would be an exception, but this would be in analogy with a lot of other calculators, which have a similar double function on their "Clear enter" key. It might be convenient, but I see that it could cause harm as well, if pressed accidently. Perhaps this should be bound on some user-configurable flag just to play it safe. Such a safety net wouldn't be necessary for the other keys, though.

Greetings,

Matthias

StephenG1CMZ · 09-08-2015, 09:14 AM

I hadn't realised you meant in an input.
I don't think that would work - swapping directions would be confusing I think, and people would end up deleting the wrong thing.

But your double-taps sound good

matthiaspaul · 09-13-2015, 08:08 PM

(09-07-2015 11:04 PM)matthiaspaul Wrote: - If the backspace button ("<x|") is pressed (shifted or normal) while the input line is completely empty already, it should recall previous contents of the input line and place the cursor at the end of that line (similar to what the HP 20b and HP 30b do in this situation). Again, this would not affect existing functionality at all, just extend behaviour.

I have to slightly correct myself here: Using the backspace key to delete a previously non-empty input line, the HP 20b and 30b will not recall the previous contents of the input line once the input line is completely empty, but the contents of the X register (lowest stack level) with full internal precision (regardless of any display modes, which might have previously truncated the display value). If you would continue to press backspace, these calculators would start to delete the freshly recalled input line from the right to left again, and so on. So, if you'd happen to delete too much, you get another chance. In exactly the same situation, the Prime (and the 50g) does nothing.

On the Prime there are other means to edit the lowest stack register (f.e. Cursor-up followed by Enter), that's why I suggest to recall the previous input line instead in the described situation (as an intuitive shortcut for Shift + Paste + Enter).

Sidenote: I was astonished I could not find this backspace key behaviour documented in the 20b/30b manual. It just says: "To correct a number entry, press the backspace key. Each press of backspace erases the last digit or symbol you entered", leaving open what happens if the entry line is empty. Is this really undocumented, or did I miss it somewhere in the document? Which other Entry RPN calculators behave in a similar way?

Greetings,

Matthias