Re: An alternative for duplicate management ...
- It is perfectly understandable that ARRL doesn't want to ruffle anyone's
feathers, and I support that notion. They should be positively focused, and
offer constructive and useful information to all LOTW users. Getting
started with LOTW is already a complex enough experience that it still
manages to intimidate, frustrate, or alienate people who are normally
comfortable with using computers. Unexpected complications like the
"Roaming Profile" problem exemplify this challenge.
What interests me is that it should be possible to communicate with users
on this issue of excessive Identical Duplicates without hurting anyone's
feelings, and bring to their attention that the length of the queue could
be shorter if they took a moment to understand that THEY are contributing
to the length of the delay in the queue.
In fact, the system owes them an apology, because it has a flaw that they
have brought to light by doing what they are doing.
If I were unknowingly adding to the delay with duplicates, I'd want to be
It is doing them a favor to at least bring it to their attention, as they
will get their confirmations sooner. I'm not personally interested in who's
responsible at an individual level. That part is irrelevant.
But I'm VERY I'm interested in dealing with and finding a way to eliminate
this flaw in the system.
If it were up to me, ANY method of transferring TQ8 files to LOTW would
require the user to directly recognize the number of QSO records they are
submitting in that file. That alone should provide the needed user feedback
to curtail this particular problem. I know it is already visible in tiny
6-point typeface on the TQSL screen, but it's far too easy to overlook or
ignore. Clearly the instructions could address this issue for NEW users,
but anyone who's already been using TQSL with a measure of what they deem
to be success is unlikely to review the latest instructions, unless
something motivates them to do so.
That motivation could be in any number of forms...
Let's FIND ONE and UTILIZE it.
"Style is a simple way of saying complicated things." --J. Cocteau
\ | | ---Tao. A chinese character that
-- |----| means "Way, Path."
/_________ Geoffrey Way
> Three years is an eternity-- especially in the hardware area.ARRL are not in the data warehousing business and likely can not
(or should not) afford the accelerated obsolescence generated when
there is need to maintain excess capacity or support inefficient
programming. Given their member funded base, each purchase/project
should be as cost effective as possible - and that includes moving
some "costs" to the users in potentially tighter input requirements.
> I also want to point out that date alone is not a good parameter toThat is true ... I tend to use "date" as shorthand for "date and start
> use for determining dup status.
time of the last QSO record uploaded".
> Also there needs to be some easy way for one to load "old logs" e.g.I would not expect someone to be transcribing old logs into one of the
> transcribed from paper without being hassled by the system.
contest programs that have the issues with redundant uploads. There
are far better tools for that purpose. Users would certainly do one
time uploads of a log that had been transcribed - much like the one
time upload of a contest log after the submission deadline had passed.
> Most decisions will be cost/resource driven. What you may want,There is nothing to prevent shifting some of that cost to the users in
> might not be affordable. The most costly part of any system generally
> is new software programming.
terms of tighter standards for uploaded data. If those standards save
substantial costs in either hardware or programming, they are justified
in a "member/user supported" environment.
Those users who generate the largest expense (e.g., wasted processing
time, etc.) deserve to bear the largest "cost" in inconvenience and
... Joe, W4TV
On 1/2/2013 10:49 AM, Brian Alsop wrote:
> Three years is an eternity-- especially in the hardware area. Many of us
> will be SK's by then anyhow.
> Why not wait and see what actually happens with the hardware update?
> I also want to point out that date alone is not a good parameter to use
> for determining dup status. Many of us have hundreds of QSO's on a
> given date. It needs to be at a minimum date and time Also there
> needs to be some easy way for one to load "old logs" e.g. transcribed
> from paper without being hassled by the system.
> Most decisions will be cost/resource driven. What you may want, might
> not be affordable. The most costly part of any system generally is new
> software programming.
> 73 de Brian/K3KO
> On 1/2/2013 15:31, Joe Subich, W4TV wrote:
> the same issue will return in about
>> three years unless the software has been "fixed" to be more efficient
>> and eliminate the redundant QSOs without wasting the system resources.
>> Whether that "fix" is user education, improved logging software, and
>> enhanced tQSL that removes the redundancies, or a LotW server that
>> rejects uploads that reach a threshold of dupes, is an open question.
>> I would posit that *all* of the above will be required if only because
>> there are some in each area (users and software developers) who can
>> not be informed or are not motivated to deal with the issues within
>> their control.
>> ... Joe, W4TV
>> On 1/2/2013 10:08 AM, Brian Alsop wrote:
>> > Those are only two possibilities.
>> > A third is that the new hardware solves the current problem and the ARRL
>> > "kicks the can down the road" on software.
>> > Kicking the can down the road is a time honored tradition.
>> > Look at the companies that didn't convert from COBOL based software to
>> > something else for several decades.
>> > I agree with one postee. Doing anything that drives away current or
>> > potential users makes the system that much less useful.
>> > A fourth possibility is to shut the system down permanently.
>> > 73 de Brian/K3KO
>> >> Either ARRL educates the users and the software developers or they must
>> >> eventually reject the defective logs.
>> >> 73,
>> >> ... Joe, W4TV
>> > -----
>> > No virus found in this message.
>> > Checked by AVG - www.avg.com
>> > Version: 2012.0.2221 / Virus Database: 2637/5503 - Release Date: 01/02/13
>> > ------------------------------------
>> > Yahoo! Groups Links
>> No virus found in this message.
>> Checked by AVG - www.avg.com <http://www.avg.com>
>> Version: 2012.0.2221 / Virus Database: 2637/5503 - Release Date: 01/02/13
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2012.0.2221 / Virus Database: 2637/5503 - Release Date: 01/02/13
> Yahoo! Groups Links