[MacLoggerContest] Contest coverage and configuration

[Jonathan G0DVJ]

So this thread is about achieving a really easy way to specify contest 
configuration which enables the widest scope of contests to be covered 
(since people don't want to have to use a different logger for 
particular events) but at the same time makes it simple for people to 
say I want to work XYZ contest and the set-up is done for them as far 
as possible...


Again to start things off ...

1) Can we achieve an all-bands contest logger in one insanely great 
app?   VHF/UHF/Microwave contesting is very different to HF contesting 
and AFAIK most existing software targets the two with separate 
applications.  However there are a lot of common aspects between the 
two categories of events and although more complex to design, I would 
encourage us to at least initially aspire to cover the needs of both 
types of contester within one app.  However I do think this is a 
classic area of where typical Mac software design philosophy can help 
to allow the things irrelevant to each category of event to be hidden 
from users as they use the other.   If you only do one sort of 
contesting, you may not be too concerned about comment on this point 
but spare a thought for those who do both and perhaps would like to 
achieve consistency and seamlessness whichever weekend (hence event) it 
is!


2) International scope.  It would be good to allow a new insanely great 
contesting app to cater for as many people as possible and that means 
providing the flexibility to cope with localisation - this has a number 
of related aspects ...

a) Some contests are only popular in Europe or the USA but not both.   
Some are only applicable to some areas (e.g. VHF contests in USA or 
Europe!)  By supplying reference files of data for as many different 
areas as possible (I think I can help here from a European perspective) 
we can make the appeal of the app as wide as possible.

b) Some contests have different objectives and requirements on the 
operators logging according to where the entrant is located.   e.g. in 
the ARRL DX contests I send a different set of information to that 
which I receive, being outside the USA and given the fact my objective 
in this case is different - to work only US stations - so the logging 
program should help me here by checking prefixes of stations I try to 
log for example.    Whereas in other contests such as CQWW, everyone 
works everyone and exchanges the same information.  By addressing both 
of these top level types we immediately cater for and support the 
operator in the best way possible.

c) Some countries/areas have different bands (segments) available.  For 
example, in the UK we have a whole series of contests on 4m (70MHz) 
which other countries don't.   Similarly, I don't know if you guys over 
the Pond have contests on 220MHz ? - a band that we simply don't have 
over here.    It would be nice to ensure that we at least allow logging 
on all the bands which people in different parts of the globe may need 
- although again maybe by asking the user one question about station 
location, the unnecessary/inapplicable  options could be hidden.

d) In different areas of the globe, within the same language, people 
use different terminology for the same concepts.  This aspect is far 
less important in my view but mentioned briefly for completeness.  One 
example would be that in North America you often use "Grid squares" 
(more important in VHF/UHF contesting) whereas over here in Europe 
people use "Locator" to mean the same thing!   There are contests here 
for example which use grid squares (e.g. WAB - worked all britain) 
which are not the same as the international locator grid square system 
:)   So just to be aware of these differences.


3) Configuring the exchange.   Consider these examples ...  One top 
level contest type is whether the location of the stations contacted is 
important.  For some events, just a report and serial number is 
exchanged.   There may be no multipliers/bonuses or other scoring 
complexities - simply a fixed number of points per accurately completed 
QSO logged.   So no location or other information is important.   This 
latter type of contest is important for the newer person to contesting 
or those who want to keep it very simple.
Alternatively in other event types, there may be a whole number of ways 
that the location of the station worked affects the score.   Typically 
sub types of this mean that the score is affected by (a) the call 
prefix of the station worked and/or (b) other information given in the 
exchange (such as ITU zone, CQ zone, province, state, county etc.)   
This scoring may be per band, per mode or per event as a whole.
Some events allow for other additional data to be exchanged for points 
(e.g. fixed items such as name or age, complex QTC information in the 
WAE DX events) and in others (e.g. RSGB Rotating Postcode events) the 
information exchanged depends on the information received in the 
previous QSO!
Doubtlessly, some of you will know of other events where additional 
schemes which can't be fitted at all into the types described here are 
required.  Please comment.


4)  Assuming we achieve the configuration of the contest in a typical 
Mac style user friendly way, is there any worth in using standards to 
specify and record these definitions of configurations?   I have been 
discussing this aspect at length with Jack W6FB - and although 
something like XML is an option, we have virtually concluded that this 
would be overkill and of little value at this point in time.  Most 
software currently uses its own file format.  I see the more important 
aspect as how we make it easy for people to set up for XYZ contest 
(i.e. the config files are supplied but details hidden from user 
selection) and also allow new configurations to be defined and added to 
the distribution as time goes on to accommodate rule changes and new 
contest events.  Maybe initially at least, as many existing contest 
loggers do, the latter aspect of changing and adding support for new 
event types could be left to the software author in order that we don't 
end up with lots of people all using some supplied config facility to 
create similar but slightly different and to varying degrees untested 
versions of the setup data files for the same contest :)
What do others think?

Please add other pre-contest aspects to this thread or new ones as 
necessary.


73,
Jonathan G0DVJ
--