Loading ...
Sorry, an error occurred while loading the content.

Re: An alternative for duplicate management ...

Expand Messages
  • Geoffrey Way
    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
    Message 1 of 219 , Dec 30, 2012
    • 0 Attachment
      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
      notified.

      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.

      -- KA1IOR

      "Style is a simple way of saying complicated things." --J. Cocteau


      \ /
      ---\--/----
      /
      ======
      \ | | ---Tao. A chinese character that
      -- |----| means "Way, Path."
      / |----|
      \ |____|
      /_________ Geoffrey Way

      websites: http://www.cape-vision.com/wayg/mrep
      http://www.cape-vision.com/wayg/ka1ior
    • Joe Subich, W4TV
      ... 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
      Message 219 of 219 , Jan 2, 2013
      • 0 Attachment
        > 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 to
        > use for determining dup status.

        That is true ... I tend to use "date" as shorthand for "date and start
        time of the last QSO record uploaded".

        > 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.

        I would not expect someone to be transcribing old logs into one of the
        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,
        > might not be affordable. The most costly part of any system generally
        > is new software programming.

        There is nothing to prevent shifting some of that cost to the users in
        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
        data scrutiny.

        73,

        ... Joe, W4TV


        On 1/2/2013 10:49 AM, Brian Alsop wrote:
        > Joe,
        >
        > 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:
        >>
        >> Brian,
        >
        > 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.
        >>
        >> 73,
        >>
        >> ... 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
        >
        >
        >
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.