Re: [chirp_users] Clone/Live radio mode support in CHIRP
Tonight, dsmith wrote: ========================= <snip>
Note that the support chart is really not meant for end-users, but could definitely be used by documentation writers to ensure that what they write matches the code. ========================
To me, from a newcomer's perspective, this is a serious issue. Picture someone picking up a radio for the first time (never had one of these in their lives), and they come across this table from the link in the wiki. How are they supposed to understand all that without some sort of legend?
As a certain pointed eared Starfleet officer would say, that's illogical. There's nothing to suggest floating a mouse over anything for a description. Perhaps that should be added to the sentence that introduces this table as an explanation. It would be better than nothing.
I was thinking of pointing to this table in the individual radio articles so a newcomer could find out the basics about the radio - including whether this radio supported clone, live or file (what is that?) processing for updating their radio's memories. And since it's updated with each build, maintenance would be a snap. Now I'm not so sure that's the best way to go here.
Mike
--- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com
On Mon, Dec 2, 2013 at 4:07 PM, Mike Agner ka3jjz@comcast.net wrote:
Tonight, dsmith wrote:
<snip>
Note that the support chart is really not meant for end-users, but could definitely be used by documentation writers to ensure that what they write matches the code. ========================
To me, from a newcomer's perspective, this is a serious issue. Picture someone picking up a radio for the first time (never had one of these in their lives), and they come across this table from the link in the wiki. How are they supposed to understand all that without some sort of legend?
As a certain pointed eared Starfleet officer would say, that's illogical. There's nothing to suggest floating a mouse over anything for a description. Perhaps that should be added to the sentence that introduces this table as an explanation. It would be better than nothing.
I was thinking of pointing to this table in the individual radio articles so a newcomer could find out the basics about the radio - including whether this radio supported clone, live or file (what is that?) processing for updating their radio's memories. And since it's updated with each build, maintenance would be a snap. Now I'm not so sure that's the best way to go here.
Mike
There's quite a bit of detail in the table, and it exposes some of the internal Chirp implementation details.
If we can figure out what's most relevant to the end user, then it should be possible to reformat that information to make it more accessible to an end user. What do you think the main attributes are ?
mike
To me, from a newcomer's perspective, this is a serious issue. Picture someone picking up a radio for the first time (never had one of these in their lives), and they come across this table from the link in the wiki. How are they supposed to understand all that without some sort of legend?
For what it's worth, I've never thought that CHIRP nor its documentation should be geared at someone who has no idea what they're doing.
There's nothing to suggest floating a mouse over anything for a description. Perhaps that should be added to the sentence that introduces this table as an explanation. It would be better than nothing.
Again, it's generated from the code automatically. It's meant for developers and interested people that know what they're looking at.
I was thinking of pointing to this table in the individual radio articles so a newcomer could find out the basics about the radio - including whether this radio supported clone, live or file (what is that?) processing for updating their radio's memories. And since it's updated with each build, maintenance would be a snap. Now I'm not so sure that's the best way to go here.
Agreed, which is why I said in my previous mail that it's likely to be used by documentation-writers, in addition to the folks it was intended for (developers). I think you said you're looking to help out by creating (or starting the effort to generate) the user-level documentation. I feel that the table is likely to be helpful for you (well, tomorrow's table with Tom's update), but it's not necessarily what should be presented to the end-user.
--Dan
participants (3)
-
Dan Smith -
Michael Pittaro -
Mike Agner