Comments interspersed with questions below.
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?
A. Modes may be looked upon from two perspectives. In the TRLog sense,
where the actual function of a key changes based on a mode setting, I agree
with Wayne that modes create more confusion than they solve. My preferred
interface paradigm places higher value on consistency of function in
response to a user action, than the ability to create multiple functions
from a single action. My brain requires less overhead to remember a few
more key patterns than it does to remember a key pattern and a mode setting.
Nevertheless, there are situations where it is useful for contest software
to adapt exchanges to fit circumstances, such as run vs. S&P. NA Sprint is
a good example of a contest where the required exchanges change between
every QSO. I have had good luck using the facilities already in WL to
create "modes" for myself through the use of the SendCallExchangeKey,
MoveNextOnEnter and QrzFunctionKey .ini options, with the Enter sends
exch/QRZ entry option. I believe that WL is presently on the right track in
approaching the mode problem with a large number of exchange memories and a
rich macro language to program the memories.
2. zooming of the bandmap. how useful is this to you?
A. In my experience, the band map is fine the way it is.
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?
A. It's not clear what the reviewer hopes to accomplish by having a
collection of floating windows, that can not be accomplished by docked
windows in a frame. The WL user is free to make the session frame any size
desired, from a small frame with only a few docked windows, to a full-screen
frame with all available windows. I would not change WL in this regard.
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?
A. While WL is a terrific value, it is a commercial product that I purchase
under the assumption that the vendor will have made a good and reasonable
effort to assure quality. Software quality takes time to achieve, and I'm
willing to wait. I appreciate the efforts of the WL beta testers, but I'm
not interested in becoming one of them.
As to the reviewer's comments about updating software in the middle of a
contest, that seems ill advised regardless of the product under
consideration.
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).
A. I believe that the update process for WL could be more streamlined than
it is at present. Having full distributions install the most recent data
files at release time is correct, since a clean install would not operate at
all if it did not include at least some data files. Updating the data files
is presently a pain, since there are three types of data files (masters,
namedmul.ini and cty data) that all come from different places (that
occasionally change) and are updated at different times. I would like to
see WL provide a data file upgrade package. This distribution would update
all relevant data files to latest versions. Since the impact of data file
update on WL functionality is almost nil, this would be the low-risk upgrade
option that could be applied right up to 0000Z. The WL program upgrade
package should remain free of data files, so that existing data files would
remain in tact if an older upgrade distribution is applied for any reason.
Applying the program upgrade distribution is the high-risk upgrade, that
should be tested thoroughly before actual use to insure compatibility with
the existing station configuration.
I hope this helps.
73+GL
Jim, W8WTS.
_______________________________________________
WriteLog mailing list
WriteLog@contesting.com
http://lists.contesting.com/mailman/listinfo/writelog
WriteLog on the web: http://www.writelog.com/
|