Template talk:Aviation accidents and incidents

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
WikiProject iconAviation: Accidents Template‑class
WikiProject iconThis template is within the scope of the Aviation WikiProject. If you would like to participate, please visit the project page, where you can join the project and see lists of open tasks and task forces. To use this banner, please see the full instructions.
TemplateThis template does not require a rating on Wikipedia's content assessment scale.
Taskforce icon
This template is supported by the Aviation accident project.

Colors[edit]

Not sure how to change this but it would be better to have some color other than red since that usually denotes an article that doesn't exist.Prezbo (talk) 09:11, 24 February 2010 (UTC)[reply]

bold blue[edit]

While it makes sense, the article you are currently on shows in bold also, so someone might think it's an error. Maybe it could be a different color instead? Griffinofwales (talk) 20:42, 18 April 2010 (UTC)[reply]

Symbols instead of colors?[edit]

I don’t think the colored (orange, purple, red) and boldface markup of the deadliest accidents is really working. The markup code is ugly, and the end result isn’t much better. I do not know if Wikipedia has a “standard” way of doing this, but it seems[citation needed] that many[who?] use dagger symbols († and ‡) for referencing notes. How do y’all like the following template:

Much cleaner, no? –Fred Bradstadt (talk) 07:01, 21 April 2010 (UTC)[reply]

  • Support, of course. It is quite at odds with all manner of accessibility guidelines to be denoting information with just color. Besides, the current colors are icky. A fine idea, Jack Merridew 07:38, 21 April 2010 (UTC)[reply]
  • Support Much better. Griffinofwales (talk) 16:08, 21 April 2010 (UTC)[reply]
  • Strong Oppose, it's a bitch to try and find the deadly ones. It works fine for the 2000 template, but for a year with a lot of accidents it becomes a pain in the elbow. Rimush (talk) 20:04, 13 May 2010 (UTC)[reply]
    • Use your browser to search for †/‡ and you should be all set. If you cannot easily enter the characters with your keyboard layout, you could copy/paste them from the template. –Fred Bradstadt (talk) 19:35, 16 May 2010 (UTC)[reply]
  • Support seems reasonable to me (note I switched the list format to use WP:HLIST, but left the symbols alone). Frietjes (talk) 23:31, 24 August 2012 (UTC)[reply]

All lost/All survived[edit]

Should we include symbols for flights where all souls were lost or that had no fatalities? --ÆAUSSIEevilÆ 03:52, 15 June 2010 (UTC)[reply]

Opposed. I think your test clearly shows how cluttered the template becomes when you try to put too much information into a navbox. I’d prefer to just have a symbol only on the year’s deadliest incident. But again, that’s just my opinion. –Fred Bradstadt (talk) 18:41, 2 July 2010 (UTC)[reply]
Supported. I especially support it in the case of incidents with no fatalities. - Mr. Initial Man

Column-based format[edit]

Please see the discussion at http://en.wikipedia.org/wiki/Template_talk:Aviation_accidents_and_incidents_in_2009#Alternative_layout, which I suppose should've happened here.
Some column widths in the templates using this template need a little (more) tweaking; "col1width", "col2width", "col3width" can be set to achieve this. 212.84.98.102 (talk) 08:55, 8 July 2010 (UTC)[reply]

  • First, you should see the (albeit brief) discussion above, on boldface/colored markup of the deadliest accidents. Second, I think the column-based layout looks quite horrible (pardon my French). If your browser window gets too narrow or too wide, it just doesn’t work. Who decides whether a template should have 2, 3 or 4 columns? And when you add a new entry to a template, you might have to move the columns around and re-tweak their widths? No thanks, please give me back the plain, simple list. –Fred Bradstadt (talk) 18:43, 9 July 2010 (UTC)[reply]
  • Thanks for your feedback. I looked through the discussion above (after that at http://en.wikipedia.org/wiki/Template_talk:Aviation_accidents_and_incidents_in_2009#Alternative_layout and checked that the combination of italics for 50+ deaths and bold smallcaps for deadliest incident ensures that neither nor the combination of both is confused with Wikipedia's bolding of self-referential links. The problem with listing the incidents in a string -- especially with dates in brackets after each link -- and with the small (one-character) dagger/double-dagger marks is that it's difficult to see at a glance what happened and when during a year and which incidents/incident involved more than 50+ deaths. I agree, though, that the column approach assumes a certain minimum page width. (Three columns is the maximum otherwise there is the assumption that most folk are using screens/windows over 800 by 600 px. Re-tweaking them if/when a new link is added is hardly a strain; the one-entry-per-line in each template's code assists here.) Perhaps the following hybrid of your preferred string approach and formatting from the current layout might be acceptable? Precise dates are absent -- follow a link to find this detail -- but a distribution (by every two months, so no more than six groups) remains visible.
The groupnames ("Jan / Feb" etc) would be included in the base template, so those without lists wouldn't appear. If a possible six-group template due to the two-monthly distribution is felt to be too big, the distribution could become three-monthly, i.e. to a maximum of four groups. For very early years, i.e. those with only a handful of links, the option to have a single list (without groupname) could be included -- in fact, if it's really on the chronology that's needed for the template, i.e. no specific dates or months, then the one-list approach could work thus:
This seems the closest to your preferred format while remaining less cluttered. It also continues to use the dot spacer that many (most?) Wikipedia navboxes use.
Perhaps a "Request for comment" should be issued? 212.84.100.119 (talk) 00:18, 12 July 2010 (UTC)[reply]
  • We disagree on the boldface/smallcaps/italics versus daggers (†‡) thing. I think that the daggers work well for getting an overview. Wading through the Wikipedia manual of style for good arguments, I read the following: “Use the simplest markup to display information in a useful and comprehensible way. […] Use HTML and CSS markup sparingly and only with good reason. […] Typically, the use of custom font styles will: * reduce consistency, since the text will no longer look uniform; […] * increase arguments, since other Wikipedians may disagree aesthetically with the choice of style.” Placing <span> tags and &nbsp;s shouldn’t be necessary.
At WP:NAVBOX I found the following:
  • “The goal is not to cram as many related articles as possible into one space. Ask yourself, does this help the reader in reading up on related topics? Take any two articles in the template. Would a reader really want to go from A to B?
  • They should be kept small in size as a large template has limited navigation value.”
Maybe the problem is that we try to put too much information into the navboxes? I mean, what are the differences between {{Aviation accidents and incidents in 2009}} and Category:Aviation accidents and incidents in 2009? The chronology, and the “severity indicator”. Instead of making the navboxes clones of the category pages, maybe we should just have the “severe” or “major” incidents in the navbox, listed chronologically? Or by body count?
As an aside, if you (212.84.100.119 and 212.84.98.102) are the same person, you should consider creating an account – and a single talk page.
Fred Bradstadt (talk) 20:50, 12 July 2010 (UTC)[reply]
  • Seems to me that it's either the bi-monthly layout (the navbox above that I've remained "Bi-monthly") or according to fatalities (the navbox below). That provides more information that the category page (a single list). By fatalities would also mean there wouldn't be the need for smallcaps/italics or (double-)daggers:
Personally, if not the columns, I think I'd prefer the bi-monthly layout plus italics/smallcaps. I suppose the (double-)daggers could be reintroduced, but, when there's quite a few "50+ deaths" to list (as in the 1989 examples above, for instance), you don't think there'd be too many daggers to look at..? 212.84.100.119 (talk) 18:19, 13 July 2010 (UTC)[reply]
Instead of daggers, the {{I sup}} could be employed, see {{Empire A ships}} for an example of how it's used. Mjroots (talk) 06:24, 1 August 2011 (UTC)[reply]

Colouring[edit]

I think other colours are needed instead of just blue, i.e. orange, purple, etc. Then it will be a lot easier to distinguish the deadly ones, as the dagger symbols are too small and unnoticable. Also, there would be no need for the smallcaps (which I think are hideous), as the deadliest would be it's own colour and/or bold. Ggoere (talk) 07:31, 17 August 2010 (UTC)[reply]


RFC: Aviation accidents and incidents template change[edit]

Out of curiosity I tried Mjroots' suggestion (see above), here's how it may look like. I think it's better than the current template. C1010 (talk) 05:40, 3 August 2011 (UTC)[reply]

Incidentally, why the superscripts in the above? Makes the template more complicated than necessary...?
Also, I'd add zeros before days 1 to 9 in a month (to keep the article links approximately aligned vertically) or perhaps use columns/tables to ensure the alignment -- although that may be overkill.
213.246.93.91 (talk) 04:20, 7 August 2011 (UTC)[reply]
I added zeros just to see how it'd look, but since it's a proportional font it's not going to align perfectly. As for the superscript, are you suggesting anything else to be used to indicate the most significant accidents? C1010 (talk) 01:57, 11 August 2011 (UTC)[reply]
Well, if the superscripts are going to be used, there'll need to be a key for them somewhere (the 'below' line?). But using italics to distinguish between less/more than 50 deaths seems sufficient..?
Meanwhile, the zeros don't make the alignment exact, but I'd say it's better than it looked before. 213.246.122.214 (talk) 20:26, 13 August 2011 (UTC)[reply]
Any reason why it uses American dates? it would probably look better the other way round. MilborneOne (talk) 20:30, 13 August 2011 (UTC)[reply]
Yes, a key explaining what 1 and 2 mean will need to be added if the superscript is used. Please disregard the current bottom line where it says "Incidents resulting in at least 50 deaths shown in italics....", it'll be replaced with something like 1 - Incidents resulting in at least 50 deaths, 2 - Deadliest incident. C1010 (talk) 22:28, 13 August 2011 (UTC)[reply]
Okay, understood. Thanks. But if there's only two things to be distinguished (at least 50 deaths, deadliest incident) then I reckon the template may as well use the italics/smallcaps method. 213.246.81.32 (talk) 09:59, 16 August 2011 (UTC)[reply]
  • Here's a suggestion: How about adding the column headings ("colheader"s) "Jan – Apr", "May – Aug" and "Sep – Dec" to the three columns and adjusting each template's entries accordingly? This would use the three-column format to suggest how evenly (or not) accidents/incidents occur across a year (and, from template to template, across years). 213.246.84.111 (talk) 07:01, 20 August 2011 (UTC)[reply]

Template breaks style guidelines[edit]

The manual of style discourages the use of small caps: WP:ALLCAPS. Plus they just look weird in this template, IMO. When I first saw this, I thought it was some kind of vandalism. Why is it even important to show the deadliest incident for a given year? Templates shouldn't be designed to optimize trivia contests. The use of italics for high-death incidents seems more than sufficient. Kaldari (talk) 20:54, 8 September 2011 (UTC)[reply]

?[edit]

Daha iyi olmaz mı admins, bürokratlar? (i know small small English)BetelgeuSeginus (talk) 15:35, 23 February 2012 (UTC)[reply]

Previous and following year links[edit]

The template currently links to the previous and following year templates in the very fist line. I removed these links but my edits were reverted. To link all the aviation accidents and incidents by year templates is both contrary to convention and unhelpful to readers. Template pages are for the project and are not content in themselves. In the absence of a series of aviation accidents and incidents by year articles I would like to see these links removed or changed so that they link to the relevant categories. -- Alan Liefting (talk - contribs) 00:46, 4 June 2012 (UTC)[reply]

Two things 1- There are sports templates which link to every year a certain event was played.
2- Changed to relevant category? The yearly templates have nothing to do with categories. Many categories to describe a crash, ::aren't put into an article till months or years after an incident due to the crash needing to be investigated. The only categories in the ::beginning for most crash are time, location, and airline and aircraft involved related. — Preceding unsigned comment added by WilliamJE (talkcontribs)
Replies:
  1. The existence of similar cases is not a relevant point
  2. By way of example Category:Aviation accidents and incidents in 2010 and Category:Aviation accidents and incidents in 2012 are much better links than Template:Aviation accidents and incidents in 2010 and Template:Aviation accidents and incidents in 2012
-- Alan Liefting (talk - contribs) 01:54, 4 June 2012 (UTC)[reply]
The proposed change appears to remove a useful navigation tool from the template, where the reader can see it. It will damage the articles for some theoretical conformance with some mysterious unstated convention. OpposeNigel Ish (talk) 09:34, 4 June 2012 (UTC)[reply]
It is not useful for readers and there is nothing "theoretical" of mysterious" about what I am suggesting. Templates pages are not part of content per se so they are not made directly accessible to readers. -- Alan Liefting (talk - contribs) 09:46, 4 June 2012 (UTC)[reply]
Since aircraft crashes show no respect for the division of time into years, it makes sense to be able to roll forward from an incident in one year to the next incident (which happens to be in a different one). Navboxes are the preferred way of managing this as far as I can see. So I'm opposed to dropping the inter-navbox links. GraemeLeggett (talk) 09:50, 4 June 2012 (UTC)[reply]
But the navigation templates are defined by year and an accident or incident can always be assigned a specific year (or even two). -- Alan Liefting (talk - contribs) 09:57, 4 June 2012 (UTC)[reply]
Yearly category pages don't cover every aviation incident. In recent years they have included a subcategory for incidents in the United States. So readers aren't being brought to a complete list.
As for the existence of similar cases not being relevant, I'll quote you 'To link all the aviation accidents and incidents by year templates is both contrary to convention'. So I countered. That was half your argument, now its not relevant? We shouldn't be having this discussion then....William 10:11, 4 June 2012 (UTC)[reply]
Oppose change. They're navigation boxes, and you want to remove one of the ways they help readers navigate. It just makes sense to keep it as it is. - Jorgath (talk) (contribs) 14:27, 4 June 2012 (UTC)[reply]
I want to remove the current method used for navigation, i.e. between templates themselves which is a little "clunky", and use an improved method. The ideal is a set of "Aviation by year" articles, and it seems that this set of templates is a surrogate for them. An article can do what a category or template cannot do. -- Alan Liefting (talk - contribs) 03:57, 7 June 2012 (UTC)[reply]
Sorry for the delay in response. While I see your point, I'd point out two things. 1) Templates have their own advantage, which is being able to be buried in the individual accident articles. 2) General consensus on how to navigate Wikipedia favors redundant navigation. I think that those two add up to my real position: I have no objection to a series of "list of aviation accidents in (year)" articles as an alternative, but I think the template should also be kept as-is. It may seem clunky to you, but it works well enough for me. - Jorgath (talk) (contribs) 05:01, 19 June 2012 (UTC)[reply]

Accessibility[edit]

This template's use of italics an emboldened smallcaps is an accessibility barrier; consider how these things appear to reader with CSS unavailable; or sound to blind people having the page read to them, for example. We should use characters such as a dagger or hash, as discussed here in 2010. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:05, 4 June 2012 (UTC)[reply]

I thought daggers were discouraged because people mistake them for a cross. Didn't MILHISTORY depreciate them for that reason?Nigel Ish (talk) 15:46, 4 June 2012 (UTC)[reply]
How does CSS handle underlining? - Jorgath (talk) (contribs) 15:52, 4 June 2012 (UTC)[reply]
Yes, Andy Mabbett is right. Per WP:ACCESS#Text, we should make this template accessible to blind users such as user:Graham87.
However, I believe that using bold to indicate major events is a good use of bold - for sighted readers only. So I think we should not drop bold altogether, but rather make it accessible using {{strong}}. This is a good example where we should use the semantic emphasis "strong" instead of the styled bold.
Concerning the similarity of a dagger and a cross, is it really a problem when the dagger is used to indicate deaths? Dodoïste (talk) 18:47, 4 June 2012 (UTC)[reply]
Yes, it is - it violates NPOV to use a cross in non-Christian or crucifixtion-related contexts, if I understand correctly, and the dagger was dropped because too many people thought it was a cross. - Jorgath (talk) (contribs) 19:40, 4 June 2012 (UTC)[reply]
Okay. I understand your opinion regarding the dagger. We can do without it.
I suggest we keep the bold appearance, trough the use of {{strong}} as explained.
Italics is invisible for most sighted readers, it's hard to notice in such a long list. Thus, i suggest to mark both 50+ death and major incidents using {{strong}}. It makes it easier for everyone. What do you think? Dodoïste 213.55.184.161 (talk) 15:32, 6 June 2012 (UTC)[reply]
Not sure we really need to bold the major or worst accident, this is just a navigation template so really doesnt add anything. MilborneOne (talk) 15:44, 6 June 2012 (UTC)[reply]
It is already boldened, in case you did not notice. I believe that boldening major events is meaningful, as the list is long and the reader might want to see the most important links at a first glance. It least I would. Anyway, since this feature is already provided, we should make it accessible to blind users. Dodoïste, from my cell phone, 213.55.184.161 (talk) 18:07, 6 June 2012 (UTC)[reply]
Sorry for the delayed response. I like the idea of using {{strong}} instead of '''bolding''' in the template, if it'll provide the same visual effect while improving accessibility for blind users. - Jorgath (talk) (contribs) 05:04, 19 June 2012 (UTC)[reply]

Has anything changed, yet? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:08, 30 July 2012 (UTC)[reply]

Deadliest[edit]

In July and August 2014, a discussion seemed to conclude that there was consensus to mark the deadliest crash in any particular year. However it seems that this functionality has since been removed from all the relevant templates.

Can WilliamJE, My name is not dave, MilborneOne or Mdann52 spread any light on this? — Martin (MSGJ · talk) 14:41, 12 January 2015 (UTC)[reply]

I am wondering about this also. Thanks for bringing it up! -137.53.91.187 (talk) 00:59, 2 April 2015 (UTC)[reply]

Alignment of dates[edit]

I was bothered by how the template does not vertically align dates properly, so I fixed it. It requires the use of {{vad}}, which I created specifically to be used with such navboxes. It's just a span tag wrapped in template. For comparison, see the old style (2010) vs. the new style (2011):

Yay or nay? Jay D. Easy (talk) 13:44, 17 January 2019 (UTC)[reply]

Looks better. - Ahunt (talk) 14:39, 17 January 2019 (UTC)[reply]
Dont have a problem with the change, makes it easier to read. MilborneOne (talk) 17:37, 17 January 2019 (UTC)[reply]
No problem here either....William, is the complaint department really on the roof? 17:56, 17 January 2019 (UTC)[reply]
I'm seeing no difference between the two. IMvHO, the shipwrecks templates are better, as they take up less space when expanded - e.g. {{2018 shipwrecks}}. Mjroots (talk) 18:29, 17 January 2019 (UTC)[reply]
That's strange. Maybe look again, focus on the dates. In any case, I'll slowly edit these navboxes. Just give me some time. Currently working on shipwrecks first, tbh. Because although @Mjroots: is right in that {{2018 shipwrecks}} takes up less space, but it also offers less oversight. Jay D. Easy (talk) 20:04, 17 January 2019 (UTC)[reply]
Ah yes, dates are different formats. As a Brit I naturally preferr d/m over m/d. Although there really ought to be a option to display whatever format the article uses that the template is placed on. Mjroots (talk) 20:31, 17 January 2019 (UTC)[reply]

Yes Jay D, go for it, and I'm definitely not in favour of the shipwrecks' and rail accidents' layout; they may be more compact when expanded, but they are also messier. Having all the entries neatly grouped in three columns makes it so much clearer. --Deeday-UK (talk) 23:45, 19 January 2019 (UTC)[reply]

Three columns? All I get is a single column! This means there's acres of blank space occupying most of the template. Mjroots (talk) 10:25, 20 January 2019 (UTC)[reply]
What device and browser are you using? With Chrome or Firefox on a wide screen I see three columns, but the table is responsive, i.e. if I shrink the browser window sideways resize the window laterally, the content is rearranged on two and then on a single column. --Deeday-UK (talk) 19:09, 20 January 2019 (UTC)[reply]
Windows 10, Firefox (latest version) 170% screen expansion. Mjroots (talk) 07:04, 21 January 2019 (UTC)[reply]
If that screen expansion has the same effect as Firefox's zoom (Ctrl + scroll wheel), then it could explain why only one column fits in the template on your screen. --Deeday-UK (talk) 01:45, 22 January 2019 (UTC)[reply]
I'm using Firefox 64.0 (current version) here on Linux and he is right, it does display very differently at 170%, just a single column. Just looking at other nav boxes, like Template:2si, it seems to work fine at 170%. Do we need to fix this template so it works at that zoom? - Ahunt (talk) 02:22, 22 January 2019 (UTC)[reply]
Ahunt, I'm not sure what you mean with fixing this template: reflowing text into fewer columns is pretty much a standard behaviour, when not all text fits anymore (e.g. because of increased zoom level). If you zoom {{2si}} at 250% or more, you'll see text reflowing there too. The alternative is not to use columns, which is what, in my view, makes {{2010 shipwrecks}} and {{1996 railway accidents}} messier and less clear. --Deeday-UK (talk) 07:31, 22 January 2019 (UTC)[reply]
Well that is why I asked the question. It could be that we can't make the nav box look pretty at all possible zoom levels in all major browsers. - Ahunt (talk) 14:32, 22 January 2019 (UTC)[reply]
At listwidth=23em, I get two columns. At 24em, it's back to one. Mjroots (talk) 20:42, 22 January 2019 (UTC)[reply]

I'm happy to go ahead and implement this proposal then, and with a further tweak: omitting the colon, which isn't present in the current template and isn't really necessary. --Deeday-UK (talk) 14:59, 18 December 2020 (UTC)[reply]

Proposed overhaul[edit]

Though these templates look a lot better now that all of them use {{vad}}, I still don't like what I see when I look under the hood. As such I've been tinkering. Compare the markup of the following templates and let me know what you think.

Thank you. Jay D. Easy (t) 21:28, 19 April 2023 (UTC)[reply]

Ahunt, Deeday-UK, MilborneOne, Mjroots: Would any of you like to weigh in again? Jay D. Easy (t) 12:31, 20 April 2023 (UTC)[reply]
Both templates outputs are the same visually. I could work with either, so no objection to a change. What I am in favour of is consistency across a range of templates covering a similar subject, but differing only by date. Mjroots (talk) 13:14, 20 April 2023 (UTC)[reply]
The output templates look visually identical to me on Firefox. I am afraid I have no expertise in the template coding, so cannot make a judgment on the pros or cons of that. - Ahunt (talk) 19:32, 20 April 2023 (UTC)[reply]
Thank you both. I'm trying to improve these templates' ease of use, not necessarily change their appearance. I want to do away with this
* {{vad|align=left|Jan 21}} &nbsp; [[Cargolux Flight 7933]]
* {{vad|align=left|Jan 24}} &nbsp; [[Taban Air Flight 6437]]
And replace it with this
 |01-21  = [[Cargolux Flight 7933]]
 |01-24  = [[Taban Air Flight 6437]]
Jay D. Easy (t) 21:18, 20 April 2023 (UTC)[reply]
Well it is more concise... - Ahunt (talk) 21:30, 20 April 2023 (UTC)[reply]

Heads up: I am about to take it live and will probably work my way through the individual templates in the coming days. Should anyone disagree then please ping me here and I will drop everything until consensus is established. Thank you. Jay D. Easy (t) 21:57, 21 April 2023 (UTC)[reply]

Ideally one would wait more than a couple of days before launching into large-scale changes, but anyway: I think the new syntax for the template source code is definitely tidier and simpler than the previous one. However, I wish it had kept the months spelled out as three-letter abbreviations, which removes all ambiguity in the date format and is also more What-You-See-Is-What-You-Get. Also, what's the deal with the letters b, c etc after some dates? Are they necessary if the same date occurs more than once? --Deeday-UK (talk) 14:05, 22 April 2023 (UTC)[reply]
So for example jan-21 instead of 01-21? Can't say I disagree it'd be less ambiguous. I might look into this further down the road. And you're right about the suffixes. It's to prevent duplicate argument errors. Jay D. Easy (t) 20:58, 22 April 2023 (UTC)[reply]
And by that I mean I got on it right away. Aliases are added now, e.g. 01-21, jan-21, jan 21. Jay D. Easy (t) 22:51, 22 April 2023 (UTC)[reply]

I have modified the template so that it can take abbreviated months also in capitalised form (Jan, Feb, etc beside jan, feb), which is even more WYSIWYG, and does not fall foul of the browser's spell checker. Finger crossed, I haven't broken anything. --Deeday-UK (talk) 20:29, 23 April 2023 (UTC)[reply]

Good call. I have removed the hyphenated parameters too (e.g. jan-21 and Jan-21), since these won't be used anyways. I'm happy with the end result. Everything looks much cleaner and easier to use now. Jay D. Easy (t) 10:21, 24 April 2023 (UTC)[reply]