| |
ZL3AI > APRDIG 17.11.03 11:27l 312 Lines 14221 Bytes #999 (0) @ WW
BID : 2301-ZL3AI
Read: GUEST
Subj: TAPR Digest, Nov 07, 2/5
Path: DB0FHN<DB0FOR<DB0SIF<DB0EA<DB0RES<ON0AR<VK6HGR<ZL2TZE<ZL2TZE<ZL3VML
Sent: 031117/0851Z @:ZL3VML.#80.NZL.OC #:13010 [Chch-NZ] FBB7.00i $:2301-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: APRS Range Scale Standardization
From: Bob Bruninga <bruninga@usna.edu>
Date: Fri, 7 Nov 2003 00:49:09 -0500 (EST)
X-Message-Number: 6
On Thu, 6 Nov 2003, Steve Dimse wrote about the standardized APRSdos RANGE
SCALES that were never implemented in many client programs:
>Another Bob UI crusade was the presence of a power-of-two scale on the
>map. He wanted to be sure that anyone looking at a "64 mile scale" was
>seeing the same thing. On findU I couldn't do it because MapBlast used
>power-of-five scales.
No my main point was to just DISPLAY a consistently defined Range scale.
It would be nice if it was the same power of two. If FINDU couldnt do
powers of two, it is PERFECTLy fine to display a map and just indicate
that it is a "50 mile" range scale. I think users are smart enough to be
able to infer the difference in what they are seeing...
Range scale means that everything within X miles (the RANGE SCALE) of the
map center WILL BE SEEN on the screen. Size shape, resolution, aspect
ratio dont matter!
>A bigger problem was, even if every client implemented this, in a
>windowing environment it still doesn't fulfill Bob's objective. My 17
>inch Apple Powerbook has more than 4 times the pixels of a VGA display,
>when I'm at the 64 mile scale, I'm seeing 4 times as much as Bob. Should
>we therefore force each APRS map display to only be 640x480? .
Wow, a total missinuderstanding of the concept of RANGE SCALE.. It has
nothing to do with pixels, or map resolution, or shape or aspect ratios...
and your example above is EXACTLY WHY we need the concept of RANGE SCALE!
wow...
RANGE SCALE is simply a common single parameter description of a single
attribute to assure that users of two different systems with any kind of
display, to be looking at approximately the SAME AREA...
A person looking at Washington DC at the 2 mile range scale sees a 100%
TOTALLY different tactical view than another user looking at the 128 mile
range scale. (the former sees the 30 APRS stations at the Marine Corps
marathon, the latter sees the typical 100 or so ICONs around the nations
capital area and is NOT aware that a Marathon is even going on. He just
sees the TOP ICON of a pile at the center, not aware that it is really
30...... in a marathon... Yet they BOTH claim to be looking at a map
centered on Washington DC!
>I maintain that there should be no limits on the UI, people should be
>free to innovate and take advange of all that technology has to offer!
Absolutly WRONG thinking. APRS is to be a STANDARD for communicating
situational awareness of what is going on in a VENUE to all users
INDEPENDENT of platforms. In that VENUE, operators must be able to
communicate the SIZE of the MAP they are viewing so that they are looking
at the SAME SITUATION. In the military we use RANGE-SCALE. If I am
looking at a 64 mile map, and I tell you to zoom to your 64 mile range
scale, then we should BOTH be seeing about the same thing...
Try getting a PALM-APRS, a WinAPRS and a FINDU user to view the same
thing...tactically, and in real time in as few words as "RANGE SCALE 64"!
IMPOSSIBLE!
As most of the other independent authors have IGNORED this fudamentlal
principle of TACTICAL REAL TIME Displays across platforms is another
PRIME example of what has SCREWED UP APRS.
As I have told you before, If I were asked for how I would do it in FINDU,
I would simply PRINT beside the map something like "[RANGE SCALE 50 Mi]"
so that FINDU users would see the same "feel" as all other users of APRS
are supposed to see. It is trivial to do and just gives so much to the
universality of APRS as a standard communication system.
>... Bob wants to take away your freedom to do... innovative design,
For 8 years, I have pointed out how the failure to convey some of these
fundamental APRS standardizing concepts is killing the useability of APRS
in real-time use across platforms. And as a result it conveys to the HAM
radio MASSES that APRS is a hopeless mess of incompatible software just
displaying pretty icons.
In the same 8 years time that we have debated this, only a few of the
authors have taken the time to innovate their own customized methods to
display the standard information required. Instead, they
just complain about how APRSdos did it...
Bob
----------------------------------------------------------------------
Subject: Re: ICON faults of some clients
From: Steve Dimse <k4hg@tapr.org>
Date: Fri, 7 Nov 2003 08:16:37 -0500
X-Message-Number: 7
On 11/7/03 at 12:28 AM Bob Bruninga <bruninga@usna.edu> sent:
>Part 1:
>On Thu, 6 Nov 2003, Steve Dimse wrote about the APRSdos SYMBOL attributes
>that were never implemented in many client programs (that use ICONS):
>
>>It certainly is not out of ignorance. Bob has been pushing this since
>>MacAPRS came out [WITHOUT THEM] nearly 10 years ago, and early GUI APRS
>>developers like the Sprouls, myself, and Brent all were APRSdos users
>>first, if for no other reason than there was no other choice.
>>
>>I maintain it is because this is simply not useful to most users, who
>>would rather have symbols that are easy to identify (and yes, even
>>pretty) than to have three bits of information conveyed by symbol color.
>
>RESPONSE:
>I will use some CAPITAL letters to emphasize some words that I think are
>critical to UNDERSTANDING the important points involved here, I am not
>shouting... But after 8 years of debating this, most people have not seen
>this recently... Here is my response:
>
>Yes, because "most users" dont care how it works (and dont know what they
>are missing) as long as it looks pretty... I'd challenge ANYONE who wants
>to use APRS as a real live "situational awareness display" to admit to me
>that they don't care if an ICON on a map conveys the following information
>IMMEDIATLY to the observer (without having to go CLICK on it):
Bob, you are missing my point. I'm not arguing with your points here and
elsewhere. (I'm also not agreeing, I find my position varies on different
points of yours.)
What I am saying is that if these features were truly missed in client
programs, they would be demanded by APRS users, and the authors would
provide them. This is free market economy, applied to feature sets. Every
author wants people to use their program, and does what they can to make
their program useful to users. I get emails every day asking for something
in findU, and I do what I can to accomodate these requests. No one ever
asked me to show if a station can accept messages, much less that it be
shown as icon color.
Perhaps those small number of people that need this feature and other
features you advocate are using APRSdos, perhaps for exactly that reason.
This is fine, it is the way it should be. If there is an unmet need,
perhaps someone else will write a version that better addresses the need.
What I'm saying is it should be the right of every developer to create his
user interface according to his own vision and the needs and desires of his
users. I think it is wrong to stifle innovation in the name of providing a
common user interface.
Steve K4HG
----------------------------------------------------------------------
Subject: Re: SSID Conventions?
From: "Sadowski, Allan" <allan.sadowski@ncshp.org>
Date: Fri, 7 Nov 2003 08:34:30 -0500
X-Message-Number: 8
OK... I'm always game to post a stupid question.
I'm 1/3 the way through building 10 tracking boxes (in plastic tool
boxes)... to use for special events... but probably more often for the
sailboat racing I'm trying to get back into.
SO I'll have 10 trackers with my callsign, two digi's with my callsign,
and two "base stations" (committee boat and shore viewing point)... 14
units all with the same callsign...
What's the recommended SSID and or TOCALL to UNIQUELY identify those 14
units - all having the same callsign..
TNX in advance
ALOHA
AH6LS
-----Original Message-----
From: Bob Bruninga [mailto:bruninga@usna.edu]
>>Sailboat (SSID = 5)
----------------------------------------------------------------------
Subject: Re: SSID Conventions?
From: Wes Johnston <wes@johnston.net>
Date: Fri, 07 Nov 2003 08:48:29 -0500
X-Message-Number: 9
Convince your wife to get a license.... then you'll have 32 ssid's you can
use.... grin
Wes
----------------------------------------------------------------------
Subject: Re: DX cluster spots on APRS (the RIGHT way)
From: Steve Dimse <k4hg@tapr.org>
Date: Fri, 7 Nov 2003 08:50:26 -0500
X-Message-Number: 10
On 11/6/03 at 3:16 PM Gregg G. Wonderly <gregg@skymaster.cytetech.com> sent:
>>Personal attacks resume. Be nice just once to have a discussion on the sig
>>without name-calling.
>
>This is not a personal attack, just a point of reference of my feelings about
>your attitude.
You are certainly entitled to your feelings. However, when you use an
inflammatory phrase like "snot-nosed", it most certainly is a personal
attack. You need to do a little self-reflection to figure out why you made
this attack, and whatever the reason was was, how well that attack met your
goal.
>You use sentences that do not include phrases like 'in my
>opinion' or 'I think' that are very declarative and absolute sounding. That's
>why I chose those words.
In my opinion, people are intelligent enough to know that everything anyone
says represents their opinion. In my opinion, it is not necessary to
constantly remind people of that. I think placing "in my opinion" or "I
think" in every sentence that contains an opinion makes it very hard to
read.
In my opinion.
>>I stand behind my statement. As Bob admits, no one else has implemented his
>>color scheme to display those three bits of information. The question is why!
>>
>>It certainly is not out of ignorance.
>
>I have been writing APRS software using only the spec because that is the
>standard and I have no way to run APRSDos, and thus have not downloaded it and
>read through all of his personal documents. Thus, I am in fact ignorant of a
>lot of these points specifically because of the fragmentation of information
>created by everyone demanding that there be nothing about the GUI be
>documented. There should have been appendices to the spec that contained all
>of Bobs documents. There could have been a lot of information clarified for
>many people if they could have, in fact, found the the vast experience that
>Bob has with APRS documented with the spec. But, alas, I can only suppose
>that you experts know the best and Bob's experience and knowledge is just
>worthless to the rest of us. We'd have nothing to learn from reading that
>information it seems.
Bob wanted exactly this, but the majority of the APRS WG did not want the
spec to demand any user interface issues, for exactly the reason I'm
arguing. They wanted the freedom to be able to pursue their own vision, and
to fulfill the needs of their own users. The APRS Working Group very
specifically placed the User Interface outside of its control. Bob is now
trying to reassert this control, and that is what I object to so strongly.
He has no moral or legal grounds to force others to follow his user
interface suggestions, and I object strong to him implying that my
software, or any other software, is deficient because it rejects his UI
suggestions.
Please be absolutely clear...I am not saying that you, or anyone else,
should not implement any of Bob's ideas. I am saying that there is a
conclusion that should be drawn from the fact that no one eelse has in
these last 10 years!
But please, if you wish to, I'd love to see you do it. More choice is
always a good thing, and if Bob is right, users will flock to your
program...
>>Bob has been pushing this since MacAPRS
>>came out nearly 10 years ago, and early GUI APRS developers like the Sprouls,
>>myself, and Brent all were APRSdos users first, if for no other reason than
>>there was no other choice.
>
>And these systems all had limitations as you specified below regarding
>mapblast that restricted what you could do with APRS.
No, findU was the only one using MapBlast as the primary engine. My earlier
project, javAPRS, had complete control over the map. The Sprouls certainly
had total control over the maps they use. Brent perhaps had less, using
Street Atlas, but he'd have to answer if that played any role for him.
>Plain and simple, the
>mapping systems you chose were not, at all, capable of doing the job you
>needed. Sure, they show where stations are at with icons. But, that's only a
>portion of the information available in APRS...
I chose the best available tool. Yes, I would rather have a free service
with the horsepower to provide the millions of maps a month I need, street
level maps of the entire world, and with an open interface giving me
complete control. MapBlast gives all but the last, and with over 5 million
hits on findU last month, I think my users are surprisingly satisfied with
a system "not at all capable of doing the job"!
>>In dos (at least as of the date I last used APRSdos), you cannot just click
>on a
>>symbol, and have a new window pop-up. The process of "hooking" an object means
>>using the cursor to get there, awkward at best. On the other hand, in Mac and
>>other windowing environments, this is a normal action. So, if I need to know
>if
>>station can accept a message, it is trivial to double click on the station and
>>bring up a window, cntaining this (and tons of other information).
>
>Yeah, but in a tactical situation with no time to spare, pattern matching with
>your eye is a lot faster than clicking through 100 icons to find one that can
>message. The dumb trackers make it even more important to have this
>information plainly visible it seems to me.
I'm not arguing that fact, only saying it must not be that important to
users, or an APRS software author somewhere would have responded to the
pressure by now. Again, please go right ahead and implement this, I really
believe more is better in APRS, that is why I fought so hard to get APRS
software development opened up for all comers!
Steve K4HG
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
