Single hand data entry

[drewdrew122]

The system shall allow the user to enter the car number, car reading, and car class in one field without having to tab to a different field. The system shall allow the use of a common field delimiter to differentiate between the fields. Such as a space, or one of the special characters that appear on the numeric key pad (+, -, /, or *). This will allow the user to enter the car numbers and readings using one hand on the numeric keypad.

Possible entries of car number and reading could be: 27 101 27.101 27/101 27+101 27-101

[mcmillanator]

I think it will be better to have multiple fields and allow the user to move to the next field by pressing the enter key.

[drewdrew122]

I have a prototype at work I can show you. Remind me to remember my IP address so we can ssh into the machine and I'll run it for you. The reason I'd like a one handed data entry interface is because if the user is working alone, they will have their other hand on the sound decibel meter.

[mcmillanator]

Single hand entry is not a problem. I just want to have separate fields for the data. It's easier to organize the data, easier to maintain and less prone to bugs. The enter key on the number pad can be used to move to the next field. When you move past the last field on the row it'll jump to the next row.

[mcmillanator]

I have a prototype on codepen where I'm working out the UX for the readings https://codepen.io/mcmillanator/full/MxewXZ

[mcmillanator]

I have a new UX prototype here http://test-raceui.stanleymcmillan.com

Pressing enter will move to the next field. Fields can be left blank. Entering the same number will allow new readings to be appended to the existing entry for the matching number. The class can be updated. Readings can be removed by entering negative number.

TODO

• [x] Sort by number
• [x] Update number field to be type number ( With #5 in mind )

[mcmillanator]

@drewdrew122 Considering the difficulty with seeing the screen while readings are entered I'm having second thoughts about making the number field required. If it were required, and the user left it blank, then an error would be displayed. If the user doesn't see this error and thinks they have moved to the reading field they will end up entering a reading in place of a number. I'm not a UX or UI person, and I'm not sure about the best approach here. I won't save readings with blank numbers to the database. This is only a question of how the front end should behave. I don't have to display an error. Do you have a preference?

[drewdrew122]

So I guess its not that difficult to see the screen. We can see error messages for other things, like printing or network dropouts. If your system needs to display an error message for anything, that should be fine.

On Thu, Mar 7, 2019 at 12:40 PM Stanley McMillan notifications@github.com wrote:

@drewdrew122 https://github.com/drewdrew122 Considering the difficulty with seeing the screen while readings are entered I'm having second thoughts about making the number field required. If it were required, and the user left it blank, then an error would be displayed. If the user doesn't see this error and thinks they have moved to the reading field they will end up entering a reading in place of a number. I'm not a UX or UI person, and I'm not sure about the best approach here. I won't save readings with blank numbers to the database. This is only a question of how the front end should behave. I don't have to display an error. Do you have a preference?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/racerecords/RaceRecords/issues/9#issuecomment-470510289, or mute the thread https://github.com/notifications/unsubscribe-auth/AtniBXX08QY_wupAqt3HaOLxIXiKhYr6ks5vUQisgaJpZM4bRJ3P .

[mcmillanator]

Sounds good. I think I'll back log it for now. Nothing will break if a number isn't entered. I can decide how to handle it later.

[drewdrew122]

Accepting issue.