So I think the next major feature I want to write is persisting data gathered from QRZ. Right now, there are currently two places to snag data from QRZ:
Entering their callsign in a log template and moving on to another field - this displays an 8 second popup with their name and QTH.
Using the QRZ search bar in the top right.
When logging, I want to persist the data from QRZ when the QSO is saved. But I’m not sure how this would work from POTA. If you get a P2P call for instance, that operator is definitely not at the QTH from QRZ, so it feels bad to persist it to the QSO. Is that a problem? Out of say 100 QSOs in a log maybe 5+% of them would not be at the grid square, city, state, that would be logged from QRZ. How should I handle this?
Here’s an idea: Display the other party’s QTH info that is pulled from QRZ in a single line in the main QSO entry panel.
Include a checkbox to “pull from QRZ.” If checked, the other party’s info is displayed but grayed out to prevent editing. If unchecked, those fields are cleared and the user can enter the relevant info. Toggling it on and off will switch between populating and erasing those fields ad hoc. The checkbox state would persist from QSO to QSO. Perhaps even better: If the user enters custom location info, toggling the “Pull from QRZ” checkbox would switch between the QRZ location info and the custom location info entered by the user. (Custom location fields would need to be stored separately in the database.) However, only the active info (reflecting the status of that checkbox) will be exported into the ADI file.
Order the fields such that the other party’s state appears first, so when the box to “pull from QRZ” is unchecked, the user can tab to it and enter the state. (Default text entry would be all caps, of course.) The second field should be the grid square, since that is most likely to be the next location-related field to be entered during a QSO.
With this approach, most users will probably keep the “Pull from QRZ” checkbox active. If the other party is at a portable location and gives either a park number (P2P) or reports a state that differs from the one displayed on that line, the user simply touches the checkbox and enters the actual location info instead.
When editing an individual QSO, this same “Pull from QRZ” feature could be incorporated as well (check/uncheck, populate when checked). This would be helpful if the activation occurred in an area where no internet service was available and the user wanted to populate these data fields after-the-fact.