WriteLog
[Top] [All Lists]

RE: [WriteLog] What should change in WriteLog w.r.t. this review?

To: <w5xd@writelog.com>, <writelog@contesting.com>
Subject: RE: [WriteLog] What should change in WriteLog w.r.t. this review?
From: "Gary Ferdinand W2CS" <w2cs@bellsouth.net>
Date: Wed, 4 Feb 2004 22:28:18 -0500
List-post: <mailto:writelog@contesting.com>
Wayne, my comments are interspersed.  While I have never used the N1MM
logger, other than brief trials but never in a contest, I have sufficient
experience to comment on WL, both single op CW and multi/multi CW, the
latter in an effort that logged many thousand of Qs across 4 operating
positions.  My prior logger was either TRLog or CT, depending on contest.

73, Gary W2CS
Apex, NC



> -----Original Message-----
> From: writelog-bounces@contesting.com
> [mailto:writelog-bounces@contesting.com]On Behalf Of W. Wright, W5XD
> Sent: Wednesday, February 04, 2004 9:30 PM
> To: writelog@contesting.com
> Subject: [WriteLog] What should change in WriteLog w.r.t. this review?
>
>
> I am interested in what current WriteLog users think might be changed in
> WriteLog with respect to the comparison in this review:
>
> http://www.pvrc.org/Newsletters/feb04.pdf   (scroll down to page 8)
>
> The specific points I wonder if I should pursue further are:
>
> 1. The reviewer thinks that "modes" in the program are good. That the
> program should change its response to certain keystrokes based on
> whether it
> is in the S&P mode or the Run mode. It has been my opinion for a very long
> time that modes cause more problems than they solve?

This one should be a no-brainer.  Purely from a marketing and business case
perspective, the lack of mode sensitivity is likely the single largest
obstacle to getting TRLog users to move to WL.  There are a lot of TRLog
users who would like an alternative.  For that reason alone there ought to
be the capability (not forced on us) to run WL in a mode-sensitive manner.

>From my personal perspective, I've used both TRLog and CT for major contest
efforts.  I find that when I'm brain dead (which happens more quickly now
than years past), I make fewer errors with the TRLog style than with CT.
When operating major stations (which mine is not), run mode is predominant
except for odd shifts in a multiplier position. The transition between the
two is far easier with a mode-sensitive logger since the brain dead op does
not need to do a thing differently (other than put it in the relevant mode
more or less once).

Single op is a bit different, for there you run into the need to switch
between S&P and Run more frequently and odds are you'll get caught in the
wrong mode now and then without realizing it.

On balance I too would like the mode-sensitive support for the operational
reasons stated above.  I agree with the reviewer.


>
> 2. zooming of the bandmap. how useful is this to you?

The bandmap I view as quite possibly the least useful appendage to WL.
There simply is not enough space to display a useful amount of information.
If I'm running and I'm using the bandmap to scan for some juicy mults, I
want to see the WHOLE band, not just a piece of it.  If I could zoom in (or
out) at will, I could tailor the display of the band map to suit my needs.
A means to jump to the next unworked station or the next multiplier is
important to have, too.  I think at least one of these was just added in
10.45, as was the ability to have the call window filled/cleared as you tune
across a frequency that has a call in the bandmap.  While I haven't used
10.45 yet, those improvements are spot-on.  You really listened. Thanks!!
But, still the bandmap doesn't give me a large enough, useful picture. (My
comparison base is TRLog's half-screen listing of calls - lots of data, but
cumbersome to use.)

I agree with the reviewer that some single-key (not pulldown) way to zoom
in/out is needed.

>
> 3. The reviewer takes away points from WL because its windows can
> be docked
> instead of floating on the desktop. Surely I should not remove
> this feature
> from WL?

I interpreted the comments a bit differently.  I would say I agree with the
comments that arranging the WL desktop is time-consuming and not all
information is intuitively place-able (if that's a word).  Sometimes
valuable space is wasted.

However, I do not agree that making all the WL "subwindows" true "Windows
windows" is the right way to go.  Too much real estate tied up with title
bars.  WL is currently able to use screen real estate far more efficiently
than if all the info were partitioned into Windows windows.  Individual
color specs, fonts, etc. are very useful, too.

Personally, I prefer the ability to move the data around, construct a
pleasing arrangement, and then dock it in place (and store the
configuration).  I think this is an overall plus for WL.  But it IS
time-consuming to "design" the desktop!  There's no denying that.

>
> 4. The review takes away points from WL because we don't update
> the software
> in real time during contest weekends and "updates come out
> infrequently". I
> have been reasonably happy with our beta test/release process (which
> routinely catches a number of bugs before they go out to thousands of
> users), but that process pretty much guarantees that from a request to a
> commercial release is a minimum of 4 to 6 weeks as that's how
> long it takes
> to get through the beta test process. Would users really prefer that the
> beta tests be publically available?

I think there's a distinction that is a matter of degree.  If we're thinking
10.45 level of update, most certainly a beta test is required.  10.45 is
really juicy. Full of excellent enhancements.  I note, for example, that the
reviewer stated that there's no way to clear the RIT with WL (other than by
hitting a key). While that used to be true, the 10.45 appears to have
addressed that problem superbly.  Again, thanks!

There are undoubtedly some things that are relatively minor that could be
issued in a more timely manner.  Perhaps all that is meant by the review is
that the support be more responsive in the peak of contest season as teams
confront issues.  Fixing bugs or operational quirks is different than adding
major product enhancements.  The former might be doable fairly quickly; the
latter generally takes more care.  At least that's been my experience in the
software industry.   Differentiate between "upgrade" and "minor
enhancement/fix" and release on separate schedules.  Perhaps the minor
update could even be a "use at your own risk" type of release.  Think about
it a bit.  Releasing code needn't be at only one extreme or another. Quality
needn't suffer, either.

>
> 5. The reviewer had 3 or 4 month old information regarding the
> way we manage
> the country files and multiplier files, so his specific complaints are
> inaccurate, but it still raises the question of how that should
> be done. The
> WriteLog FULL distributions have copies of those files that were current
> when the distribution was created, and the UPGRADE distributions
> do NOT have
> the files at all. This means that you have to download the new files, and
> you get notices on writelog@contesting.com when they change. I don't think
> its a good idea to embed those files in the UPGRADE installs
> because I think
> there should be exactly one way for a user to get the latest
> files and some
> users don't upgrade right before the contest, and some users upgrade their
> software, but not necessarily to the most recent version (and so would get
> old files if the UPGRADE had them).

Somewhere in the DOC, be it K9JY or the help/install doc, there should be a
cookbook that includes EVERYTHING that needs to be re-updated prior to a
contest.  Relying on master.dta, etc., files in ANY distribution be it
upgrade or full, a operator does at his/her own peril anyway.  It should be
common practice for an operator to run an update pass on the appropriate
files a day or two prior to a contest.

So, on balance, I don't care where and how you distribute them, because I'm
going to download the then-current versions just prior to a contest anyway.
This is a non-issue to me.  I didn't understand it when I saw the comments
in the WL reflector and I don't understand it now ;-)  But, a newbie needs
to know WHAT he needs to download.

>
> I invite email comments to any or all of the above, either direct
> or on the
> reflector. I personally value thoughtful answers the most (and prettymuch
> ignore flames and my-dog-is-better-than-your-dog comments) and I try to
> thoughtfully consider recommendations. However, I don't promise any action
> or even a response to any email (and I confess that I am guilty as charged
> in the review of not answered 100% of all email queries I get--I have no
> excuse.)

I found that my prior suggestions were almost all implemented in 10.45 -
either be design or coincidence, dunno, but a hearty THANK YOU for that
upgrade. It went a long way to improve many aspects of WL's operational
characteristics.

I'll close with one overall comment... I got sold on trying WL and then in
trying to shoehorn my TRLog brain into getting comfortable with it, for two
very simple reasons: Architecture and design.

TRLog's network support, relying as it does on serial port architecture and
DOS architecture, has reached end of life IMHO.  Worse, TRLog never
implemented any form of network recovery whatsoever.  WL is strong in both
these areas. It warmed my heart when one of our ops in the CQ WW CW had a
computer go down, requiring a reboot, and watching him almost giggle in
delight as he saw the log getting repopulated during the restart. Then he
glanced over at the stats and saw that his position was displaying the same
QSO numbers, multipliers, etc., as everyone else.  In TRLog, they would all
be totally out of synch by end of contest, requiring Byzantine
post-processing to determine what our score was.  With WL, what you see is
what you've worked.  The code you put in there to support ethernet and to
support log recovery in a M/M station is simply superb!

This characteristic transcends just about everything else IMHO.  Throw 10.45
in there and just about the only thing I'd add is mode-sensitivity and
bandmap zoom in/out to the mix.   OH, and one other thing: the ability to
list stats on each operator by call sign.  If I view the log a as a
relational database, I'd like to order the log by call sign and summarize
info (rates, bands, mults, etc).  Perhaps that's possible; I've just not run
across it.

73,

Gary W2CS
Apex, NC



_______________________________________________
WriteLog mailing list
WriteLog@contesting.com
http://lists.contesting.com/mailman/listinfo/writelog
WriteLog on the web:  http://www.writelog.com/

<Prev in Thread] Current Thread [Next in Thread>