Wikipedia:Featured list candidates/List of chronometers on HMS Beagle/archive1


 * The following is an archived discussion of a featured list nomination. Please do not modify it. Subsequent comments should be made on the article's talk page or in Wikipedia talk:Featured list candidates. No further edits should be made to this page.

The list was promoted by Giants2008 20:10, 18 June 2012.

List of chronometers on HMS Beagle

 * Nominator(s):  Spinning Spark  23:20, 17 May 2012 (UTC)

I am nominating this for featured list because it is a list of important instruments on an important voyage of a highly notable ship. Besides which it tells a great story. It has been through Peer Review and GOCE.  Spinning Spark  23:20, 17 May 2012 (UTC)

Support -- The frood (talk) 21:42, 20 May 2012 (UTC)


 * Support interesting, well written, nicely illustrated, good work. The Rambling Man (talk) 11:11, 14 June 2012 (UTC)

Comments from RexxS

Disclaimer: This is a fascinating list/article, covering a real niche topic in fine detail. Any following criticism is not intended to detract from my impression that this is a piece of work worthy of being considered "among Wikipedia's best".

In terms of accessibility, the more complex you make the structure of any table, the less likely it is to be accessible by all screen readers. A table which contains no row or column spans is guaranteed to work with virtually any user agent, including text-only browsers that may be used by visitors on very low bandwidth connections. A sophisticated screen reader like JAWS will generally make quite a good job of fairly complex tables, but at the cost of some misinformation. For example, in the table 'Chronometers on second voyage', the cells with images would be preceded by the spoken word "Maker" when column header announcement is turned on. Generally, I'd recommend that tables are best when used to contain comparable information on a number of related items.
 * Therefore, I'd question whether it is a good decision to include images within a table if most of the entries do not have images. Would they not be better as larger images with an informative caption in the surrounding text?
 * Similarly, is it better to include the rows which contain considerable extra commentary, such as K, M, V, and X in 'Chronometers on second voyage'? or is it better to employ the same technique as you used in the two 'Chronometers on first voyage' tables, where you added extended commentary beneath each table? Simplifying the tables will always lead to an increase in accessibility.

I see that you are concerned about the visual appearance of the lists, and have mentioned white-space as a consideration. I've taken a screen-shot of how the table 'Chronometers on second voyage' appears on my monitor at http://www.metropolis2.co.uk/demo/Beagle%20chronometers%20list.png
 * If minimising white space is an important consideration, then you need to appreciate that setting explicit column widths (rather than percentages) will lead to the sort of problem with white space that the screen shot illustrates. The table 'Chronometers on third voyage'' appears even more cramped to me for the same reasons.

It's worth remembering that HTML is a markup language, not a desktop-publishing program, and attempts to fine-control how a browser displays content will always lead to problems when different screen sizes, resolutions, and browsers are considered. There's no perfect solution, and I encourage you to consider my comments above as 'food-for-thought' for you when looking at the compromises you have to make in each table. --RexxS (talk) 12:47, 5 June 2012 (UTC)


 * You have not commented on the suitability of the format I pointed you to at User:Spinningspark/Sandbox. Please take a look at this before the format of this article gets ripped apart yet again.  My original concept for the format of this article was the much simpler scheme of a sub-heading for each chronometer and the tables being used merely to format basic information.  This was changed following comments at Peer Review.  I'm sure you will appreciate my reluctance: it is a little soul-destroying to have to completely rework an article each time a new reviewer comes along.  I certainly don't want to do it before the editor concerned is given an opportunity to comment.  Whatever the solution here, I am utterly against separating images and/or text from the chronometer to which they belong.  This makes the article more difficult to understand by everybody, including those with screenreaders.
 * Regarding the whitespace, the issue is to avoid large amounts of whitespace within the table. I appreciate that there is whitespace to the right of the table on your screen, but that is not the issue.  If I were to display the article using the full width of my double-monitor 3840 pixel display there would be even more whitespace to the right.  But on such a display, if the tables were made 100% width of the screen, the columns with just single words or numbers would be spaced so far apart the table would be virtually unusable.  At the other end of the scale, on my 1024 pixel notebook, the table still displays quite nicely, and does not need a scrollbar until the window is reduced to about half that size.  Getting down as small as PDAs and mobile phones the table will not fit on the screen, but then neither will most tables on Wikipedia.
 * Your point that some text is outside the table already is not really valid. In all cases this can be justified because the text is not describing a chronometer, is describing a group of chronometers, or is quite close to the chronometer being described anyway.  Spinning  Spark  14:13, 5 June 2012 (UTC)
 * At the time I looked at your sandbox, the table was so far from usable that I didn't seriously consider it. Your latest sandbox version is a worthwhile improvement, though.
 * I understand your reluctance to change things: it's only natural when you've put a lot of work into an article. Nevertheless, as I look through the revision history of the article, I see a gradual, but significant improvement over time. Each new reviewer seems to have given you good advice.
 * You asked my opinion on the accessibility of the tables in this FLC. I'm sorry if I wasn't clearer: the tables can be coped with by some screen readers, but could be improved. The most significant improvements would be to simplify the structure of the tables, and to ensure that captions are unique.
 * I disagree with your contention that moving excess text out of the table is not justifiable because of loss of proximity to the relevant entry. I don't find it appropriate to jam large amounts of additional text (or images) into just a few entries. But I suspect we have a different view of the purpose of tables anyway. --RexxS (talk) 16:42, 5 June 2012 (UTC)
 * Here's where I'm coming from: this article is being sold as a list. If list means anything, it means describing the items of the list sequentially by members.  To restructure it in some other way puts into question its qualification as a list.  The article was not originally table format.  I don't see how you can maintain that the move to a table format was an improvement and at the same time point out the shortcomings of having all the information in table format for screenreaders.  The original format would have been completely trouble free for screenreaders as far as I can make out.  A lot of effort went into getting this into table format, but if it has to be unpicked then so be it (although I might go away and sulk for a week or two before doing it).  Spinning  Spark  17:23, 5 June 2012 (UTC)
 * Here's where I'm coming from: a table is an HTML structure designed to contain a two-dimensional list. That is a list where each entry (row) contains individual data that is essentially similar to the corresponding data for other rows. I used to write databases for a living, so I guess I tend to look at a table as if it were a 'flat-file' database. I fully accept that tables are equally validly used as a means to organising a display of related information, so you mustn't take what I say as a prescription - it's just one way of looking at things. I would say that screen readers in particular treat a table as if it were a database with column headers being the fieldnames and row headers being the primary key entries, so I find my approach as useful in solving problems with the accessibility of tables.
 * Please don't unpick your list to an earlier format. I can support the present layout as acceptable, if not optimal. I'm interested in your sandbox version as it appears to be an improvement. Would you be able to find the time to get User:Graham87's opinion on the contents of your sandbox? He is a very experienced wikipedian who is blind, so I always value his opinion on these issues. (You'd have to clean up the refs, etc. so as not to distract him from the zero-width column that is the key point here, though). --RexxS (talk) 17:51, 5 June 2012 (UTC)
 * I'll drop a note to Graham87. You are right, we have different views on the purpose of tables here.  The table is merely a tool to help format the article.  The table is adjusted to suit the required content of the article, we don't adjust the content to suit the requirements of tables.  The starting point to me is the conception of what the article should look like, then choose the tools to achieve that conception.  I am not really very interested in writing the kind of articles that are "prose-free" table=database in nature.  Spinning  Spark  18:31, 5 June 2012 (UTC)
 * I like the sandbox version, as it's easier to navigate with my screen reader than the previous version, especially due to the extra "Extended comments" column (which is fairly easy to move past when necessary). Graham 87 07:13, 6 June 2012 (UTC)
 * That's more than good enough for me - and thank you once more, Graham!
 * Please make the changes to the list, Spark; and I'd be grateful if you moved that sandbox to a permanent subpage. I'd like to refer to it in future as a sensible technique for reducing the impact of rowspans when extra-large cells are needed.
 * @TRM - this looks a good work-around, and I think we need to keep it in mind for future FLCs when similar rowspan problems arise. --RexxS (talk) 14:23, 6 June 2012 (UTC)
 * The changes have now been made and I have added an example to Manual of Style/Accessibility/Data tables tutorial/Internal guidelines.  Spinning Spark  19:44, 6 June 2012 (UTC)

Thank you, Spark. I'd be happy to support this list article for FL on accessibility grounds and general interest. Other reviewers are commenting on other aspects. --RexxS (talk) 20:00, 6 June 2012 (UTC)


 * The above discussion is preserved as an archive. Please do not modify it. No further edits should be made to this page.