Multiple trunking info boxes templates

[ka3jjz]

I was going to start to go through all the trunking articles in the wiki and standardize them with an infobox template, thus giving these articles a common 'look and feel ' (as is the norm with a database) but it seems we have a problem

There are a fair number of such infobox templates already out there - many of which are state-specific. They don't all show the same information - some have FBI links, for example, others don't. Most do have their own 'return to db' link.

I was going to start with the RID/UID pages we have already identified and see if they tie to a database entry. If they did, that page would get an infobox, and a link to the article with the RID/UID information (along with whatever other information is already there). However with several versions of the infobox out there, it would appear that before I can even think of attempting this, some decision has to be made about consolidating these templates to a single version - one that would apply to everyone.

Thoughts? Mike

 

[ka3jjz]

Here is an example of an article that could be 'standardized'. Click the wiki button for;

Pacific Gas and Electric (PG&E) Trunking System, Various, California - Scanner Frequencies

Now for someone coming in from the database, it's not really a problem. However one must keep in mind that this is not the only path to get to the wiki article. If someone were to look at this article directly, there's no context here for this information. No system information, no link to the database, FCC information - nothing. This limits this article's usefulness.

This is the kind on construction that should be avoided, I think

Mike

 

[ka3jjz]

Here is a link to all the 'trunking infobox'es that I could identify in the template namespace

Template:Federal Trunking Infobox - The RadioReference Wiki

Template:Illinois Infobox - The RadioReference Wiki
(evidently this one has an error that was never corrected)

Template:Iowa Infobox - The RadioReference Wiki

Template:Michigan Infobox - The RadioReference Wiki

Template:Minnesota Infobox - The RadioReference Wiki

Template:Minnesota Trunking Infobox - The RadioReference Wiki

Template:MultiCounty Trunking Infobox - The RadioReference Wiki

Template:Trunking Infobox - The RadioReference Wiki

Template:Wisconsin:Trunking Infobox - The RadioReference Wiki

As you can see there's some redundancy, but some unique items here, too. Those that don't have any users could likely be dropped.

Mike

 

[QDP2012]

...some decision has to be made about consolidating these templates to a single version - one that would apply to everyone.

I understand your intent, and appreciate the uniformity-goal that you describe.


However, since the Wiki is community-maintained, my opinion is that in general...

• "content and presentation-style" should be "maintained by community" and can thus vary in many ways showing the creativity of contributors and the differences between communities.
  
  
• "structure and navigation" should be "maintained/supervised by administrator" to help ensure uniformity and consistency so that navigation is convenient and easy for all Wiki-visitors.

I think that infobox-style and infobox-content is almost entirely a matter of presentation-style, and as such should be left to the page-contributor(s) to choose.

• If one region relies on the FBI heavily and another region does not even have FBI, then it makes sense to have customized infoboxes to reflect that difference.
  
  
• My interest in uniformity of the infoboxes only goes far enough to ask "are the infoboxes clear and understandable?"
  • I have thought about developing an alternate horizontal layout for the TRS infobox because of how the vertical affects surrounding text.

I also believe the infoboxes should be optional, just as the "collaboration" template is optional. Even though I used the "collaboration" template on the first few pages I created, I plan to remove it from them because I like the appearance better without it. I believe the infoboxes should be optional, too.

The differences in layout-style choices shows the creativity of the contributors, and gives contributors room to experiment and learn more about the Wiki and how to program in it. When/If the fancier GUI drag-and-drop Wiki-editor tools are implemented, we might see even more creative layouts since contributors won't need to know (so much) Wiki-code.

Uniformity certainly has its place and its benefits. I just don't see a big value in trying to consolidate these infobox styles, especially since many are similar, and maybe are even derivatives of one another. Administratively limiting the Wiki community to a particular infobox style seems too restrictive.

Allowing contributors to learn-by-experimenting with different layout styles hopefully will lead to more active and more experienced contributors. That's how I started here.

Just a thought,

 

[ka3jjz]

Well I agree with most of that - except that making the infoboxes optional opens the door to a very unclear article. Look at the one I posted in an earlier message. If you were to come into that directly (not via the db), you have absolutely no context in which to understand the data there. What kind of system is it? Do we have a db entry for it?

While I agree that we probably shouldn't require an infobox, I think it should be strongly encouraged. Otherwise articles like that one stand out there without much to explain them

I don't think it's a good idea to wait to see if someone is going to install a tool to help in writing in MediaWiki. The more these kinds of articles proliferate, the more difficult it's going to be to correct the problem as time passes. I kinda doubt anything is going to happen on that front, to be honest, unless W9BU has something he knows on that subject.

Mike

 

[QDP2012]

Regarding data/content, I certainly agree that the information normally contained in the existing TRS infobox template would add value, and probably significant value, to the above PG&E page. I was not meaning to suggest otherwise.

I think page creators should be encouraged to clearly display the data commonly displayed by the infobox, and offered the infobox as a convenient starting point for their page-design, but not required to use the infobox as a specific presentation-style.

Edit:
My statement about the GUI tools was not suggesting that anyone wait until the tools are installed before improving a page's content or design. Rather it was intended to point to the GUI tools' enhanced capability and convenience, and how design-experimentation should be encouraged now especially since upcoming tools will let the page-creators be more creative.

 

[AK9R]

However, since the Wiki is community-maintained, my opinion is that in general...

• "content and presentation-style" should be "maintained by community" and can thus vary in many ways showing the creativity of contributors and the differences between communities.

I disagree, to an extent, on your first point. The RR Wiki is a feature of RR that has some value. As a valuable part of the RR experience, I think the administrator, me, should steer the presentation style towards a certain level of consistency. Mike and I through the years have maintained an informal style guide and we occasionally enforce it when we see major deviations from it. However, we've never built a rigid style guide, so most of our presentation ideas are contained in the Wiki quick editing guide.

As for a better Wiki editor, I know that the MediaWiki folks are leaning in that direction, but we typically lag behind their software development and we tend to avoid the Wiki extensions and add-ins as much as possible.

 

[ka3jjz]

Well, Bob - what do you think I should do here? We have an awful lot of articles in the trunking categories that resemble the PG&E article. While I'm kinda loathe to use multiple types of infoboxes, it would be better than we have now.

If I did put in infoboxes, would I need to split off any of the data that the article now has into separate sub-articles? After all, at least some of the infoboxes say that this is where a user may index articles related to that trunk system. Articles that are real long should be split off anyway to allow their topics to grow without creating a frankenstein sized monster (which can get hard to read, never mind maintain)

I think I would like to see the RID/UID categories contain nothing but that data - it would open their articles up so that they could grow without overwhelming the rest of the data in the article. It would surely simplify reading it, too. Right now, at least some of this data is mixed up in the article.

Once that's done, then perhaps I could look at the Trunking Information categories.

Mike

 

[AK9R]

Well, Bob - what do you think I should do here?

Relax. Put your feet up. Have an adult beverage. Nothing that we do here is going to change the world.

While I'm kinda loathe to use multiple types of infoboxes, it would be better than we have now.

I'm not crazy about it, either. But, maybe, multiple types of infoboxes is better than not having any at all.

If I did put in infoboxes, would I need to split off any of the data that the article now has into separate sub-articles?

Use your discretion, but don't make a lot of work for yourself. Refer to my opening remarks.

I think I would like to see the RID/UID categories contain nothing but that data - it would open their articles up so that they could grow without overwhelming the rest of the data in the article.

I agree.

 

[ka3jjz]

An adult beverage, huh? 16 or 32 oz (hi)?

OK let me take a crack at this. I'll do a few, then I think I need to look at that Illinois template that the wiki is flagging with a loop error. I don't understand that one - no doubt it's some sort of coding issue there.

Mike

 

[QDP2012]

I disagree, to an extent, on your first point. The RR Wiki is a feature of RR that has some value. As a valuable part of the RR experience, I think the administrator, me, should steer the presentation style towards a certain level of consistency. Mike and I through the years have maintained an informal style guide and we occasionally enforce it when we see major deviations from it. However, we've never built a rigid style guide, so most of our presentation ideas are contained in the Wiki quick editing guide.

I understand. And, thank you for the clarification on guidance-formality and -informality.

As for a better Wiki editor, I know that the MediaWiki folks are leaning in that direction, but we typically lag behind their software development and we tend to avoid the Wiki extensions and add-ins as much as possible.

I expected this to be the case even if only due to system-stability and security requirements. Thank you for even considering the MediaWiki's GUI tool.

 

[QDP2012]

An adult beverage, huh? 16 or 32 oz (hi)?

OK let me take a crack at this. I'll do a few, then I think I need to look at that Illinois template that the wiki is flagging with a loop error. I don't understand that one - no doubt it's some sort of coding issue there.

Mike

The Illinois Infobox template code is this:

{| class="toccolours" style="width:23em; border collapse:collapse; border:1; font-size:90%; text-align:left; float:right;" cellpadding="2"
|+ style="margin-left: inherit;" | '''{{{County}}} County, [[Illinois(US)|Illinois]]'''
|-
|colspan="2" align="center"|{{{Image| }}}
|-
| '''County Number'''
| {{{County Number}}}
|-
| '''[[Illinois_State_Police|ISP]] District'''
| {{{ISP District}}}
|-
|valign="top"| '''[[Michigan_State_Police|MSP]] Post'''
| {{{MSP Post}}}
|-
| '''[[Department_of_Transportation_(MDOT)_(MI)|MDOT]] District'''
| {{{MDOT District}}}
|-
| '''[[Department_of_Natural_Resources_(DNR)_(MI)|DNRE]] District'''
| {{{DNRE District}}}
|-
| '''[[Michigan%27s_Public_Safety_Communications_System_(MPSCS)|MPSCS]] Zone'''
| {{{MPSCS Zone}}}
|-
| '''[[FBI_North Eastern_Region#Michigan|FBI]] Division'''
| {{{FBI HQ}}}
|-
| '''[[FBI_North Eastern_Region#Michigan|FBI]] Resident Agency'''
| {{{FBI RA}}}
|-
| '''FIPS Code'''
| {{{FIPS}}}
|-
| '''ctid'''
| {{{ctid}}}
|-
|colspan="2"|
----
|-
|colspan="2"|[http://www.radioreference.com/apps/db/?ctid={{{ctid}}} {{{County}}} County Database]
|-
|colspan="2"|[http://www.radioreference.com/forums/michigan-radio-discussion-forum/ Michigan Forum]
|-
|colspan="2"|
----
|-
|colspan="2"|[http://www.mediawiki.org/wiki/Help:Contents MediaWiki]
|-
|colspan="2"|[[Quick guide to editing pages|QuickRef]]
|-
|colspan="2"|[http://meta.wikimedia.org/wiki/Help:Reference_card PDF Card]
|}<noinclude>


<pre>
{{Michigan Infobox
|County        = 
|County Number = 
|MSP District  = 
|MSP Post      = 
|MDOT District =
|DNRE District = 
|MPSCS Zone    = 
|FBI HQ        =
|FBI RA        = 
|FIPS          =
|ctid          =
 }}</pre>
</noinclude>


[b]{{Illinois Infobox
|County        = 
|County Number = 
|ISP District  = 
|      = 
|IDOT District = 
|IEMA District = 
|IDPH District = 
|IDNR District = 
|MABAS Division  = 
|FIPS          = 0
|RR ctid     = 
}}
[/b]

Please note the last section which I have bolded for emphasis. It is CALLING "Illinois Infobox", which is the template's own name, so it is calling itself, in a self-referential call. This section should be removed to prevent the looping-error.

I would also expect that the section preceding it (see the call to Michigan Infobox just below the PRE-tag) should also be deleted, so that only the top section remains.

EDIT: correction: The second section is INACTIVE because it is wrapped with the NOINCLUDE tag. If the closing NOINCLUDE tag were moved from the end of the second section to the end of the third section, it probably would prevent the looping-error also.

EDIT2: in preview-mode, moving the closing NOINCLUDE tag seemed to have no effect, which suggests the third section would need to be removed to prevent the looping-error.

EDIT3: the third section has been removed, clearing-up the looping error.



Hope this helps,

 

[ka3jjz]

Thanks. This is timely since I'm now up to Illinois. I'll start with this state shortly...Mike

 

[DaveNF2G]

I prefer consistency of presentation where possible. However, not all systems or system types are configured identically, so there does need to be some latitude to account for actual differences among the systems being described.

Such leeway is not as possible or permissible in the DB because it is a database and must have some overall structure imposed upon it. Consequently, there are many DB listings with blank fields simply because those fields are not relevant to the entity listed. It seems to me that the Wiki is a far more inherently flexible way to allow for a clean presentation of information that has different parameters and that such flexibility should be "managed" (for want of a better term), but not to the point of inflexibility.