Testing Updates to "Template:Infobox_TRS" -- Request for comments

Status
Not open for further replies.

QDP2012

Member
Joined
Feb 8, 2012
Messages
1,921
Good morning all,

An update to "Template:Infobox_TRS" is being tested on the articles listed below. Your review and comments are requested below.

---
The intent of the update is to:
  • Increase ease of reading/navigating by:
    • Making link-names shorter
    • Decreasing word-wrapping in link-names
    • Maximizing use of white-space
    • Increasing uniformity of text-positioning
    • Visually separating TRS details (NAC, WACN, RAN, etc.) from the TRS General Info (name, location, etc.)
    • Adding the optional ability to hide the following parameters in the TRS Details section of the Infobox, when they are unused/unrelated:
      • SysType
      • SysID
      • CTone
      • WACN
      • NAC
      • DMR CCode
      • NXDN RAN
      .
  • Decrease/Shorten overall length of the Infobox by:
    • Listing multiple callsigns in a horizontal comma- or space-delimited list instead of a vertical line-break-delimited list.
    • Adding the optional ability to hide any unused/unrelated parameters in the TRS Details section of the Infobox, as mentioned above.

  • Add new functionality or convenience
    • Provide uniform links to the TRS-specific Site Maps produced by the RRDB
    • Add the "Trunktracking FAQ", "Trunktracking Glossary", and "Wiki Editing FAQ" links to the "Other Resources" section, which did not exist when Template:Infobox_TRS was created.
    • Add the optional ability to include the "Tracker..." templates uniformly in the Infobox_TRS template-call, so that they no longer need to be applied separately to articles.

---
The pages used for this test are:


---
Additional change(s) planned:
  • Also, later, after initial implementation of the updated-template across the Wiki, the "FCC" parameter (which in the existing template can only handle one callsign), and the "MoreCallsigns" parameter, will be merged into one parameter that handles multiple callsigns.

  • Later, as needed, parameter(s) for TETRA systems will be added, with the option of hiding it/them.

  • After this update is finalized and implemented, then the other "Template:Infobox_TRS_..." templates will be updated accordingly, to achieve parameter and presentation uniformity across all TRS templates as much as possible.




Request for comment



Thanks in advance for your help and comments,
 
Last edited:

QDP2012

Member
Joined
Feb 8, 2012
Messages
1,921
Some updates...
---
---
Additional change(s) planned:
  • Also, later, after initial implementation of the updated-template across the Wiki, the "FCC" parameter (which in the existing template can only handle one callsign), and the "MoreCallsigns" parameter, will be merged into one parameter that handles multiple callsigns.

To the test-template , the new parameter "Callsigns" has been added which overrides, and will later replace, both the "FCC" and the "MoreCallsigns" parameters. This will allow the existing-template, when updated, to be backward-compatible with the existing template's articles, and will allow the "FCC" and "MoreCallsigns" parameters to be deprecated smoothly article-by-article as the updated-template is applied across the Wiki. When all related articles have been updated to use the "Callsigns" parameter, the "FCC" and "MoreCallsigns" parameters will be considered deprecated entirely, and will then be removed from the template.



---
  • Add new functionality or convenience
In the test-template, the parameter "SysName" now has a default-value of (the system variable) "{{PAGENAME}}", which means that the parameter "SysName" will no longer be required on the TRS' primary-page, because the primary-page's name is the same as the TRS' name, and the Wiki engine will automatically place the page's name in place of the system variable "{{PAGENAME}}". If the InfoBox is applied to a TRS' secondary page (like RID/UID page, or Unknown TGs page, or other Trunking Info pages, etc.) then the "SysName" parameter would be used to specify the TRS' correct name on the TRS' secondary page.




---
EDIT:
  • Later, as needed, parameter(s) for TETRA systems will be added, with the option of hiding it/them.

TETRA related parameters have been added to the test-template, and can be hidden when unused/unrelated.


---
Comments and suggestions are welcome.

Thanks,
 
Last edited:

ka3jjz

Wiki Admin Emeritus
Joined
Jul 22, 2002
Messages
25,354
Location
Bowie, Md.
It's really not necessary to even consider TETRA at this point. The FCC has put a kibosh on any public safety system using TETRA (see the thread on this topic), and like Open Sky, there are no scanners now, or in the planning stages (that anyone is talking about, anyway) that can copy this mode.

To me, it's a non sequitur

Mike
 

ka3jjz

Wiki Admin Emeritus
Joined
Jul 22, 2002
Messages
25,354
Location
Bowie, Md.
The New Jersey Turnpike entry should be using the Multi county template, since it goes up and down the state. I didn't change it since it's a part of your test bed

The only concern I might have would be the FCC callsigns. If there are more than a few of them, I can see that area becoming pretty crowded and hard to read. That's why I built the multi site templates - so we can use the RR mapping functions (which you already have) to view them.

It's a little odd seeing the trunktracking FAQ and the other one showing their links on two lines, but due to the length, you can't help it...Otherwise this looks nice..Mike
 

QDP2012

Member
Joined
Feb 8, 2012
Messages
1,921
Thanks

The New Jersey Turnpike entry should be using the Multi county template, since it goes up and down the state. I didn't change it since it's a part of your test bed
Thanks for catching that. I noticed the county was designated as "multiple" or "various" but didn't stop to assign a different template at the time. Since you reminded me of it, I looked at all of the articles that use either the multi-county or the multi-state templates, and have made some adjustments to the test-template so that when I update the other templates, they will simply invoke the main TRS template but with custom values. That way the look-and-feel will be consistent no matter which template is assigned to a particular article.



The only concern I might have would be the FCC callsigns. If there are more than a few of them, I can see that area becoming pretty crowded and hard to read. That's why I built the multi site templates - so we can use the RR mapping functions (which you already have) to view them.
I understand and agree; but so far, I have only seen a few articles that have a good-handful of callsigns, which in this new format seems like it would only be two rows. So, hopefully, it won't be a problem. But, I will definitely monitor that in case something gets too long and needs some spacing-adjustment or something.



It's a little odd seeing the trunktracking FAQ and the other one showing their links on two lines, but due to the length, you can't help it...Otherwise this looks nice..Mike

Yeah, single-line would have been ideal, but this seems to work.

Thanks for the time it took to review everything and for the comments.


I will still be in test-mode for a while, working through the articles to make sure nothing gets messed-up by the updates to the test-template. I will post here again when things get finished up, and at any major points along the way as needed.

Thanks again,
 
Last edited:
D

DaveNF2G

Guest
TETRA can be detected by DSDPlus. I'm not sure if it decodes it yet, but there are other tools for that as well.

Let's try to keep RadioReference salient to more than just scanners, please.
 

Spitfire8520

I might be completely clueless! =)
Joined
Jun 29, 2009
Messages
1,969
Location
Colorado
Bringing this topic back to light as I believe there is an error with the Infobox_TRS_P25 and P25P2 templates. I do not believe that the CTone field is relevant to any P25 system as is it specifically related to Motorola systems. The CTone field should be removed from all P25 infoboxes.

I am a bit unsure on how to approach this as the current P25 infobox has been mass deployed to more than a hundred articles with "CTone = ?" already set by default.
 

QDP2012

Member
Joined
Feb 8, 2012
Messages
1,921
Bringing this topic back to light as I believe there is an error with the Infobox_TRS_P25 and P25P2 templates. I do not believe that the CTone field is relevant to any P25 system as is it specifically related to Motorola systems. The CTone field should be removed from all P25 infoboxes.

I am a bit unsure on how to approach this as the current P25 infobox has been mass deployed to more than a hundred articles with "CTone = ?" already set by default.

Good afternoon Spitfire8520,

Thanks for pointing out this issue, but I am already monitoring it, and have been since the design-phase of the Infobox_TRS update project.

Right now, I am still in the testing-phase for the new InfoBox TRS templates, though I am deploying the templates in a controlled manner while testing each individual deployment, (not "mass-deploying" -- meaning not without evaluation of the template-design at each step).

As I encounter any issue with template-design, I investigate and research the situation, and then adjust the template(s) accordingly, but only after ensuring that there are no exceptions to the hypothesis (whether a parameter should be added or removed).

Even though I agree (since initial design) that the parameter CTone seems to be unnecessary for P25 systems, the CTone parameter was included because, during the research part of the design-phase, the parameter was found to have a value listed in the DB and/or the Wiki for at least one P25 or P25P2 TRS.

During design and testing, I have been watching for this CTone issue, and already plan to review all of the P25 / P25P2 TRS pages (in DB and Wiki) again before ending the testing-phase, to confirm whether the CTone parameter can be removed, or whether it must be kept.

If during that review, I find that the CTone value is not displayed in the DB and also not in the Wiki for the P25 / P25P2 TRS's, then I will remove the CTone parameter from the related templates, and update the template-calls on the related P25 / P25P2 Wiki pages. (Of course, on the other hand, if the CTone parameter has a specific value in either the DB or the Wiki, then those situations would need to be addressed individually before I remove the parameter from the template.)

I appreciate you posting your concerns here instead of making adjustments to the templates that are still being tested.

Thanks again for bringing up the issue.
 

GTR8000

NY/NJ Database Guy
Database Admin
Joined
Oct 4, 2007
Messages
15,372
Location
BEE00
Connect Tones are not used for P25 systems, period. If any wiki articles for P25 systems have any value in the CTone field, then it is incorrect and should be removed. As should the CTone field from the P25 templates.
 

QDP2012

Member
Joined
Feb 8, 2012
Messages
1,921
Connect Tones are not used for P25 systems, period. If any wiki articles for P25 systems have any value in the CTone field, then it is incorrect and should be removed. As should the CTone field from the P25 templates.

That is what I expected when I started, but if I recall correctly, there were CTones listed on P25 TRSs in both the DB and Wiki. During my review I will check the DB and submit change-requests for any I find accordingly. I will also take care of the related templates and Wiki-pages.

Thanks to both Spitfire8520 and you for bringing up the topic and clarifying the correct use of Connect Tones.
 

GTR8000

NY/NJ Database Guy
Database Admin
Joined
Oct 4, 2007
Messages
15,372
Location
BEE00
That is what I expected when I started, but if I recall correctly, there were CTones listed on P25 TRSs in both the DB and Wiki. During my review I will check the DB and submit change-requests for any I find accordingly. I will also take care of the related templates and Wiki-pages.

Thanks to both Spitfire8520 and you for bringing up the topic and clarifying the correct use of Connect Tones.

No 'Connect Tone' field exists within the RRDB for P25 systems, so it would have to be something that was entered into one of the free-form text fields. As far as a Connect Tone being listed in the wiki for a P25 system, well that's another story entirely. ;)
 

QDP2012

Member
Joined
Feb 8, 2012
Messages
1,921
No 'Connect Tone' field exists within the RRDB for P25 systems, so it would have to be something that was entered into one of the free-form text fields. As far as a Connect Tone being listed in the wiki for a P25 system, well that's another story entirely. ;)

Thanks again to both of you for clarifying these points. The P25 / P25P2 templates still being tested have been updated accordingly, and the Wiki pages to which they were applied were also updated.

I will still do the planned review just for quality-control, as the project continues.

Thanks again,
 

GTR8000

NY/NJ Database Guy
Database Admin
Joined
Oct 4, 2007
Messages
15,372
Location
BEE00
While we're on the subject, how does the Wiki handle P25 systems that have multiple SysID's, WACN's, NAC's?
 

QDP2012

Member
Joined
Feb 8, 2012
Messages
1,921
While we're on the subject, how does the Wiki handle P25 systems that have multiple SysID's, WACN's, NAC's?

The new Infoboxes that are still being tested can handle multiple values for those parameters without any problem, as comma-separated values, which allows natural wrapping within the column. Also, the html <br/> command can be used to force a new-line, if really needed. Commas are easier for most people, and should be used unless there is a clear reason to employ a <br/> in the parameter's value-list.

Examples of comma-separated values
e.g.: SysID = 123, 234, 345, 456, etc.
e.g.: WACN = ABC12, ABC13, ABC14, etc.
e.g.: NAC = 123, 124, 125, 150, etc.

Examples of consistent multiple values
e.g.: WACN = BEE00 (for all SysIDs)
e.g.: NAC = 123 (for all SysIDs)


If you know of a different use-case, please let me know, so I can consider it relative to the current template-design. -- Thanks.


After testing and initial deployment is complete, and all "initial" template-changes have been finalized, I will create corresponding documentation for the templates which will include examples of multiple values for the given parameters.


Hope this helps,
 
Last edited:

ka3jjz

Wiki Admin Emeritus
Joined
Jul 22, 2002
Messages
25,354
Location
Bowie, Md.
I noticed that infobox template is being built based on the trunk type- in this case, Project 25 phase 2. While it looks nice, it's opening up a HUGE can of worms. Are you planning on going through every state and province, adding a new infobox for each, then adding new templates for everything that uses NXDN and DMR trunking?

That's where this is heading; that's a whole lot of work that is really unneeded, as the warning templates can be put on any article, and no changes are needed for the infobox based on trunk type. Not to mention the cleanup that will be necessary to remove all the orphaned templates once the conversion is done. I doubt Bob would be looking forward to doing that (heh)


Mike
 

AK9R

Lead Wiki Manager and almost an Awesome Moderator
Super Moderator
Joined
Jul 18, 2004
Messages
9,262
Location
Central Indiana
As I've stated before:

If we make the Wiki too complicated and challenging to edit, I think we risk losing user contributions to the Wiki.

Let's try to keep things simple. The whole idea of the Wiki is that is less structured than the DB.
 

QDP2012

Member
Joined
Feb 8, 2012
Messages
1,921
I noticed that infobox template is being built based on the trunk type- in this case, Project 25 phase 2. While it looks nice, it's opening up a HUGE can of worms.
From my chair, I see no can of worms being opened here.

Are you planning on going through every state and province, adding a new infobox for each, then adding new templates for everything that uses NXDN and DMR trunking?

That's where this is heading...
Completely incorrect assessment/guess and conclusion. The new Infobox_TRS... templates are first type-specific, then (as was in the earlier generation of templates) by US or CA/Canada. I am not creating InfoBox_TRS... templates based upon states or provinces.

Not to mention the cleanup that will be necessary to remove all the orphaned templates once the conversion is done. I doubt Bob would be looking forward to doing that (heh)
Again, inaccurate/incomplete assessment and conclusion. When I am done, there will only be nine (9) Infobox_TRS templates that will need to be deleted because they will no longer be used at that time.



As I've stated before:
Let's try to keep things simple. The whole idea of the Wiki is that is less structured than the DB.
The new versions of the Infobox_TRS... templates do not create more structure in the Wiki than the old Infobox_TRS... templates did/do. Any Wiki-editor is as free in choosing their page design now as before. As mentioned earlier, too much simplicity is what led to the problems we have with the Infobox_TRS... templates that are being replaced. They are templates that were created when the Wiki had one primary type of TRS (Moto Type II), and were updated to handle P25, then P25P2, then TRBO, then NXDN, then Tetra, etc. The revisions made the "simple" Infobox_TRS templates convoluted and unusable, hence the need for newer templates.

The new Infobox_TRS templates simply...
(1) present the TRS' information in a more readable format in the box,
(2) eliminate incorrect/unused fields that do not relate to the particular TRS' system-type,
(3) follow the existing/pre-established owner-type groups found on (nearly) every "Trunked Radio Systems (ST)" page (education, public, private, utility, etc.), which makes it easier to maintain those static lists because of the templates' "What Links here" feature,
(4) make it much more obvious which TRS is being referenced so that when TRS's get renamed in the DB, or worse when a TRS name is reused verbatim in the DB for one of a newer type, then the existing Wiki page (for the old TRS) is not confused with the new TRS, as has happened _many_ times in the Wiki heretofore, and can be appropriately preserved and deprecated if needed.

Hope this helps,
 

ka3jjz

Wiki Admin Emeritus
Joined
Jul 22, 2002
Messages
25,354
Location
Bowie, Md.
I don't think you understood what I was questioning. If you look in the list of templates just for Phase 2, you have one that is just for the US, military, military multi county, military multi state, public, public multi county, public multi state, utility, utility multi state; roughly 24 in all.

The logical progression of this is that this pattern would be extended for TRBO and NXDN trunks. This would mean a HUGE amount of work to convert all the trunked system articles, and you would eventually need to drop the originals (all right I will accept your 9 - I think there's more but I could be wrong...). In addition, the one you have coded that says 'US' on it suggests that, at some point, you would need one for Canada, and other countries that we have in the wiki. And each of them would require a series of infoboxes for P2, DMR, etc.

And it's all unnecessary.

It may well be more readable, but it's absolutely less flexible. By using the various warning templates, variations on the original 9 can be easily coded. And here's the kicker - if a new trunk type were ever to be identified, you are painting yourself into a corner by having to create numerous new infoboxes to maintain the pattern. The way it is now, all you'd need to do is to create a new warning template and apply that where needed.

Needed? In my not-so-humble opinion, no. More complex? Yes, most definitely. Potentially setting up additional confusion (even now, folks aren't always sure as to which infobox template to use, when they do use them) as to which infobox to use? Without a question.

This is an unnecessary exercise. You're free to do as you wish, of course, but I think you're making a huge mistake in making things a heckuva lot harder for folks to use. This path seems to be somewhat similar to the one the database uses - even money says that a page with a hard coded message for Phase 2 was built for these systems.

Do we really want to go down that rather inflexible path?

Mike
 
Last edited:
Status
Not open for further replies.
Top