Board Thread:News and Announcements/@comment-15636815-20131111185541/@comment-15636815-20131129123107

Rastislav,

(new numbers)

1. Filtering is not going to happen. Native MediaWiki cannot do it. People have written a couple of filtering extensions for their wikis, but they work very differently than we want it to work here.

2. I see pros and cons (positives and negatives) with the "Key Facts" boxes. 3. I haven't yet looked at the shorter intro texts in detail. However, I frequently edit those thiings in Workshop E as I go. We should wait until we're ready to go live with everything before we attempt to make any of that text "final".
 * PRO: Consistent presentation of data throughout the page.
 * PRO: Good integration of "smiley" legend.
 * PRO: Game Updates could be placed in a collapsible table that begins with the last row of the Key Facts table. G.U. data is exactly the sort of data that collapsible tables were designed to contain.
 * CON: Too busy. Listing every source of free and bonus extensions is distracting, occasionally confusing, and definitely unnecessary. (This is especially true of the "Train Slots" box.) Listing the maximum available probably is a good idea, but we should leave the rest of that info in the table itself.

4. Identifying the types of data (Train Slot, International Slot, etc) in the left column of each table is good. Using different terms than the game uses is bad. In particular, "Local Train Slot #xx" is a big box of confusion just waiting to be opened. Nothing in the game is called "Local Train Slot". People can find "Train Slot" in the game easily enough, and our text makes it crystal clear that these are for local trains. It's even a subsection of the "Local Trains" section! I strongly recommend we use "Train Slot" and "International Slot" to match the terms the game uses.

5. Bold names in left column: This MAY be a good idea in the cells that have images, because that text can be difficult to see. Apart from that, this idea--and especially the method used on your WorkshopExt page--are severe violations of Wikipedia's MOS. Again, I think bold text may be the solution we need in the cells with images. I put them in Workshop E for testing. For all others, let's stick with Wikipedia's standard guide, please. 6. I understand your point about colspan="3". I agree that it looks cleaner than the current method. I also agree that it doesn't hurt sorting. I disagree that it has no drawbacks. Look at your WorkshopExt page, at the Rails table. This table has five entries, but it's difficult to see that initially. Your eyes automatically move to the four cells with images. The listing for Maglev 1st Rail has no image, PLUS that row is tiny compared to the other four. It gets lost quickly and gets found slowly.
 * Bold text is designed to be used sparingly, when needed for emphasis. When half of the text on a page is bold, it loses its value.
 * Using a ! instead of a | for those cells is a huge no-no.
 * It converts the cell from a regular data cell, which it is, to a "row header" cell. In other words, the table's design tells the user: "The items in the left column are equal in importance to the items in the header at the top of the table." This is true in some tables. It is not true for any table on any page of the TrainStation Wiki.
 * Screen readers draw more attention to these cells than they deserve. This creates confused users.
 * Using rowspan already creates issues with sorting. Row headers also have the potential to screw up sorting. Using unnecessary row headers is like going swimming in the ocean and begging someone to tie heavy weights to your feet.

That does not mean that I think colspan="3" is a bad idea. It means the idea needs work before we can use it. Yes, that line looks better then before. No one cares how good your data looks if they can't see the data. :-)

7. Superscript for 1st, 2nd, etc.:  NO!! Out of the question. Absolutely not. I will not bend on this issue. There is no room for negotiation.
 * Wikipedia's subscript &amp; superscript page makes it clear that those features are for specific uses where they are critical, mainly formulas, mathematical expressions, and chemical notation such as H2O.
 * Wikipedia's MOS guide for numbers, under the subheading "Typography", clearly states:The ordinal suffix (st, nd, rd, or th) is not superscripted (123rd and 496th, not 123rd and 496th).

This is because the superscripted text is more difficult to read for many people who can see. For people who cannot see, it gets worse. Screen readers interpret them inconsistently, and almost always differently than the author intended.

You have many, MANY good ideas, and I'm using a bunch of them to help me design our new Extensions page. I hope you continue to present your ideas. A few of your ideas are things that need more thought or, in one case, will not work for our purposes. Please let go of the chaff and concentrate on the things that work well. We need more improvements like those!