A lot of comments have been made about whether wiki markup is a barrier to entry, and if it is, whether it (the barrier to entry) is a good thing or not.
On the first part, it would be interesting to measure edit attempts - how many people clicked edit, but did not click save or preview. Of course this does not tell you if the markup is a barrier to entry, but it may be some kind of rough indicator. The experience of editing a well developed page can be like looking at source code: if you don't know the language, there's an awful lot of gobbledygook in there, and I'd think it intimidates some people.
So... it would just be an interesting figure, to hold up next to other figures, like completed edits.
Aerik
On 8/11/06, Aerik Sylvan aerik@thesylvans.com wrote: [snip]
The experience of editing a well developed page can be like looking at source code: if you don't know the language, there's an awful lot of gobbledygook in there, and I'd think it intimidates some people.
So... it would just be an interesting figure, to hold up next to other figures, like completed edits.
I'd be especially interested to know how the number of failed edits relates to page edits on pages with infoboxes at the top.
In my experience wikitext markup isn't frightening to many people until you are faced with templates.... which are, unfortunately, the first bit of wikitext source that many editors see.
Once we're sampling views it wouldn't be too hard to sample edit pages. :)
Gregory Maxwell wrote:
In my experience wikitext markup isn't frightening to many people until you are faced with templates.... which are, unfortunately, the first bit of wikitext source that many editors see.
Until one of us if proven to be wrong, let me claim the opposite ;)
Looking at the plain table wiki-code is sure more frightening than the clean abstraction presented by an infobox template call.
If you look at http://en.wikipedia.org/wiki/John_Forbes_Nash those template parameters are much easier to understand than the table at http://en.wikipedia.org/wiki/Hazleton_Mountaineers.
--Ligulem
On 8/11/06, Ligulem ligulem@pobox.com wrote:
Looking at the plain table wiki-code is sure more frightening than the clean abstraction presented by an infobox template call.
Probably, but infoboxes are a) much more common, and b) almost invariably at the very top of articles, making them the first thing most users see. *Anything* that isn't very similar to what's displayed is scary to technophobes. The technically-inclined can comfortably look at it and say "Hmm, it must somehow generate the box there, or something", then ignore it, but someone like my mother would become instantly uncomfortable and worried that they might break something if they tried to edit. She wouldn't try to decipher what it actually meant, if all she was thinking of doing was correcting a date or something; she wouldn't want to put in the effort.
On 8/11/06, Ligulem ligulem@pobox.com wrote:
Looking at the plain table wiki-code is sure more frightening than the clean abstraction presented by an infobox template call.
From the "don't scare the user" point of view, the best is a template
substition that hides *everything*, like if the first thing you see is:
{{Paris infobox}} '''Paris''' is a city in France that...
Of course, many purists hate this apparent abuse of one-use templates...
Steve
From the "don't scare the user" point of view, the best is a template
substition that hides *everything*, like if the first thing you see is:
{{Paris infobox}} '''Paris''' is a city in France that...
Of course, many purists hate this apparent abuse of one-use templates...
Wouldn't that be a great use for subpage-templates? Have the Infobox at Paris/infobox and just include it as a template.
On 8/12/06, Daniel Schwen lists@schwen.de wrote:
Of course, many purists hate this apparent abuse of one-use templates...
Wouldn't that be a great use for subpage-templates? Have the Infobox at Paris/infobox and just include it as a template.
That sounds nice actually. Technically we have a rule against mainspace subpages, but that sounds like a good reason to change the rule.
Steve
On 8/11/06, Ligulem ligulem@pobox.com wrote:
Until one of us if proven to be wrong, let me claim the opposite ;)
Ahh the power of discussion to improve the clarity of our statements...
I think tables are just as bad as infoboxes, okay fine.. a concession: they are indeed worse. The point I was trying to make was more along the lines of "when someone wants to edit the intro and they get something which is not the intro it leads to confusion".
On 8/11/06, Gregory Maxwell gmaxwell@gmail.com wrote:
I think tables are just as bad as infoboxes, okay fine.. a concession: they are indeed worse. The point I was trying to make was more along the lines of "when someone wants to edit the intro and they get something which is not the intro it leads to confusion".
Yes. Footnotes sometimes have this effect too, as do excessive use of arcane page layout formatting.
Steve
Steve Bennett wrote:
On 8/11/06, Gregory Maxwell gmaxwell@gmail.com wrote:
I think tables are just as bad as infoboxes, okay fine.. a concession: they are indeed worse. The point I was trying to make was more along the lines of "when someone wants to edit the intro and they get something which is not the intro it leads to confusion".
Yes. Footnotes sometimes have this effect too, as do excessive use of arcane page layout formatting.
I think the absolute worst part of this is references.
Firstly, if you spot a typo in a reference, the instinct is to click the "edit" link for the References section. But then all you see is:
== References == <references/>
The other thing is that if you spot a typo in the middle of a paragraph which has inline references in every sentence, it is *extremely* hard to find that typo because all the inline references distract. You look somewhere and you don't even know if you're looking at the paragraph or the inside of a <ref> tag.
If the person designing the references syntax had thought about this a bit more, these severe problems should have been apparent to them. A much more sensible thing would be to use [1], [2] etc. in the text, and define the references in the place where they are actually displayed -- the References section. (Duh.)
Timwi
On 8/14/06, Timwi timwi@gmx.net wrote:
I think the absolute worst part of this is references.
Firstly, if you spot a typo in a reference, the instinct is to click the "edit" link for the References section. But then all you see is:
== References == <references/>
Yes.
The other thing is that if you spot a typo in the middle of a paragraph which has inline references in every sentence, it is *extremely* hard to find that typo because all the inline references distract. You look somewhere and you don't even know if you're looking at the paragraph or the inside of a <ref> tag.
Agreed again. And you haven't even mentionde the problem of multiply-used footnotes.
To me this says that the needs of the creator of the footnote, and the needs of the future maintainer of the footnote are in direct conflict.
If the person designing the references syntax had thought about this a bit more, these severe problems should have been apparent to them. A much more sensible thing would be to use [1], [2] etc. in the text, and define the references in the place where they are actually displayed -- the References section. (Duh.)
We used to have a system (or 3) like that. It was crap. Hard numbering footnotes is an awful solution.
The only thing I can think of that would work is that a person can add a footnote like this:
Sometext<ref> a reference in the good old style</ref>...some more text.
...which the software would actually move down to the references section.
Sometext<ref name="ref1"/>...some more text. ... <references> <ref name="ref1">a reference in the good old style</ref> </references>
Easy on the writer, easy on the maintainer. And totally confusing for aynone who witnesses the transition.
Steve
Steve Bennett wrote:
If the person designing the references syntax had thought about this a bit more, these severe problems should have been apparent to them. A much more sensible thing would be to use [1], [2] etc. in the text, and define the references in the place where they are actually displayed -- the References section. (Duh.)
We used to have a system (or 3) like that. It was crap. Hard numbering footnotes is an awful solution.
Why? I can't think why. Of course, the software would have to automatically renumber them if references get deleted or moved around.
The only thing I can think of that would work is that a person can add a footnote like this:
Sometext<ref> a reference in the good old style</ref>...some more text.
....which the software would actually move down to the references section.
That's another possibility, of course -- although I would still contend that something like [1], or even if it needs to be [ref:1], is much better (easier to read, easier to ignore, easier to type, easier to type without mistakes) than <ref name="ref1"/>.
Timwi
On 8/15/06, Timwi timwi@gmx.net wrote:
Why? I can't think why. Of course, the software would have to automatically renumber them if references get deleted or moved around.
I said why in my last post:
The advantages of having the full reference in the text are that it works with section editing, and the ref doesn't break invisibly if someone transplants the section or whatever without thinking to move the refs as well. Trust me, that's constant and horrible with the {{ref}} style: I've had to spend half an hour or more on more than one occasion digging through page histories to figure out where the references disappeared.
I stressed the second point, but the first is important as well: to add something with a source, you have to either make two edits or do a full-page edit rather than a section edit, either of which is annoying. Both styles are imperfect; I would guess that Avar tried out the inline one because people complained about the flaws of the then existing ref-at-end style. I still prefer the inline style overall, if those are the only two choices, because you don't get horrible numbers of broken refs with that.
On 8/15/06, Timwi timwi@gmx.net wrote:
Why? I can't think why. Of course, the software would have to automatically renumber them if references get deleted or moved around.
Can you elaborate on that? What exactly is your proposal, because anything that involves typing in numbers manually sounds like a terrible idea, at first glance.
That's another possibility, of course -- although I would still contend that something like [1], or even if it needs to be [ref:1], is much better (easier to read, easier to ignore, easier to type, easier to type without mistakes) than <ref name="ref1"/>.
Still a problem if you have to add the references to a references section (bad if you're doing section editing).
Steve
Steve Bennett wrote:
On 8/15/06, Timwi timwi@gmx.net wrote:
Why? I can't think why. Of course, the software would have to automatically renumber them if references get deleted or moved around.
Can you elaborate on that? What exactly is your proposal, because anything that involves typing in numbers manually sounds like a terrible idea, at first glance.
The proposal is that a new reference is added the same way as now, but replaced at save-time with a number. All references are re-numbered at save-time so they start at 1 and don't skip numbers.
Currently, if you want to re-insert a second link to an existing reference, you have to hunt down its name (or worse, first assign one yourself, for which you would potentially have to know the other names in use so yours doesn't clash with them). Ideally you should only need to look at the (rendered) References section to get the number, and then type something like [1] to insert it.
I find your statement "anything that involves typing in numbers manually sounds like a terrible idea" amazing -- does that mean you find "<ref name='blah'/>" easier to type than "[1]"?
That's another possibility, of course -- although I would still contend that something like [1], or even if it needs to be [ref:1], is much better (easier to read, easier to ignore, easier to type, easier to type without mistakes) than <ref name="ref1"/>.
Still a problem if you have to add the references to a references section (bad if you're doing section editing).
As explained above, you never need to /add/ a reference to the references section (unless you want to add one without a link inline in the text; which, by the way, the current system doesn't allow, which makes for extremely ugly formatting in many References sections). However, one should be able to /edit/ the references in the References section, because that's where they are.
Timwi
Hi Tim,
The proposal is that a new reference is added the same way as now, but replaced at save-time with a number. All references are re-numbered at save-time so they start at 1 and don't skip numbers.
Ok that's the bit I hadn't picked up on - automatic re-numbering. A curious idea, combining static and dynamic numbering.
Currently, if you want to re-insert a second link to an existing reference, you have to hunt down its name (or worse, first assign one yourself, for which you would potentially have to know the other names in use so yours doesn't clash with them). Ideally you should only need to look at the (rendered) References section to get the number, and then type something like [1] to insert it.
Your ideas have merit.
I find your statement "anything that involves typing in numbers manually sounds like a terrible idea" amazing -- does that mean you find "<ref name='blah'/>" easier to type than "[1]"?
I was stuck on the idea of dynamic numbering. Inserting a new footnote 2 and having to manually renumber the others...you know...
As explained above, you never need to /add/ a reference to the references section (unless you want to add one without a link inline in the text; which, by the way, the current system doesn't allow, which makes for extremely ugly formatting in many References sections). However, one should be able to /edit/ the references in the References section, because that's where they are.
Sounds pretty good.
Steve
On Mon, Aug 14, 2006 at 05:51:55PM +0100, Timwi wrote:
Firstly, if you spot a typo in a reference, the instinct is to click the "edit" link for the References section. But then all you see is:
== References ==
<references/>
The other thing is that if you spot a typo in the middle of a paragraph which has inline references in every sentence, it is *extremely* hard to find that typo because all the inline references distract. You look somewhere and you don't even know if you're looking at the paragraph or the inside of a <ref> tag.
If the person designing the references syntax had thought about this a bit more, these severe problems should have been apparent to them. A much more sensible thing would be to use [1], [2] etc. in the text, and define the references in the place where they are actually displayed -- the References section. (Duh.)
Well, now; *here* we go into water that's easier to deal with: even now, and particularly once the syntax is cleaned up a bit, it wouldn't be that hard, I don't think, to implement syntax coloring in the wikitext editor (he says, not being the one who's gonna write the code :-), which would make it substantially easier to deal with such circumstances.
And FWIW, I'm split, Timwi, on whether it's better to put the reference inline or not; I can see good arguments both ways.
Cheers, -- jra
On 8/14/06, Timwi timwi@gmx.net wrote:
If the person designing the references syntax had thought about this a bit more, these severe problems should have been apparent to them. A much more sensible thing would be to use [1], [2] etc. in the text, and define the references in the place where they are actually displayed -- the References section. (Duh.)
If you had thought about this a bit more, the severe problems with your suggestions should be apparent to you. :) More precisely, neither you nor Avar probably saw all the arguments for each side before you made your respective statements/commits. (When Avar did it, the arguments against hadn't been *developed*, due to lack of experience.)
Basically, the advantages of having just a reference name be in the text itself, and the text in the references section, are intuitiveness and less clutter. The advantages of having the full reference in the text are that it works with section editing, and the ref doesn't break invisibly if someone transplants the section or whatever without thinking to move the refs as well. Trust me, that's constant and horrible with the {{ref}} style: I've had to spend half an hour or more on more than one occasion digging through page histories to figure out where the references disappeared.
Jay is right that coloring the refs probably wouldn't be too hard with current wikitext. Ideally, WYSIWYG would handle refs in some special way so that editing them is fully intuitive and uncluttered. Something like being able to click the ref number to bring up a floating popup-y thing that you could edit, while also being able to click the ref in the references section and edit that directly, with the Javascript keeping them synced and secretly editing only the <ref> contents either way.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Simetrical wrote:
Jay is right that coloring the refs probably wouldn't be too hard with current wikitext. Ideally, WYSIWYG would handle refs in some special way so that editing them is fully intuitive and uncluttered. Something like being able to click the ref number to bring up a floating popup-y thing that you could edit, while also being able to click the ref in the references section and edit that directly, with the Javascript keeping them synced and secretly editing only the <ref> contents either way.
Or implementing them using WikiData to store references and linking to that data from article text.
On 8/14/06, Simetrical Simetrical+wikitech@gmail.com wrote:
Basically, the advantages of having just a reference name be in the text itself, and the text in the references section, are intuitiveness and less clutter. The advantages of having the full reference in the text are that it works with section editing, and the ref doesn't break invisibly if someone transplants the section or whatever without thinking to move the refs as well. Trust me, that's constant and horrible with the {{ref}} style: I've had to spend half an hour or more on more than one occasion digging through page histories to figure out where the references disappeared.
Trust me, from the POV of the person *adding* the references, genuine inline references are *extremely* attractive. It is *much* more pleasant to simply write and John Smith was born in 1953 <ref>http://some.web.site.info</ref> and died in 1923, than to have to mess around with choosing a reference name and add things in two different places - *especially* when you're doing section editing (because otherwise you have to make two separate edits, and the article is in an inconsistent state in the meantime). I basically never added footnotes at all until this new method came along, and now I add them regularly.
However, genuine inline references *suck* for the maintainer. They're a nightmare. There's actually a simple algorithm to find the source of a footnote: click the footnote, then click the first letter on that footnote line, then click edit - but it's not at all intuitive.
My suggestion is the only way I can think of making footnotes bearable for both creator and maintainer. Short of a separate "footnotes" editing box, that is (which I believe has been proposed before).
Steve
Jay is right that coloring the refs probably wouldn't be too hard with current wikitext. Ideally, WYSIWYG would handle refs in some special way so that editing them is fully intuitive and uncluttered. Something like being able to click the ref number to bring up a floating popup-y thing that you could edit, while also being able to click the ref in the references section and edit that directly, with the Javascript keeping them synced and secretly editing only the <ref> contents either way. _______________________________________________ Wikitech-l mailing list Wikitech-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l
"Steve Bennett" wrote:
My suggestion is the only way I can think of making footnotes bearable for both creator and maintainer. Short of a separate "footnotes" editing box, that is (which I believe has been proposed before).
Good idea. What Simetrical said was more in the idea of a wysigig editor, but we could have it now. We can edit per sections ?section=N, we could also have a per-reference section ?reference=reference_name (incompatible with per section editing), where you would only edit that references. What i don't know is where to put the edit link, as it may fill almost the same as the reference. a javascript floating div, perhaps? They usually aren't very nice, but may fit here.
wikitech-l@lists.wikimedia.org