On 02/06/2012 06:19 AM, Pavel Tkachenko wrote:
Mihaly Heder,
It's better to say harsh truth than soft lie. No offense.
In your speech about wikitext you were clearly keeping *current*
markup in mind. I'm sure about this because you mentioned LaTeX which
also is not a perfect text markup language.
Wikitext is not a proper IQ test indeed, it's test for geekness at
best in its current form.
But what kind of IQ are we talking about when quoting paragraphs in
maillists? Are those ">"s that hard to comprehend? Or are *bold*,
/italic/ and _underline_ are much harder to remember than [b], <em>
and \stuff?
Let me get this straight: there has no ideal, or even good, plain text
editing language created to date, not one that is widely used and
known to me. And the overwhelming majority of them are Latin-centric.
A classical freshmen commencement procedure:
awkward things to do,
some humiliation, and bullies.
I understand that wikitext became an important part of this culture.
But I also think that the knowledge of wikitext should not be a status
symbol of our group membership unless we want to appear as a sect or
something like that.
I agree with you completely: "b/w terminal does not
pardon some
cryptic Unix". Content must be presented and edited in clear form. I
am not a big fan of wikitext myself, probably the opposite and I'm all
for changing it for the best. And in my opinion visual editor isn't a
solution but a concealment.
You assume that it is best solved by using a
somewhat cryptic
language which will tell us apart the good from the bad.
Absolutely not. It seems
I've been misunderstood here :(
I'm not voting for keeping current wikitext, I'm voting to rework it.
Knowledge about the article one wants to edit?
Surely not.
Devotion to make an edit? Probably.
Markup skills? Probably.
Tolerance for outdated interfaces? I say this, too.
Can you repeat all of this if
someone is reluctant to read Wikipedia
editing/copyright guidelines? Why in your opinion editing with plain
yet intuitive markup is different from rich editor?
I would love to give practical examples if someone has outlined
specific causes of "devoted and intelligent people going away when
seeing wikitext". For now, I can invent my own - templates of
infoboxes that appear on top of most articles can scare anyone out of
his senses.
But let's be blunt and say that markup is about text MARKUP, not
presentation. Not to the extent that drives such text to
incomprehensibleness. If we accept the thesis that markup must be
human-readable and everything else MUST be handled by the machine no
matter how "complex" this might become for it we can achieve some
interesting results.
For example, if I'm a "newbie but intelligent" Wikipedian and open the
page on "The Earth" I see this:
{{About|the planet}}
{{pp-semi|small=yes}}{{pp-move-indef}}
{{Infobox Planet
| bgcolour = #c0c0ff
| name = Earth
| symbol = [[File:Earth symbol.svg|25px|Astronomical symbol of Earth]]
...
}}
This is how I understand what human-readable markup means:
1. Okay, I understand that "{{" and "}}" are some special symbols -
but why pipe is between what seem to be words and in the start of some
new lines?
2. What is "pp-semi" why it "move-indef"?
3. Why bgcolour is there? It's presentation. Is any editor going to
change background color of the infobox, ever? Perhaps it has a
different tone and must be #c0c1ff?
These are just 3 basic questions. Processed, the above snippet might
look like this:
{{About Earth, the planet}}
{{Infobox
symbol = [[File:Earth symbol.svg|25px|Astronomical symbol of Earth]]
...
}}
That's it. Now the machine's part:
1. "About" is a special "template" or some other construct. When
it's
"ran" (processed) it accepts 2 colon-separated "arguments". The
first
specifies "name" of something (place, planet, object, etc.), the
second - its "role". Moreover, even these are article-specific and can
be changed. The point is that this line remains equally understandable
regardless of the article type.
2. "{{pp ... indef}}" thing has disappeared. If that's something
system it must go in system properties of the page, not be visible to
anyone - what's the point in seeing it if the page is protected? And
it's often protected to prevent changes to such "system" entries
anyway. Vicious circle.
3. "Infobox Planet" has transformed into just "Infobox" - we've
got
"planet" defined in "About".
4. "bgcolor" is system presentation-specific thing, no place for it in
the contents.
4. "name = Earth" - we've got this along with "Planet".
We have just reduced the source almost by 50% of lines.
Another example on the same page:
| temperatures = yes
| temp_name1 = [[Kelvin]]
| min_temp_1 = 184 K<ref name=asu_lowest_temp/>
| mean_temp_1 = 287.2 K<ref name=kinver20091210/>
| max_temp_1 = 331 K<ref name=asu_highest_temp/>
| temp_name2 = [[Celsius]]
| min_temp_2 = ?89.2 °C
| mean_temp_2 = 14 °C
| max_temp_2 = 57.8 °C
...
<ref name=asu_lowest_temp>{{cite
web|url=...|work=...|publisher=...|accessdate=2010-08-07}}</ref>
...
What kind of false positives are we talking about? Will any sane
individual spend his precious time not editing but preparing to edit
this mess?
Again, not to offend anyone and least - MediaWiki devs, but if we're
talking about wikitext future the above must look much more plain:
temperatures = in Kelvin: 184, 287.2, 331
temperatures min = {{Cite from web: url ..., work ..., publisher
..., access date 2010-08-07}}
5 times less "code" and still perfectly handled by the machine and -
what's important too - more managable with more features:
1. "temperatures = yes" - obviously, if any temperatures are specified
in the infobox then the temperature block is enabled. Is it possible
otherwise?
2. No Celsius temperatures - the machine does better job converting
values than human plus calculator.
3. No link in "[[Kelvin]]" - the machine can place link itself, can't it?
4. No because it just fixes some engine problem and is problem
for its devs, not editors or, mind you, users.
5. Replaced all <ref>s with another "template argument" named
"temperatures min". This works simple: the machine calculates minimal
value and applies given reference to it, if corresponding argument is
passed. If no - no reference.
6. No degree symbols: it's cleaner and users don't have to search for
the special char (°).
And at least one added benefit:
Should Wikipedia core group decide that there are not just Celsius and
Kelvin but some different temperature values it can be added without
changing ANY article source as long as conversion between Kelvin or
Celsius and the new value can be done. Moreover, since K/C is managed
by the machine each Wikipedia visitor can customize what he wants to
see or their order (for instance, Celsius is his native and he wants
to see it first).
---
The above are just small examples not involving large markup changes.
I am ready to give more detailed reviews.
Try to imagine what kind of syntax we will get if we rework it from
scratch. Personally for years I have been using a home-made markup
that I'm using on some of my resources as a replacement for wiki,
BB-codes and HTML and from my experience it's possible to create an
international and intuitive markup suitable for virtually anyone using
a computer. And added a simple plain-text editor like wikEd it will
combine powers of both text and rich editors.
Especially if a group like WMF undertakes this task.
Signed,
P. Tkachenko
_______________________________________________
Wikitext-l mailing list
Wikitext-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitext-l
I am forwarding below a response from Oliver Keyes, who isn't on this list.
--
Sumana Harihareswara
Volunteer Development Coordinator
Wikimedia Foundation
Hey guys
Sumana asked me to chip in; most of the arguments that can be made have
already been typed up by people like Trevor, but I thought I'd go into a
bit more detail and provide some links for those of you who want to do
slightly deeper reading.
I'm not commenting on the pros or cons of redoing the underlying
wikimarkup; that's a technical issue, and I'm not a technical person.
What I *am* is a community engagement person - and Pavel's line that
intelligent people can parse markup languages is pretty well within my
bailiwick :).
The problem with this line is that it has the potential to turn into a
"true scotsman" argument. Pavel, you're clearly both an intelligent and
a technical man - but not all intelligence is of the same,
technically-minded type, and it's not always backed up by pertinent and
complex knowledge. I'm sure that you, were you a new editor, would be
able to quickly parse our syntax inside your head. However, you're
someone who is technically proficient and knows a lot of the background
to markup languages, and most people - indeed, most *intelligent* people
- simply aren't.
It wasn't always the case. Early and mid-term adopters of the internet
(I count myself as the latter, having first got online circa 1999) were
technically proficient, could probably code, and would certainly be able
to deal with not only our markup languages but markup languages generally.
This isn't necessarily because they were more intelligent than anyone
else, though; this is because the structure of the internet at that time
penalised anyone who *wasn't* technical; websites and communications
methods expected a degree of technical proficiency.
Today that isn't the case. Site after site after site have realised that
instituting technical barriers to participation artificially limits your
audience and volunteers, and have introduced WYSIWYG editors in some
way, shape or form. The result is that the generation of intelligent
people we're dealing with now is not the generation of early and
mid-level adopters we all know, love and are members of; it's the
Facebook generation: people who have come to expect that the barriers to
participating will be low, easy to comprehend, and simple to bypass. And
because they've come to expect this, and the internet has indulged this,
they don't necessarily have the technical knowledge or background to
parse markup languages in the same way that members of this list might.
Of course, it's a mistake to think that just because someone is young
they won't be technical - we have a lot of great, technically minded
volunteers. Similarly, it's a mistake to think that just because someone
is older they will be. For some cases-in-point, I recommend the
usability studies the Foundation ran a couple of years ago - there are
some great examples at
http://usability.wikimedia.org/wiki/Usability,_Experience,_and_Evaluation_S…
http://usability.wikimedia.org/wiki/Usability_and_Experience_Study#Wiki_Syn…
The simple fact of the matter is this: editing is complex and technical
and we are not, as experienced people, necessarily qualified to say what
the general population can or cannot do, because *we are not the general
population*. The people qualified to tell us what gen pop feels
comfortable doing and what gen pop expects of websites are, well, gen
pop. And they've spoken, through the usability initiative and just about
every conversation I've had with a reader, and, I'm sure, a heck-load of
conversations other contractors and staffers have had too. The
complexity of our existing markup language is a barrier, but not as much
as the presence of any markup language whatsoever as a default.
I appreciate this is a bit TL:DR, and as I'm not really subscribed to
this list I'm unlikely to see responses unless Sumana is kind enough to
act as my gopher ;). If you want to chat more about the philosophical
and cultural underpinnings of usability rather than the technical, I'm
always up for a natter; okeyes(a)wikimedia.org