[MacLoggerContest] Exchange entry methods

[Jonathan G0DVJ]

So this thread is about achieving the best way to accommodate most 
people's preferred style of logging the contest QSOs in realtime as 
efficiently, accurately and easily as possible ...


To start things off ...

Most existing contest loggers approach this in one of 2 basic ways 
(with different variations) ...

1) The operator is faced with a logging line consisting of separate 
dedicated fields into which the various parts of the contest QSO 
exchange are entered and then provided with one or more ways of quickly 
moving between these fields (e.g. TAB, SPACE, ENTER etc.)   When the 
operator is content that all required data has been logged the QSO is 
committed to the log.

2) The operator is faced with one single field into which he/she can 
enter any of part of the contest QSO exchange in any order followed by 
Enter (or some other key), and the software uses various methods to 
decipher which should go into which actual field in the log.   When all 
required fields have had some data entered, the QSO can be committed to 
the log.


I note a number of principles that various people have mentioned about 
this part of the process in other mails ...

-  for speed, the entry should be entirely keyboard based and no 
mouse/pointing required
-  again for speed reasons, as well as ease of thought, single 
keystrokes should be used (i.e. no sets of key combinations to learn 
for control functions).
-  for cases where corrections must be made - it must be easy to amend 
the right field contents quickly
-  for some data parts of the exchange (e.g. callsign) it is preferable 
to reflect information such as potential dupe, potential mult/score, 
partial matching from standard contest databases such as that 
maintained by K5ZD as individual characters are typed, not after the 
whole call has been entered.
-  for logged data items which the operator need not type, that data is 
automatically populated by the software from various lookup sources (or 
a best guess made when possible that can be easily 
overridden/overtyped)
-  for reliability and integrity, particularly realising that many 
contest efforts are from field locations perhaps using generators, QSOs 
should ideally be sent to disk after they are individually committed, 
so that if power is lost for example, only uncompleted/uncommitted QSOs 
might be lost when the system is restarted.
-  from a computing viewpoint, the application should be multi-threaded 
in the sense that entering a QSO exchange should not hold up other 
features happening in background or parallel (e.g. a cw or voice keyer 
could be running while the operator is entering data from the exchange 
that he/she has heard).


I imagine that different individuals (even within the same team taking 
turns at operating) will favour one of the two basic ways listed above 
more than the other.   Does it therefore make sense to offer both as 
alternative tabbed panes in the main window which can be toggled at 
will to offer the 2 ways to enter QSOs into the same log?   Some of the 
principles listed are easier to uphold in the case of one of the ways 
than the other.


Are there any other ways (existing or novel) that are not variations of 
one of the 2 described above, which would work?

What other principles could we agree on as characteristics of this QSO 
entry process to add the 6 I have listed above?


Please comment ...
73,
Jonathan G0DVJ
--