http://higheredmarketing.blogspot.com/2008/01/your-web-site-vs-wikipedia.htm...
WikiProjects that have rejected infoboxes (the opera project, anyone else?) may wish to reconsider.
- d.
Readers like infoboxes
Was there any doubt about this?
WikiProjects that have rejected infoboxes...
They have? Whaffo? (Oh, wait, I can guess. "This subject is far too broad and multifaceted to be crammed into stylized templates. Readers will be better served and will gain a deeper understanding by gleaning the information they seek from prose paragraphs." Classic serve-the-server, as opposed to serve-the-customer.)
From: Steve Summit scs@eskimo.com
WikiProjects that have rejected infoboxes...
They have? Whaffo? (Oh, wait, I can guess. "This subject is far too broad and multifaceted to be crammed into stylized templates. Readers will be better served and will gain a deeper understanding by gleaning the information they seek from prose paragraphs." Classic serve-the-server, as opposed to serve-the-customer.)
One of Wikipedia's big advantages, IMO, has been that it's written by the same people who are reading it. That means that in theory we tend to focus on the stuff that actually matters to our readers, optimizing our coverage and the degree of effort spent.
Unfortunately as Wikipedia's syntax becomes more complex and as our internal heirarchy becomes more rigid I worry that we're losing that to a large degree. The recent mass blanking of television episode articles, for example, doesn't strike me as the sort of thing that is done to benefit the _reader_ in any meaningful way. And we still don't have anonymous article creation functionality back.
Using meta-templates to simplify the creation of complex templates such as infoboxes seems like one way to ameliorate this problem, albeit a minor one.
On 21/01/2008, Bryan Derksen bryan.derksen@shaw.ca wrote:
From: Steve Summit scs@eskimo.com
WikiProjects that have rejected infoboxes...
They have? Whaffo? (Oh, wait, I can guess. "This subject is far too broad and multifaceted to be crammed into stylized templates. Readers will be better served and will gain a deeper understanding by gleaning the information they seek from prose paragraphs." Classic serve-the-server, as opposed to serve-the-customer.)
One of Wikipedia's big advantages, IMO, has been that it's written by the same people who are reading it. That means that in theory we tend to focus on the stuff that actually matters to our readers, optimizing our coverage and the degree of effort spent.
Unfortunately as Wikipedia's syntax becomes more complex and as our internal heirarchy becomes more rigid I worry that we're losing that to a large degree.
Template syntax, while perfectly logical if you can read it properly, has always been out of the range of the average user. Getting them to use headings and links properly is a reasonable expectation. If there were a WYSIWYG editor it may be nice to include easy to use template mechanisms in it, but before then it seems like a bit of a side issue.
The recent mass blanking of television episode articles, for example,
doesn't strike me as the sort of thing that is done to benefit the _reader_ in any meaningful way. And we still don't have anonymous article creation functionality back.
Wikipedia needs to assert control over its content once in a while. The fact that the majority of most-frequented articles on wikipedia are fiction means nothing to administrators who only care for the project, as opposed to those readers who just use up bandwidth and processing power on the server. It would be quite valuable to the project to wipe out fiction articles as it would save heaps on monthly bandwidth bills.
Using meta-templates to simplify the creation of complex templates such as infoboxes seems like one way to ameliorate this problem, albeit a minor one.
It would be nice to have meta-templates, but it won't help with people who see infoboxes as ugly and not able to portray their POV Truth(tm).
Peter Ansell
On 21/01/2008, Peter Ansell ansell.peter@gmail.com wrote:
Wikipedia needs to assert control over its content once in a while. The fact that the majority of most-frequented articles on wikipedia are fiction means nothing to administrators who only care for the project,
Funny.
as opposed to those readers who just use up bandwidth and processing power on the server. It would be quite valuable to the project to wipe out fiction articles as it would save heaps on monthly bandwidth bills.
Citation needed. Also need to show that donations wouldn't drop by a greater amount.
It would be nice to have meta-templates, but it won't help with people who see infoboxes as ugly and not able to portray their POV Truth(tm).
Please explain how you would fit one in say [[Canals of Great Britain]]
On Mon, 2008-01-21 at 02:20 +0000, geni wrote:
Please explain how you would fit one in say [[Canals of Great Britain]]
I don't think it was implied that *all* articles must have an infobox, and obviously articles that cover several subjects, such as a list or an article similar to the one you mention wouldn't need one. If it was, which doubt, implied that all articles should have an infobox by default, I am sure there would be a command to get rid of it, similar to _NOTOC_
Ian [[User:Poeloq]]
From: Peter Ansell ansell.peter@gmail.com
Wikipedia needs to assert control over its content once in a while. The fact that the majority of most-frequented articles on wikipedia are fiction means nothing to administrators who only care for the project, as opposed to those readers who just use up bandwidth and processing power on the server. It would be quite valuable to the project to wipe out fiction articles as it would save heaps on monthly bandwidth bills.
I actually can't tell whether this is intended as a serious position statement or as an over-the-top parody of deletionism. If it's parody, good show. If it's serious... good lord. _Our readers are not our enemies_. We're not some sort of noble guardians of an ivory tower, trying to fight off hordes of yokels unworthy to read our precious works of pure academia. There's no "Us" and "Them" to insert a "versus" between. The more people that find value in our content the better, no matter who they are.
If bandwidth reduction is so important, how about we require login to view our pages and bounce non-logged-in viewers to answers.com or one of our other mirrors? (Yes, it's a ridiculous idea. I'm doing the parody thing there).
On 21/01/2008, Bryan Derksen bryan.derksen@shaw.ca wrote:
From: Peter Ansell ansell.peter@gmail.com
Wikipedia needs to assert control over its content once in a while. The fact that the majority of most-frequented articles on wikipedia are fiction means nothing to administrators who only care for the project, as opposed to those readers who just use up bandwidth and processing power on the server. It would be quite valuable to the project to wipe out fiction articles as it would save heaps on monthly bandwidth bills.
I actually can't tell whether this is intended as a serious position statement or as an over-the-top parody of deletionism. If it's parody, good show. If it's serious... good lord. _Our readers are not our enemies_. We're not some sort of noble guardians of an ivory tower, trying to fight off hordes of yokels unworthy to read our precious works of pure academia. There's no "Us" and "Them" to insert a "versus" between. The more people that find value in our content the better, no matter who they are.
If bandwidth reduction is so important, how about we require login to view our pages and bounce non-logged-in viewers to answers.com or one of our other mirrors? (Yes, it's a ridiculous idea. I'm doing the parody thing there).
A good parody has a certain amount of truth in it! Better to get frustrations out with extreme parody than endless ramblings ;-)
The answers.com idea sounds like the kind of idea that fits a good parody!
Peter
AboutUs.org http://www.aboutus.org/Wikipedia.org also makes interesting use of an infobox in every article. Their stuff is almost exclusively about web domains, so obviously it's external links and the like. But the interesting part is that they can point to a section to glean address info from (they don't do it on the wikipedia domainpage), thus being able to use a Google maps function. This might be really cool for appropriate geography articles on Wikipedia.
On Jan 20, 2008 9:28 PM, Peter Ansell ansell.peter@gmail.com wrote:
On 21/01/2008, Bryan Derksen bryan.derksen@shaw.ca wrote:
From: Peter Ansell ansell.peter@gmail.com
Wikipedia needs to assert control over its content once in a while. The fact that the majority of most-frequented articles on wikipedia are fiction means nothing to administrators who only care for the project, as opposed to those readers who just use up bandwidth and processing power on the server. It would be quite valuable to the project to wipe out fiction articles as it would save heaps on monthly bandwidth bills.
I actually can't tell whether this is intended as a serious position
statement or as an over-the-top parody of deletionism. If it's parody, good show. If it's serious... good lord. _Our readers are not our enemies_. We're not some sort of noble guardians of an ivory tower, trying to fight off hordes of yokels unworthy to read our precious works of pure academia. There's no "Us" and "Them" to insert a "versus" between. The more people that find value in our content the better, no matter who they are.
If bandwidth reduction is so important, how about we require login to
view our pages and bounce non-logged-in viewers to answers.com or one of our other mirrors? (Yes, it's a ridiculous idea. I'm doing the parody thing there).
A good parody has a certain amount of truth in it! Better to get frustrations out with extreme parody than endless ramblings ;-)
The answers.com idea sounds like the kind of idea that fits a good parody!
Peter
WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: http://lists.wikimedia.org/mailman/listinfo/wikien-l
Steven Walling wrote:
AboutUs.org http://www.aboutus.org/Wikipedia.org also makes interesting use of an infobox in every article. Their stuff is almost exclusively about web domains, so obviously it's external links and the like. But the interesting part is that they can point to a section to glean address info from (they don't do it on the wikipedia domainpage), thus being able to use a Google maps function. This might be really cool for appropriate geography articles on Wikipedia.
We have something like that; see the template in http://en.wikipedia.org/wiki/Channel_Tunnel#External_links , specifically http://maps.google.com/maps?q=http%3A%2F%2Ftools.wikimedia.de%2F%7Epara%2Fcg... .
On Jan 22, 2008 7:23 AM, SPUI drspui@gmail.com wrote:
We have something like that; see the template in http://en.wikipedia.org/wiki/Channel_Tunnel#External_links , specifically http://maps.google.com/maps?q=http%3A%2F%2Ftools.wikimedia.de%2F%7Epara%2Fcg...
I just ported my OpenStreetMap plugin from de to en.wikipedia. Put importScript('User:Magnus Manske/osm.js'); on your monobook.js page (or someone make this a gadget, I'm not sure how), and on pages that have "article coordinates" (on the upper right, below the title baseline), you'll get a link that says "OSM". When you click on it, it will open a map at the top of the article. OSM is free (as in freedom), so no problem transcluding it in the article.
Screenshot from de.wikipedia for Berlin: http://magnusmanske.de/wikipedia/wp_osm.png
This uses one of my tools on the toolserver to generate the map parameters, and it will get coordinates from related articles and display them (the blue flag things in the screenshot). This, however, takes a few seconds. The map appears pretty quickly, though.
The underlying technology is OpenLayers, a free GoogleMaps-like JavaScript. It can also use other layers, e.g., NASA WorldWind. Haven't gotten around to implement that, though.
Cheers, Magnus
Bryan Derksen wrote:
From: Peter Ansell ansell.peter@gmail.com
Wikipedia needs to assert control over its content once in a while. The fact that the majority of most-frequented articles on wikipedia are fiction means nothing to administrators who only care for the project, as opposed to those readers who just use up bandwidth and processing power on the server. It would be quite valuable to the project to wipe out fiction articles as it would save heaps on monthly bandwidth bills.
I actually can't tell whether this is intended as a serious position statement or as an over-the-top parody of deletionism. If it's parody, good show. If it's serious... good lord. _Our readers are not our enemies_. We're not some sort of noble guardians of an ivory tower, trying to fight off hordes of yokels unworthy to read our precious works of pure academia. There's no "Us" and "Them" to insert a "versus" between. The more people that find value in our content the better, no matter who they are.
If bandwidth reduction is so important, how about we require login to view our pages and bounce non-logged-in viewers to answers.com or one of our other mirrors? (Yes, it's a ridiculous idea. I'm doing the parody thing there).
To satisfy my own curiosity I just hist Random article 10 times, and didn't even get a single article from anything that might be termed fiction. The bulk of the bandwidth used in connection with fiction articles appears to stem from the interminable crusades devoted to ridding us of these articles, and the inevitable response from those who seek to protect Wikipedia from this kind of depradation.
Ec
Ray Saintonge wrote:
Steve Summit wrote:
Readers like infoboxes
Was there any doubt about this?
Neither doubt nor support for that statement, only an absence of factual data from reliable sources.
Ec
That came out a bit harsher than I wanted, perhaps because there was another thread happening about "user"boxes and pedophiles. Sorry about that.
I do find some value to user boxes, but their structure has become incomprehensible. This is a far cry from the early ones that I did work on.
Ec
I have to say, that article gets the point across fairly well.
I would like to see infoboxes one day integrated more closely with the Wikipedia UI. It would be great to select an infobox by cat from a dropdown menu, have all the fields displayed form style with optionals marked as so. I think it would be incredibly easy to do without actually editing the infobox syntax. There is a bit of an issue with Infobox duplication and the ability for the novice to integrate infoboxes with articles.
-aliasd
On Jan 21, 2008 11:23 AM, David Gerard dgerard@gmail.com wrote:
http://higheredmarketing.blogspot.com/2008/01/your-web-site-vs-wikipedia.htm...
WikiProjects that have rejected infoboxes (the opera project, anyone else?) may wish to reconsider.
- d.
WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: http://lists.wikimedia.org/mailman/listinfo/wikien-l
On 21/01/2008, aliasd wiki4@da-bom.com wrote:
I would like to see infoboxes one day integrated more closely with the Wikipedia UI. It would be great to select an infobox by cat from a dropdown menu, have all the fields displayed form style with optionals marked as so. I think it would be incredibly easy to do without actually editing the infobox syntax. There is a bit of an issue with Infobox duplication and the ability for the novice to integrate infoboxes with articles.
I used to think of them as a bit of a blight, but one day realised, uh, these are machine-readable information and hence potentially vastly useful. The trick would be to standardise the plumbing behind them without changing each template - the fields and some of the behaviour need standardising.
- d.
David Gerard wrote:
On 21/01/2008, aliasd wiki4@da-bom.com wrote:
...It would be great to select an infobox by cat from a dropdown menu, have all the fields displayed form style...
I used to think of them as a bit of a blight, but one day realised, uh, these are machine-readable information and hence potentially vastly useful.
Indeed. They're the stealth advance guard of the Semantic Wikipedia, unwittingly beloved by lots of people who either have never heard of the "Semantic" idea, or imagine that they believe it's too theoretical or unnecessarily complicated or otherwise not for them.
On 21/01/2008, Steve Summit scs@eskimo.com wrote:
David Gerard wrote:
On 21/01/2008, aliasd wiki4@da-bom.com wrote:
...It would be great to select an infobox by cat from a dropdown menu, have all the fields displayed form style...
I used to think of them as a bit of a blight, but one day realised, uh, these are machine-readable information and hence potentially vastly useful.
Indeed. They're the stealth advance guard of the Semantic Wikipedia, unwittingly beloved by lots of people who either have never heard of the "Semantic" idea, or imagine that they believe it's too theoretical or unnecessarily complicated or otherwise not for them.
Semantic's is still as complicated as it seems. However infoboxes are structured nicely enough to allow outsiders to infer things from them without the trouble of explicitly including microformats or RDFa in Wikipedia pages.
Peter Ansell
Peter Ansell wrote:
On 21/01/2008, Steve Summit scs@eskimo.com wrote:
Indeed. They're the stealth advance guard of the Semantic Wikipedia, unwittingly beloved by lots of people who either have never heard of the "Semantic" idea, or imagine that they believe it's too theoretical or unnecessarily complicated or otherwise not for them.
Semantic's is still as complicated as it seems. However infoboxes are structured nicely enough to allow outsiders to infer things from them without the trouble of explicitly including microformats or RDFa in Wikipedia pages.
Oh, but I wasn't talking about the Semantic *Web*! If Semantic MediaWiki, on the other hand, is too complicated for people to use, we've got only ourselves to blame! (Me, I believe there could and ought to be a Semantic MediaWiki that would be as easy if not much easier to use than infoboxes...)
On 21/01/2008, David Gerard dgerard@gmail.com wrote:
On 21/01/2008, aliasd wiki4@da-bom.com wrote:
I would like to see infoboxes one day integrated more closely with the Wikipedia UI. It would be great to select an infobox by cat from a dropdown menu, have all the fields displayed form style with optionals marked as so. I think it would be incredibly easy to do without actually editing the infobox syntax. There is a bit of an issue with Infobox duplication and the ability for the novice to integrate infoboxes with articles.
I used to think of them as a bit of a blight, but one day realised, uh, these are machine-readable information and hence potentially vastly useful. The trick would be to standardise the plumbing behind them without changing each template - the fields and some of the behaviour need standardising.
dbpedia.org make use of infobox information to provide semantic RDF computer readable representations of wikipedia together with their other sources. I tried to explain this to the WikiProject Opera and Classical groups but I was hounded out by POV pushers IMO. I am still pro infoboxes for all wikipedia articles though.
On 21/01/2008, Peter Ansell ansell.peter@gmail.com wrote:
dbpedia.org make use of infobox information to provide semantic RDF computer readable representations of wikipedia together with their other sources. I tried to explain this to the WikiProject Opera and Classical groups but I was hounded out by POV pushers IMO. I am still pro infoboxes for all wikipedia articles though.
How would you do it for say [[Canals of Great Britain]]?
On 21/01/2008, David Gerard dgerard@gmail.com wrote:
I used to think of them as a bit of a blight, but one day realised, uh, these are machine-readable information and hence potentially vastly useful. The trick would be to standardise the plumbing behind them without changing each template - the fields and some of the behaviour need standardising.
Problem is there are only and handful of people who understand all the code behind the average infobox.
From: geni geniice@gmail.com
Problem is there are only and handful of people who understand all the code behind the average infobox.
If we could get those people together and have them help craft an {{infobox}} meta-template, though, that would help future editors make good infoboxes by automating and concealing that complexity.
From: David Gerard dgerard@gmail.com
I used to think of them as a bit of a blight, but one day realised, uh, these are machine-readable information and hence potentially vastly useful. The trick would be to standardise the plumbing behind them without changing each template - the fields and some of the behaviour need standardising.
In the past six months or so there's been a massive effort to convert navigation boxes over to the standardized {{navbox}} template (and before that was {{navbox generic}}, since subsumed into {{navbox}}. I occasionally run afoul of editors who resist the changeover on their pet navboxes but it's generally gone quite well. Is there any equivalent meta-template for infoboxes? It'll probably be a harder template to come up with since infoboxes have more complex structure than most navboxes but maybe we could start with something relatively simple that can handle the easier cases and work from there.
On 1/20/08, David Gerard dgerard@gmail.com wrote:
I used to think of them as a bit of a blight, but one day realised, uh, these are machine-readable information and hence potentially vastly useful. The trick would be to standardise the plumbing behind them without changing each template - the fields and some of the behaviour need standardising.
Well, that would in fact require changing pretty much every template except for the one(s) which is/are already in the Ideal State, if any exist. Naturally: 1. From the outset, everybody is going to disagree as to the nature of the Ideal State. 2. "Consensus", if reached, should not be abjectly averse to changes in the future. 3. Future changes will be less hampered by bureaucratic inertia if they are easier to implement (and easier to reverse) than the initial standardization process.
Of course the easiest strategy would be to have all infobox templates derived from an abstract base class, i.e. a meta-template (which, when edited, would globally affect all templates inheriting their properties from it).
—C.W.
Charlotte Webb wrote:
Of course the easiest strategy would be to have all infobox templates derived from an abstract base class, i.e. a meta-template (which, when edited, would globally affect all templates inheriting their properties from it).
Well, how about we boldly get that started? :) I note that http://en.wikipedia.org/wiki/Template:Infobox is almost completely unused, it's just sitting there as a chunk of example text that's meant for copying and pasting as a starter point for new infoboxes. It's linked from fewer than 500 pages, and the transclusions that I've sampled all appear to be transcluded in error. So let's hijack it.
I've whipped up a quick and dirty "meta-Infobox" at http://en.wikipedia.org/wiki/User:Bryan_Derksen/Template_sandbox
It's pretty basic but it includes the common features I've seen on most infoboxes and I'm sure that over time people with better parser skills than I will be able to extend it with others; this is just intended to get the ball rolling. If nobody raises any strenuous objections, I'll clean up the transclusions of {{Infobox}} and move the new meta-template's code over.
Yeah, Infoboxes are a nice touch to articles: lift the heavy, bookish feel from the article and make them more Web 2.0-ish.
Of course the easiest strategy would be to have all infobox templates derived from an abstract base class, i.e. a meta-template (which, when edited, would globally affect all templates inheriting their properties from it).
I agree to that. That would allow a much-needed margin to be added (margin-top: 1px; margin-left: 1px; etc...), which stops the templates clashing by adding an invisible border on the outside (as oppose to padding: 1px, which adds space in the inside of the template's edges. Just a nice touch that makes it look more professional.
Anthony
User:AGK en.wikipedia.org
On 22/01/2008, Bryan Derksen bryan.derksen@shaw.ca wrote:
Charlotte Webb wrote:
Of course the easiest strategy would be to have all infobox templates derived from an abstract base class, i.e. a meta-template (which, when edited, would globally affect all templates inheriting their properties from it).
Well, how about we boldly get that started? :) I note that http://en.wikipedia.org/wiki/Template:Infobox is almost completely unused, it's just sitting there as a chunk of example text that's meant for copying and pasting as a starter point for new infoboxes. It's linked from fewer than 500 pages, and the transclusions that I've sampled all appear to be transcluded in error. So let's hijack it.
I've whipped up a quick and dirty "meta-Infobox" at http://en.wikipedia.org/wiki/User:Bryan_Derksen/Template_sandbox
It's pretty basic but it includes the common features I've seen on most infoboxes and I'm sure that over time people with better parser skills than I will be able to extend it with others; this is just intended to get the ball rolling. If nobody raises any strenuous objections, I'll clean up the transclusions of {{Infobox}} and move the new meta-template's code over.
WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: http://lists.wikimedia.org/mailman/listinfo/wikien-l
On 1/24/08, AGK agkwiki@googlemail.com wrote:
I agree to that. That would allow a much-needed margin to be added (margin-top: 1px; margin-left: 1px; etc...), which stops the templates clashing by adding an invisible border on the outside (as oppose to padding: 1px, which adds space in the inside of the template's edges. Just a nice touch that makes it look more professional.
I don't have an opinion on what makes what look more professional. The specifics of that can be hammered out at a later date. The first step is to establish a self-maintaining consistency of appearance. The second step is to (somehow) ensure that it's not overridden unless there is a damn good reason to do so. For something as simple as margin size, CSS classes would be helpful in the first step[1], much less so for the second[2].
[1] Using CSS definitions wherever possible would also shift much the "job queue" burden to the client side when minor formatting changes are made. [2] It's all too easy to override any part of a CSS class that you don't like, so CSS alone wouldn't prevent decadent ugliness like <table class="infobox" cellpadding="10" style="background-color:hotpink; border:3px solid hotterpink; -moz-border-radius-bottomleft: 8px; etc. etc. etc...">.
—C.W.
Charlotte Webb wrote:
I don't have an opinion on what makes what look more professional. The specifics of that can be hammered out at a later date. The first step is to establish a self-maintaining consistency of appearance.
I've completed my hijacking of [[Template:Infobox]] without any complaints being raised and have actually started using it in a few reasonably out-of-the-way places (I want to test it in the field without stumbling into any landmines in the process :). So hopefully step one is on the way.
The second step is to (somehow) ensure that it's not overridden unless there is a damn good reason to do so.
I've included the ability to override all the various styles in [[Template:Infobox]] in the same manner as [[Template:Navbox]]. But I wouldn't worry too much about that. I've done a lot of navbox work and I've found that in practice the colors are often changed, a relatively harmless modification in most cases, but the other styling characteristics are much more rarely overridden. And being able to restyle the template helps overcome resistance from editors who are guarding an old-style navbox against intruders, by allowing the guts to be changed with minimal disturbance to the outward appearance.
If we didn't allow the CSS to be tweaked using parameters people would do it anyway by inserting divs and spans instead, making it much more awkward to fiddle with in the future. In some far distant time if we decide "all navboxes will have uniform color schemes without exception", we'd be able to override every last one of the overrides simply by editing the root navbox template.