search

nojronatron / Bigfoot-Bib-Report-WL-Form

Customized Winlink Race Tracker Form and Template for use in Bigfoot ultramarathon events.
https://enchanting-pony-09ae40.netlify.app/bigfoot-bib-report-initial
The Unlicense
5 stars 1 forks source link

Feature: Scroll entries so last one entered is always at top of entries list #24

Closed nojronatron closed 1 year ago

nojronatron commented 1 year ago

This issue has been posted to promote debate over the pros and cons of implementing this suggestion.

The form contains a notice stating users should limit bib entries to a certain number. Currently this is just informational and is not enforced in any way.

Risk: It is possible to generate a Winlink Message that is larger than the current Winlink System hard limit of 120k compressed, which if just below that limit will slow-down the Winlink System and the user's Winlink Express installation as well as the recipient's system, and could result in failed message transfers. Any of these risks, if realized, will frustrate operators and slow down message transfers.

By applying a hard limit, the user will be blocked from adding more entries once the hard limit is reached.

There is no expectation that this limitation will be easy to change, as it will be an in-code (hardcoded) setting.

bytescream commented 1 year ago

I changed our form code at Windy (which then was used at Chain) to show 30 lines of entry. We would routinely get a full page of 29 entries from the people doing the recording on yellow lined paper with that many lines. This made it so I could always monitor what I had just entered, a very important thing when doing 4 pages of 29-30 entries per page. Then at the end of each 29 or 30 entries per page was a good time to post to outbox and start another.

However, if I had all the time in the world, I would have created/changed the event that posts the results to the data area and added a command to scroll the last entry into view. But, since 30 lines was not too much to show, I just left that idea idea alone.

You need to see the last line you just entered, no matter what is decided here. And some people crank up the resolution/magnification in the PC or the browser so even less than 20 can be viewed. Balance any changes with that requirement as well.

I would suggest simply making a Javascript Alert() popup on each entry over the decided max, that can be acknowledged but does not cause a hard stop. Or have the CSS change the textbox background to a reddish-pink as long as the total lines is over that hard-coded number.

bytescream commented 1 year ago

...or have an animated monkey image display modally to delay your being allowed to continue to enter data for a few seconds on each extra entry. Yeah, that's right. It is a joke.

nojronatron commented 1 year ago

Hard limit might not be an issue, but forcing a user to scroll down to check the last bib entry breaks the user's workflow, so this Issue has been renamed.

Goal: Implement a means to keep the last-entered bib number at the top of the Entries box so it is likely to always be in view even for smaller (or zoomed) viewports.

nojronatron commented 1 year ago

See fix in PR #33