nojronatron / bigfoot-bib-report-wl-form Goto Github PK

Describe the bug
The "Form Information - READ" button opens a pop-up with information that is incomplete, and also mixes current form usage and UltraLive usage, which is confusing.

To Reproduce
Steps to reproduce the behavior:

1. Click on button "Form Information - READ"
2. Read what is there

Expected behavior
Popup/modal is fine but the text describing how to use this form needs to be updated so it:

1. Applies to actual form usage.
2. Is easy to read.
3. Includes some step-by-step.
4. Is succinct.

Screenshots
None

Desktop (please complete the following information):

• OS: Win 11
• Browser: chrome, edge
• Version: (latest for both)

Smartphone (please complete the following information):

• Device: Emulated using chrome DevTools

Additional context
The README might have some helpful text to use as a starter or reference.

When transcribing a long set of paper-based records, it can be easy to lose track of where one has left off. It would be helpful if the form assisted in keeping track. Such as:

• When posting to the outbox, copy the most recently supplied entry in to a readonly field indicating it was the end of the prior batch.
• When posting to the outbox, increment the Message # field and copy the old value into a read-only fiield.

These can take the place of / supplement notations made on the source paperwork. Between the paper and alt-tabbing into Winlink to review this can be replicated, but less clicking/scrolling at 2am the better,

Is your feature request related to a problem? Please describe.

Yes. It is possible to edit bib entries within the box where IN, OUT, and DROP buttons place the bib record data. If I make an error entering a bib record, I might decide to edit the data within that text box, but it is not easy to re-create tabs using just a keyboard (without using special techniques), and I'm likely to just add lots of spaces to make things line up.

If the Winlink Message recipient receives this poorly formatted data, they might not be able to easily import it to Excel (as the Form promises), and some data might be missed or incorrectly copied by the recipient.

Describe the solution you'd like

Allow the Form to support comma-delimited entries. If I must go in and update an error, I can easily re-create the comma(s), maintaining a useful data format.

The recipient will still be able to import the comma-delimited data and it will be less likely to cause a problem on their end.

Describe alternatives you've considered

• Blocking access to editing the text field: This is acceptable (for the recipient) but potentially troublesome for the remote operator. Everyone makes mistakes, why can't the remote operate fix a mistake before transmitting it elsewhere (pushing to problem to someone else)?
• Enable editing or removing "bad entries": This sounds easy but will require re-writing portions of data processing JavaScript and could clutter-up the user interface (even more than it already is), making it more difficult to use, especially on a small-screen device.

Additional context

BF Base will be provided the ability to process comma-delimited records, in addition to the current tab-delimited.

There are areas in the form where css and js code lines are probably never touched. Find them and remove them. Test to verify overall operation is not negatively impacted.

Take a peek at the html as well and trim unnecessary elements and attributes to make the code easier to read and maintain.

While using the form, I found it difficult to use the Tab key or mouse to move the cursor/caret to the necessary field or UI component, especially when bulk-entering lots of data (i.e. 30 or more).

Leverage key clicks to complete each bib entry to speed-up the process and spare the keyboard's TAB key.

IN => i
OUT => o
DROP => d

Once i, o, or d is clicked, the form should behave exactly as it does when the IN, OUT, or DROP buttons are clicked (or the space bar is pressed while selected).

BF/Destination Trail does not use UltraLive data at this time. For now hide the Save and Load UltraLive buttons but retain the underlying code so it can be utilized in the future.

File Bigfoot Bib Report.txt has the required Form: declaration but somehow cannot properly read the file as-is.

The fix is to add line-feeds between each line in the template file to ensure there is no incidental concatenation.

Update the file so each entry has an additional CR/LF character between each Template keyword and following argument(s) for proper operation.

Color: Using orange, blue, and black is a start. Research hi-contrast color options and employ them to meet minimum guidelines.

Screen Readers: Research HTML accessibility features and implement them to provide screen reader support.

Please describe.
When developing and updating this code, it is sometimes necessary to hit the Submit button to complete the expected end-user processes. When doing this in an IDE, Netlify (etc) there is no API for the form to send the data to, and the POST call goes literally nowhere.

Describe the solution you'd like
In this project, add an API server that can respond to REST calls Get and Post. When running, the server will serve-up a static webpage of the Form under test with its own FormServer and FormPort values added. When a Submit event happens on the Form, it sends a Post call back to the API server, and a log of the received data is recorded to a console/terminal so it can be analyzed to verify Form actual operation. Express.js is probably a simple option to consider.

Describe alternatives you've considered
Copy the Form to the proper Winlink Express file system area and use Winlink Express to launch a new message using the Form, and observe the results of submission by examining the new message that results. This is what I currently do, and will continue to do before deciding code is ready for consideration to merge in.

Additional context
Forms are coded with a Post action attribute set to http://{FormServer}:{FormPort}. When a Form is selected by a user in Winlink Express, that attribute is overwritten with http://localhost:8001, presumedly this is done to allow avoiding port conflicts, or potentially sending the POST data to a different instance of Winlink Express. Also an assumption: These settings are configured via Winlink Express Settings Menu, Form Settings configuration window.

A custom API service for development and testing would re-write the HTML form before delivering the static content, so that the Form Data that is Posted can be viewed, verifying the Form data is formatted correctly and contains the expected data.

Describe the bug
Stored Race Data includes the Event, Message, Send To, Location, and Subject to a file. Clicking "Save Race data" puts the data there. Clicking "Load Race data" only reloads the Bib Entries and not the top-section data.

To Reproduce
Steps to reproduce the behavior:

1. Complete the top portion of the form: Event, Msg number, Send to, Subject, and perhaps a bib number (optional).
2. Select an Aid Station and take note (e.g. Klickitat).
3. Click "Save Race data" button and click OK to save the file.
4. Change the Aid Station to something else (e.g. Marble Mountain SnoPark).
5. Click "Load Race data" button and click on the file saved in step 3.

Note: If you clear your browser cache and load the form so that NONE of the entries are filled you can:

1. Click "Load Race data" button and select a previously saved data file.
2. Note that none of the top-of-form entries are filled.

Expected behavior
Top-of-form fields are re-populated with data stored in a valid file loaded using "Load Race data" button.

Screenshots
Add screenshots to help explain your problem, only if necessary.

Desktop (please complete the following information):

• OS: 11
• Browser chrome 114.0.5735.134, edge 114.0.1823.51
• Version [e.g. 22]

Smartphone (please complete the following information):

• Device: n/a
• OS: n/a
• Browser n/a
• Version n/a

Additional context
None.

From bytescream: "...we always recorded the data on notepads in the order Bib#, in/out/drop, time. We should probably make the form collect the data in that order."

Is your feature request related to a problem? Please describe.

Whenever I look at the output from Save Race Data button, I struggle to read and understand the data. Usually this isn't a problem because the data is stored for backup and for moving to a computer with Winlink Express installed and not looked at. But for instances where data verification is necessary (for whatever reason), reading through the current formatting is tedious (at best), and definitely time consuming.

I think this can be improved.

Describe the solution you'd like

When saving race data, the formatting should include newlines, and proper spacing and indentation for readability. This includes the bib records themselves: They should be properly comma-separated rather than tabs, and if possible, displayed as collections.
When loading race data, it should be able to read-in this neatly formatted data so as not to break

Describe alternatives you've considered

• Not changing anything: The problem of difficulty reviewing data remains.
• Writing out data to a single line: Will line-wrap too easily causing added difficulty reading the data.
• Simple JSON: Be default, a JavaScript JSON parser does not make human-readable JSON, rather machine-readable usually for REST calls or efficient data processing.
• JSON with tab-delimited bib records: The bib records are still difficult to read.

Additional context

An ideal output would look something like:

{
  "thisVersion": "2.0.0",
  "EventTitle": "Bigfoot FF Test",
  "MessageNumber": "1",
  "address": "N0CALL",
  "Location": "WM_Wright Meadow (Rd.9327)",
  "msgsubject": "Bigfoot FF Test Wright Meadow (Rd.9327) Message #1",
  "numlines": "4",
  "TheData": [
    "106,DROP, 1510, 24, WM", 
    "106, IN, 1510, 24, WM", 
    "105, OUT, 1510, 24, WM", 
    "105, IN, 1510, 24, WM",
    ],
  "Comment": "Testing FF.",
  "previousRecord": {
    "runner": "106",
    "action": "DROP",
    "time": "15:10",
    "dayOfMonth": "24",
    "location": "WM",
    "messageNumber": "1"
  }
}

Right now, the versioning system is embedded in the HTML form, does not follow widely adopted convention, and is out-of-sync from GH Releases.

In the future I would like these changes:

• Contributors (myself especially) follow the semantic versioning convention, numbers only, denoting MAJOR.MINOR.PATCH levels to denote breaking changes, feature enhancements, and bug fixes (accordingly).
• Ensure the declared version is updated in the HTML file so each data-entry operator knows they have the correct (latest) version.
• Ensure the declared version is updated in the template TXT file so the recipient sees within the message that the correct (latest) version was used to construct the message.
• Stretch Goal: Find a way to manage versioning without hard-coding (perhaps with GH Actions).

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.

From bytescream: ...what about the case of entering times from before midnight? There ought to be a way to determine that if you are entering a time that is a certain number of minutes (hours?) before 2400, then the date is likely not TODAY. Maybe we let it default to "TODAY" and have a button for "Yesterday".

Keep it professional.

Describe the bug
From Doug H: "I was playing with the Bigfoot form and noticed that the Subject line is not taking in the message number form the web form. Bigfoot Quartz Ridge Message # Shouldn't the # be a 1?"

To Reproduce
From Doug H: " installed the txt and HTML file in C:\RMS Express\KF7RQ\Templates\bigfoot\

1. Open Winlink Express
2. Open a new message window,
3. Select Template
4. Navigate to the txt file "Bigfoot-Bib-Report.txt" and double click.
5. Enter several bib numbers in any set of buttons (in, out, drop)
6. Submit.
7. OK

At this point, back in the Winlink "Enter new message" box, I don't see the Message # in the subject line. Last night i tried it with and without incrementing the Message #. did not make a difference. I also tried "Save Rave Data" and "Load race data" with no effect on the message #. I am using Microsoft Edge on this PC"

Expected behavior
Clicking the Increment button should update the Subject Line to reflect the current number.

Screenshots

Desktop (please complete the following information):

• OS: Windows (10/11)
• Browser: Edge
• Version: (latest to date)

Additional context
None

"delBlankLines" has/had some.
Root out and remove duplicated code wherever possible without changing form functionality, so code is easier to read and update.

Identify state that could be stored in LocalStorage instead of global variables (where applicable).

The original form makes minimal use of it, but also enforces a workflow that repeatedly reformats, stores, and calls data in various ways. It might be possible to use LocalStorage to simplify the mechanics of:

• Format to UltraLive
• Remove UltraLive formatting
• Storing entered data to a file
• Restoring data from a file

There is also at least one case where NOT using LocalStorage causes a bug when loading data stored in a file.