| |
ZL3AI > APRDIG 20.11.03 20:28l 282 Lines 10915 Bytes #999 (0) @ WW
BID : 2340-ZL3AI
Read: GUEST
Subj: TAPR Digest, Nov 13, 10/14
Path: DB0FHN<DB0THA<DB0ERF<DB0FBB<DB0BI<DB0NOS<DB0EA<DB0RES<ON0AR<7M3TJZ<
ZL2TZE<ZL2TZE<ZL3VML
Sent: 031120/1713Z @:ZL3VML.#80.NZL.OC #:13190 [Chch-NZ] FBB7.00i $:2340-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: MULTI-ICON proposal
From: Bob Bruninga <bruninga@usna.edu>
Date: Thu, 13 Nov 2003 12:47:31 -0500 (EST)
X-Message-Number: 54
On Wed, 12 Nov 2003, Tyler Allison wrote:
>However, maybe I dont care about *ANY* attributes. I only want to see the
>map and the symbol.
Then I dont want you participating in my communicatinos event if your
display cannot let you see the difference between an ICON that is hours
old and one that is current. Communications is supposed to improve
clarity, not add to obfuscation...
>Should I be forced to have the attributes of that symbol displayed?
YES!, otherwise you are clueless as to what is being presented. Is the
ICON current? How old is it? Is it moving or fixed. Is it a one-time
object or something that is being updated frequenctly. Where is it
headed? These are all attributes of symbology in a tactical real-time
display. They must be presented by default.
Seeing just an ICON on the map without these common attributes is exactly
the kind of obfuscation that causes missconmunications and errors. We
dont want to be INTRODUCING errors because of poor displays.
>Im not real concerned with range scale....most all the APRS functions
>I've looked at use some kind of background map which uses lon/lat which
>forces a scale upon the viewer.
Then you dont undrstand the problem or have not participated in an event
wehere you need to rapidly communicate to another APRS operator to zoom
into the same view you have (NOT KNOWING WHAT CLIENT SOFTWARE HE IS
USING).. For example, POCKET APRS uses maps with a scale system of 1X,
2X, 4X, etc that is meaningless to anyone that is not useing the identical
MAP file. Try telling one of them to zoom to the 32 mile scale around the
capital.
de WB4APR@amsat.org, Bob
PCsat WEB page http://www.ew.usna.edu/~bruninga/pcsat.html
ISS-APRS FAQ: http://www.ew.usna.edu/~bruninga/iss-faq.html
CUBESAT Designs http://www.ew.usna.edu/~bruninga/cubesat.html
APRS LIVE pages http://www.ew.usna.edu/~bruninga/aprs.html
APRS SATELLITES http://www.ew.usna.edu/~bruninga/astars.html
MIM/Mic-E/Mic-Lite http://ssdl.stanford.edu/mims/
----------------------------------------------------------------------
Subject: Re: MULTI-ICON proposal
From: "peterkhr" <peterkhr@rollanet.org>
Date: Wed, 12 Nov 2003 21:59:35 -0800
X-Message-Number: 55
Wrong, race cars now have automatic transmissions 73 Peter
----------------------------------------------------------------------
Subject: Re: MULTI-ICON proposal
From: "AE5PL Lists" <HamLists@ametx.com>
Date: Thu, 13 Nov 2003 12:49:05 -0600
X-Message-Number: 56
>-----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
>
>>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.
>
>Wow, And I ABSOLUTELY NEVER IMPLIED THAT. You (and many others) are
>apparently missreading into this their own biases and issues. I NEVER
Just quoting your post, Bob. Maybe you should look at your own biases
and issues.
>Where do you read "APRSdos" in that?
In your posts.
>No, but I see FEWER and FEWER clubs that use APRS generally, and I see
Too bad. I see just the opposite. And by the way, out here the clubs
don't dictate what ARES and RACES use.
>MORE and MORE clubs that tend to focus on only one client
>progarm so that
>they can get consistent results in real live events and
>situatinos... and
>can plan and train their operators.
And this has nothing to do with what the different applications display.
It has everything to do with training personnel to use a single user
interface (something you claim you are not addressing with this thread).
>>perfect and all other software is broken and incomplete",
>
>And where on earth did you hear that? Certainly not from me.
Again, just quoting your post.
>missleading
>users who cannot tell the difference between something that is:
>
>1) A station or an OBJECT
Not an issue with our ARES organization. A nicety, maybe, if it does
not clutter the display too much.
>2) Moving or not
All software that I am aware of displays this.
>3) Precise or ambiguous
Again, not an issue with our EC's. In fact, they do not want their
displays cluttered with ambiguous spots. However, it is probably
something that would be good to have for anyone that uses ambiguity. Of
course, the next problem (as discussed in earlier posts with no firm
agreement) would be how to properly display ambiguity.
>4) Dedreckoned or not
Those who have expressed interest in this to me have also said they want
to be able to turn it on and off. Personally, I find global dead
reckoning on a display to be both confusing and difficult to interpret
in a "stress" situation. More often, our people are trying to figure
out where a storm or person was last reported with something indicating
direction and speed of travel. Something about working with knowns
instead of guesses.
>5) Old or current
What defines old? If your reply is what you (Bob) set down in APRSDos,
that is not desired by those users that I talk to. Most want a way to
filter out reports using their own parameter defining "old".
>6) Message capable or not
Within the framework of a "stress" situation, this has only been
indicated as desirable for someone to select a specific station to see
if it accepts messages. Again, they don't want to see this at all times
cluttering their display.
>7) Killed or active
Most people that I have talked with want the killed objects to go away
completely, again not cluttering their display.
>8) Your objects or someone elses
IMO, this is hardly a mandatory under the current APRS architecture. If
you don't know when you generate an object, don't generate the object.
Again, not necessary to be "seeable" at a glance.
>You just dont get it. Where on earth do you get the idea that I am
>saying APRSdos is great, or what should be used!!!! Nothing could be
From your posts, Bob. As you can see above, all but one of the 8
attributes you want shown on all displays all of the time are not
necessarily desirable by others. I am not saying that everyone does not
want to see these attributes all of the time, just that an author's
decision to support or not to support one or more of these attributes is
not ruining APRS nor adversely impacting the usability of each piece of
software nor impairing our ability to communicate via APRS.
>>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.
>
>I will do so in the next email.
An email IMO is not a coherent specification document. Feel free to
post it, but it ends up with all the other hundreds of posts on this SIG
when the day is done: archived for someone to look at in the future,
maybe. So don't feel bad if the authors of APRS software don't jump on
your recommendations and immediately put them into their software. As I
pointed out before, some might and some might not. It all depends on
THEIR interpretation of priorities and what THEY perceive as desired by
their application users.
Again, I am not saying that what you want to see displayed is bad or
good. I am simply saying that software authors may disagree with your
priorities and that does not make their software "broken and
incomplete". It simply means that they perceive different requirements
from their users and/or different requirements for their application's
intended use.
73,
Pete Loveall AE5PL
pete@ae5pl.net
----------------------------------------------------------------------
Subject: Re: MULTI-ICON proposal
From: "AE5PL Lists" <HamLists@ametx.com>
Date: Thu, 13 Nov 2003 13:08:43 -0600
X-Message-Number: 57
>-----Original Message-----
>From: bounce-aprssig-19826@lists.tapr.org
>[mailto:bounce-aprssig-19826@lists.tapr.org] On Behalf Of
>Henk de Groot
>Conversation: [aprssig] Re: MULTI-ICON proposal
>Subject: [aprssig] Re: MULTI-ICON proposal
>
>Now I have to defend APRSdos. It's navigation and visiual
>representation is
>outdated, but there went a lot of thinking in the program that is to
>valueble to throw away. The problem is that there is so much
>that there is
>no overview anywhere of all these details.
No disagreement here, at all. In fact, I said the same in my post.
>Maybe its good to put all the display features in a table
>(not how they are
>represented but what information should be conveyed to the
>user). Then rank
>these features from 0..5 for importance, where 0 is
>"nice-but-niche" and 5
>is "fundamental-must-have". Then rank the clients against
>this table so
>authors can focus on what is missing to get a better rank.
>Clients that do
>not have the "fundamental-must-have" are "rank 6"; which
>could be quite
>okay if the client is not a "general purpose" APRS client but
>only used for
>example a WX viewer or DX cluster viewer. The lower the rank
>number, the
>more features are supported. A rank 3 client must fullfill
>all rank 3, 4
>and 5 requirements, if one is missing then the client should
>have a higher
>number rank.
The trouble with this is it sets a finite set of parameters that each
author must use to achieve a "higher" ranking. What I and many others
have stated is that this is not a matter of saying this software is
better than that software because it displays xyx and the other only
displays abc. It all depends on what your target audience is and their
perceived needs. You can have the absolute "best" display ever, but it
won't go anywhere if it is difficult to understand or use. But you know
that, and that is one of the things Steve was talking about when he
talked about "market forces".
>structured way to get the displays alligned). The easiest way
>is to have
>somebody make a proposal ranking (Bob?) and then allow 3
>iterations of
>adjustments before freezing it.
I think it is a poor direction to take to have an arbitrary "committee"
say in absolute terms "display this or you won't be accepted". As I
encouraged Bob to do in my earlier posts, I think it would be great for
him to come up with what he thinks is necessary for an adequate APRS
display and put it into a coherent document. However, to then say that
if some software doesn't do one or more of those things makes that
software inadequate or incomplete is, IMO, a mistake. Contrary to Bob's
assertions, I do not believe that APRS as a communications media is
impeded if different software display APRS data differently and/or
without certain attributes on the display.
73,
Pete Loveall AE5PL
pete@ae5pl.net
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
