[MacLoggerContest] 1st draft at consensus of top 5 MLC feature list priorities

[Jack Brindle]

We seem to be making feature selections by the perceived difficulty in  
implementation. Many might be amazed that some features, such as voice  
playback are very easy to implement, and others far more difficult. I  
would suggest that implementation difficulty might be scored by the  
developers, then a fresh look at priority be made. Examples in my  
discussion below.

By far the most difficult part of a contest program is user interface.  
Getting it right, with needed information displayed where it gets the  
operators attention, and lesser, but still import info also being  
displayed is rather difficult. Things that seem important may not be to  
the experienced contester. Things that don't seem important to the  
casual user, such as rate charts, are actually paramount to making  
tactical decisions.

Compared to UI, pretty much everything else is easy to implement. I  
believe we will need to pursue a UI discussion in order to nail down  
many features. For now, though, we continue...

On Mar 11, 2005, at 2:30 PM, Jonathan G0DVJ wrote:

> CHECKING & INFO FOR OPERATORS:
> - Real-time checking (preferably as callsign characters are typed  
> without touching other keys/buttons) of DUPLICATES, but also  
> country/band/locator/other multiplier analysis, beam headings,  
> potential multiplier status ) plus re-scoring in real-time &  
> continuous summary of scoring per band/mode/multipliers/etc.

Scoring is pretty easy to do. I believe that real-time scoring and  
statistics (rates, etc) are an important part of the contest data and  
should be displayed. It would be nice to have rate charts and graphs,  
but being a UI item, it is more difficult to do...

> INTERFACES & STANDARDS:
> - Use of all existing "standard" file formats used by other similar  
> software such as:
> 	-  Partial matches to the standard callsign contest databases  
> produced by K5ZD,
> 	-  Use of standard CTY country prefix files
> 	-  optional Cabrillo log entry file generation
> 	-  ADIF generation for integration with MacLoggerDX and other loggers  
> for your main station log

Decoding the standard files can be difficult because of a lack of  
documentation. However, this information can be uncovered, and their  
use should be a requirement.

Cabrillo is not optional. It is required for submission of contest  
entries for pretty much all major contests on this side of the pond.  
Without it a contest program is useless. I would put ADIF in the  
optional category, but it may be easy to drop it in from some other  
code piece. Developer?

> INITIAL BELL & WHISTLE:
> - A contest CW memory keyer

There are two ways to do this. The first is to output a CW digital open  
collector/drain signal to key rigs. This requires rather precise timing  
within the Mac, something not very easy in a non-real time environment.  
Still, it can be done. Perhaps an existing drop-in facility can be  
used?

The second method is to make use of the ASCII CW facility in many  
contemporary rigs. I would strongly urge the support of this - text to  
be transmitted is simply sent out the RS-232 port to the rig for it to  
encode and transmit. An alternative to this is to adopt one or more of  
the various keyer systems, such as that from K1EL, which also provide  
the same service. Probably both should be implemented in the long run.

I would also move the SSB audio play system to this level. It is  
amazingly easy to implement. Creation of the audio files can be done  
with external applications such as Peak LE or the freeware Audacity. I  
would NOT add audio recording at this time unless the author  
understands the part of the QuickTime system. When audio recording is  
added, it should allow for the creation of contest exchange files as  
well as recording of contest audio from the radio(s).

Also long-run should be a facility to insert numbers and letters for  
the exchange. Concatenating sound so that it sounds natural is not  
easy, and will require quite a bit of work in both the sound recording  
and playback facilities. I don't believe this facility is required in  
the first round.

> - A facility to connect to a public/private DX cluster (either on the  
> net or via RF/TNC) which highlights spots which are potential  
> multipliers.

I also believe this is mandatory, at least for internet access. This is  
more important than access through the packet system. In the US, the  
packet system has decayed tremendously, and has been surpassed by the  
far more reliable internet.

> - SO2R support for 2 radio operation

I agree with moving this to the future, but not too far. The foundation  
for it should be placed in the initial code, though, or a complete  
rewrite will be required for implementation. When it is added, the UI  
_will_ be modified extensively to properly display roles and  
operations. How much it needs to be changed will be determined by the  
up-front UI design.

> - Inbuilt contest voice "keyer" for CQ parrot calling.

See above. No reason not to do it now.


> - Multi-operator support for logging and statistical analysis of rates  
> and mults etc.
>
> - Rendezvous support for Multi-multi operation over ethernet or  
> airport networks.
>
> -  Integration with Apple's iChat for IM chat between operators in  
> multi-multi situations, spotting stations etc.

M/M support is very argumentative. It is in a major state of evolution  
in the PC world at this point.
I agree that it should be moved back to a later version.


- Jack Brindle, W6FB
------------------------------------------------------------------------ 
---------------------