Infoboxes: After the war

Editor's note: To go beyond the mere facts of cases, the "Arbitration report" invited several editors who participated in the recent Infoboxes case to comment on infoboxes: what they are, where new users can go to find out about them, specifications and protocols, best practices, and how the upcoming community discussion recommended by the Committee in the case decision should be framed.

The war is over, declared one music editor preparing to return to editing classical music articles in the wake of ArbCom's Infobox decision. The editor had spent two years away from music topics, "I could see I would get involved in this long-running controversy on infoboxes and it would be an unproductive waste of time."

Another music editor, who had stopped editing in June, and who asked not to be identified, told the Signpost that even though the current guidelines say infoboxes are neither required nor prohibited, and the committee cannot decide a content issue, the arbitrators did well with the case, by calling a halt to the disruption, and calling for a community discussion for clarification of the guidelines.

"The decision to include an infobox in an article is a content decision," wrote arbitrator Worm That Turned. Worm further clarified the reasoning behind this, in a way that should put to rest any lingering questions about the role of WP:OWN in the debate:

Worm delineated the difference between "content creation" edits and "maintenance" edits. Maintenance tasks should not change the meaning of the article for the casual reader, he explained. These tasks include categorisation, stub sorting, adding wikilinks, formatting and stylistic changes such as number and position of headers or placement of images, and simple copy-editing such as grammar and spelling fixes.

Content creation would include addition and removal of text, images, tables, references and so on—and infoboxes—and should be done by an editor who has some knowledge of the subject.

Starter templates are fine, and general recommendations by a WikiProject are fine, says Worm, but editors should not go through a group of articles, adding infoboxes to each systematically.

Before the case had even been closed, a new RFC was started on the talk page of WikiProject Quality Article Improvement by Chedzilla, an alternate account of Ched, who had initiated the original Infoboxes case request. The RFC drew immediate protests from music editors. The RFC should be in a neutral area, not on the pages of a project that was home to the two topic-banned editors, they said. The language of the proposal should be neutral. And the music editors were already exhausted by years of acrimony. Time was needed.

Arbitrator Carcharoth agreed: "My suggestion, for those who want to sort through their thoughts on this while they are still fresh, would be for people to make notes or mini-essays offline or in their userspace, and to leave articles and talk page discussions well alone for a bit. Don't rush into post-case discussions, but let things calm down, and find other things to do in the meantime. It's not like the issues are going to go away."

As a followup to this, the Arbitration report has compiled a partial listing of essays and previous discussion at the end of this report.

"I don't think the discussions should be hurried", agreed Quiddity. The RFC should run for many months to avoid fatigue, he told the Signpost, and needs a large amount of preliminary research, adding that Sphilbrick and Kleinzach have some of the best ideas . "I believe that all of the objective problems with infoboxes can be fixed", he said, "and all of the subjective problems can be minimized." He added, "I do think WikiData needs to be taken into account; there will soon be more facts and stats than could reasonably fit in an infobox."

"Structuring the discussion is important", music editor Kleinzach told the Signpost. Kleinzach calls for a drafting committee of three or five members to structure the questions. Interested parties would submit topics to the committee and all meaningful questions would be included.

In the past, community discussions have been muddled, and issues have been conflated. The problems need to be separated, said Kleinzach, and detoxified, one by one. The discussion should distinguish between publishing issues and technical issues.

"Any future discussion needs to be much broader than that defined by ArbCom", Kleinzach told the Signpost. "Looking just at how infoboxes are ‘used‘ (i.e. inclusion/exclusion disputes on article pages), but not at how the templates are created, means concentrating on effects rather than causes. Fundamental issues about template design and MOS guidance should be faced."

Infoboxes have been controversial, explained Kleinzach, because they have often been edited behind the scenes, without content contributing editors being involved. The idea that there are two ‘stances', "pro-box" and "anti-box", is not really correct. "There is a spectrum. Objections to infoboxes have been localized, and focused on particular topics and particular infoboxes.

One particularly controversial infobox is the 'bio-box' or biographical infobox. Another infobox that received a particularly negative reaction from serious music editors was Musical artist infobox with anachronistic, pop music derived fields such as 'birth name', 'genres', 'occupations', 'labels', 'associated acts', and 'past members' —misapplied to classical music articles.

An example of a positive response to an infobox was the Template:Infobox classical composer, which according to Quiddity was the result of a 2010 discussion which clarified problem areas in the documentation, and has been uncontentiously used in a few articles.

"Rather than trying to force them on the unwilling," recommends Brian Boulton, "improve them by returning to their original principles ('a few key facts'). I have recently added an experimental infobox to an opera article I have written." The sample infobox proposal was intentionally introduced in a relatively low-profile opera article, to minimize controversy.

English Wikipedia infobox for Angela Merkel
Chancellor of Germany
Incumbent
Assumed office 22 November 2005
President	Horst Köhler Christian Wulff Joachim Gauck
Deputy	Franz Müntefering Frank-Walter Steinmeier Guido Westerwelle Philipp Rösler
Preceded by	Gerhard Schröder
Minister of the Environment
In office 17 November 1994 – 26 October 1998
Chancellor	Helmut Kohl
Preceded by	Klaus Töpfer
Succeeded by	Jürgen Trittin
Minister of Women and Youth
In office 18 January 1991 – 17 November 1994
Chancellor	Helmut Kohl
Preceded by	Ursula Lehr
Succeeded by	Claudia Nolte
Member of the Bundestag for Stralsund-Nordvorpommern-Rügen
Incumbent
Assumed office 2 December 1990
Preceded by	Constituency Created
Personal details
Born	Angela Dorothea Kasner (1954-07-17) 17 July 1954 (age 70) Hamburg, West Germany
Political party	Christian Democratic Union
Height	1 m (3 ft 3 in) 65 / 1.65 m
Spouse(s)	Joachim Sauer (1998–present) Ulrich Merkel (1977–1982)
Alma mater	University of Leipzig
Signature

While there are a few uncompromising ‘pro-box' editors who believe there should be a box on every article, no-one has taken up the opposite position: that there should be no infoboxes at all, says Kleinzach, a music editor who has added hundreds of infoboxes to articles. "Unfortunately many current boxes are not fit for purpose because of poor design."

In particular, some 'monsterboxes' have been created with far too many fields, unfamiliar abbreviations etc. that are actually longer, bigger, more prominent and more difficult to read than the articles they are supposed to summarise."

German Wikipedia in particular is known for its minimalist approach to infoboxes. They are particularly unpopular on biographies. Even the article for Angela Merkel has no infobox, only a photo and signature (see above). In contrast, the infobox for Merkel's English Wikipedia page (right) would extend well past the fold in most browsers.

One of the major criticisms of infoboxes is the loss of nuance, when complex information about a subject is forced into an abbreviated infobox format.

"I feel strongly that it is poor form to use an infobox entry, which almost by definition is extremely short, to summarize situations which might be too complicated for a one word or short phrase, says SPhilbrick. "That is exactly what well-written prose is for—to explain nuance, in as many words as it takes to explain the issue."

The articles best suited to infoboxes, says Smerus, in an essay provided to the Signpost, may be in scientific and geographical topics. "The arguments over infoboxes seem to have occurred in articles relating to history, biography and music." Infoboxes may be particularly unsuited to liberal arts fields when they repeat information already available in the lead section of the article, are misleading or oversimplify the topic for the reader, or include a vast amount of irrelevant or inappropriate information from the article.

The metadata question may well be obsolete. If you Google La traviata , Giuseppe Verdi, and Johann Sebastian Bach, you will find that it now creates its own small infobox on the subject, even though none of the corresponding Wikipedia articles have infoboxes. [screenshot] Quipped one user, "The Google box is better than the WP ones!" Perhaps Google has spent time and money identifying what their customers want.

Anyone who attempts to read any of the infobox discussions will quickly come up against some specialized terms.

What exactly is an infobox? A navbox? A template? A header or a footer? And where can new users turn to for assistance? Is there a place to "shop" for infoboxes, where you can see what is available and how it will look in a new article? The answer to the last question is no; apparently new users who are creating articles outside of a WikiProject have little to go on.

According to Kleinzach and Smerus, an infobox offers a quick summary of the article, sometimes with an illustration. It is normally in the right hand corner position. A navbox (navigation box) offers links to related articles, and is often found at the bottom of the page. All infoboxes are templates, but not all templates are infoboxes.

Quiddity provides a crash course in all things infobox and navbox, along with examples and links to the help files:

Note: The natural place to look is [[Wikipedia:Infoboxes]], but that is a redirect to [[Wikipedia:WikiProject Infoboxes]] which is of more interest to someone interested in designing a new infobox. There are also various options at Category:Infobox templates.

• Proposed Decision September 2013—the 66,392-word talk page, with proposals for framing the infobox discussion

• THRC: An essay on infobox issues, particularly the "upper right hand corner", provided to the Signpost by Smerus.
• Brianboulton, "Infoboxes: time for a fresh look?" Signpost, July 2013
• Disinfoboxes: "The disinfobox offers a competitive counter-article, stripped of nuance."
• Riggr Mortis's Wikipedia as database "As long as Wikipedia drifts from its origins as a tool for human learning to a second-rate quasi-database—apparently to the benefit of ADD-inducing tech companies—I will no longer participate as a volunteer. Neither should you."
• Quiddity: framing the discussion (Notes from Proposed Decision talk)
• Design solution proposal from Vibhabamba at the WMF.

• April 2013 – discussion with multiple people in Ched's user space – machine readable data, advantages and disadvantages of infoboxes
• 2010 RFC on microformats
• Brianboulton's a sample infobox, a proposal introduced in a relatively low-profile opera article, L'Arianna, to minimize controversy. Discussion is ongoing.
• Classical music infobox-related discussions 2007–2010

All infoboxes are templates, but not all templates are infoboxes. People create new ones unnecessarily all the time, hence many editors bring them to TFD to get them merged.

• Template Infobox journal, that generated a lot of discussion.
• Infobox soap character 2
• Infobox TaiLamTunnelENG
• And most of the current contents of Wikipedia:Templates for discussion#To review

← Previous "Arbitration report"

Next "Arbitration report" →

In this issue

2 October 2013 (all comments)

Op-ed

Discussion report

News and notes

Featured content

Arbitration report

WikiProject report

+ Add a comment

Discuss this story

These comments are automatically transcluded from this article's talk page. To follow comments, add the page to your watchlist. If your comment has not appeared here, you can try purging the cache.

• Wikidata has changed everything. We need to seriously start thinking about (meta)data display user preferences, a.k.a. smart boxen. There is the data (such as a date), and how that data is displayed (dmy, mdy), and different readers and situations may call for different interpretations. Data may even need editing-specific interfaces, in the inevitable case when data storage formats are too complex to deal with directly (think templates for Wikidata). Or something... Yes, that's hard, but its a next iteration of the project, and its way too complicated for me to deal with. I, personally, want automatic dmy date formatting preferences; but I think now its part of a bigger problem in need of a more general solution. Int21h (talk) 02:24, 6 October 2013 (UTC)[reply]

Dates: once you take the time to code a templated date, every language and culture can render the date with their order and names for months, example: {{Start date|2013|10|06|df=yes}} shows as 6 October 2013 (2013-10-06), --Gerda Arendt (talk) 11:46, 6 October 2013 (UTC)[reply]

The problem is that makes dates dmy for everyone; in US-centric articles, mdy dates are appropriate, but I still want to see dmy dates regardless. This is not possible at the moment. Int21h (talk) 21:31, 6 October 2013 (UTC)[reply]

I don't understand, - if you use {{Start date|2013|10|06}} you get October 6, 2013 (2013-10-06). Or do you think further that a user preference could render all templated dates this way or the other? --Gerda Arendt (talk) 20:39, 7 October 2013 (UTC)[reply]

Yes; I think one should be able to render such templated dates this way or the other, as determined by a user preference (or even a page-by-page or other control, or any combination thereof). Certain people may want dmy, some people may prefer mdy, and some people may just want to let the article editors decide. It was just one immediately available example where the underlying data should be separate from its display, i.e. "different readers and situations may call for different interpretations". I see no reason why the same could not be true for infoboxes, e.g., some may want only certain information displayed, some people may want to filter certain information, some people may want none, and some people everything. Int21h (talk) 06:12, 8 October 2013 (UTC)[reply]

• Infoboxes, if small and concise, can add value to a page. The Merkel box, on the other hand, is an excellent example of what they should not be. Carrite (talk) 04:39, 6 October 2013 (UTC)[reply]

  I disagree, while the example is a bit too long, the truth is, things like a politician's history in elective office are very relevant, for example James Madison; where people forget how extraordinarily qualified he was for the office of the Presidency, and a quick access point for basic information is quite useful. OTOH, I would agree that an inboxbox that runs "below the fold" on a computer screen is overdoing it. Montanabw^(talk) 22:35, 6 October 2013 (UTC)[reply]

• Why is this article focusing on the negative aspects of infoboxes only and doesn't take into account at all their value? I feel infoboxes are extremly valuable (and yes, the Merkel one too is fine by me) in providing a quick and concise recap of basic facts about a subject. It is the first thing I look in a WP article. While there are reasonable objections to them, I feel this is a very biased article about the issue. --cyclopia^speak! 09:14, 6 October 2013 (UTC)[reply]

• And because (per Gerda's comment below), those of us expressing a pro-infobox viewpoint were attacked quite unreasonably, with our views, comments, and our noting the non-AGF and non-NPA behavior of the anti-infbox crowd discounted. The bullying by the anti-infoboxers was pretty much winked at, while defenses by and of the pro-infobox group were viewed as "attacks" or "not getting it." Very frustrating experience. Montanabw^(talk) 22:35, 6 October 2013 (UTC)[reply]

The answer is easy: because the case was biased, and - if you ask me - it wasn't even on infoboxes. - I was restricted and told to be silent, that's another reason. Let's get real. Look at L'Arianna, the author of that article (at FAC) tried an infobox on 9 September. Look at the alternatives, the present so-called identibox (a step in the right direction), my suggestion of an infobox presenting date and place, and the former side navbox. What do you prefer? --Gerda Arendt (talk) 11:18, 6 October 2013 (UTC)[reply]

Uhm, let me state the obvious: The article about the opera L'Arianna shouldn't show "Titian's depiction of Bacchus's arrival on Naxos" at the top, but it should prominently provide an example of the music:

Lamento d'Arianna

BTW, as a german Wikipedian i have to say that de:L’Arianna is a terrible example. An ugly, 100% repetitive infobox and very little content in the article. --Atlasowa (talk) 12:45, 6 October 2013 (UTC)[reply]

What you say about L'Arianna would best be said in the FAC. - The sound example is not so great because it shows not the operatic version. - I like the German infobox: beauty is not needed, but repetition of the key facts wanted. - Do you know {{infobox opera}}? --Gerda Arendt (talk) 13:07, 6 October 2013 (UTC)[reply]

The metadata aspect of infoboxes was always more beneficial to the small developer than a large company that can spend a lot of resources parsing the article. In that respect I think it is not obsolete. 173.61.149.213 (talk) 04:46, 7 October 2013 (UTC)[reply]

• The scope and specificity of infoboxes is an issue as well—what is the focus, and what should, or can, they be mandated to contain? For example, should {{Infobox book}} be a box about the book in general, or about the first edition of the book, as some have insisted? Should particular images be mandated—is an imageless infobox even allowable? Can an image be automatically enforced by a WikiProject, without debate as to the particular image's pros and cons? Curly Turkey (gobble) 06:18, 7 October 2013 (UTC)[reply]

The scope can be discussed. Please note that I - thinking that infoboxes can be helpful to readers - would not claim they or anything in them should be "mandated". I like to show an unprepared reader at a glance what an article is about (in the above mentioned example: L'Arianna is an opera) plus a time and location, - that's why I would pefer "my" suggestion to the "identitybox". --Gerda Arendt (talk) 07:32, 7 October 2013 (UTC)[reply]

It was discussed. The result of the discussion was that it was not to be discussed. I like the idea of an "identitybox"—that sounds exactly like what I had intended (and have been barred from). Curly Turkey (gobble) 20:18, 7 October 2013 (UTC)[reply]

Do we mean the same thing by "it"? I meant the scope of an infobox in general, "was discussed" sounds like you mean {{Infobox book}}. Identitybox is the name the author of L'Arianna gave to the box now in that article, which can be seen also in Symphony No. 1 (Sibelius). I would like to add (for a random reader who may come across the article via a search) a time and location, as for example in Lolita (opera) and Symphony No. 8 (Dvořák). I respect the wish of the author but would like to know what uninvolved people think. --Gerda Arendt (talk) 20:35, 7 October 2013 (UTC)[reply]

• I see some comments here that seem to suggest the design of our infoboxes is part of the problem. I think most English Wikipedians are not aware of the fact that the small team of professional designers at the WMF would love nothing more than to streamline the look and feel of infoboxes. Frankly, they mostly don't because A) it's a daunting task with so many different templates B) the templates are viewed as "community controlled" and thus not particularly open to changing C) there is always more work to do in other places and on our normal work projects, like VisualEditor and mobile. I can tell you though, that if there were community members willing to lead the discussion on redesigning infoboxes to be more clean and less heavy-handed, then the designers would love the feedback and would be very happy to see some improvements go live. In short: they'll do the design work for you. Just check out some of the early mockups I linked to above. Steven Walling (WMF) • talk 03:55, 8 October 2013 (UTC)[reply]
  • Yeah, the community sure does shoot itself in the foot with its shock-horror knee-jerk resistance to technical trial and innovation—most unhelpful (even destructive) in relation to VisEd. Quite a bit has been said in the past about engineers being out of touch with the community; now its time for the community to reach out. Tony (talk) 04:09, 8 October 2013 (UTC)[reply]

    One problem in infobox land is that different subjects require different info, and the info needed by specialists may be different from laypeople. Personally, while past debates over silly things like which color to make the stripe have wasted untold bandwidth, a totally standardized model may be impossible, I use the Presidents of the USA model as an example, sometimes, a person just needs to know when Woodrow Wilson was Governor of New Jersey, and it's easier to use the long infobox than to scroll through the text. As for Visual Editor, it was an unmitigated disaster, rolled out too soon with too many bugs and required an entire re-learning to use, not a knee-jerk reaction at all. Was a solution in search of a problem (yes, a more user-friendly interface would have some advantages, but VE wasn't it. Almost as bad as Windows eight ...  :-P ) Montanabw^(talk) 06:23, 8 October 2013 (UTC)[reply]

    • The need for different color variables is something that could be more easily built in. Designers are used to the requirement for a complimentary but varied color palette, and with templates able to be written in proper code now, it's quite easy to define switches that could change colors based on the desire of a certain WikiProject or other set of maintainers. Anyway, just putting the thought out there. If the design of infoboxes is a sticking point, then the designers can potentially help. It just takes the community stepping up to lead on this one, since WMF management isn't going to dictate any change. Steven Walling (WMF) • talk 07:46, 8 October 2013 (UTC)[reply]

Thoughts like this sound promising, but if there was an infobox war (which I doubt) the arbs supported those who want no infobox at all, ignoring their widespread use on Wikipedia. However, while the case was still open, (missed) Smerus installed a compromise for the Sibelius symphony mentioned above, and now we see the approach on Monteverdi's opera, - I still have hope for peace, in discussion rather than restriction. As for colour, I like unobtrusive better than overly colourful, - being able to make a choice seems a good idea, --Gerda Arendt (talk) 08:20, 8 October 2013 (UTC)[reply]

• Stephen, what does the community need to do if it's to liaise effectively with WMF engineers on this matter: if a page is established to knock ideas around, it may become bloated and unruly. If we knew the kind of boundaries, wish-lists, specs that engineers could work with (and that would be essential for them to frame the job technically—and perhaps throw back with comments in a negotiation process), it could open up a route. Tony (talk) 08:42, 8 October 2013 (UTC)[reply]