| |
ZL3AI > APRDIG 20.11.03 20:05l 325 Lines 14142 Bytes #999 (0) @ WW
BID : 2335-ZL3AI
Read: GUEST
Subj: TAPR Digest, Nov 13, 5/14
Path: DB0FHN<DB0FOR<DB0SIF<DB0EA<DB0RES<ON0AR<7M3TJZ<KP4IG<KD7HAH<GB7BHX<
GB7BHM<ZL2BAU<ZL3VML
Sent: 031120/1713Z @:ZL3VML.#80.NZL.OC #:13185 [Chch-NZ] FBB7.00i $:2335-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: Station attributes -was- RE: APRS Icon statistics
From: Bob Bruninga <bruninga@usna.edu>
Date: Wed, 12 Nov 2003 17:34:17 -0500 (EST)
X-Message-Number: 26
On Wed, 12 Nov 2003, Steve Dimse wrote:
>I'm sorry I caved in on the UI things you put into the spec, I wish I
>had fought those to the bitter end. I say, it is because this issue
>wasn't resolved in a definitive manner that explicitly recognized the
>right of each programmer to present data as they and their users see fit
>is why we have this mess today!
Nothing could be a further missunderstanding of what "communications"
means. You are talking from the persepctive of a "programmer" who just
likes to make neat displays. And WE HAVE ALLOWED everyone to do their own
thing. And as a result, MANY of the most popular APRS programs are grossly
deficient and incompatible...
I am talking from the perspective of the end users that must have a
consistent INFORMATION DATA SET with which to communicate human to human...
Communications means that operators are sharing THE SAME INFORMATION and
that information MEANS THE SAME THING TO ALL VIEWERS. It has nothing to do
with how or in what format this information is displayed....
And I say again for the 2,000,000 time, that APRS map symbology ALL have
MANY ATTRIBUTES and the display of those ATTRIBUTES MUST be conveyed to the
end user. AND I DONT CARE HOW. But they MUST be part of every display...
or we dont have a consistent system for the end viewers.
And yet MANY "APRS" programs display NONE OF THESE ATTRIBUTES and so the
end user sees the SAME map symbology whether the ICON is 5 minutes old or 5
days old. Whether it is a real station, or just an object posted by
someone else, Whether it is moving and was not at this location last time
you saw it and probably wont be here next time.... whether it is an
estimated postion or an exact position, etc...
Your lack of acceptance of the need for "Communications Standards" is
killing APRS as a useable system across platforms...
de WB4APR, Bob
----------------------------------------------------------------------
Subject: Re: MULTI-ICON proposal
From: "AE5PL Lists" <HamLists@ametx.com>
Date: Wed, 12 Nov 2003 16:44:36 -0600
X-Message-Number: 27
Bob,
Your self-serving diatribe finally got me to respond...
>-----Original Message-----
>From: bounce-aprssig-19826@lists.tapr.org
>[mailto:bounce-aprssig-19826@lists.tapr.org] On Behalf Of Bob Bruninga
>Conversation: [aprssig] Re: MULTI-ICON proposal
>Subject: [aprssig] Re: MULTI-ICON proposal
>
>And by Steves method (which has gotten us to this mess in the
>first place)
Which mess are you talking about? The 20,000+ stations that are now on
world-wide (increased from about 6,000 three years ago)?
>we end up with "APRS" that CANNOT be used under stress by
>come-as-you-are
>volunteers to an event or emergency!
I have used APRSDos (I am a registered user) and in no way could it be
used by the "come-as-you-are" volunteer, IMO.
>These days, about the only way that an EOC or other
>ARES/RACES planner can
>even hope to get APRS to do anything useful is to FORCE all
>people in the
>event to use ONE version and ONE version only. Otherwise, it is
>impossible to consistently train operators to use APRS. This kind of
>MONOPOLY is what Steve's "market" forces result in...
We successfully trained a number of operators in the use of many different
APRS software. And guess what, APRSDos was not the software of choice by
any of them.
>BUT IT DOESNT WORK IN HAM RADIO. There is no market force,
>there is no
>central authority, there is nothing but volunteerrs that
Bob, what do you think market forces are? Time to leave the military hat
behind. Market forces work BECAUSE there is no central authority.
>It is this lack of insistance on APRS as a STANDARD that is actually
>KILLING APRS. Locally our local clubs just dont use APRS
Again, a 3-4 times growth in APRS stations is hardly denoting the death of
APRS.
>bells and whistles that look pretty... but are not actually
>usable under
>stress... by the lowest commond denominator of operator.
IMO, APRSDos is the lowest common denominator in display graphics. I know
of far more APRS+SA, UI-View, Xastir, WinAPRS, and MacAPRS stations being
used "under stress" than APRSDos in the DFW area. Bottom line: APRSDos was
a good application written for the human interfaces available at the time.
Times change. Instead of saying "APRSDos is perfect and all other software
is broken and incomplete", it might be time to honestly look at what the
other software does bring to the table and how your theories on what needs
to be displayed on an APRS display can be accomplished utilizing the
expanded capabilities of the new GUI's.
By your reasoning, we would be better off if Unix, Linux, Windows, MacOS,
PalmOS, etc. didn't exist because we have a "tower of babble" of operating
systems and GUI's available to the uneducated masses. What is actually the
case is we have people choosing the GUI they are most comfortable working
with which makes them far more productive in "stress" situations than if
they had to learn a new GUI at the time of an emergency.
Over the years, you have created a large number of documents with a lot of
good information about what you believe should be in a APRS display.
Unfortunately, the documentation is disjointed, in some places
contradictory, and difficult to glean the important information for someone
writing a new application. That is one of the biggest things IMHO that the
APRS WG did: assemble a coherent document (yes, there are some mistakes)
that is usable as a foundation by all authors. Instead of restating your
disdain for the WG accomplishment because it didn't cover GUI's, you might
think about how you could emulate the WG end product with a coherent
specification of what you think are the minimum requirements for an APRS
GUI.
73,
Pete Loveall AE5PL
pete@ae5pl.net
----------------------------------------------------------------------
Subject: Re: MULTI-ICON proposal
From: Mark Earle <wa2mct@mearle.com>
Date: Wed, 12 Nov 2003 17:06:30 -0600
X-Message-Number: 28
>cover GUI's, you might think about how you could emulate the WG end
>product with a coherent specification of what you think are the minimum
>requirements for an APRS GUI.
>
>73,
>
>Pete Loveall AE5PL
>pete@ae5pl.net
And more or less, this is what is happening - users and authors are
defining a new standard. I agree it might be better if a working group like
document existed and could be used as a modern foundation. Absent that,
we'll see what we are seeing. Choices, and lots of good products.
To use Pete's analogy, it's like the Palm vs WinCE debate. Neither is
"right". Both are tools that get jobs done. The owner / user chooses which
is best for their needs, and gets productive things done. Same with APRS.
As far as I know all the sofware out there today can be demo'd. For a small
investment of time, I can try and choose what is best for my particular
situation. This is a great thing, compared to being "forced" to use only
one product and in a particular way.
) ) de WA2MCT Mark
( (
) ) You will be assimilated... oooh, coffee!!
_|****| http://www.findu.com/cgi-bin/find.cgi?wa2mct-8 Home
( | | http://www.findu.com/cgi-bin/find.cgi?wa2mct-9 Mobile
`|____| wa2mct@mearle.com wa2mct@juno.com www.mearle.com/mark
----------------------------------------------------------------------
Subject: Re: Station attributes -was- RE: APRS Icon statistics
From: Steve Dimse <k4hg@tapr.org>
Date: Wed, 12 Nov 2003 18:06:42 -0500
X-Message-Number: 29
Bob.,.. Why does a guy concerned how the wind is going to spread a toxic
cloud need to now whether something is an object, or any of the other data
above?
And, if someone is concerned just with wind spreading a toxic cloud, they
have enough to worry about, why should their senses be overloaded with data
they don't need????
Now, granted, some people may have the need, but the fact that some don't
means they ought to be free from being subjected to that meaningless (to
them) data.
Anyway, of the 6 things you show above, the clients I use grey out old vs
current, use vectors for movement, and show DR station. Maybe the other two
are critical to you, but not so important to others, otherwise those too
would be shown. In any event, I certainly don't think those two things (or
even all 6) are going to be responsible for the death of APRS as you claim.
Steve K4HG
----------------------------------------------------------------------
Subject: Re: MULTI-ICON proposal
From: Bob Bruninga <bruninga@usna.edu>
Date: Wed, 12 Nov 2003 18:12:25 -0500 (EST)
X-Message-Number: 30
On Wed, 12 Nov 2003, Steve Dimse wrote:
>Bob, your user interface was full of single keystroke commands... It
>required a lot of experience to use efficiently... most other users
>COULDNT walk into an event and.. use it..
ABSOLUTELY CORRECT!
My gosh you just dont get it. I would NEVER expect someone to walk into
an EOC and use someone else's program!!! What I want is ANYONE to walk in
and use HIS FAVORITE, and the one that HE is PROFICIENT with! BUT.... what
I want is for him to see the SAME INFORMATION on a map as eveyone else is
seeing on THEIR maps... when they are both looking at the same thing!
If you cannot understand that last sentence, read it over again until you
do.
Why can't you understand this? How many times to I have to say this.
NONE OF the user interface details that you keep raising has ANYTHING to
do with what I am saying about COMMON USER CONVEYANCE of CONSISTENT
STANDARD APRS information to the end-viewer.
Let me say it again for the 2,000,001th time that this his is what I mean
by STANDARD, CONSISTENT DISPLAYS:
An APRS display SHALL:
1) use the STANDARD APRS symbology (ICONS)
2) display the STANDARD ATTRIBUTES associated with such symbology
3) have a consistent means of describing its VIEW SIZE (range scale)
between end users
THAT IS ALL. None of this other bunk you keep raising. The above is the
ONLY THING I MEAN when I say STANDARD PRESENTATION!!!!!! and the reason I
am so frustratred with APRS is that the ONLY thing many client programs
consistently implemented was #1!!!!
Leaving out #2 and #3, makes us operators totally incapable of using APRS
across platforms as a means to FOSTER human end-user understanding of what
they are seeing.. Without #3, they can't even tell if they are looking at
the same thing! ARGH!
>However, even if every software had exactly the same display, so I knew
>what the colors meant, which is what we are talking about, it is the use
>of your program that would be a mystery to me. The only way you could
>improve cross-platform compatibility is to insist that all menu items be
>identical, no one use any GUI feature you are not able to implement in
>APRSdos, never use a pop-up menu, window, or mouse roll-over. No
>sophisticated maps, because an APRSdos could walk in and make a
>Precision Mapping window or Tiger map work right.
You dont get it. None of the above details has anything to do with
it. I have said OVER and OVER and OVER and OVER and OVER and OVER and
OVER that I dont care how authors present the information, but the
presentation MUST show teh same fundamental INFORMATION:
1) All symbols (icons) in the APRS standard
2) The ATTRIBUTRES associated with those symbology
3) And have a consistent, standard means of describing the size
of the view the operator is seeing (range scale).
I dont know how in the world you can interpret those 3 fundamental
requirments as limiting your abilities as a programmer to use whatever
GUI you want. But I am disappointed at the lack of creativity in most
client programs with all the power of modern PC's such that in 7 years,
they still havent figured out how to do #2 and #3!
>A couple days ago you denied trying to make all programs work and look
>the same, saying they just needed to display the same data, yet here we
>are again...
Yep, becasue still, after 7 years of this, MANY CLIENT programs still do
not present the same information (as defined above) to the end user. SO
we have no means of assuring that users with cross platforms can
effectively communicate the SAME INFORMATION...
>Realistically, if I'm going to be a volunteer in an EOC, and I know they
>use xyzAPRS,... then as part of the personal training I give myself, I
>will learn to use that program. This is simply not an impediment...
Absolutely. I want eveyrone to use whatever program he feels best with...
But when you are talking on the VOICE net from your EOC to another EOC,
you need to be able to say "Zoom to the 16 mile scale and look at the
Object near the lake" and have EVERYONE using whatever client they want,
to INSTANTLY recognize the OBJECT near the LAKE.
Without RANGE SCALE, "near" is meaningless
Without ATTRIUTES, users cant tell what is an object and what is not!
>If there is something that is preventing the wider adoption of APRS
>among emergency managers, I'd say it is that none of the APRS programs
>(including yours) are able to meet their needs. The answer isn't to
>further limit the ways in which a client may develop, but rather to give
>adeveloper the freedom to meet any unmet needs they find!
Absolutely nothing that I want and Ask for IN ANY WAY limits client
authors! In fact it is the OPPOSITE. The client programs I am RANTING
about are what is LIMITING our ability to communicate!
Authors are currently unconstrained, yet, after 7 years, they still DONT
DISPLAY the basic fundamentals of map symbology properly. And I DONT CARE
HOW THEY DO IT. Only that the SHOULD DISPLAY the fundamental APRS
information:
1) Map symbology (the symbols and ICONs in the standard)
2) The ATRIBUTES associated with that symbology
3) A consistent means of describing across platform the same area of
interest (Range Scale).
Now how in the world is that "limiting" authors?
de WB4APR, Bob
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
