Antenna Height Entry

[Jim Frame]

I'm perplexed by the antenna height screen -- the user interface for height entry seems totally unintuitive to me, so much so that every time I have to change the height I have to figure it out all over again.

I don't have any issue with most of the screen, it's the numeric entry system that befuddles me. Why isn't there a decimal point key? A user should be able to hit the CLR button and then type in a height, not have to fuss with cursor control. Most keyboard situations default to insert mode, not overwrite mode, so why subject the user to overwrite mode in this screen?

Is there a setting that I've missed?

Thanks!

 

[Matt Johnson]

I agree a decimal point needs to be added like I have shown:

I will request this be done. I'll also check to see if the keyboards could be switched to an overtype mode.

 

[Matt Johnson]

A more detailed explanation of how overtype mode should work:

In overtype mode, when the keyboard is opened the existing text is highlighted and when you start typing any existing text is replaced with the entered text. Hitting either of the arrow keys moves the cursor to the front or back and causes text not to be replaced.

 

[Javad]

We can label the ">" button as ">." For now assume ">" button is "." button too. This simple!

 

[Aleksey Kolesnichenko]

Good day
I want to remember the history of keyboard buttons changing


At the very begging we had only buttons < and > for cursor moving.

For example, we write new number from 0.0 to 12.34
We should push 1_2_>_3_4

After we added “.” with functionality of TRIMming end of integer part and moving to fraction part.

“.” allows us fast change 11111.456 to 123.456

We should push 1_2_3_.

But after we extend functionality of “.” to other parts of number

Meaning of “.” for NOT integer part is uncertain. That’s why we change “.” to image “x>|”

“x>|” trims end of current number part and move to next part

“x>|” allows us fast change 111°11’11.111” to 1°2’3.4” without Clr

We should push 1_ x>|_2_x>|_3_ x>|4_ x>|


As result

We don’t want add new button “.” because “x>|” has the same functionality
We don’t want change “x>|” to “.” because meaning of “.” for NOT integer part is uncertain

If you don’t like image “x>|” we can change it on any image or word(for example TRIM or NEXT)

Thank you

 

[Matt Johnson]

Hi Javad and Aleksey,

You are right after I think about it more that "." would duplicate “x>|”. What do you changing “x>|” to "." in the distance keyboard when the cursor is before the decimal place, once it is past the decimal it could change to “x>|” ?

The icon could have similar dynamic functionality for the bearing keyboard, changing between: ° ' " and .

 

[Jim Frame]

This approach is far outside the realm of standard user interface design, and it would appear that this convolution is intended to get around error checking of the entry. Is it really that hard to modify the code to use a standard text entry interface with pass/fail error checking of the result?

 

[Aleksey Kolesnichenko]

Most keyboard situations default to insert mode, not overwrite mode, so why subject the user to overwrite mode in this screen?

Now you can’t setup insert mode for numbers (Insert mode is only supported in text keyboard)


In our application numbers has restrictions in length

Keyboard interface automatically control length correction

You can’t write too many digits in number, angle or serial port (for example minutes in angle have max two digits length restriction)
We use replace (overwrite) mode because it is clear in case of length restriction

Insert mode logic does not have a single meaning

For adding insert mode in numeric keyboard we must decide what to do if number part has already maximum length and we try to add new digit

I see only one possible decision. It is removing last digit if length is too large

Let’s imagine float number with max length restriction 3 digits for integer part and 3 digits for fraction

Current value is 12.34 and cursor positon after digit 1

1|2.34

We start push key “0” many times

First “0” push 10|2.34

Second “0” push 100.|34 – digit 2 removed because of integer part length restriction, cursor is moved to fraction

Third “0” push 100.0|34

Fourth “0” push 100.00|3 – digit 4 removed because of fraction length restriction

Fifth “0” push 100.000| – digit 3 removed because of fraction length restriction

Sixth “0” push – do nothing because cursor is on last positon


I think this logic is not as intuitive as current – some digits appear and some disappear

But we can discus that

Thank you

 

[Aleksey Kolesnichenko]

This approach is far outside the realm of standard user interface design, and it would appear that this convolution is intended to get around error checking of the entry. Is it really that hard to modify the code to use a standard text entry interface with pass/fail error checking of the result?

In addition to error checking there is another significant reason of values length restriction
Length restrictions allow us guarantee that number will fit to its place on screen
So we can minimize scrolling and cutting of data view

 

[Aleksey Kolesnichenko]

Hi Javad and Aleksey,

You are right after I think about it more that "." would duplicate “x>|”. What do you changing “x>|” to "." in the distance keyboard when the cursor is before the decimal place, once it is past the decimal it could change to “x>|” ?

The icon could have similar dynamic functionality for the bearing keyboard, changing between: ° ' " and .

We have thought about mutable key view


Some of our men think that one stable icon is more understandable than a lot of views for one key with fixed functionality
So we must discuss that with more persons before implementation


Important notice

For some cases like integer number or fraction of float number we don’t have symbol like ° ' " .

And we can’t remove x>| at all
So in some cases we will see ° ' " . and in some x>|

 

[Jim Campi]

I was under the impression that there was a design error or bug that hadn't been addressed on the HI screen.

I appreciate the explanation and now understand the basis for data input (although it does seem awkward and unintuitive). I also thought RPN data input on an HP calculator was initially confusing. Now that's all the only method I use and have done so for the last 25 years.

Testing version of J-Field
The simple calculator (last choice on the calculator page) doesn't seem to work. Also I suggest that you remove the "." from this calculator so that all numeric input is consistent.

 

[Aleksey Kolesnichenko]

Thank you.
I have fixed this UI bug and simple calculator will be correct in next version.

I want explain difference between simple calculator and other types of calculators (data type oriented calculators).


Simple calculator does not have restrictions in length. If result value is too large it can be shown in exponential view like 1.23456789e+063. Simple calculator values don't have measurement units and don't support unit type compatibility. All values have float view. It has simplified input mode without cursor.


Data type oriented calculators resemble keyboard. They have guarantee units types compatibly and have data length and data view restrictions. Because of these restrictions we can write/read that calculators values to/from keyboards clipboards (memory).

 

[Jim Frame]

I understand that the choice of the antenna height input UI has a rational basis, what I'm questioning is whether it's the best choice given the awkward nature of that UI. As a matter of comparison, my Carlson data collector -- which also runs a version of Windows -- has a bunch of numeric input fields, all of which respond to a "normal" behavior (numbers and a decimal point). It seems to manage just fine without having to require the user to manipulate the cursor in order to quickly enter a number like 1.234 in order to proceed, and has error-checking features that prevent unacceptable input

In field work, any interaction with a device that requires keypresses slows down prosecution of the work, so quick is important, especially for input that may have to be changed often. It may be that I'm the only one who's slowed down by the antenna height entry format, but I doubt it.

 

[Jim Campi]

Thank you.
I have fixed this UI bug and simple calculator will be correct in next version.

I want explain difference between simple calculator and other types of calculators (data type oriented calculators).


Simple calculator does not have restrictions in length. If result value is too large it can be shown in exponential view like 1.23456789e+063. Simple calculator values don't have measurement units and don't support unit type compatibility. All values have float view. It has simplified input mode without cursor.


Data type oriented calculators resemble keyboard. They have guarantee units types compatibly and have data length and data view restrictions. Because of these restrictions we can write/read that calculators values to/from keyboards clipboards (memory).

Got it. I didn't catch the unit piece earlier...

 

[Matt Johnson]

The keyboards have been updated to dynamically show ° ' " or . in the trim button: