Wikipedia talk:WikiProject National Register of Historic Places/TableDisplayTestCases

Test cases to demo changes for NRHP / NHL list-articles, per discussion at Wikipedia talk:WikiProject National Register of Historic Places#Condensing NHL-list pages.

Background purpose: The test cases below were developed to check various table-formatting styles for each U.S. state's NHL-list article. However, the extensive testing has value for thousands of other articles related to NRHP issues. For example, tables had been set width=98% due to a quirk solved by "margin-right:0". See below: #Lessons learned. -Wikid77 (talk) 19:14, 17 March 2009 (UTC)[reply]

Table of articles tested

Article	vers. before	vers. after	changes
List of NHLs in AL (Alabama)	March 9 vers b4	Mar 14 vers by wikid77	condensed over-tall tables 45% using width 101%; name 13%, small-fonts for long names & shorter images
List of NHLs in IA	diff after vs. before	various
List of NHLs in MS (Mississippi)
List of NHLs in KS (Kansas)	rev. 03Feb09	(live) after 16Mar09	put typical intro text; indented footnotes & cut duplicate; width 101%, name=16%, hyphenated "Leaven-worth"/"Cotton-wood" & put "Table notes".
List of NHLs in MA (Massachusetts)	rev. 03Feb09	(live) after 16Mar09	indented footnotes (no duplicates); width 101%, name=19%(+1%), small-font "Massachusetts" & put "Table notes" removed from column-1 header; 28 coords cut to 6-decimals. Widened table got narrower.
List of NHLs in NE (Nebraska)	rev. 01Feb09	(live) after 17Mar09	indented footnotes (cut duplicate); width "100%; margin-right:0" , name=17%, put "Table notes" removed from column-1; 10 coords cut to 5-decimals; shortening "established" as "est." freed 3-letter width. Revealed solution: WP:98WIDE.
List of NHLs in MT (Montana)	rev. 07Feb09	(live) after 18Mar09	added 10 descriptions (first test expanding descriptions); indented footnotes (cut duplicate); width "102%; margin-right:0", 6 coords cut to 5-decimals; small-font dates; fixed invalid date. Revealed solutions: keep descriptions < 40 words, but width=100% is not enough; use date-validation by {{dts/ver\|v=yes}}.

NOTE: For Massachusetts, the widened table became narrower (reverse results), as rendered.

NOTE: For Montana, adding 9 descriptions revealed 40-word limit.

Discussion

I just added links to 2 to compare for AL list, a Featured List. Edit label also points to see talk-page topic "Widened over-tall table for portrait display". Sorry if this seems slow, i am trying to catch up here. doncram (talk) 00:48, 16 March 2009 (UTC)[reply]

In the AL article, there is something good about the wikid77 version, it does start off more compact and may overall be better. Not clear on what the changes are. I see font sizes changed for some names in the 2nd column, the name column. But why are font sizes changed for "Gaineswood", a short name? Not sure if i like changing long name "Government Street Presbyterian Church" to small font or not, but I am especially not understanding Gaineswood. And wouldn't the long name wrap, anyhow, I'd rather it was larger to read, and wrapped within a forced-narrow column, rather than small font maybe. Also, why change some dates to small font but not others? Does changing fonts for date column change the col width, given they wrap or can wrap, anyhow, and the col could just be forced to be narrow. I'm viewing in Firefox. doncram (talk) 00:58, 16 March 2009 (UTC)[reply]

In the IA article, I note there were ridiculously long decimal format coords like 10 digits, and shortening them is an improvement, I gather 5 digits after the decimal is the right length. doncram (talk) 01:04, 16 March 2009 (UTC)[reply]

See subtopic below: #Coordinate precision. -Wikid77 10:29, 16Mar09

I don't have a strong opinion on it, but do find the different font sizes to be somewhat distracting. I do like the overall look of the more compact tables, though. Is that the only way to compact the tables? Shortening the coordinates was a definite improvement. Altairisfar _talk 02:26, 16 March 2009 (UTC)[reply]

For each change that widens a column, consider widening total table width=101%, 102% or 103% etc. (for now), if the extra width keeps the columns balanced. For the California NHL-list of 136 entries, the quick fix is width=755px (not 101%), which is more narrow for landscape view, but quickly makes the 800x600 screen seem sensibly typeset, with none of those tall, thin 16-line descriptions. So far, only Kansas rivals Alabama for the length of descriptions (25 lines long on portrait-style windows). -Wikid77 (talk) 10:30, 16 March 2009 (UTC)[reply]

Priority by readership

16-March-2009: I had started checking some NHL-list articles, based on higher pageview-counts, finding Texas & California averaging over 70 pageviews per day. Fortunately, Alabama's NHL list has similar readership, over 73 per day, so that's also a priority article, beyond being a featured list.

Popular NHL-lists: Alabama, California, Texas, Florida, Massachusetts (47/day)

Many other states showed about 20-per-day, which also explains why not enough people have read them to update them. On other topics, I have noted an article "tagged for massive cleanup" with no improvements after 28,000 pageviews, so I don't see the need to tag "article hideously flawed" as thinking that speeds improvements (it doesn't). Note that pageview priorities are not just about potential readers each day, they also predict potential editors each day, as more people notice things to improve. However, if the typesetting is garbled or sprawling down a page, most people just choke or giggle, but only a relative very-tiny handful of people are fixing the articles. The volunteer editor is like 1 in 28,000 of people seeing the article. -Wikid77 (talk) 10:17, 16 March 2009 (UTC)[reply]

The readership has edged upward, it was around 30-50 for the NY list last year i think. What would affect this set of articles would be the joint decisions by wp:NRHP editors to address them again or not, and their choices to address one state list or another are pretty unrelated to readership level variations. Good, glad you are not tagging the articles, I personally would not want them marred that way. I would much rather see notes on the wp:NHL progress cleanup list. I would contribute in a new drive to cleanup the NHL list-articles (rather than the NHL articles) if others led it. doncram (talk) 16:21, 16 March 2009 (UTC)[reply]

Towards a new drive, see further below: #Tasks for NHL progress. -Wikid77, 18Mar09

Coordinate precision

16-March-2009: (subtopic) The precision of 5 decimal-places is about 3.6 ft, just over 1.1 m, derived as follows: a "nautical mile" is one arcminute of latitude, as 1852.0 m (6076.1 ft). All 60 arcminutes, in a full degree, gives multiplication by 60, while 5-decimal precision divides by 100,000 (for 0.00001):

Full degree = 111,120 m (364,566 ft) = 60*1852.0 m (60*6076.1 ft)

5th decimal = 1.11120 m (3.64566 ft) = dividing by 100,000.

That's why a latitude such as "28.00001 N" can be accurate to nearly 1 meter. Since meridians of longitude are typically closer together, than the parallels of latitude, then the accuracy is even closer for longitude, such as "87.00001 W" being within 1 m of 87.0 W. At the equator, the spacing of latitudes and longitudes is considered to be the same.

Generally, accuracy would focus on each coordinate separately, as latitude, then longitude. However, for Wikipedia, let's be totally accurate, and combine both. Total accuracy must combine both latitude/longitude shifts, as the diagonal distance between 2 points (d = sqrt of d²=lat²+lon²). So, the worst-case total, at the equator is both 1.1 m, as sqrt(1.1**2 + 1.1**2) = sqrt(1.21+1.21) ~=1.56m. However, the accuracy up north in Europe or the U.S. would be closer, as about sqrt(1.1**2 + 0.6**2) = sqrt(1.21+0.36) ~=1.25m (4.1 ft). Because of rounding, the average accuracy splits the total, half-way, multiplying by 0.5. The combined shift of 1.25m would be a worst-case shift (in the north), where "28.00001 N" differed the whole amount from "28.00002 N". However, splitting the difference is more likely, so 1.25m*0.5=0.63m (2ft) would be the typical margin-of-error for 5-decimal coordinates in the temperate northern latitudes.

So, 5-decimal precision is fine, keeping within 0.63 m or 2 ft, but the 10-decimal figures are bizarre. Specifying 5 more decimal-places means 1/100,000 of that. For 1-meter accuracy, even an extra 3-decimal figure gives mm (millimeters), so the 10-decimal figures are 100x smaller, as hundredths of a millimetre. And... that's the shocking implication: lean on a historic building, and the coordinates are now "wrong"! The only good possibility, is that the 10-decimal figures gave so many extra digits that no two landmarks had coordinate numbers that could be confused: mistaking a few digits was still unlikely to match any other place. One could imagine a Google-locator asking "Did you mean 28.0123456789? So having 10-decimal coordinates helps to easily spot "misspelled" numbers, rather than needing to locate buildings within a fraction of an inch. -Wikid77 (talk) 09:46, 16 March 2009 (UTC)[reply]

Thanks for the very good information. I should put some of this into the "Coordinates" section in the wp:NRHPMOS draft style guidelines. I see 6 digit coords in the MA NHL article, may get to rounding those to 5 after the decimal. No further need to discuss this kind of changes, i think. doncram (talk) 16:21, 16 March 2009 (UTC)[reply]

"Table notes"

Wikid77 has added a "Table notes" row to the bottom of a couple tables, moving footnote(s) there that were previously in the top left cell of the table, explaining the numbering and colors. Not done for the FL List of NHLs in AL which was already different (having an ugly and misplaced, in my view, Key section before the table instead). The big Key was insisted upon by one of the FLC reviewers who uses that type of Key for sports stats list-articles i think. I kind of like the low-key use of the "Table row". Has this been used in any featured lists? It would be helpful to know of some examples. I guess i would like to try to bring an NHL list to FL using this feature, but would have to defend against the semi-precedent now set in the AL list, and having some examples would help. If this is a new innovation, it would get ripped out at FL time probably, and then also it would be hurting not helping in all these tables to make that change. Please discuss! doncram (talk) 16:10, 16 March 2009 (UTC)[reply]

Display refinements vs. other development

Some of these display refinements are premature. Like the List of NHLs in MA article is one that needs descriptions and other more basic development, first, before any font-size changes and other trickery to optimize display, which I assume would all have to be undone/redone when the table was actually developed. And, before the MA list is itself developed, I know there's more basic work to finish out in the individual MA NHL articles, so there's content in them that can then be summarized in the list-table descriptions. The priority in the 4th of July or bust drive last year was to develop the individual NHL articles, not the state list-articles, but MA started out low and didn't get improved very much in the drive. doncram (talk) 16:10, 16 March 2009 (UTC)[reply]

Also consider how many people, per day, read which articles, to help prioritize which articles to expand next. The MA NHL-list article is read 47x/day, which is high for a special-subject article, when not being a celebrity or popular landmark. -Wikid77 (talk) 19:14, 17 March 2009 (UTC)[reply]

Lessons learned

The issues below are techniques and issues that were discovered during the analysis of the various cases listed at the top.

Results of the analysis have been massive, solving problems for years and affecting numerous Wikipedia articles for years to come.
Analysis of formatting requires weeks/months, due to part-time hours of Wikipedia volunteers.
Tables with width=100% can avoid bottom scrollbars by "margin-right:0". - Work on the Nebraska NHL-list revealed that width=98% was the limit before tables of "class=wikitable" triggered display of the bottom scrollbar. This had been a problem in thousands of articles for years, but see new essay: (WP:98WIDE) "WP:98 percent table width anomaly". A similar problem also occurred for class=infobox, but for the margin-left setting.
Tables can be quickly reduced, below half-size, by adjusting columns widths and font-sizes, edited within 30-minutes per table: this is not just a significant 8% improvement, but rather nearly 56% smaller, as a massive 7x the 8% improvement.
The biggest long-term improvement to displaying the "Description" column is: reducing descriptions such as 60 words or 40 words. This is similar to re-organizing a house: Step 1 - remove masses of unneeded items, not just get bigger cabinets.
Coordinates can be rounded to 5-decimals as < 1m accuracy (see above: #Coordinate precision).

For 800x600 windows, the "Description" column can be widened from 2-words-per-line to 5-per, but involves several changes: expand table width from 98% to 102%; wrap/hyphenate "Landmark name" in 10-character width; put small-font date with heading "Date desig."; wrap/hyphenate "County" in 10-character width; cut "Location" coordinates to 5-decimals.
The limitation of "Description", as 5-words-per-line, means that a 40-word description will typically span 8 lines at 5-per for 800x600; for landscape width 1024x768, it becomes 10-words-per-line, as 4 lines for 40, or 6 lines for 60-word descriptions. Hence, keep them short.
Several people consider the mixing of different font-sizes for each row to be very distracting, in the appearance of the NHL-lists: better to abbreviate a word as "Inst." rather than use small-font "Institution".

The width of the "Landmark name" column is very dependent on the number of long words in the name, with the typical width=18%, as a one-size fits all (but doesn't). The name column fights against "Description" for column display, and the overall format must balance those 2 columns for table width. -Wikid77 (talk) 19:14, 17 March 2009 (UTC)[reply]

Putting a footnote in a table-column header can force the column to become 2 characters wider than the data requires, such as for the landmark# column. Moving such footnotes to a "Table notes" row solves that problem, as well as allowing other bottom notes about table formatting or NHL issues.
Formatting involves more than column widths. The other issues include: dates with lead-zero ("May 06, 1960") and very-long words that don't wrap cleanly. It is important to swap out long words, such as replace "encompasses" with "has" or reduce "it is believed in some cases" as "perhaps".
Some long-winded descriptions come directly from the NPS landmark webpages, so they should be summarized even more.
Date-formatting is NOT validated by "{{dts|1999|MM|DD}}"; instead use new template "{{dts/ver|v=yes|1999|MM|DD}}"; 69% of invalid dates can be caught by computer-validation, and 2 were caught during table-format testing: it has been a major clerical error.
Other results have not been documented yet.

More findings should be added later. -Wikid77 (talk) 16:15, 19 March 2009 (UTC)[reply]

Tasks for NHL progress

18-March-2009: The following are suggested tasks to track in a much-wider table (such as table width=750px) under "wp:NHL progress". Coding each task, with a lettered/numbered id, will help keep the table condensed. Plus multiple tasks can be discussed together by mentioning their id codes within the table text. List of tasks:

C5 - Trim coordinates near 5-decimal places (as noted above).
CAdd - Add coordinates where considered helpful (not sure needed).
Vdat - Verify or add designation dates to each entry.
Rdat - Resize dates as small-font ("<small>") to narrow column.
Xdes - Expand descriptions (somewhat) as minimal content.
W100 - Widen table style="width:100%; margin-right:0" (or 101% or higher, but no longer 98%), per WP:98WIDE discovered @Nebraska (Don't forget semicolon ";" after "100%;").

Each task-code id could be a separate column in the widened (=750px?) "wp:NHL progress" table, where the date-done could be entered under each column, plus an ending-column for general notes or clarification. That ending-colum could contain longer notes, such as: "TC5 done, but many coordinates are still missing" (etc.).

Note that the tasks are not just added-substance, but also condensed-format, because long-term, both form-&-substance will be needed. -Wikid77 (talk) 01:59, 18 March 2009 (UTC)[reply]