[Ham-Mac] Hallucinations from this side of the Pond!

[Jack Brindle]

Some great points, Jonathan!

On Jan 29, 2005, at 6:45 AM, Jonathan G0DVJ wrote:

> I see two major structural components as key to whether a large number  
> of contesters will adopt a particular application:
>
> 1) Contest event configuration flexibility:
> I would advocate a high percentage of effort go into allowing the user  
> to easily but flexibly define the contest logging parameters for as  
> wide a range of worldwide events as possible.  This means significant  
> options for setting the exchange info to be passed and logged, the  
> supplementary information that is used (e.g. databases, prefixes,  
> zones etc,) and the scoring scheme upon which the event is based.   
> These 3 sets of parameters vary in all sorts of combinations for  
> events large and small, national and international, past present and  
> future.   To aid usability, I would suggest that standard template  
> settings for the major contest types be definable, loaded at start-up  
> and therefore sharable/extendable by users/contest organisers!

This is a major problem across the board for contest programs. N1MM has  
discussed various solutions - perhaps the best might be an XML  
definition for each contest that can be used for various contest  
programs no matter the platform. I could see contest sponsors releasing  
such a definition file with their contest announcements. The user would  
just download the file, set it up for his system, then start using it.  
There would probably be things that the user would want to enhance for  
their operation, such as the name for the entry window or something  
similar. Assuming Tom's suggestion to use XML, MacOS X's excellent XML  
support would make things relatively easy. As far as I know, nothing is  
defined at this time, although Tom may be adding something of this sort  
to his version 5.0 code.

Why is having a common definition so important? To make things much  
easier for the user. Not having to input the specific parameters  
available for a contest is a big win. Allowing the user to select  
entries within these parameters makes life easier, allowing the user to  
concentrate on the contest and not the software.

> 2) Input method for logging contacts in real time
> Here things need to be as slick as possible but different contest  
> operators prefer different approaches as being slick!   So again I  
> plead for maximum flexibility!   There are 2 fundamental approaches  
> ... A) have one entry field and let the machine figure out what data  
> is being entered at any particular time (TacLog uses this sort of  
> approach as did a contest logger for Mac many years ago from an HB9  
> developer).  B) have separate fields per data item and a slick way  
> (SPACE & Enter) for moving between them.  The advantage of this latter  
> approach is that it enables information to be fed back to the operator  
> in real time as each character of a data item is typed (SD adopts this  
> approach).   Hence as different OPs even in the same team using the  
> same system in an event may prefer different styles of input, my  
> panacea would be to see both basic approaches implemented and  
> selectable by Tabbed window panes (like MLDX does).  People could thus  
> select their preferred method as they take the chair to operate :)

I sent Jonathan an email discussing this already. I believe this is the  
biggest place that can, and needs to be, improved from the PC contest  
software. Variations of both of the ideas Jonathan mentioned are now  
available in PC contest software. In using them I really get the  
feeling (mostly from mistakes I have made in using them) that something  
better needs to be created. What that might be is very much open for  
discussion. Any ideas are most welcome!

My central belief is that the contest software should make it easier  
for me to operate a contest. If I have to spend time messing with the  
software while I should be making QSOs then something is definitely  
wrong. Most current contest software is overly complex and gets in the  
way of contest operations, slowing down the operator. Making it more  
"natural" would make things far better. We in the Mac world have been  
dealing with this for quite a while now. Perhaps we should lead the way  
for others?

Thanks, Jonathan, for bringing up this topic!
>

- Jack Brindle, W6FB (ex WA4FIB)
------------------------------------------------------------------------ 
---------------------