Template talk:Infobox OS version

Template talk:Infobox OS
This page is a soft redirect.

Ready for use

I finally got around to writing the documentation for this infobox... whew, there's quite a bit of it! Hopefully it will serve as a useful guide for implementers of this template. -/- Warren 00:25, 24 September 2006 (UTC)[reply]

logo_size

I added an optional logo_size parameter for logos that look bad at 250px like this one. It still defaults to 250px, so existing uses should be unaffected. Deco 21:41, 27 February 2007 (UTC)[reply]

Style / layout

So there's a perfectly good set of defaults for {{infobox}}. These defaults work fine on a great many templates, including most of the computing ones ({{infobox software}}, {{infobox computer}} and {{infobox OS}} being the most obvious). There's no real need IMO to deviate from these at all. I'd appreciate a rationale for why this box demands a special layout. For now, I've conceded to re-adding the colour strip for headers and collapsed the table borders. Chris Cunningham (not at work) - talk 20:12, 2 December 2008 (UTC)[reply]

I've made yet more concessions to the old version. A reminder again that this is temporary, until Warren explains what he means by the terms "organized", "too wide" et cetera. However, the current version is practically the same layout as the old, and is by my reckoning more compact. Chris Cunningham (not at work) - talk 08:05, 3 December 2008 (UTC)[reply]

If you consider it "concessions", then you haven't thought about why the old template was the way it was.

I've set up User:Warren/Tableau with the current template at the top, and working backwards chronologically to the original template, so you can see the issues all at once.

Width: You've increased the width of the template by 35 pixels without a justification. Again, it's vital to remember that width is at an absolute premium at the beginning of articles. The navbox was 310px before, which is already too wide.

Chances are pretty good that you're using a high-resolution display... try viewing User:Warren/Tableau when the browser is set to fit within a 1024 pixel-wide display. The lead sentences of the article break roughly as follows: "Windows Vista is a line of operating systems[4] developed by Microsoft for" "use on personal computers, including home and business desktops," "laptops, Tablet PCs, and media center PCs. Prior to its announcement on" "July 22, 2005, Windows Vista was known by its codename Longhorn.[5]" The original template layout has enough extra width to add two more words, "Development of", in those first four lines. It's not much, but every bit helps on a smaller screen.

Now you might argue that you needed to make it wider to fit "Default user interfaces" on one line. I don't think we don't need this field at all; it wasn't in the original template design, but someone added it and several other parameters earlier this year without an edit summary or any decent rationale for doing so. With the exception of "Platform support", which is something that has changed from version to version of the operating systems we use this template on, I think all of those fields can go. That'll reduce the perceived need for width.

Organization: The old template had sections for Developer (whose contents are centered), Release Information (which is a table), Support Status (whose contents are centered), and a free-form "Further reading" section. Remember that the only purpose of the navbox is to help the user navigate and find some detail they're looking for quickly. Your earlier design lost all of that organization and turned it into a single long table... long tables are hard on the eyes, and the user ends up not even trying to take it all in. (this is user interface design philosophy) Your revisions have fixed some of this, but I still believe that "is it being supported" is still worthy of its own section.

Border: It should go around the whole thing. There is a visual consistency involved in having the top border of the box align with the first line of the article. Having a logo and part of the information contained in the navbox floating free adds a bunch of empty space around the top, which is disconcerting. Again, this is UI design philosophy.

Also, the colons are missing. The text on the left serves as a label for the text on the right. Colons are a visual cue. Again, this is UI design philosophy.

I keep bringing UI design up because I work professionally as a user interface and user interaction designer. Organizing and presenting information on computer screens is my life's work. So I like to think what I know what I'm talking about here. You self-identify as a system administrator on your user page, so I understand why you'd value consistency and the technical aspects underlying how the template works. But that's really not important as far as the final output is concerned -- what's important is the answer to the question, "will the user look at the article and be helped, or be frustrated?" Everything you do with template editing should serve only that purpose. Warren -talk-

Hey, my current job isn't under discussion here. Let's not go pulling rank. To address these points:

Width. The default width of an {{infobox}} is 22em. This is used by all {{infobox}} templates by default. If you think that this value is too high, then it should be addressed at template talk:infobox, which will benefit the whole project and not just a handful of articles on various Windows and Mac OS versions. The same goes for the additional spacing caused by not making the borders collapse - if you think this should be the infobox default then please request that centrally and it'll benefit everyone. Turns out that just shortening a couple of labels fixes this without resorting to hacks. With the borders uncollapsed (which is the default), the infobox is currently only a handful of px wider than the old one, and doesn't result in any wrapping of text relative to the old one if the first paragraph of your test page.
Organisation. I agree that there is some value in breaking up long lists of key-value pairs if it helps readability. This can be easily done using section headers. The current version splits at the same points as the old one.
The infobox is a table. Using a caption to denote a table heading is a perfectly standard, semantically valid way of presenting an HTML table title. I just can't agree that this is a negative usability-wise.
The colons are unnecessary - the information is presented in clear key-value pairs, using separate HTML elements and different styling. We could add all sorts of different ways of making the types stand out from each other - putting the key in upp case, or making it bright red, for instance - which we do not do because it is unnecessary. Colons are an indistinct form of screen punctuation and do not add significantly to the distinction.

In the interests of keeping a dialogue going, so far as I can tell the only current sticking points are:

The need for colons as separators;
The use of a caption rather than an in-table header for the title;
The need for an off-green background colour to the headers rather than leaving it transparent.

Chris Cunningham (not at work) - talk 11:28, 3 December 2008 (UTC)[reply]

Coloured Infobox section headers are extremely common on Wikipedia. I picked Cleveland Indians, World War II, Mars and James Earl Jones off the top of my head as articles likely to have Infoboxes, and all four of them use a background colour. Again, it's a visual navigation aid; if you don't like coloured backgrounds for Infobox section headings, fine, but you'll have to take up the fight elsewhere.

I disagree that colons are unnecessary, but whatever, not worth arguing over. I've seen colons go into and out of Infobox templates a number of times over the years.

I am also in the group of people that thinks 22em is too wide for most Infoboxes. {{Infobox}}, at its default size, will occupy almost a third of the browser's total width when maximized on a 1024-pixel wide screen. And that's a third of ~1000 pixels... a lot of people using mobile devices don't have that kind of luxury, and a lot of other people don't use fully-maximized browser windows. Frankly, it looks like shit, and I have some doubts that that particular decision was made through any kind of process beyond "hey, what's this wedged in my ass? i'll pull it out! oh, it's a 22!". 19 or 20em would work better for a wider range of display devices, and wouldn't infringe on the actual content of the article so much.

Finally, the Infobox isn't a "table". It's a box containing information, which includes a list of name/value pairs (and a name/value pair is really stretching the definition of a "table", which is typically a construct that gives specific meaning to the X and Y axis), lists of articles, images, and other navigation elements. The notion that a table caption appears above the top of the table's border doesn't apply here. And again, it looks bad. If you aren't going to change it back, then I will. Warren -talk- 16:16, 3 December 2008 (UTC)[reply]

In order:

transparent headers are also extremely common. I could rattle off a few examples too. And I already did "take up the fight elsewhere"; I took it up on the WikiProjects: I took it up on the {{infobox}} discussion; and I take it up periodically when people discuss further standardisation of infobox templates. The rest of the computing WikiProject uses them, which was my doing, and has done for some time now without opposition. So here I am "taking up the fight" with the last hold-out on the Project. If you'd like to give the argument for why it is that including an arbitrarily-coloured stripe aids in readability of the template significantly enough to overcome the drawback of the distraction it causes, then we can have that, but I'd rather it were done centrally on template talk:infobox.
Cool, that's settled then. Again, I'd have no problem with these going back in if there were consensus on the issue. In fact, in the long run these could be automatically generated using the CSS :after pseudo-class. But that's something to discuss in the years ahead.
Well, that the standard width "looks like shit" is definitely a minority position right now. I'd have to ask you to take up the fight elsewhere on this one. :)
It's made from a <table>, uses semantically-valid HTML table constructs and classes, and presents data in a structured and tabular format. I don't think the definition of "table" you've given is what is generally meant by the term when discussing semantic HTML. As for it "looking bad", again, it's gone unopposed on a good deal of other templates, so this is an issue of personal preference. If you want to change it then it can be modified into an "above" attribute pretty easily, but I'd rather we had a wider discussion on the final outcome.

Chris Cunningham (not at work) - talk 17:02, 3 December 2008 (UTC)[reply]

←Perhaps one of you could kindly put both versions side by side so that others might compare them? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 20:23, 3 December 2008 (UTC)[reply]

/testcases. Warren's pre-infoboxing rev is in the /sandbox. Chris Cunningham (not at work) - talk 20:46, 3 December 2008 (UTC)[reply]

Thank you. I made a table so that they are now side-by-side. I can't believe there's an edit war over such small differences, but FWIW, I prefer the {{infobox}} version overall, but prefer the heading to be inside the box, as in the "Previous" version. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 22:58, 3 December 2008 (UTC)[reply]

Windows 7 is one of the top 100 articles on Wikipedia. Windows Vista was in the top 20 when it was released. This template isn't off in some far-flung corner of the encyclopedia; tens of thousands of people see it every day. I've been working on the encyclopedia long enough to know that people need to be literally brow-beaten into producing something that looks good instead of focusing solely on the technical exercise of simply adding content, or consolidating for the sake of maintainability. The new {{Infobox}}-based template may be more maintainable, but given that there were only a handful of non-bot edits in the last year and a half, there's no solid justification for improving the maintainability at the expense of the visuals. Warren -talk- 00:00, 9 December 2008 (UTC)[reply]

That's a purely subjective call. Given that there has been no discussion on any of the other software templates regarding the styling, and that several articles using those infoboxen are higher placed than Windows 7 in the page view listings, this suggests that you're the only one who feels so. You're using "code versus looks" as a straw man, when in fact I believe that the new styling was more attractive as well as being more functional. Still, there's no time limit on getting these improvements rolled out; I'll take the issue to the WikiProject page. Chris Cunningham (not at work) - talk 00:51, 9 December 2008 (UTC)[reply]

Reference styling

So a change to have the references in the lede changed to use proper <ref></ref> tags instead of superscripted inline extlinks was reverted with a cryptic edit summary which I can only assume was meant to mean something like "I respectfully disagree that this is a productive change". I don't see why there's a reason for these links to be included inline instead of in the refs section - reference styling should be consistent within articles and that includes the infobox. Planning on restoring the use of proper ref tags here. Chris Cunningham (not at work) - talk 11:56, 8 December 2008 (UTC)[reply]

Os Cite needed

The "Os cite needed" is not working, if the release_version does not have a URL, still show "[info]" but with no link--Sotcr (talk) 01:42, 9 December 2008 (UTC)[reply]

I Mean, like in here [1], in the Preview_Release says (citation needed), but now that does'nt work --Sotcr (talk) 01:44, 9 December 2008 (UTC)[reply]

Discussion at WP:SOFTWARE

I've opened a larger discussion of the styling issue over at Wikipedia talk:WikiProject Software#Infobox discussion. Chris Cunningham (not at work) - talk 10:11, 9 December 2008 (UTC)[reply]

Six weeks later, there has been no opposition. This has been broadcast as widely as it can be put now; as such, in the continuing lack of opposition from anyone but the template author, I'm syncing this with the new sandbox code again. Any issues, please let me know. Chris Cunningham (not at work) - talk 14:25, 17 January 2009 (UTC)[reply]

Yeah, you didn't resolve /my/ issues with the infobox layout. Until you can produce a version of the {{infobox}} template where the top part goes inside the box, not outside, then I vehemently oppose this change. Warren -talk- 17:55, 17 January 2009 (UTC)[reply]

Done. Test cases. Chris Cunningham (not at work) - talk 11:24, 18 January 2009 (UTC)[reply]

ref tag broken

It appears that some changes to this template have broken the element that generates the <ref> ... </ref> tags. This looks to be from the data9 and data10 elements in the template.

For examples, see:

Windows 7 where the first entry in the references section is "[{{{preview_url}}} info]"
Mac OS X v10.5 where the first two entries in the references section are: "[{{{first_release_url}}} info]" and "[{{{release_url}}} info]"

--- Barek (talk • contribs) - 18:09, 17 February 2009 (UTC)[reply]

I don't know why the URLs aren't being formatted properly in the ref tags, but I've changed them to inline links again to fix this. Chris Cunningham (not at work) - talk 09:27, 18 February 2009 (UTC)[reply]

proceeded by/succeeded by

Could we have:

| header22 = proceeded by

| data22 =

| header23 = succeeded by

| data23 =

Such that one can indicate Apple System 6 was succeeded by System 7 etc.. ? An alternative might be next/previous. Alternative:

| label31 = Predecessor

| label32 = Successor

Electron9 (talk) 09:37, 12 May 2009 (UTC)[reply]

I just swung by to ask for the exact same thing (only it's spelled preceded). I would love to just go through OSes and not have to hunt for the earlier OS. But looks like this was requested a year ago with no comment (I don't know if the addition was made to the template and the /doc page not updated). But if anyone's out there, a "preceded by" and "followed by" parameters in the infobox would be wonderful. – Kerαunoςcopia^◁_galaxies 00:26, 10 June 2010 (UTC)[reply]

Added. I tested it on my own sandbox, but obviously feel free to fix/revert and be sure to double-check my additions to the /doc page as well. Appreciated. – Kerαunoςcopia^◁_galaxies 01:00, 10 June 2010 (UTC)[reply]

Merging templates

When this template is merged with template:inforbox os could we create a section so for example it would look like it is now but you would for example do this to get version

{{inforbox os 
| os version = yes
}}

So that it is still a different type of template compared to template:infobox os please 86.135.255.245 (talk) 16:50, 15 December 2013 (UTC)[reply]

Hi.

Who says it is going to be merged? I tried to merge them twice but their technical differences are so huge, I aborted midway. Those carried-away flock of uninformed editors who blindly voted can sure try, but if I see a single problem with their merger, I'd revert.

Best regards,

Codename Lisa (talk) 02:50, 16 December 2013 (UTC)[reply]

Completely new Infobox OS

There is no way we can merge Template:Infobox OS and Template:Infobox OS version, because as Codename Lisa said, there are huge and complex differences between the two infoboxes. My suggestion is that we create an entirely new Infobox OS, or at the very least add more parameters to the existing Infobox OS. It's not worth merging the infoboxes when there are huge differences between the two. That's my suggestion.

Warm regards, Helixsoft (Talk|Contributions|Templates|Userboxes) 15:20, 22 January 2014 (UTC).[reply]

Hi. Joel Spolsky once wrote that it is only on TV that two quarreling kids are subdued by shouting louder than either of them. In real world, such an attempt would turn into a three-way quarrel. He says such was the case when someone tried to resolve the conflict between the incompatible RSS versions with an Atom specification.

We have two infoboxes already. A third won't fix a problem. It only adds to the problem. A merge is out of question at the moment but something close will eventually happen, either by me or someone more experienced than me, or someone who just finds the delicate spot of compromise. When I was replying to the other user, I needed to snap him out of his daydreaming of bliss. The guest editor had assumed so much about the end result that was already making edit requests on the future template!

Best regards,

Codename Lisa (talk) 15:52, 22 January 2014 (UTC)[reply]

date parameter?

A user edited OS X Mavericks, saying "|date=June 2013" deleted from Infobox. Not sure what it is (doesn't display))", although they didn't actually remove that in the edit.

As a test, I tried changing the date parameter's value to "hello sailor" and previewing the article; it showed the article as being in the redlinked category "Articles with unsourced statements from hello sailor".

I then removed the "date=" parameter; the AnomieBOT put it back, with a value of March 2014.

Does a date=XXX parameter add the article to the category "Articles with unsourced statements from XXX"? Are some of the "Articles with unsourced statements from XXX" categories hidden, so that they don't show up?

Where, if anywhere, is that parameter documented? Guy Harris (talk) 20:13, 4 March 2014 (UTC)[reply]

Hi. Just checked the source code for your question. Unlike several other infoboxes, {{Infobox OS version}} does implement an actual |date= parameter. You see this infobox implements |first_release_url=, |GA_url=, |release_url= and |preview_url=; if they are empty, the infobox inserts a {{Citation needed}} in their places and passes the |date= parameter to {{Citation needed}}, which needs a date.

Best regards,

Codename Lisa (talk) 06:53, 5 March 2014 (UTC)[reply]

Add frequently updated

Hi please add support for frequently updated. 86.135.252.13 (talk) 22:44, 26 March 2014 (UTC)[reply]

Over my dead body! And over Jimbo Wales's dead body too: This parameter would be a recipe for a disaster called eternal state of sourcelessness, eternal undue weight, associated edit wars and version number vandalism. No! Let the sleeping devil lie! Hell, don't create the sleeping devil.

Best regards, Codename Lisa (talk) 03:25, 27 March 2014 (UTC)[reply]