Difference between revisions of "Forum:Page layout templates and formats"
|Line 60:||Line 60:|
: And one more aside: [[User:Rancke|Rancke]] mentions 7,000 articles. When I use the toolbox app named "special pages" under the "statistics" option (Wiki data and tools), I see the following: 11,418 content pages. In just over 4 months, I have been able to edit well over 5,000 pages and probably many more pages. Whatever the community decides, we can match up everything and make it all look sharp. It's possible. I am not the only ultra-productive editor and contributor to the community. We can make this happen. I've really enjoyed working with some of the many users here already and I'm very much looking forward to working more with an old grognard and valued member of the community like [[User:Rancke|Rancke]]. Let's make this happen. Not to be lurkers. Not to argue about OTU, ITU, and all that, but come together to make this site even better. [[User:Maksim-Smelchak|Maksim-Smelchak]] ([[User talk:Maksim-Smelchak|talk]]) 14:07, 28 April 2015 (EDT)
Revision as of 16:17, 28 April 2015
I've seen two discussions regarding the layout of headers on the article pages:
- First discussion - how/why the sub-headings are done on articles. I've tended to do them however the existing article was marked up, but I don't really understand why each sub-heading includes the full name (and more) of the article. Surely that is redundant information that just adds to the bulk of the page. It also makes it more difficult to use the headings in the "Contents" list as anchors on the page to direct links in from outside as a link could be something like Zhodani#History & Background (which only takes you to the top of the page as the subheading is not complete) but instead would have to be Zhodani#Zhodani (Sophont) History & Background (Dossier)(which will take you to the desired location on the page).
- Second discussion - I don't think it's a good idea to introduce a new article format without discussing it first. I, for one, would not have approved. The basic idea is that we try to keep articles so like actual in-setting library data as we can (subject to various practical limits). The multiple headlines and parentheses makes the articles seem overly busy and quite disquieting to me. It also makes them stylistically different from the 7,000 previous articles. Rancke (talk) 21:24, 26 April 2015 (EDT)
I tend to agree with both of these points. I would like to come to a good agreement about the size and scope of the headers in the article to allow clear delineation of topics without over specification. Tjoneslo (talk) 19:56, 27 April 2015 (EDT)
- Hi Rancke, I think you make excellent points. I did not act alone and Tjoneslo liked some of the layouts I helped pioneer enough to make a template out of them. I am very open to discussion and cooperation as part of the community. Please note that there was and still is discussion. I am not a lone wolf and I am a very reasonable person. Thank you. Maksim-Smelchak (talk) 20:12, 27 April 2015 (EDT)
- Hi Rancke, please also note that these layouts are not a brand new thing. They have been around for nearly four months now and vetted by the community of active users, many of whom like them and have begun to use them. This being a new occurrence to you coincides with your last contribution (before the last few days) being nearly four months ago. At any rate, I do not want to pick a fight. I admire you and your work. Thanks for all of your hard work over the years. Maksim-Smelchak (talk) 20:15, 27 April 2015 (EDT)
The heading system, which is very much a work-in-progress, works as following:
SUB 2 hierarchy -- ARTICLE (category) [2-word title such as 'History & Background'] (clarification) --
SUB 3 HIERARCHY --- ARTICLE (One of the two word titles) [area title] ---
SUB 4 HIERARCHY
[area title] ----
There are four SUB 2 HIERARCHIES common to most articles:
- History & Background (Dossier)
- References & Contributors (Sources)
The above four SUB 2 HIERARCHIES govern most articles, but specific layouts exist for articles, which benefit from other categories.
So, for instance, publications use two different version of the basic SUB-2 HIERARCHY:
- [Book title] (Book) Synopsis
- [Periodical title] (Periodical) Synopsis
They both add a category for: [Book title] (Book) Credits
And that's it in a nut shell.
The system was originally developed by intelligence agencies such as the MI6, CIA, KGB, GRU, etc. Hence, the word "dossier." I'm a former military guy and I used similar systems in the two militaries I had experience serving.
It is now also used in many Wikis, particularly those for younger readers (I have worked on the "Five Nights at Freddy's" Wiki), who grew up with electronic information devices, "Handcomps" in Traveller parlance, and do not have the willingness to read long tracts of expository writing.
This system breaks down those expository "whales" into smaller, more digestible pieces and allows readers to pick out what they are most interested in... (such as militaries, synopses, etc.). This often leads to the reader deciding to read the rest of the article.
It also makes it easier for active users to see what's missing from an article and could be added to, such as "History & Background", a GURPS World Paragraph, or other "holes" in what's available.
Since the system has been implemented in January 2015, I have been non-scientifically monitoring the articles and their access counts. Pages with the layout schema are overwhelmingly being read more. This could be due to many factors, but I think at least one contributing factor is that the pages are more organized and it's easier to access the information.
I don't know what the community will, in the end of ends, decide to go with, but I do very much think that the pages could use some kind of an organizational schema.
- As one more aside, I am a former public school teacher and have exposed hundreds of young people over the years to Traveller and other games ("Lunch-time Game Club"). I meet very few young people who have the patience to dig through the canon of dozens or hundreds of Traveller books that now exists. Every time I run games with groups of young people, I refer them to the Traveller, which has been far more successful at getting those same young people interested in Traveller lore and the Traveller OTU storyline. It works. Wiki technology, when well-organized can be one of the best tools we older grognards have for getting the younger generation interested. I see that idea in action all the time. Some of my friend's children and former students get the Traveller bug from a site like this. Maksim-Smelchak (talk) 14:07, 28 April 2015 (EDT)
- Such an organizational scheme isn't needed for old grognards like many of us, folks like User:Jmattera, User:Ronald B. Kline, Jr., User:OGuutan, User:Tjoneslo and many others. We grew up with Traveller when it consisted of an easily-countable number of books. The newer generation hasn't had that experience and never will. They need help. Plus, as a generality, they are not as literary, as many of us were. They are far more apt to text, surf the Internet, use a computer than to read an old-fashioned Mk. I book. Collecting some of the lore in this Wiki, making it easy to access, and having it organized is a boon toward the goals of getting more young people interested in Traveller. In summation, the older generation of Traveller fans doesn't need much of any of the articles on the Wiki, we are already dedicated fans. The younger generation needs a project like this very much. Maksim-Smelchak (talk) 14:07, 28 April 2015 (EDT)
- And one more aside: Rancke mentions 7,000 articles. When I use the toolbox app named "special pages" under the "statistics" option (Wiki data and tools), I see the following: 11,418 content pages. In just over 4 months, I have been able to edit well over 5,000 pages and probably many more pages. Whatever the community decides, we can match up everything and make it all look sharp. It's possible. I am not the only ultra-productive editor and contributor to the community. We can make this happen. I've really enjoyed working with some of the many users here already and I'm very much looking forward to working more with an old grognard and valued member of the community like Rancke. Let's make this happen. Not to be lurkers. Not to argue about OTU, ITU, and all that, but come together to make this site even better. Maksim-Smelchak (talk) 14:07, 28 April 2015 (EDT)
- I'll add my thoughts here as well.
- I don't have any problem understanding the benefit of subheadings. The point I find odd is the fact that every subheading has the name of the article in front of it when that is obvious from the fact that it is on that page. A set of subheadings that are individually concise are still helpful in subdividing the bulk of an entry (although they can still be a bit much in something that is only going to be a sentence or two long anyway). So using subheadings (with further subdivisions as appropriate) in the fashion:
- Meta-History & Background
- makes a lot of sense to me. But when this is added to the article GURPS Traveller: Alien Races 4, as an example, and then you use:
- GURPS Traveller: Alien Races 4 (Book) Synopsis
- GURPS Traveller: Alien Races 4 (Book) Description
- GURPS Traveller: Alien Races 4 (Book) Meta-History & Background
- GURPS Traveller: Alien Races 4 (Book) Credits
- GURPS Traveller: Alien Races 4 (Book) Contents
- you have massively increased the word content in the subtitles with no benefit, and you have reduced the effectiveness of the subheadings as navigation link anchors. About the only useful bit to my mind might be the (Book), which could be added as a single line at the start of the article to indicate the category it falls into if it was felt necessary to do so.
- How an individual looks at categorisation of information probably depends on their experience. I have worked for a long time in technical marketing, writing detailed technical data sheets, product performance recommendations and technical papers. In all those cases, short, concise subheadings clarify the divisions in the document without adding unnecessary overhead.
- I'm happy to implement whatever is agreed as a method, but given a vote I would go for simplicity as an aid to clarity.
- OGuutan (talk) 16:12, 28 April 2015 (EDT)