| |
ZL3AI > APRDIG 17.11.03 11:28l 246 Lines 10854 Bytes #999 (0) @ WW
BID : 2302-ZL3AI
Read: GUEST
Subj: TAPR Digest, Nov 07, 3/5
Path: DB0FHN<DB0THA<DB0ERF<DB0FBB<DB0GOS<ON0AR<ON0AR<VK6HGR<ZL2TZE<ZL2TZE<
ZL3VML
Sent: 031117/0851Z @:ZL3VML.#80.NZL.OC #:13011 [Chch-NZ] FBB7.00i $:2302-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: Where's Dad?
From: David VanHorn <dvanhorn@cedar.net>
Date: Fri, 07 Nov 2003 09:24:25 -0500
X-Message-Number: 11
At 11:51 PM 11/6/2003 -0500, Bob Bruninga wrote:
>Placing an ICON on your KIDS PC desktop to shown them "where DAD is" only
>takes 3 clicks of a mouse and is so easy I cant believe I just got around
>to it!
I've been using it that way, since Findu came out. :)
----------------------------------------------------------------------
Subject: Re: ICON faults of some clients
From: Bob Bruninga <bruninga@usna.edu>
Date: Fri, 7 Nov 2003 10:02:54 -0500 (EST)
X-Message-Number: 12
On Fri, 7 Nov 2003, Steve Dimse wrote:
>>Yes, because "most users" dont care how it works (and dont know what
>>they are missing)... 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.)
And I appreciate your feedback and the open (and long running) debate we
have had on these fine points of APRS, so thanks for not taking any of
this personally...
>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.
Sometimes I think things cannot be designed well by commmittee by just
tacking on things as people ask for them. APRSdos came from a very well
developed and tried and proven legacy of the US Navy's tactical Display
systems (at the time, and good or bad, but it sure had the combined legacy
of the knowledge of tens of thousands of experts in the field and proven
in war).. Now if other authors had simply fully implemented that baseline
as their starting poing, then I agree that user feedback would evolve that
baseline into an even better system by now.
Lets say that APRSdos was like a vietnam era jeep with everything you
needed for a SAR mission. Where it should be now is a HummVee. But some
of what we have now are like 4 chrome wheels with spinners on a sooped up
color TV with 500 channels and a 400 cubic inch engine and a box full of
maps and the driver a MOUSE and then pass it off as a new and improved
model (but without a transmission)...
>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.
Again, It is not a common user interface at all that I want. It is
displaying a COMMON SET OF TACTICAL INFORMATION to the end user in
real-time. That information that was supposed to be conveyed to end users
of APRS was designed from day one to include thnigs like:
Is it moving?
If moving is it more than a few minutes old?
Is it an OBJECT from someone else?
Is it one of the OBJECTS I am responsible for?
Is it an OLD ICON more than 80 minutes old?
Is it the old position of an object that just this instant moved?
Is it Message capable?
Is it ambiguous? What is the size of the ambiguity?
Is it marked with one of the 36 OVERLAY characters possible?
Is it also a digipeater? (even if it is not using the DIGI ICON?)
I have always said that authors are free to design their on User Interface
and I welcome innovation in how we can find even better ways to convey
this information to the users.. But my argument over these same 8 years
is that those elements are IMPORTANT for real time display and
fundamentally part of the STANDARDIZED APRS INFORMATION that is supposed
to get to the end user... (without him having to go find it on each
ICON)...
>...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
>acommon user interface.
But I havent stiffled innovation. We have so many APRS software versions
now of so many varieties it is dizzying, but in 8 years, the "innovation"
has still not brought these most fundamental missing bits of information
to the end user's display in any innovative way...
Look at BROWSERS! Look what WEB browsers have made of the internet! And
it is NOTHING to do with stiffling innovation in the world wide web. The
ONLY Thing that made it possible is for the BROWSER authors to STICK to a
COMMON STANDARD OF INFORMATION exchange and they can display it however
they want.
APRS is supposed to be that STANDARD for the common display of the
STANDARD information. How the author does it is up to each author...
But WE DONT HAVE THAT, because some of the authors have not fully
implemented the fundamental standards of information display that is
fundamental to APRS..
de WB4APR, Bob
----------------------------------------------------------------------
Subject: Re: SSID Conventions?
From: "Kurt O. Jauss" <kf6hjo@earthlink.net>
Date: Fri, 07 Nov 2003 07:06:03 -0800
X-Message-Number: 13
Program them as BOAT-1, BOAT-2, BOAT-3..... and put your call in
the Beacon text.
----------------------------------------------------------------------
Subject: Re: SSID Conventions?
From: Bob Bruninga <bruninga@usna.edu>
Date: Fri, 7 Nov 2003 10:16:53 -0500 (EST)
X-Message-Number: 14
I'd program them this way..
SAIL-0 (A BOAT ICON with an OVERLAY of "0")
SAIL-1 (A BOAT ICON with an OVERLAY of "1")
SAIL-2 (A BOAT ICON with an OVERLAY of "2")
SAIL-3 (A BOAT ICON with an OVERLAY of "3")
SAIL-4 (A BOAT ICON with an OVERLAY of "4")
SAIL-5 (A BOAT ICON with an OVERLAY of "5")
SAIL-6 (A BOAT ICON with an OVERLAY of "6")
SAIL-7 (A BOAT ICON with an OVERLAY of "7")
SAIL-8 (A BOAT ICON with an OVERLAY of "8")
SAIL-9 (A BOAT ICON with an OVERLAY of "9")
BASE-1 for the two basestations...
BASE-2
START for the committee boat
By using the BOAT icon with the NUMBER overlays, then you can even turn
off callsigns on the MAP display to reduce clutter and yet you can still
see which boat is which.
AND in APRSdos (which doesnt use ICONS) the BOAT symbol looks like the
hull of a boat with the OVERLAY character on it and the HULL POINTS in the
direction of movement!
de WB4APR, Bob
----------------------------------------------------------------------
Subject: Re: DX cluster spots on APRS (the RIGHT way)
From: Bob Bruninga <bruninga@usna.edu>
Date: Fri, 7 Nov 2003 10:47:00 -0500 (EST)
X-Message-Number: 15
On Fri, 7 Nov 2003, Steve Dimse wrote:
>>... There should have been appendices to the spec that contained all
>>of Bobs [original User Interface concepts]...
>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.
And after these many years, the lack of any presentation of the
fundamentals of what constituted a "minimum" GUI has quite completely
lead to a system that simply does not work cross-platform under "real
use under stress"....
>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.
FINDU is a fantastic tool of APRS that has made APRS what it is today. I
do not in any way want to "criticise" your tremendous contribution to
APRS. But as you say, I have only been giving "suggestions" of all of
the things that are missing in MOST ICON based displays that I see
these days... Very important things that are fundamental to
tactical-real-time display of moving objects on maps... I'm just trying to
help by reminding viewers of all that is misssing in those displays...
>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 else has in
>these last 10 years!
AND this is WHY most clubs and SERIOUIS communicators DONT use APRS as
anyting but a FLASHY SIDESHOW at real-time events. The lack of any
commonality of presentation across the VAST variety of platforms that
volunteers bring to such an event FORCES such groups to either use ONLY
ONE CLIENT program and train everyone how to use it, or to NOT DEPEND on
APRS at all becasue they cannot even find 3 volunteers with the same
system....
>>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 [with the attributtes you want]...
>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!
but newcommer authors only implement what they like, and a lot of the
fundamental stuff (not normally visibile to the eye) is left out and as a
result the INTERSECTION of the lowest common denominator of what many
clients have implemented is SHRINKING... THus, programs are becoming LESS
and LESS able to convey the same STANDARD INFORMATION across platforms
instead of better...
Some authors think that as long as they can parse a position report and
put an ICON on the map, that they have a WORKING APRS program!!! What
about the other 30,000 lines of code and the other 90% of the
communications INTENT of the system??? Many, once they have the map
problem in hand and a nice display just ignore the rest...
Waiting for the users to ask for what they dont know is missing is not the
way to design a system who's intent was a STANDARD SYSTEM for the tactical
real-time exchange of digital data on a local common user channel to all
come-as-you-are users...
de WB4APR, BOb
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
