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

[Jonathan G0DVJ]

Hi Jack et al.

Thanks for responding both on the email list and also directly to me - 
I will reply personally too but I just wanted to answer a few things 
that you raised in public too.

On Jan 28, 2005, at 11:39 pm, Jack Brindle wrote:
>
> First, I would like to take issue with you over the issue of the 
> Windows contest software not being stable/reliable/usable. I have been 
> using N1MM logger for several years with few problems.

I worded my original mail very loosely - sorry - I didn't mean to 
criticise the Windows contest software per se in terms of 
reliability/stability etc, rather I had meant to contrast the 
characteristics of the platforms that the developers have to rely upon. 
  Most people would agree I think that UNIX based systems are inherently 
more stable than Windows based systems - and specifically the consumer 
versions of the latter (95, 98, ME, XP Home etc,)   Also from the 
system perspective, it is always likely that when the hardware and 
system software are produced by the same crew (as with Apple), one is 
likely to end up with fewer anomalies and weak points.  However we 
don't need to elaborate on these types of benefits since we are all 
Apple users here LOL.

I too have successfully used a variety of contest software (CT, SD, 
TacLog, WGV, WriteLog etc.) for many years - but like you not on my 
platform of choice.   Like so many I have to have a PC in the shack 
simply for contesting!

> I spoke with Tom about porting his code over to the Mac. He offered 
> his source if I wanted to try.

I don't think a port of code from any of the other systems would result 
in the sort of top end product I was talking about.   I too have 
discussed ports of the SD software that I (and many people in Europe) 
use most on PC with its creator Paul O"kane but it isn't going to 
happen :)    However taking the best approaches to end up with a very 
usable powerful system from a number of existing PC packages as ideas 
is a very sensible approach (see later below).

> As I noted above, I have been working on this for two years, and it 
> isn't ready. The folks who write contest software on the PC have been 
> at it for much longer. It isn't an easy task to get a full-featured 
> system, so it really isn't surprising that there is a lack of this 
> type of software on the Mac.  From past experience it will be a slow, 
> evolutionary user-dependent effort that brings the software to a level 
> we really want.

I also have a professional background in Computer Science and have been 
a software developer in the past - so I do agree with you that top end 
full featured systems are not instantaneous projects - hence my 
original mail worded as a dream and couched as hallucination :)   And I 
certainly agree that it is not an easy task to develop really top notch 
apps.
However really nice software has been produced for Mac OSX in recent 
years (I already quoted Don and Chris's software amongst others in 
previous mail) and so it need not be such a long term project as one 
might imagine given that a number of features are already implemented 
in some of the existing quality programs around.   For example, I 
suspect Don's timescales in producing the 3D map addition to MLDX were 
shortened by the fact that his MacDoppler software already featured 3D 
mapping.

Don and I have discussed the contest logging topic before - and I 
accept that for him or others to invest professional time in developing 
such a product requires some confidence that there is a definite 
reasonably sized market for it.   I am therefore delighted by the 
response on this small group (mailing list) even so far in a short 
time.


I will be delighted to discuss the features of contest software with 
you in a 1-1 email Jack as you raised some interesting points.   
However let me leave 2 such points on the list for the consideration of 
others ...

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!

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 :)


Thanks guys for indulging me in this discussion.
73,
Jonathan G0DVJ
--