- 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. --cyclopiaspeak! 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:
- 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]
← Back to Arbitration report