Hi everyone,
Part of the Wikipedia Usability Initiative is a project to create a system whereby template calls are hidden (minimized, really) for most users on the edit page, and when users do want to edit template calls, they can do so via a form instead of editing the template call directly. I'm involved with that project; my previous experience with such matters was creating the Semantic Forms extension, which is similar in its basic concept. I've put together a page explaining the current thinking on how the system should work, here:
http://usability.wikimedia.org/wiki/Template_forms
We're looking for feedback; any thoughts or questions are welcome, either on that page's talk page or by responding to this email.
Thanks, Yaron
Yaron Koren wrote:
Hi everyone,
Part of the Wikipedia Usability Initiative is a project to create a system whereby template calls are hidden (minimized, really) for most users on the edit page, and when users do want to edit template calls, they can do so via a form instead of editing the template call directly. I'm involved with that project; my previous experience with such matters was creating the Semantic Forms extension, which is similar in its basic concept. I've put together a page explaining the current thinking on how the system should work, here:
http://usability.wikimedia.org/wiki/Template_forms
We're looking for feedback; any thoughts or questions are welcome, either on that page's talk page or by responding to this email.
Thanks, Yaron
Perhaps it could be made so form parameters and template documentation can be defined at the same time? At first, I thought in the ability of embedding the documentation in the template, but if XML provides benefits, it could be made so the documentation can be provided from the XML.
I like the XML way of resolving this problem but I think it MediaWiki has a bigger task to do. Restructure the wiki language, XML-ize the language completely. Forms and attributes will have a place in this WikiXML-definition. Pages can be constructed from one or more XML-sources. XML-source, or a transformed version of it, can be used on more than one page. 'Extensions' will be (sub)-elements of the standard MediaWiki definition. Recursive tasks can be done as long as the definition allows it. We are not depending on the MW-parser as is. Easier construction of editors. Use of XML-stylesheets for presentation. etc.
non-realistic? May be. In my vision the only way to make a real difference. If this is a first step towards structuring the language than I think its ok.
Andre
Op 23 sep 2009, om 20:24 heeft Yaron Koren het volgende geschreven:
Hi everyone,
Part of the Wikipedia Usability Initiative is a project to create a system whereby template calls are hidden (minimized, really) for most users on the edit page, and when users do want to edit template calls, they can do so via a form instead of editing the template call directly. I'm involved with that project; my previous experience with such matters was creating the Semantic Forms extension, which is similar in its basic concept. I've put together a page explaining the current thinking on how the system should work, here:
http://usability.wikimedia.org/wiki/Template_forms
We're looking for feedback; any thoughts or questions are welcome, either on that page's talk page or by responding to this email.
Thanks, Yaron _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Wed, Sep 23, 2009 at 4:37 PM, apri a.vd.wiel a.vd.wiel@apri.nl wrote:
I like the XML way of resolving this problem but I think it MediaWiki has a bigger task to do. Restructure the wiki language, XML-ize the language completely. Forms and attributes will have a place in this WikiXML-definition. Pages can be constructed from one or more XML-sources. XML-source, or a transformed version of it, can be used on more than one page. 'Extensions' will be (sub)-elements of the standard MediaWiki definition. Recursive tasks can be done as long as the definition allows it. We are not depending on the MW-parser as is. Easier construction of editors. Use of XML-stylesheets for presentation. etc.
non-realistic? May be. In my vision the only way to make a real difference. If this is a first step towards structuring the language than I think its ok.
Wikis are supposed to be easy to edit. Maybe I am misunderstanding your intent, but XML-ize everything sounds like an approach that would make it much harder for novice editors to figure out what they are doing. XML tends to be verbose and complicated when edited by hand, and rather opaque for people who have no experience with it.
-Robert Rohde
On Wed, Sep 23, 2009 at 7:54 PM, Robert Rohde rarohde@gmail.com wrote:
Wikis are supposed to be easy to edit.
Wikitext is not easy to edit. It's incredibly confusing and intimidating to any normal person. The only thing that would be easy to edit is something WYSIWYG-based. And AFAICT, the only way we're going to get that is to use some kind of backend storage that can round-trip sensibly with HTML. It doesn't have to be XML-based, but it needs to be a lot simpler (from a programming standpoint, not a human standpoint) than what we have now.
But there would be transition costs here that are prohibitive in the medium term. Hopefully at some point we'll have the resources to devote to this, but in the short to medium term, there's a lot of low-hanging fruit that will give much better usability improvements per dev-hour than getting WYSIWYG reliable enough to deploy.
Aryeh Gregor <Simetrical+wikilist <at> gmail.com> writes:
Wikitext is not easy to edit.
It is easy enough to edit for power users, who make the large majority of edits; and way more comfortable than WYSIWYG. Wikis require a certain hacker mentality - not in the technical sense, but a desire to understand things in depth. It takes effort to learn the syntax, but once you did, it gives you freedom and effectiveness, because you are actually in control of things (as opposed to rich text editors which sometimes do something similar to what you intended, at other times not even close, because they use some fucked-up internal representation that you have no way of knowing or understanding). This might be a problem for Wikia with its fanboi target demographic that has the attention span of a Naruto episode, but Wikipedia is an encyclopedia, and writing a good encyclopedia article requires hacker mentality in the first place, so whatever.
And then there is the ecosystem of bots, gadgets and other third-party tools which is based on wikitext, and not only would moving away from wikitext a huge maintenance burden, but again it would be replaced with something that is way less intuitive and actually harder to use (simple text operations are somewhat easier than fooling around with document trees).
So if you can do WYSIWYG on top of wikitext, cool (the learning curve is certainly steep for new users, and that will only become worse as new features are added). If you can do a sort of WYSIWYM with syntax highlighting, context-sensitive help and wizards for the more inconvenient elements like templates, that is even better, because it wouldn't create a gap between people using WYSIWYG and wikitext, and would allow for a gradual learning experience. But replacing wikitext with some sort of internal representation that is unreadable for humans would be a huge mistake IMO.
2009/9/24 Tisza Gergő gtisza@gmail.com:
It is easy enough to edit for power users, who make the large majority of edits; and way more comfortable than WYSIWYG.
Much as vim is more powerful than Notepad.
However, impenetrable wikitext is one of *the* greatest barriers to new users on Wikimedia projects. And this impenetrability is not, in any way whatsoever or by any twists of logic, a feature.
- d.
On Thu, Sep 24, 2009 at 14:36, David Gerard dgerard@gmail.com wrote:
However, impenetrable wikitext is one of *the* greatest barriers to new users on Wikimedia projects. And this impenetrability is not, in any way whatsoever or by any twists of logic, a feature.
Adding a gui layer to wikitext is always okay, as long as it's possible to get rid of, since majority of edits not coming from "new users", and losing flexibility for power users to get more newbies doesn't sound like a good deal to me.
At least all of the GUIs I've seen were slow and hard to use, and resulted unwanted (side) effects if something even barely complex were entered. And this isn't the problem of Wikipedia: google docs, which is one of the most advanced web-based gui systems I guess have plenty of usability problems, which only can be fixed by messing with the Source. And many core people want to mess with the source.
So, adding a newbie layer is okay as long as you don't mess up the work of the non-newbies.
g
On Thu, Sep 24, 2009 at 10:44 PM, Peter Gervai grinapo@gmail.com wrote:
Adding a gui layer to wikitext is always okay, as long as it's possible to get rid of, since majority of edits not coming from "new users", and losing flexibility for power users to get more newbies doesn't sound like a good deal to me.
There does seem to be a common presumption that "us old-timers" would switch off the WYSIWYG and get straight into the wikitext. Speaking for myself though, I'd love a good interface where I didn't feel compelled to do that. I hate the amount of time it takes just to find the point I want to edit. I'd love to be able to hide all the wikitext that I'm not right in the process of editing. I can't really picture such a beast yet, but hopefully someone else can.
Steve
On Thu, Sep 24, 2009 at 05:44, Peter Gervai grinapo@gmail.com wrote:
On Thu, Sep 24, 2009 at 14:36, David Gerard dgerard@gmail.com wrote:
However, impenetrable wikitext is one of *the* greatest barriers to new users on Wikimedia projects. And this impenetrability is not, in any way whatsoever or by any twists of logic, a feature.
Adding a gui layer to wikitext is always okay, as long as it's possible to get rid of, since majority of edits not coming from "new users", and losing flexibility for power users to get more newbies doesn't sound like a good deal to me.
At least all of the GUIs I've seen were slow and hard to use, and resulted unwanted (side) effects if something even barely complex were entered. And this isn't the problem of Wikipedia: google docs, which is one of the most advanced web-based gui systems I guess have plenty of usability problems, which only can be fixed by messing with the Source. And many core people want to mess with the source.
So, adding a newbie layer is okay as long as you don't mess up the work of the non-newbies.
I totally agree with this analysis, and that's what brought us to write MeanEditor. Unfortunately I don't have much time to work on it right now (it was part of a much bigger wiki project which never came to light), so it's just a prototype.
It would be valuable if someone with a lot of wiki experience could write a list of what can be considered "basic" wikitext. That is, syntax that newbies can be reasonably expected to understand and manipulate through a (visual) editor. My list is at http://www.mediawiki.org/wiki/Extension:MeanEditor#Details.
I also want to share a funny fact with you: we have a sandbox on which anyone can test the editor. For some reason, a _lot_ of people expect to be able to write HTML code in wikitext (maybe they are implementing a CMS and are used to HTML coding?). Some even write stuff like "<h2>heading</h2>" and then complain that the editor lets them enter the text (of course, it's valid wikitext after all), but not edit it afterwards (HTML-style headings do not show up in the TOC, an odd wikitext feature which we surely don't want newbies to use). It might be useful to have a list of these "common mistakes" and show a warning ("Do you really want a non-TOC heading? Use == heading == otherwise.").
I'm not sure if the Usability team is working on this. They ran a visual editor survey some time ago, but right now they are probably working on more urgent matters. -- Jacopo
On Thu, Sep 24, 2009 at 8:34 PM, Jacopo Corbetta jacopo.corbetta@gmail.com wrote:
(HTML-style headings do not show up in the TOC, an odd wikitext feature which we surely don't want newbies to use).
HTML-style headings do show up in the TOC, and have for a few years as far as I know.
Aryeh Gregor wrote:
On Thu, Sep 24, 2009 at 8:34 PM, Jacopo Corbetta jacopo.corbetta@gmail.com wrote:
(HTML-style headings do not show up in the TOC, an odd wikitext feature which we surely don't want newbies to use).
HTML-style headings do show up in the TOC, and have for a few years as far as I know.
HTML heading have changed status several times. Currently, they are shown in TOC, but don't have edit link.
On Thu, Sep 24, 2009 at 7:33 AM, Tisza Gergő gtisza@gmail.com wrote:
It is easy enough to edit for power users, who make the large majority of edits;
Retention of existing users is not a problem. We don't have to worry that a significant number of dedicated contributors will leave because of a switch to WYSIWYG. They are, by hypothesis, dedicated. On the other hand, new users being reluctant to contribute due to wikitext is a demonstrable and serious problem.
I also contest your implication that power users will uniformly or even mostly prefer wikitext to WYSIWYG. I'm a power user by any standard, but I use WYSIWYG wherever possible.
Last I heard, by the way, even now most actual *content* is added by occasional contributors. Power users may have more edits, but that doesn't mean they're the most important ones.
Of course, I should emphasize that ideally we should keep everyone happy. But making Wikipedia easier to edit for new users is *much* more important than making it easier for established editors. It will *always* be easier for established users to edit than new users, and established editors require a lot less coddling than new editors.
Wikis require a certain hacker mentality
- not in the technical sense, but a desire to understand things in depth.
No, they don't. One of the core principles of wikis is eliminating barriers to entry. Ten thousand people who each fix one typo a month are a tremendously valuable resource even if none of them ever contribute more. But many of them will -- *if* you can lure them into making those typo fixes to begin with. Which you can't, if they're scared off by the fixed-width text with random incomprehensible punctuation thrown in everywhere that has no obvious relationship to the article's actual content.
And then there is the ecosystem of bots, gadgets and other third-party tools which is based on wikitext, and not only would moving away from wikitext a huge maintenance burden, but again it would be replaced with something that is way less intuitive and actually harder to use (simple text operations are somewhat easier than fooling around with document trees).
Are you arguing here that it's easier for *bots* to edit wikitext than XML? Because that seems to be what you're saying, but I don't understand how that would make any sense. Wikitext is unparseable, bots have to resort to fragile regexes and hope they mostly work.
But replacing wikitext with some sort of internal representation that is unreadable for humans would be a huge mistake IMO.
It's not going to happen anytime soon in any case.
On Thu, Sep 24, 2009 at 7:27 AM, Aryeh Gregor Simetrical+wikilist@gmail.com wrote: <snip>
Last I heard, by the way, even now most actual *content* is added by occasional contributors. Power users may have more edits, but that doesn't mean they're the most important ones.
<snip>
It may depend on your definition of "occasional contributor" and "power user", but the way I tend to think about such distinctions would suggest your statement is false. I've never been able to do the analysis directly for enwiki, because it is too large and lacks appropriate dumps, but looking at other large Wikipedias suggests that as a rule of thumb about 70% of article content (measured by character count) comes from accounts with more than 1000 edits to articles. Only ~15% of content originates from people with 100 article edits or less. In practice, adding sentences, paragraphs, sections, and entirely new articles, is something that most people have to ease their way into. In addition, young editors who try to add large blocks of text too early in their career often find their content is reverted because of writing style or formatting problems. So, the creation of new blocks of content tends to be primarily accomplished by experienced editors.
You are right that the multitude of drive-by editors willing to do spell checking and make other small edits is a great resource, and should be encouraged. However, I would suggest that for the expansion and long-term development of Wikipedia it is the retention of existing power users and the development of new ones that is most important.
However, making it easier for people to first start editing should also ultimately lead to more potential power editors, so I think the goals are generally compatible. There is no reason why making it easier for newbies should ever be anything other than a net benefit to everyone.
-Robert Rohde
On Thu, Sep 24, 2009 at 11:20 AM, rarohde rarohde@gmail.com wrote:
It may depend on your definition of "occasional contributor" and "power user", but the way I tend to think about such distinctions would suggest your statement is false. I've never been able to do the analysis directly for enwiki, because it is too large and lacks appropriate dumps, but looking at other large Wikipedias suggests that as a rule of thumb about 70% of article content (measured by character count) comes from accounts with more than 1000 edits to articles. Only ~15% of content originates from people with 100 article edits or less.
Do these statistics take into account things like vandalism reversions? Also, how do they handle anonymous users -- are they summed up by edit count like anyone else? I distinctly remember seeing a study conclude that most of the actual content comes from users with few edits, but I can't recall where or how long ago (possibly two or three years).
Regardless, the point remains that heavy contributors only exist because they started out as new users. Just because you're a power user type of person doesn't mean you'll be less daunted by wikimarkup if you've never seen it before -- any barrier to entry is a problem. (Otherwise, why not require registration too? That's probably *easier* than understanding wikimarkup for most people.) And of course, a lot of contributors that Wikipedia would really like to encourage are people like academics in the humanities, say, who can't be expected to be particularly comfortable with computers. How much of the bias toward science and technology in Wikipedia is because of wikimarkup?
2009/9/24 Aryeh Gregor Simetrical+wikilist@gmail.com:
Do these statistics take into account things like vandalism reversions? Also, how do they handle anonymous users -- are they summed up by edit count like anyone else? I distinctly remember seeing a study conclude that most of the actual content comes from users with few edits, but I can't recall where or how long ago (possibly two or three years).
Aaron Swartz.
http://www.aaronsw.com/weblog/whowriteswikipedia
Most of the edits are done by a very small group of regulars.
But most of the actual text is contributed by drive-by contributors and then beaten into shape by the regulars.
- d.
On Thu, Sep 24, 2009 at 12:50 PM, David Gerard dgerard@gmail.com wrote:
2009/9/24 Aryeh Gregor Simetrical+wikilist@gmail.com:
Do these statistics take into account things like vandalism reversions? Also, how do they handle anonymous users -- are they summed up by edit count like anyone else? I distinctly remember seeing a study conclude that most of the actual content comes from users with few edits, but I can't recall where or how long ago (possibly two or three years).
Aaron Swartz.
http://www.aaronsw.com/weblog/whowriteswikipedia
Most of the edits are done by a very small group of regulars.
But most of the actual text is contributed by drive-by contributors and then beaten into shape by the regulars.
Yes, I have seen that too. My analysis, using a blame engine against a Wikipedia's full history, suggests that Aaron's thesis is simply not true in general. There could be any number of reasons he got a different result. For example he looked at only one article discussing a fairly well known person, which may not have been representative of the bulk of Wiki cotnent, or things may be different in English rather than say Russian (one of the wikis I used), or things may have changed since 2006. Whatever the reason, my conclusion is that the core, highly-active community (perhaps 25,000 accounts on a site the size of enwiki) contributes more than 50% of the currently displayed text.
To answer Aryeh, yes, I paid attention to handling vandalism reversions, and yes anons were tracked as if they were users.
I went into it expecting a result like that described in the blog post, and came out with the opposite conclusion.
-Robert Rohde
PS. A full write-up of this analysis has been on my to-do list for a while now.
2009/9/24 Robert Rohde rarohde@gmail.com:
I went into it expecting a result like that described in the blog post, and came out with the opposite conclusion. PS. A full write-up of this analysis has been on my to-do list for a while now.
If you could do it sooner rather than later, that would be of tremendous utility, because this would constitute a surprising result - Aaron's analysis is the current one. Aaron would be interested too, I'm quite sure!
- d.
Tisza Gergő wrote:
Aryeh Gregor <Simetrical+wikilist <at> gmail.com> writes:
Wikitext is not easy to edit.
It is easy enough to edit for power users, who make the large majority of edits;
And then there is the ecosystem of bots, gadgets and other third-party tools
One more thing: wikitext diffs are more easily viewable than XML or HTML diffs would be, especially after they would be mangled by a WYSIWYG editor.
On 9/23/09 4:54 PM, Robert Rohde wrote:
On Wed, Sep 23, 2009 at 4:37 PM, apri a.vd.wiela.vd.wiel@apri.nl wrote:
I like the XML way of resolving this problem but I think it MediaWiki has a bigger task to do. Restructure the wiki language, XML-ize the language completely. Forms and attributes will have a place in this WikiXML-definition. Pages can be constructed from one or more XML-sources. XML-source, or a transformed version of it, can be used on more than one page. 'Extensions' will be (sub)-elements of the standard MediaWiki definition. Recursive tasks can be done as long as the definition allows it. We are not depending on the MW-parser as is. Easier construction of editors. Use of XML-stylesheets for presentation. etc.
non-realistic? May be. In my vision the only way to make a real difference. If this is a first step towards structuring the language than I think its ok.
Wikis are supposed to be easy to edit. Maybe I am misunderstanding your intent, but XML-ize everything sounds like an approach that would make it much harder for novice editors to figure out what they are doing. XML tends to be verbose and complicated when edited by hand, and rather opaque for people who have no experience with it.
-Robert Rohde
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Indeed.
WikiText != XML on purpose.
- Trevor
On Thu, Sep 24, 2009 at 9:54 AM, Robert Rohde rarohde@gmail.com wrote:
Wikis are supposed to be easy to edit. Maybe I am misunderstanding your intent, but XML-ize everything sounds like an approach that would make it much harder for novice editors to figure out what they are doing. XML tends to be verbose and complicated when edited by hand, and rather opaque for people who have no experience with it.
I think the intention is that newbies will never even see the XML, let alone be expected to edit it. The XML defines the template, and tells MediaWiki how to construct the form that the user edits with. You would only need to edit the XML if you were modifying the template itself - hardly likely for a newbie.
Steve
* Steve Bennett stevagewp@gmail.com [Thu, 24 Sep 2009 14:18:17 +1000]:
On Thu, Sep 24, 2009 at 9:54 AM, Robert Rohde rarohde@gmail.com
wrote:
Wikis are supposed to be easy to edit. Maybe I am misunderstanding your intent, but XML-ize everything sounds like an approach that
would
make it much harder for novice editors to figure out what they are doing. XML tends to be verbose and complicated when edited by hand, and rather opaque for people who have no experience with it.
I think the intention is that newbies will never even see the XML, let alone be expected to edit it. The XML defines the template, and tells MediaWiki how to construct the form that the user edits with. You would only need to edit the XML if you were modifying the template itself - hardly likely for a newbie.
What if I need to add a simple table to the page? With wikitext that would take much less of keys to press than using html or xml. Even simple things, like headers, bolds, italics and images are shorter to define in wikitext. Dmitriy
Dmitriy Sintsov wrote:
- Steve Bennett stevagewp@gmail.com [Thu, 24 Sep 2009 14:18:17 +1000]:
On Thu, Sep 24, 2009 at 9:54 AM, Robert Rohde rarohde@gmail.com
wrote:
Wikis are supposed to be easy to edit. Maybe I am misunderstanding your intent, but XML-ize everything sounds like an approach that
would
make it much harder for novice editors to figure out what they are doing. XML tends to be verbose and complicated when edited by hand, and rather opaque for people who have no experience with it.
I think the intention is that newbies will never even see the XML, let alone be expected to edit it. The XML defines the template, and tells MediaWiki how to construct the form that the user edits with. You would only need to edit the XML if you were modifying the template itself - hardly likely for a newbie.
What if I need to add a simple table to the page? With wikitext that would take much less of keys to press than using html or xml. Even simple things, like headers, bolds, italics and images are shorter to define in wikitext.
I think the intention is that newbies will never even see the XML, let alone be expected to edit it. The XML defines the table, and tells MediaWiki how to construct the table editor that the user edits with.
Having said that, I don't see why would XML be necessary. Table and template markup are well structured and could be used by any editor just as XML would. Additionally, it is easier to observe diffs with wiki markup.
* Nikola Smolenski smolensk@eunet.rs [Thu, 24 Sep 2009 08:44:28 +0200]:
Having said that, I don't see why would XML be necessary. Table and template markup are well structured and could be used by any editor
just
as XML would. Additionally, it is easier to observe diffs with wiki markup.
So it would be menu and icon-driven editing, where the hands should move from keyboard to mouse and vice versa, like MS Word. Not very handy for programmers and people who prefer to do most of tasks in command line. But, the majority probably wants the WYSIWYG. It;s just with wikitext you may have both source text and WYSIWYG, with XML source text becomes a real pain.. Dmitriy
On Thu, Sep 24, 2009 at 5:31 PM, Dmitriy Sintsov questpc@rambler.ru wrote:
So it would be menu and icon-driven editing, where the hands should move from keyboard to mouse and vice versa, like MS Word. Not very handy for programmers and people who prefer to do most of tasks in command line.
I think you're making a large number of unjustified assumptions here. If you look at the proposal (and remember - it's a proposal), it says "it would be enabled by default for every user". Reading between the lines, that means you can disable it. Relax.
Steve
On Thu, Sep 24, 2009 at 3:31 AM, Dmitriy Sintsov questpc@rambler.ru wrote:
So it would be menu and icon-driven editing, where the hands should move from keyboard to mouse and vice versa, like MS Word. Not very handy for programmers and people who prefer to do most of tasks in command line.
Programmers rank far, far below normal people when it comes to usability prioritization. Programmers can use WYSIWYG just as well as anyone else, even if it's not as powerful as they'd like. FWIW, on forums I go to where I can use either BB code or WYSIWYG, I use WYSIWYG most of the time -- it's just more convenient. I only resort to BB code to work around deficiencies in the WYSIWYG editor.
Even for programmers, learning a new syntax is a significant issue. A few months ago I spoke to a programmer I know who tried editing Wikipedia a few times. He got lost in the wikitext. He knew he could figure out how to make the correction he wanted if he had to, but in practice, he just gave up without putting in the effort. It was too much of a barrier to entry to overcome his weak interest in fixing the error he saw.
As far as I'm concerned, a situation in which WYSIWYG is the only supported editing method would be far superior to the current situation. If we could allow power users to edit manually, that would be a nice bonus. Note that even if we use a format like XML that's a pain to manually edit, programmers can write up their own front-ends if they like -- they're programmers, after all! And also note that as with most WYSIWYG editors, there would presumably be a slew of keyboard shortcuts for power users to memorize if they didn't want to use the mouse.
2009/9/24 Aryeh Gregor Simetrical+wikilist@gmail.com:
On Thu, Sep 24, 2009 at 3:31 AM, Dmitriy Sintsov questpc@rambler.ru wrote:
So it would be menu and icon-driven editing, where the hands should move from keyboard to mouse and vice versa, like MS Word. Not very handy for programmers and people who prefer to do most of tasks in command line.
Programmers rank far, far below normal people when it comes to usability prioritization.
Indeed, as do robot editors. This is part of the "no way, not even with logic twisting, is the impenetrability of wikitext a feature."
As far as I'm concerned, a situation in which WYSIWYG is the only supported editing method would be far superior to the current situation. If we could allow power users to edit manually, that would be a nice bonus. Note that even if we use a format like XML that's a pain to manually edit, programmers can write up their own front-ends if they like -- they're programmers, after all! And also note that as with most WYSIWYG editors, there would presumably be a slew of keyboard shortcuts for power users to memorize if they didn't want to use the mouse.
Realistically, Tim has already stated we're not throwing out wikitext because of the huge body of text already in it. WYSIWYG editing is getting there bit by bit - FCKeditor would be fine on a fresh wiki without the unspeakable atrocities inventive geeks have perpetrated upon wikitext on en:wp and should continue to get better at dealing with more obtusities.
- d.
On Thu, Sep 24, 2009 at 10:48 AM, dgerard dgerard@gmail.com wrote:
Realistically, Tim has already stated we're not throwing out wikitext because of the huge body of text already in it.
Not in the foreseeable future, but maybe someday. We'd just need a very careful and thorough migration plan.
WYSIWYG editing is getting there bit by bit - FCKeditor would be fine on a fresh wiki without the unspeakable atrocities inventive geeks have perpetrated upon wikitext on en:wp and should continue to get better at dealing with more obtusities.
Funnily enough, I just talked to a user in #mediawiki asking why FCKeditor didn't work right on his wiki when copy-pasting from MS Word.
2009/9/24 Aryeh Gregor Simetrical+wikilist@gmail.com:
On Thu, Sep 24, 2009 at 10:48 AM, dgerard dgerard@gmail.com wrote:
WYSIWYG editing is getting there bit by bit - FCKeditor would be fine on a fresh wiki without the unspeakable atrocities inventive geeks have perpetrated upon wikitext on en:wp and should continue to get better at dealing with more obtusities.
Funnily enough, I just talked to a user in #mediawiki asking why FCKeditor didn't work right on his wiki when copy-pasting from MS Word.
*facepalm* And then there's the obvious things users will do that I hadn't thought of, yes.
- d.
David Gerard wrote:
2009/9/24 Aryeh Gregor Simetrical+wikilist@gmail.com:
On Thu, Sep 24, 2009 at 10:48 AM, dgerard dgerard@gmail.com wrote:
WYSIWYG editing is getting there bit by bit - FCKeditor would be fine on a fresh wiki without the unspeakable atrocities inventive geeks have perpetrated upon wikitext on en:wp and should continue to get better at dealing with more obtusities.
Funnily enough, I just talked to a user in #mediawiki asking why FCKeditor didn't work right on his wiki when copy-pasting from MS Word.
*facepalm* And then there's the obvious things users will do that I hadn't thought of, yes.
- d.
I had a user who copied an article from the html of Wikipedia (no edit button) into Wikia's RTE.
The real disturbing part is unlike when people copy Wikipedia's html into the edit box where it results in tell tale ?'s (Anime related articles, 99.99% of articles copied in my case will be using the nihongo template) and various other patterns, something copied html to rte looks almost perfectly fine when looking at it, up till you hit the edit button and see the mangled source.
T_T RTE makes it easier for inexperienced people to do stupid things.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
On Tue, Sep 29, 2009 at 5:55 AM, Daniel Friesen lists@nadir-seen-fire.com wrote:
I had a user who copied an article from the html of Wikipedia (no edit button) into Wikia's RTE.
Theoretically that use case could be supported, right? If there were enough id's in the HTML source, then we could map back onto the underlying wikitext and paste that in instead. Difficult though...
OTOH, it might be easier to detect when this is happening and warn the user.
Steve
* dgerard dgerard@gmail.com [Thu, 24 Sep 2009 15:48:16 +0100]:
Realistically, Tim has already stated we're not throwing out wikitext because of the huge body of text already in it. WYSIWYG editing is getting there bit by bit - FCKeditor would be fine on a fresh wiki without the unspeakable atrocities inventive geeks have perpetrated upon wikitext on en:wp and should continue to get better at dealing with more obtusities.
It should be possible to have wikitext and XML in parallel, even mixed - there are already parser tags for extensions and I remember Robert Rohde wrote they can be patched to work recursively. Dmitriy
On Thu, Sep 24, 2009 at 8:48 AM, dgerard dgerard@gmail.com wrote:
2009/9/24 Aryeh Gregor <Simetrical+wikilist@gmail.comSimetrical%2Bwikilist@gmail.com
: On Thu, Sep 24, 2009 at 3:31 AM, Dmitriy Sintsov questpc@rambler.ru
wrote:
So it would be menu and icon-driven editing, where the hands should move from keyboard to mouse and vice versa, like MS Word. Not very handy for programmers and people who prefer to do most of tasks in command line.
Programmers rank far, far below normal people when it comes to usability prioritization.
Indeed, as do robot editors. This is part of the "no way, not even with logic twisting, is the impenetrability of wikitext a feature."
As far as I'm concerned, a situation in which WYSIWYG is the only supported editing method would be far superior to the current situation. If we could allow power users to edit manually, that would be a nice bonus. Note that even if we use a format like XML that's a pain to manually edit, programmers can write up their own front-ends if they like -- they're programmers, after all! And also note that as with most WYSIWYG editors, there would presumably be a slew of keyboard shortcuts for power users to memorize if they didn't want to use the mouse.
Realistically, Tim has already stated we're not throwing out wikitext because of the huge body of text already in it. WYSIWYG editing is getting there bit by bit - FCKeditor would be fine on a fresh wiki without the unspeakable atrocities inventive geeks have perpetrated upon wikitext on en:wp and should continue to get better at dealing with more obtusities.
- d.
This round the Usability Initiative got 800,000 dollars. That's a load of money. If the Foundation decides that it wants to fix the problem the correct way then it can. And it can start at any time! We just need to agree on a solution.
We can't fix the problem by looking backwards at the wikitext that has already been produced along with the language definition (5,000 lines of parser code) and saying that the problem is simply intractable. In fact, the problem does not depend in any way on the quantity of wikitext that has been produced - it only depends on an understanding (if not a definition) of the language as it currently exists. Hard work but not, at all, impossible.
It doesn't seem productive to me to start by looking at the problem from that looking-backwards angle of "oh my god there is so much wikitext written in this language that isn't even defined". It would be more productive to first decide what we would like to see. For example:
* wikitext parsing would be much faster if the language was well defined and we could use flex/bison/etc... * usability would be greatly enhanced if all wikitext was easy to understand, even for newcomers. this includes a clear breakdown of the problem of including/querying remote resources and a clean solution to that problem (unlike templates) * if the language is well defined, then we can have a wysywig editor whose behavior is well defined * if the language is well defined, we can have multiple fully compatible parser implementations, for example, flex/bison, php, python and importantly, javascript.
After we have together designed and implemented the new solution we could start work on the isomorphic mapping between old school wikitext and new school wikitext. Or they can happen in parallel. It certainly doesn't seem helpful to our movement to settle on the existing solution, which has so many flaws, when we can easily imagine so many other solutions which are clearly better.
On Thu, Sep 24, 2009 at 4:03 PM, Brian Brian.Mingus@colorado.edu wrote:
This round the Usability Initiative got 800,000 dollars. That's a load of money. If the Foundation decides that it wants to fix the problem the correct way then it can. And it can start at any time! We just need to agree on a solution.
Only at the expense of sacrificing some, most, or all of the work they're already doing. $800,000 is not a particularly large sum for a programming project, and the usability project had to prioritize it. They decided to target things other than WYSIWYG first. I'd be inclined to think that's wise, without having considered the issue very deeply. Full WYSIWYG *is* really needed, but it would be unjustifiably expensive when there are so many more minor improvements that could be (and are being) made much more easily.
On Thu, Sep 24, 2009 at 2:22 PM, Aryeh Gregor <Simetrical+wikilist@gmail.comSimetrical%2Bwikilist@gmail.com
wrote:
On Thu, Sep 24, 2009 at 4:03 PM, Brian Brian.Mingus@colorado.edu wrote:
This round the Usability Initiative got 800,000 dollars. That's a load of money. If the Foundation decides that it wants to fix the problem the correct way then it can. And it can start at any time! We just need to
agree
on a solution.
Only at the expense of sacrificing some, most, or all of the work they're already doing. $800,000 is not a particularly large sum for a programming project, and the usability project had to prioritize it. They decided to target things other than WYSIWYG first. I'd be inclined to think that's wise, without having considered the issue very deeply. Full WYSIWYG *is* really needed, but it would be unjustifiably expensive when there are so many more minor improvements that could be (and are being) made much more easily.
I definitely think it's a good idea to go after the low hanging fruit first, which it sounds like is what they are doing with this 800k. Fixing the core of the problem is definitely not low hanging fruit - it's hard work. On the other hand, the foundation just got a couple million in unrestricted funds, and when I say that they can start fixing the problem at any time, I mean they can seek out an additional grant if necessary for this specific issue. Basically what I am saying is that I don't jive with the perspective that we should accept wikitext as it is and hack in new "fixes" on top of it. I would like to see the foundation go out and try to fix this problem the correct way, starting nowish.
On Thu, Sep 24, 2009 at 4:28 PM, Brian Brian.Mingus@colorado.edu wrote:
I definitely think it's a good idea to go after the low hanging fruit first, which it sounds like is what they are doing with this 800k. Fixing the core of the problem is definitely not low hanging fruit - it's hard work. On the other hand, the foundation just got a couple million in unrestricted funds, and when I say that they can start fixing the problem at any time, I mean they can seek out an additional grant if necessary for this specific issue. Basically what I am saying is that I don't jive with the perspective that we should accept wikitext as it is and hack in new "fixes" on top of it. I would like to see the foundation go out and try to fix this problem the correct way, starting nowish.
They could do that. I wouldn't be surprised if they start serious WYSIWYG work in a year or two. But there are a *lot* of things on Wikipedia that could be improved. Even with the big grants Wikimedia's now getting, it operates on a budget less than 0.1% that of some comparably large websites (like Google).
Right now I hope we're going to focus on getting more full-time experienced programmers, like hiring a CTO and letting Brion become only senior software architect. We have lots of junior people doing work, but code review is still a huge bottleneck AFAICT. Just look at the current discussion on JS2, for instance, or the outages caused by performance problems that weren't caught before deployment.
On Thu, Sep 24, 2009 at 2:38 PM, Aryeh Gregor <Simetrical+wikilist@gmail.comSimetrical%2Bwikilist@gmail.com
wrote:
On Thu, Sep 24, 2009 at 4:28 PM, Brian Brian.Mingus@colorado.edu wrote:
I definitely think it's a good idea to go after the low hanging fruit
first,
which it sounds like is what they are doing with this 800k. Fixing the
core
of the problem is definitely not low hanging fruit - it's hard work. On
the
other hand, the foundation just got a couple million in unrestricted
funds,
and when I say that they can start fixing the problem at any time, I mean they can seek out an additional grant if necessary for this specific
issue.
Basically what I am saying is that I don't jive with the perspective that
we
should accept wikitext as it is and hack in new "fixes" on top of it. I would like to see the foundation go out and try to fix this problem the correct way, starting nowish.
They could do that. I wouldn't be surprised if they start serious WYSIWYG work in a year or two. But there are a *lot* of things on Wikipedia that could be improved. Even with the big grants Wikimedia's now getting, it operates on a budget less than 0.1% that of some comparably large websites (like Google).
Right now I hope we're going to focus on getting more full-time experienced programmers, like hiring a CTO and letting Brion become only senior software architect. We have lots of junior people doing work, but code review is still a huge bottleneck AFAICT. Just look at the current discussion on JS2, for instance, or the outages caused by performance problems that weren't caught before deployment.
Working through the current backlog of bugs definitely counts as low hanging fruit so I definitely agree that there should be more hackers on hand at the foundation and a CTO to guide them. On the other hand, given the admitted size of the wysiwyg problem and the large number of existing smaller problems it doesn't seem wise to to try and shoehorn it into the current usability initiative if we all agree that they already have their work cut out for them. The solution we come up with, for example this xml proposal for templates, could in practice end up being counter to our long term goals to standardize wikitext. It could quickly propagate throughout the wikisphere and not only will we have to deal with templates and parser functions, but now an entire form language. I think something much simpler and cleaner than all of that is desirable.
Brian wrote:
This round the Usability Initiative got 800,000 dollars. That's a load of money. If the Foundation decides that it wants to fix the problem the correct way then it can. And it can start at any time! We just need to agree on a solution.
We can't fix the problem by looking backwards at the wikitext that has already been produced along with the language definition (5,000 lines of parser code) and saying that the problem is simply intractable. In fact, the problem does not depend in any way on the quantity of wikitext that has been produced - it only depends on an understanding (if not a definition) of the language as it currently exists. Hard work but not, at all, impossible.
...
- wikitext parsing would be much faster if the language was well defined and
we could use flex/bison/etc...
Have you read the archives? It has been tried. Several times. There's even a mailing list for that.
Getting a formal definition of ~90% of the wikitext syntax is easy. The other 10% drived nuts everyone trying to do it hard enough, so far.
Keep trying, but build over what's already done.
2009/9/24 Platonides Platonides@gmail.com:
Brian wrote:
- wikitext parsing would be much faster if the language was well defined and
we could use flex/bison/etc...
Have you read the archives? It has been tried. Several times. There's even a mailing list for that. Getting a formal definition of ~90% of the wikitext syntax is easy. The other 10% drived nuts everyone trying to do it hard enough, so far. Keep trying, but build over what's already done.
I suspect it'll be approached from the other end: FCKeditor will be improved until it can do quite a lot of the stuff, and there'll eventually be sufficiently little remaining that it can be bot-converted to a form FCKeditor can handle.
At which point we formalise that and away we go with third-party parsers galore!
Well, I can dream.
- d.
"David Gerard" dgerard@gmail.com wrote in message news:fbad4e140909241512h5c56dd09xe6d3d7de0603f968@mail.gmail.com...
2009/9/24 Platonides Platonides@gmail.com:
Brian wrote:
- wikitext parsing would be much faster if the language was well defined
and we could use flex/bison/etc...
Have you read the archives? It has been tried. Several times. There's even a mailing list for that. Getting a formal definition of ~90% of the wikitext syntax is easy. The other 10% drived nuts everyone trying to do it hard enough, so far. Keep trying, but build over what's already done.
The 10% drove people off cliffs because it is, pretty much by definition, the horrible unexpected behaviour that is a *consequence* of not having a formal definition. Writing a formal definition is not impossible if you require that it be sensible at the final reading. The parser is, in many places, *not* sensible, and naturally those quirks are difficult to describe, but they're also undesirable overall. A true move to a formal language definition involves action from both ends: writing a formal definition that follows the current parser in general, *and* being prepared to alter the parser to remove some of the more egregious deviations from expected behaviour.
--HM
On Thu, Sep 24, 2009 at 4:05 PM, Platonides Platonides@gmail.com wrote:
Brian wrote:
This round the Usability Initiative got 800,000 dollars. That's a load of money. If the Foundation decides that it wants to fix the problem the correct way then it can. And it can start at any time! We just need to
agree
on a solution.
We can't fix the problem by looking backwards at the wikitext that has already been produced along with the language definition (5,000 lines of parser code) and saying that the problem is simply intractable. In fact,
the
problem does not depend in any way on the quantity of wikitext that has
been
produced - it only depends on an understanding (if not a definition) of
the
language as it currently exists. Hard work but not, at all, impossible.
...
- wikitext parsing would be much faster if the language was well defined
and
we could use flex/bison/etc...
Have you read the archives? It has been tried. Several times. There's even a mailing list for that.
Getting a formal definition of ~90% of the wikitext syntax is easy. The other 10% drived nuts everyone trying to do it hard enough, so far.
Keep trying, but build over what's already done.
Platonides, if you had read the archives you would know that I am very familiar with previous work done on creating formal grammars for wikitext, and that I know it would take a redesign of certain parts of the language. Of course, this information is embedded in the very text you quote.
On Fri, Sep 25, 2009 at 8:05 AM, Platonides Platonides@gmail.com wrote:
Getting a formal definition of ~90% of the wikitext syntax is easy. The other 10% drived nuts everyone trying to do it hard enough, so far.
I wouldn't put it quite like that. Yes, the problem gets harder as you get nearer the end - but it also doesn't matter, because you're dealing with rare examples. There are also parts of the language best not dealt with this way. For example, there's not much point attempting to parse template transclusions like this, because there will always have to be a pre-processor that handles them.
What actually really drove me mad was ANTLR - it wasn't stable, and the effort in turning a language file into a working Java program that I could play with was a lot greater than I expected. And I discovered the usual problem with declarative languages - that small changes in one place can have huge impacts in others.
I would definitely like to take up the challenge again sometime. I've sort of been waiting for ANTLR to become more stable. And we'd need some kind of plan of what to do with the language spec file, like whether to actually build a parser off it or whatever.
Steve
* Aryeh Gregor Simetrical+wikilist@gmail.com [Thu, 24 Sep 2009 09:57:27 -0400]:
Programmers rank far, far below normal people when it comes to usability prioritization. Programmers can use WYSIWYG just as well as anyone else, even if it's not as powerful as they'd like. FWIW, on forums I go to where I can use either BB code or WYSIWYG, I use WYSIWYG most of the time -- it's just more convenient. I only resort to BB code to work around deficiencies in the WYSIWYG editor.
I prefer to use BB code and rarely use forum icons. That's a matter of personal choice.
Even for programmers, learning a new syntax is a significant issue. A few months ago I spoke to a programmer I know who tried editing Wikipedia a few times. He got lost in the wikitext.
The only really complex part of wikitext are the templates - nested, sometimes really weird subst and so on. I remember reading "Advanced Templates" at meta and have the feeling I am reading something really cryptic - I am still not good at making complex templates. Tables, links, text formatting, images are easy to me (there were great guides like "Advanced tables" at meta back in v1.9.3..v1.10 when I've started to use MediaWiki). Of course it doesn't matter, because I am hardly a representative.
He knew he could figure out how to make the correction he wanted if he had to, but in practice, he just gave up without putting in the effort. It was too much of a barrier to entry to overcome his weak interest in fixing the error he saw.
Only the complex template I can think of reason.
As far as I'm concerned, a situation in which WYSIWYG is the only supported editing method would be far superior to the current situation. If we could allow power users to edit manually, that would be a nice bonus. Note that even if we use a format like XML that's a pain to manually edit, programmers can write up their own front-ends if they like -- they're programmers, after all! And also note that as with most WYSIWYG editors, there would presumably be a slew of keyboard shortcuts for power users to memorize if they didn't want to use the mouse.
Maybe it should be possible to store everything in XML and "map" XML to wikitext on the fly for these who like wikitext, and also to make future core compatible with old bots. Eg. {| will be stored internally as wmf:table. Dmitriy
On Thu, Sep 24, 2009 at 12:47 PM, Dmitriy Sintsov questpc@rambler.ru wrote:
The only really complex part of wikitext are the templates - nested, sometimes really weird subst and so on.
Templates and refs are by far the worst offenders, for sticking tons of content in the page that doesn't have any obvious relationship to the actual content. Getting rid of them would be a huge step forward. But stuff like '''bold''' and ==headings== are also a real problem. Everything unexpected like that is going to increase the risk that a new user will get worried he doesn't know what he's doing, and give up rather than risk breaking something or put effort into figuring out what to do. If you give *anyone*[1] a WYSIWYG interface, they'll know how it works, because they're used to it from Word and whatnot. That's just not true of wikitext, no matter how simple it is once you *already* understand it.
[1] Yes, yes, I mean anyone who uses computers much at all, not farmers in rural Africa or my maternal grandmother.
* Aryeh Gregor Simetrical+wikilist@gmail.com [Thu, 24 Sep 2009 15:40:46 -0400]:
Templates and refs are by far the worst offenders, for sticking tons of content in the page that doesn't have any obvious relationship to the actual content. Getting rid of them would be a huge step forward. But stuff like '''bold''' and ==headings== are also a real problem.
What's complex in '''bold''' and ==headings== ? Here when we've installed the wiki for local "historical records" at the local Russian university the humanitarians got to understand such things really quickly. The Ms or PhD in History cannot be that much stupid.. To me it looks like you are overstating the complexity of the wikitext. But yes, they are calling technical staff for complex cases, but it happens _rarely_. Historical records are mostly just plain text with links and occasional pictures.
Everything unexpected like that is going to increase the risk that a new user will get worried he doesn't know what he's doing, and give up rather than risk breaking something or put effort into figuring out what to do. If you give *anyone*[1] a WYSIWYG interface, they'll know how it works, because they're used to it from Word and whatnot. That's just not true of wikitext, no matter how simple it is once you *already* understand it.
Maybe, but it would be nice if source wikitext will remain as aliernative. Anyway, you're the head developers, it's upon you. Dmitriy
On Fri, Sep 25, 2009 at 4:00 PM, Dmitriy Sintsov questpc@rambler.ru wrote:
What's complex in '''bold''' and ==headings== ? Here when we've
It *looks* complex. That's pretty much most of the problem. Here's our desired use case:
1) User views a page that is deficient in some way. 2) User decides to edit. 3) User edits. 4) User has improved the world.
Here's our actual use case. 1) User views a page that is deficient in some way. 2) User has no idea they can edit.
Ok, moving on... 2) User decides to edit. 3) User sees wikitext. 4) User runs screaming.
The Ms or PhD in History cannot be that much stupid.
We're not in a position to offer training to our potential end users.
Steve
* Steve Bennett stevagewp@gmail.com [Fri, 25 Sep 2009 16:13:51 +1000]:
On Fri, Sep 25, 2009 at 4:00 PM, Dmitriy Sintsov questpc@rambler.ru wrote:
What's complex in '''bold''' and ==headings== ? Here when we've
It *looks* complex. That's pretty much most of the problem. Here's our desired use case:
You haven't convinced me. I am not the most bright person in the world (my coding skills aren't top - I am more of humanitarian brain person actually) but it was really easy to me to understand basics of wikitext. Just in few minutes. Also, such repeated single markup characters are faster to type than choosing formatting with GUI. I like wikitext.
Anyway, the displays have a large resolution nowadays. What about splitting edit page in two areas? One for entering wikitext with syntax highlighting and another one - an AJAX generated on-the-fly preview how would it looks like after the save. Such way, the learning curve would be much lower.
But I probably will stop arguing, because my opinion is hardly representative. Dmitriy
2009/9/25 Dmitriy Sintsov questpc@rambler.ru:
You haven't convinced me. I am not the most bright person in the world (my coding skills aren't top - I am more of humanitarian brain person actually) but it was really easy to me to understand basics of wikitext. Just in few minutes. Also, such repeated single markup characters are faster to type than choosing formatting with GUI. I like wikitext.
At this point in the discussion, I'm thankful you're not the person who needs to be convinced.
- d.
-----Original Message----- From: wikitech-l-bounces@lists.wikimedia.org [mailto:wikitech-l-bounces@lists.wikimedia.org] On Behalf Of Dmitriy Sintsov Sent: 25 September 2009 07:01 To: Wikimedia developers Subject: Re: [Wikitech-l] Proposal for editing template calls within pages
- Aryeh Gregor Simetrical+wikilist@gmail.com [Thu, 24 Sep 2009
15:40:46 -0400]:
Templates and refs are by far the worst offenders, for
sticking tons
of content in the page that doesn't have any obvious
relationship to
the actual content. Getting rid of them would be a huge
step forward.
But stuff like '''bold''' and ==headings== are also a real
problem.
What's complex in '''bold''' and ==headings== ? Here when we've installed the wiki for local "historical records" at the local Russian university the humanitarians got to understand such things really quickly. The Ms or PhD in History cannot be that much stupid.. To me it looks like you are overstating the complexity of the wikitext. But yes, they are calling technical staff for complex cases, but it happens _rarely_. Historical records are mostly just plain text with links and occasional pictures.
The problem is the ambiguity with italics, (''italics''). So the current parser doesn't really make its final decision on what should be bold or what should be italic until it hits a newline. If there are an even number of both bold and italics then it assumes it interpreted the line correctly.
However if there is an uneven number of bold & italic, it starts searching for where it could have misinterpreted something.
I think this is part of what makes wikitext undescribable in a formal grammar.
Jared
* Jared Williams jared.williams1@ntlworld.com [Fri, 25 Sep 2009 10:49:54 +0100]:
The problem is the ambiguity with italics, (''italics''). So the current parser doesn't really make its final decision on what should be bold or what should be italic until it hits a newline. If there are an even number of both bold and italics then it assumes it interpreted the line correctly.
However if there is an uneven number of bold & italic, it starts searching for where it could have misinterpreted something.
Shouldn't these cases be considered a syntax error? How much is common to wikipedia to have uneven numbers of occurences of that? Is there any use for that (weird templates)?
I think this is part of what makes wikitext undescribable in a formal grammar.
Jared
Let's assume an odd occurence of ''' will be converted to wmf:bold and an even occurence ''' to </wmf:bold> (begin/end of the node)? Non-paired occurence will simply cause XML parsing error - there should not be uneven number of '' or '''. Dmitriy
2009/9/25 Dmitriy Sintsov questpc@rambler.ru:
Let's assume an odd occurence of ''' will be converted to wmf:bold and an even occurence ''' to </wmf:bold> (begin/end of the node)? Non-paired occurence will simply cause XML parsing error - there should not be uneven number of '' or '''.
The point is that wikitext doesn't *have* parsing errors. The parser is very tolerant in that it tries to resolve 'invalid' and ambiguous constructs by some combination of guessing what was probably intended and trying not to mess up the rest of the article (the newline thing mentioned earlier fall in the latter category). I agree that this probably causes the weird quirks that make wikitext such a horribly complex language to define and parse, so I think a good way to continue this discussion would be to talk about how invalid, ambiguous and otherwise unexpected input should be handled.
Roan Kattouw (Catrope)
2009/9/25 Roan Kattouw roan.kattouw@gmail.com:
The point is that wikitext doesn't *have* parsing errors. The parser is very tolerant in that it tries to resolve 'invalid' and ambiguous constructs by some combination of guessing what was probably intended and trying not to mess up the rest of the article (the newline thing mentioned earlier fall in the latter category). I agree that this probably causes the weird quirks that make wikitext such a horribly complex language to define and parse, so I think a good way to continue this discussion would be to talk about how invalid, ambiguous and otherwise unexpected input should be handled.
In past discussions I have noted that "tag soup" is a *feature* of human languages, not a bug.
HTML was constructed as a computer markup language for humans. Unfortunately, the humans in question were nuclear physicists; lesser beings couldn't handle it.
Note how HTML5 now defines how to handle "bad" syntax, in recognition of the fact that humans write tag soup.
Wikitext spitting errors would be a bug in wikitext, not a feature.
- d.
* David Gerard dgerard@gmail.com [Fri, 25 Sep 2009 11:59:04 +0100]:
2009/9/25 Roan Kattouw roan.kattouw@gmail.com:
In past discussions I have noted that "tag soup" is a *feature* of human languages, not a bug.
HTML was constructed as a computer markup language for humans. Unfortunately, the humans in question were nuclear physicists; lesser beings couldn't handle it.
Note how HTML5 now defines how to handle "bad" syntax, in recognition of the fact that humans write tag soup.
Wikitext spitting errors would be a bug in wikitext, not a feature.
XML is used to store "human-produced" rich formatted text by many standalone and web apps. XML parsers are also very strict and spitting errors. As it's been mentioned recently, XML is really good for bots, too, for that reason (the input is "error-free" tree). I wonder, If the browsers can handle tag soup, most probably MediaWiki parser can handle wikitext soup, too? Eg, instead of parsing error, properly close the nodes. The existing wikitext of millions of articles has to be converted by commandline upgrade script in case the wikitext will be abandoned. Though I wonder whether it's possible to keep wikitext editing mode for backwards compatibility by using the same method online. Dmitriy
2009/9/25 Dmitriy Sintsov questpc@rambler.ru:
XML is used to store "human-produced" rich formatted text by many standalone and web apps. XML parsers are also very strict and spitting errors. As it's been mentioned recently, XML is really good for bots, too, for that reason (the input is "error-free" tree). I wonder, If the browsers can handle tag soup, most probably MediaWiki parser can handle wikitext soup, too? Eg, instead of parsing error, properly close the nodes. The existing wikitext of millions of articles has to be converted by commandline upgrade script in case the wikitext will be abandoned. Though I wonder whether it's possible to keep wikitext editing mode for backwards compatibility by using the same method online.
Wikitext started as a shorthand for HTML. The horrible things that have happened since then are from ad-hoc additions to a parser and no formal spec, leaving the parser behaviour as, literally, the only definition.
- d.
-----Original Message----- From: wikitech-l-bounces@lists.wikimedia.org [mailto:wikitech-l-bounces@lists.wikimedia.org] On Behalf Of Dmitriy Sintsov Sent: 25 September 2009 11:09 To: Wikimedia developers Subject: Re: [Wikitech-l] Proposal for editing template calls within pages
- Jared Williams jared.williams1@ntlworld.com [Fri, 25 Sep 2009
10:49:54 +0100]:
The problem is the ambiguity with italics, (''italics''). So the current parser doesn't really make its final decision on
what should
be bold or what should be italic until it hits a newline.
If there are
an even number of both bold and italics then it assumes it
interpreted
the line correctly.
However if there is an uneven number of bold & italic, it starts searching for where it could have misinterpreted something.
Shouldn't these cases be considered a syntax error? How much is common to wikipedia to have uneven numbers of occurences of that? Is there any use for that (weird templates)?
I think this is part of what makes wikitext undescribable
in a formal
grammar.
Jared
Let's assume an odd occurence of ''' will be converted to wmf:bold and an even occurence ''' to </wmf:bold> (begin/end of the node)? Non-paired occurence will simply cause XML parsing error - there should not be uneven number of '' or '''. Dmitriy
Problem is quotes are also valid as part of the textual content, so could not italics immediately before or after an apostrophe. As in
L'''arc de triomphe''
Which the current parser resolves to L'<i>arc de triomphe</i>
Jared
Jared Williams wrote:
Problem is quotes are also valid as part of the textual content, so could not italics immediately before or after an apostrophe. As in
L'''arc de triomphe''
Which the current parser resolves to L'<i>arc de triomphe</i>
What I am going to say is going to be the worst heresy, but could this problem be solved by gradually migrating to a new wiki markup, for example **bold** and //italic//? This markup is more logical and easier to remember, more used outside of MediaWiki (unofficial email markup is similar) and more easily visible than apostrophe markup, and I never understood how the apostrophes came to be in the first place. The most important for this discussion - it also has much less potential to confuse the parser.
Nikola Smolenski <smolensk <at> eunet.rs> writes:
What I am going to say is going to be the worst heresy, but could this problem be solved by gradually migrating to a new wiki markup, for example **bold** and //italic//? This markup is more logical and easier to remember, more used outside of MediaWiki (unofficial email markup is similar) and more easily visible than apostrophe markup, and I never understood how the apostrophes came to be in the first place. The most important for this discussion - it also has much less potential to confuse the parser.
You avoid a lot of pain if the opening and closing markup is different. That is IMHO the other big problem besides reusing the same characters in ''/''' and {{/{{{.
Jared Williams wrote:
The problem is the ambiguity with italics, (''italics''). So the current parser doesn't really make its final decision on what should be bold or what should be italic until it hits a newline. If there are an even number of both bold and italics then it assumes it interpreted the line correctly.
[SNIP]
I think this is part of what makes wikitext undescribable in a formal grammar.
And he also wrote:
Problem is quotes are also valid as part of the textual content, so could not italics immediately before or after an apostrophe. As in
L'''arc de triomphe''
Which the current parser resolves to L'<i>arc de triomphe</i>
There lies one of the main problems with parsing wikitext - that it uses a wide range of standard text characters to implement it's markup. In HTML, there are basically two (< and >) plus an escape character (&). Therefore HTML can in theory[1] consist of "Any text you like, with <, > and & replaced by < > and & respectively" with two special markup symbols (<markup goes here> and &escaped_entity;). No room for ambiguity there, and only minimal translation required to convert plain-text to a format suitable for use in an HTML document.
In MediaWiki, just taking that single ' character as an example, it could be one of several punctuation symbols (apostrophe, single-quote, prime, etc.) or it could be part of an opening italic tag, a closing italic tag, an opening bold tag, or a closing bold tag. As far as I understand, it is impossible to deal effectively with this massive overloading of the apostrophe character without the kind of special logic we have in place already (as described by Jared). To take his example one step further, here's something to really throw a formal grammar-based parser, but which our parser handles just fine: '''Photo of L'''arc de triomphe'' by 'John''''
- Mark Clements (HappyDog)
[1] I'm ignoring all the document-structure requirements, plus character-encoding issues, etc. that complicate things a bit.
2009/9/24 Dmitriy Sintsov questpc@rambler.ru:
The only really complex part of wikitext are the templates - nested, sometimes really weird subst and so on. I remember reading "Advanced Templates" at meta and have the feeling I am reading something really cryptic - I am still not good at making complex templates. Tables, links, text formatting, images are easy to me (there were great guides like "Advanced tables" at meta back in v1.9.3..v1.10 when I've started to use MediaWiki). Of course it doesn't matter, because I am hardly a representative.
Indeed. I can only recommend that you spend more time with people who can't work computers very well. We also need as editors people who are experts in things that you are a dunce in but who are dunces in the computers that you are an expert in. There's a lot more people who can't work computers very well than who can.
- d.
On Thu, Sep 24, 2009 at 4:44 PM, Nikola Smolenski smolensk@eunet.rs wrote:
Having said that, I don't see why would XML be necessary. Table and template markup are well structured and could be used by any editor just as XML would. Additionally, it is easier to observe diffs with wiki markup.
Is it possible, currently, to define the types of parameters to functions? Can you include hints in them about what the parameter is for? Can you specify maximum lengths, or choose from a small number of choices?
Steve
Steve Bennett wrote:
On Thu, Sep 24, 2009 at 4:44 PM, Nikola Smolenski smolensk@eunet.rs wrote:
Having said that, I don't see why would XML be necessary. Table and template markup are well structured and could be used by any editor just as XML would. Additionally, it is easier to observe diffs with wiki markup.
Is it possible, currently, to define the types of parameters to functions? Can you include hints in them about what the parameter is for? Can you specify maximum lengths, or choose from a small number of choices?
It seems that we are talking about two different things here:
1) What would be the markup of template description pages, that will be used to make template editing forms.
2) What would be the markup of a template call, that will be used in the source of article pages to make actual template call.
Given that #1 is an entirely new thing, it can have an entirely new markup. I see no reason for it not to be XML. #2 however should be kept as is.
Hi,
Just to clarify a few things:
- yes, it's important to distinguish between the editing of templates and the editing of template calls. Most people understand that distinction, but just to clarify, this project would allow for editing of template *calls*; while template pages themselves would just get extended with a new XML file.
- yes, users could opt out of it and stick with standard wiki-text editing.
- I don't think there's any support for replacing wiki-text with XML, by the way.
- there's no way currently within templates to specify the "type" of a parameter (that is, whether it's a string, date, enumeration, etc.), descriptions of parameters, etc.; that's why something like the XML subpage is needed. XML seems like a good solution for the task; and the German Wikipedia's implementation provides a good proof of concept for it.
- this project isn't about getting WYSIWYG onto Wikipedia, although I think it's a step toward that goal: first, because it would put in place some sort of Javascript-enabled editor in place of the standard edit page textarea; and second, because, as far as I know, handling of template calls is one of the big stumbling blocks (though not the only one) preventing WYSIWYG from getting used on Wikimedia projects.
-Yaron
The idea of having the template specification be stored as something more human-readable, and possibly more like wiki-text, certainly has its appeal (at least, to those people who don't want wiki-text to be replaced by XML in the first place!) It would be easier for users to create and edit; unless there were a tool to edit the XML, and users always used that tool... I really don't know whether XML or something simpler would be the better solution in the long run.
I do believe, though, that the thing that prevents a simpler storage format is the need for translation. Without it, a template parameter can be defined by a simple set of values: a label, a description, an input type, and then a handful of modifiers for the input type (like the list of allowed values, if it's a radiobutton or dropdown). If translation of different values is allowed, though, you really need the structure that XML provides, or else the whole thing devolves into chaos.
Most wikis won't require translation, though; and that includes most Wikimedia projects - they're in one language at a time. The one big exception is Wikimedia Commons, which also happens to be the proposed first usage of this template-call-editing system. And for that site, translation really is necessary (I think).
So, at the risk of complicating things even further - maybe it makes sense to have a split approach - one format that handles translation, another that doesn't? The non-translation format, given that it would be simpler, could even be embedded directly in the template - possibly within a <documentation> tag in the template, as Platonides suggested. I put together some ideas on how this could work, here:
http://usability.wikimedia.org/wiki/Template_forms#Specification_structure
-Yaron
Yaron Koren wrote:
I do believe, though, that the thing that prevents a simpler storage format is the need for translation. Without it, a template parameter can be defined by a simple set of values: a label, a description, an input type, and then a handful of modifiers for the input type (like the list of allowed values, if it's a radiobutton or dropdown). If translation of different values is allowed, though, you really need the structure that XML provides, or else the whole thing devolves into chaos.
Most wikis won't require translation, though; and that includes most Wikimedia projects - they're in one language at a time. The one big exception is Wikimedia Commons, which also happens to be the proposed first usage of this template-call-editing system. And for that site, translation really is necessary (I think).
So, at the risk of complicating things even further - maybe it makes sense to have a split approach - one format that handles translation, another that doesn't? The non-translation format, given that it would be simpler, could even be embedded directly in the template - possibly within a <documentation> tag in the template, as Platonides suggested.
There could be <documentation lang="en">, <documentation lang="fr">, <documentation lang="de">...
That would certainly simplify the format; on the other hand, it would lead to a lot of redundancy between the different <documentation> tags, which could lead to conflicting data structures; so it's probably not a workable solution. -Yaron
There could be <documentation lang="en">, <documentation lang="fr">,
<documentation lang="de">...
* Yaron Koren yaron57@gmail.com [Tue, 29 Sep 2009 00:53:07 -0400]:
That would certainly simplify the format; on the other hand, it would lead to a lot of redundancy between the different <documentation> tags,
which
could lead to conflicting data structures; so it's probably not a workable solution. -Yaron
There could be <documentation lang="en">, <documentation lang="fr">,
<documentation lang="de">... _______________________________________________
What if to have an <documentation> section to define common settings, such as parameter types and english names, and to use <documentation lang=code> to override the names and descriptions for the particular code of language? Or, maybe using XML-like trees, but with shorter syntax, without much of nested tags, something like JAML or alternative nested brackets syntax, like the one library was once described by Gregory Maxwell? But, in case it would not have to be source-edited, maybe XML will be the most proper way. Dmitriy
This thread has gotten WAY off topic - so I wanted to try and help clarify a few things and then get it back on-topic if at all possible.
* As Roan mentioned, we are planning on implementing a *wiki-text *editing interface with collapsible blocks for template calls and tables. We may also get a bonus of basic syntax highlighting, but that's not a driving feature. * WYSIWYG is a hope, dream, intention, and long-term-plan of the Wikimedia Foundation - but it's not going to be a reality until we can make progress in at least 3 areas (explained below) and perhaps others as well. * It's important to understand that wiki-text it'self is not the enemy of WYSIWYG, these (and perhaps others as well) are... o *Data corruption: *All current solutions convert wiki-text to some kind of HTML, edit it as if it were HTML, and then convert it back, causing disconnection between the original content and edited content. This in-turn causes diffs to show changes made by the lossy process for conversion such as white-space, tables being in short or long notation, and HTML comments being stripped. More importantly of course, it changes the wiki-text of the page in ways the user did not intend to and wipes out important formatting and comments that people using text editing interfaces (by choice or because their browser is unsupported) need, want and use.* * o *Template abuse: *Template calls do not always result in whole objects. When expanding a template, the result is allowed entirely arbitrary. For instance, I've seen templates that create only the head, a single row, or the foot for a table. When the user wants to change the table, they click edit, and not only does the software not have any way of knowing that these consecutive template calls are related.* * o *Embedded page logic:* Template functions are not visually representable in any way I've ever seen that would make any sense to a non-programmer, yet they often have a profound impact on the content of the page. Nesting a series of if statements is especially going to be a mess in a GUI. * This is not to say I have no ideas or plans on how to solve these issues. We are actively making choices to pave the way for WYSIWYG, but a topic like this hasn't yet proven to be very useful in this process. So far I have only seen the same circle of "Editing wiki-text sucks!" -> "We need WYSIWYG!" -> "WYSIWYG is broken" -> "It must be wiki-text's fault!" -> "Let's change wiki-text" -> "But it's so easy to edit!" -> "No it's not! Editing wiki-text sucks" -> and so on... So, FYI, this is not a new or in anyway original chain of thought or conversation - it's not bad, it's just going to be seen as spam to most people on this list. * The topic is supposed to be on Template Editing which is, at least in the way it's being proposed, a little less of a stale topic - so where is all the energy on that front? We have an XML format to design and complex problems to sort out. Help is really needed. Let's all take a look at the link provided at the beginning of this thread http://usability.wikimedia.org/wiki/Template_forms
- Trevor
On Fri, Sep 25, 2009 at 12:30 PM, Trevor Parscal tparscal@wikimedia.orgwrote:
- The topic is supposed to be on Template Editing which is, at least in the way it's being proposed, a little less of a stale topic - so where is all the energy on that front? We have an XML format to design and complex problems to sort out. Help is really needed. Let's all take a look at the link provided at the beginning of this thread http://usability.wikimedia.org/wiki/Template_forms
- Trevor
I do think that sufficient energy has been directed at this topic. People have complained that xml is harder to edit that wikitext and that it is too complicated, among other things. Additionally, several people have pointed out that solving this little part of the problem doesn't make sense in the context of the larger problem at hand here. You are trying to separate the issue of template editing from the larger issue of wikitext, and that doesn't make sense. Also, I am quite serious about my point that an entirely new language interface specification will be added to MediaWiki and that it will be widely adopted and propagate throughout the wikisphere, much like parser functions, and in the end will make the job of fixing MediaWiki much, much harder. As it is very important developers already thing the problem is so hard as to be impossible. I disagree with that, but at the same time I don't think it's a good idea to make it even harder.
So I don't think help is needed in designing a new xml interface specification for mediawiki right now. I'm also a bit confused, because I thought we had this new strategic planning wiki, but it looks like the strategy aspect of this proposal is being largely ignored. From what I have heard, there was a meeting about how to solve this problem among core devs and a few others at wikimedia headquarters, they decided what the solution would be, and now you guys are moving forward on implementing it, totally ignoring the strategy wiki.
2009/9/25 Brian Brian.Mingus@colorado.edu:
Also, I am quite serious about my point that an entirely new language interface specification will be added to MediaWiki and that it will be widely adopted and propagate throughout the wikisphere, much like parser functions, and in the end will make the job of fixing MediaWiki much, much harder.
Whatever wikitext ends up becoming, it will probably still have templates in some form. If the XML language is designed properly, it won't make any assumptions about the current state of wikitext and templates, other than that:
* there are such things as templates * they accept parameters * parameters can, but need not, have names, types, descriptions, etc.; types may or may not be enforced
This very limited set of assumptions will hold in any language that implements templates in a remotely sane way.
From what I have heard, there was a meeting about how to solve this problem among core devs and a few others at wikimedia headquarters, they decided what the solution would be
That's news to me; I'd very much like to hear from these people what their proposed solution is.
, and now you guys are moving forward on implementing it, totally ignoring the strategy wiki.
You make it sound like we're just going ahead and doing this, totally ignoring everyone else's opinions. Instead, we're proposing and discussing it on this list to get input from other people. If you think there's a more appropriate place to discuss this, just point us there; don't go around blasting us because we failed to read your mind.
Roan Kattouw (Catrope)
On Fri, Sep 25, 2009 at 1:49 PM, Roan Kattouw roan.kattouw@gmail.comwrote:
2009/9/25 Brian Brian.Mingus@colorado.edu:
Also, I am quite serious about my point that an entirely new language interface specification will be added to MediaWiki and that
it
will be widely adopted and propagate throughout the wikisphere, much like parser functions, and in the end will make the job of fixing MediaWiki
much,
much harder.
Whatever wikitext ends up becoming, it will probably still have templates in some form. If the XML language is designed properly, it won't make any assumptions about the current state of wikitext and templates, other than that:
- there are such things as templates
- they accept parameters
- parameters can, but need not, have names, types, descriptions, etc.;
types may or may not be enforced
This very limited set of assumptions will hold in any language that implements templates in a remotely sane way.
From what I have heard, there was a meeting about how to solve this problem among core
devs
and a few others at wikimedia headquarters, they decided what the
solution
would be
That's news to me; I'd very much like to hear from these people what their proposed solution is.
, and now you guys are moving forward on implementing it, totally ignoring the strategy wiki.
You make it sound like we're just going ahead and doing this, totally ignoring everyone else's opinions. Instead, we're proposing and discussing it on this list to get input from other people. If you think there's a more appropriate place to discuss this, just point us there; don't go around blasting us because we failed to read your mind.
Roan Kattouw (Catrope)
It appears that there is a desire for this project to fit within the scope of the Usability Initiative, which to me says that there is a strong desire to implement it starting soon. Trevor's e-mail indicates as much - let's stop talking strategy and start designing so we can implement.
I believe there was a meeting at headquarters with Brion, Trevor, Yaron, and maybe others. I don't know, I wasn't there. All I know is that at this meeting they decided that they would implement this feature. The XML aspect is honestly immaterial to me - it's just an implementational detail, the decision to do this having been decided entirely off wiki.
I am not here saying that it is a bad feature, not a bit. In fact I have previously advocated on this list for the ability for users to specify form-like interfaces. What I am saying is that I think it's premature. There is a tradeoff that needs to be balanced here. It's easy to add new features and hard to fix the old one. As we add new features however we diverse farther and farther from the possibility of fixing wikitext. This is especially when efforts to add new features are done entirely out of the context of a clear strategy for eventually fixing wikitext.
So before a feature such as this is implemented, or any new substantial language is added to MediaWiki (such as ParserFunctions, or this interface specification language), I would like to see work done on the Strategy wiki. I don't think new work such as this should be done outside of the context of a very clear vision of how we will eventually fix the whole problem. And I'm entirely willing to help.
On Fri, Sep 25, 2009 at 2:03 PM, Brian Brian.Mingus@colorado.edu wrote:
On Fri, Sep 25, 2009 at 1:49 PM, Roan Kattouw roan.kattouw@gmail.comwrote:
2009/9/25 Brian Brian.Mingus@colorado.edu:
Also, I am quite serious about my point that an entirely new language interface specification will be added to MediaWiki and that
it
will be widely adopted and propagate throughout the wikisphere, much
like
parser functions, and in the end will make the job of fixing MediaWiki
much,
much harder.
Whatever wikitext ends up becoming, it will probably still have templates in some form. If the XML language is designed properly, it won't make any assumptions about the current state of wikitext and templates, other than that:
- there are such things as templates
- they accept parameters
- parameters can, but need not, have names, types, descriptions, etc.;
types may or may not be enforced
This very limited set of assumptions will hold in any language that implements templates in a remotely sane way.
From what I have heard, there was a meeting about how to solve this problem among core
devs
and a few others at wikimedia headquarters, they decided what the
solution
would be
That's news to me; I'd very much like to hear from these people what their proposed solution is.
, and now you guys are moving forward on implementing it, totally ignoring the strategy wiki.
You make it sound like we're just going ahead and doing this, totally ignoring everyone else's opinions. Instead, we're proposing and discussing it on this list to get input from other people. If you think there's a more appropriate place to discuss this, just point us there; don't go around blasting us because we failed to read your mind.
Roan Kattouw (Catrope)
It appears that there is a desire for this project to fit within the scope of the Usability Initiative, which to me says that there is a strong desire to implement it starting soon. Trevor's e-mail indicates as much - let's stop talking strategy and start designing so we can implement.
I believe there was a meeting at headquarters with Brion, Trevor, Yaron, and maybe others. I don't know, I wasn't there. All I know is that at this meeting they decided that they would implement this feature. The XML aspect is honestly immaterial to me - it's just an implementational detail, the decision to do this having been decided entirely off wiki.
I am not here saying that it is a bad feature, not a bit. In fact I have previously advocated on this list for the ability for users to specify form-like interfaces. What I am saying is that I think it's premature. There is a tradeoff that needs to be balanced here. It's easy to add new features and hard to fix the old one. As we add new features however we diverse farther and farther from the possibility of fixing wikitext. This is especially when efforts to add new features are done entirely out of the context of a clear strategy for eventually fixing wikitext.
So before a feature such as this is implemented, or any new substantial language is added to MediaWiki (such as ParserFunctions, or this interface specification language), I would like to see work done on the Strategy wiki. I don't think new work such as this should be done outside of the context of a very clear vision of how we will eventually fix the whole problem. And I'm entirely willing to help.
Sorry for my typos: one -> ones, diverse -> diverge.
2009/9/25 Brian Brian.Mingus@colorado.edu:
I am not here saying that it is a bad feature, not a bit. In fact I have previously advocated on this list for the ability for users to specify form-like interfaces. What I am saying is that I think it's premature. There is a tradeoff that needs to be balanced here. It's easy to add new features and hard to fix the old one. As we add new features however we diverse farther and farther from the possibility of fixing wikitext. This is especially when efforts to add new features are done entirely out of the context of a clear strategy for eventually fixing wikitext.
So before a feature such as this is implemented, or any new substantial language is added to MediaWiki (such as ParserFunctions, or this interface specification language), I would like to see work done on the Strategy wiki. I don't think new work such as this should be done outside of the context of a very clear vision of how we will eventually fix the whole problem. And I'm entirely willing to help.
You seem to be missing my point (or at least are not refuting it): if implemented properly, with the minimal assumptions I mentioned, subsequent reworking of wikitext *wouldn't* *matter*, because the template call editor could easily be ported to the 'new language' or whatever we end up with. It wouldn't put us any further away from fixing wikitext; the trade-off you mentioned does not exist IMO.
Roan Kattouw (Catrope)
On Fri, Sep 25, 2009 at 2:20 PM, Roan Kattouw roan.kattouw@gmail.comwrote:
2009/9/25 Brian Brian.Mingus@colorado.edu:
I am not here saying that it is a bad feature, not a bit. In fact I have previously advocated on this list for the ability for users to specify form-like interfaces. What I am saying is that I think it's premature.
There
is a tradeoff that needs to be balanced here. It's easy to add new
features
and hard to fix the old one. As we add new features however we diverse farther and farther from the possibility of fixing wikitext. This is especially when efforts to add new features are done entirely out of the context of a clear strategy for eventually fixing wikitext.
So before a feature such as this is implemented, or any new substantial language is added to MediaWiki (such as ParserFunctions, or this
interface
specification language), I would like to see work done on the Strategy
wiki.
I don't think new work such as this should be done outside of the context
of
a very clear vision of how we will eventually fix the whole problem. And
I'm
entirely willing to help.
You seem to be missing my point (or at least are not refuting it): if implemented properly, with the minimal assumptions I mentioned, subsequent reworking of wikitext *wouldn't* *matter*, because the template call editor could easily be ported to the 'new language' or whatever we end up with. It wouldn't put us any further away from fixing wikitext; the trade-off you mentioned does not exist IMO.
Roan Kattouw (Catrope)
I think calling it a 'template call editor' does not do the proposed new feature justice. It would fundamentally change MediaWiki. Once this language is created it will, if I understand it correctly (please correct me if I don't), immediately support the creation of interfaces that automatically create new interfaces, and so on and so forth. It is a fundamental departure from the way we currently do things on the wiki.
However powerful it is, I'm not sure we can really rule out future incompatibility as you suggest by simply stating that we can easily forwardport. This feature is intended to hack a fix on top of the usability issues inherent in templates. Every time we have a discussion about the pitfalls of wikitext the center of this discussion is templates. Even without parser functions they are turing complete - with them it is a complete usability disaster. So it seems that when we finally get around to developing a consensus about the changes we want in wikitext, there will be widespread agreement that we need to change templates. But so far, without any clear strategy on that front, we have no idea what those changes will be.
2009/9/25 Brian Brian.Mingus@colorado.edu:
However powerful it is, I'm not sure we can really rule out future incompatibility as you suggest by simply stating that we can easily forwardport. This feature is intended to hack a fix on top of the usability issues inherent in templates. Every time we have a discussion about the pitfalls of wikitext the center of this discussion is templates. Even without parser functions they are turing complete - with them it is a complete usability disaster. So it seems that when we finally get around to developing a consensus about the changes we want in wikitext, there will be widespread agreement that we need to change templates. But so far, without any clear strategy on that front, we have no idea what those changes will be.
It's important to separate template *calls* from template *implementation*: only the latter involves ParserFunctions and all that other ugliness. Even if and when we do completely redo the way templates are *written* on the inside, the way they're *called* from the outside would probably not change significantly, nor would the concepts of parameters and types. This means redoing template syntax does not require any changes to the XML format.
Roan Kattouw (Catrope)
On Fri, Sep 25, 2009 at 2:42 PM, Roan Kattouw roan.kattouw@gmail.comwrote:
2009/9/25 Brian Brian.Mingus@colorado.edu:
However powerful it is, I'm not sure we can really rule out future incompatibility as you suggest by simply stating that we can easily forwardport. This feature is intended to hack a fix on top of the
usability
issues inherent in templates. Every time we have a discussion about the pitfalls of wikitext the center of this discussion is templates. Even without parser functions they are turing complete - with them it is a complete usability disaster. So it seems that when we finally get around
to
developing a consensus about the changes we want in wikitext, there will
be
widespread agreement that we need to change templates. But so far,
without
any clear strategy on that front, we have no idea what those changes will be.
It's important to separate template *calls* from template *implementation*: only the latter involves ParserFunctions and all that other ugliness. Even if and when we do completely redo the way templates are *written* on the inside, the way they're *called* from the outside would probably not change significantly, nor would the concepts of parameters and types. This means redoing template syntax does not require any changes to the XML format.
Roan Kattouw (Catrope)
It's certainly possible, particularly with something as generic as xml, to create an extension to mediawiki that supports a variety of backends.
As I've suggested, however, without any clear vision of where we want wikitext, and more generally, MediaWiki to go, then it is impossible to evaluate the efficacy of this feature, especially considering that the consequences of it haven't even been evaluated. Given the power of the backend that this feature will be kludged on top of it will fundamentally change MediaWiki is used. And yet, I just checked Strategy, there is no vision for where MediaWiki should go moving into the future, let alone wikitext. As far as I can tell this feature was cooked up in order to improve usability, and yet when you improve usability by definition you make the software easier to use and provide new affordances to your users. We have no idea whether these affordances are in line with our general vision for how users should interact with MediaWiki because we simply do not have one. I have never seen a discussion about whether the ability to create new interfaces via an interface is in line with either our lesser mission to build an encyclopedia or our greater one to bring knowledge to every human being. Lastly I would just point out that everything that can be done with this new feature will be done, and I invoke the spirit of #qif to make my point.
Are the XML specifications intended as?
A) A required addition to current and future templates
OR
B) An optional addition to aid / facilitate the functioning of some advanced tools
The latter case seems far more achievable than the former case.
-Robert Rohde
On Fri, Sep 25, 2009 at 12:49 PM, Roan Kattouw roan.kattouw@gmail.com wrote:
2009/9/25 Brian Brian.Mingus@colorado.edu:
Also, I am quite serious about my point that an entirely new language interface specification will be added to MediaWiki and that it will be widely adopted and propagate throughout the wikisphere, much like parser functions, and in the end will make the job of fixing MediaWiki much, much harder.
Whatever wikitext ends up becoming, it will probably still have templates in some form. If the XML language is designed properly, it won't make any assumptions about the current state of wikitext and templates, other than that:
- there are such things as templates
- they accept parameters
- parameters can, but need not, have names, types, descriptions, etc.;
types may or may not be enforced
This very limited set of assumptions will hold in any language that implements templates in a remotely sane way.
From what I have heard, there was a meeting about how to solve this problem among core devs and a few others at wikimedia headquarters, they decided what the solution would be
That's news to me; I'd very much like to hear from these people what their proposed solution is.
, and now you guys are moving forward on implementing it, totally ignoring the strategy wiki.
You make it sound like we're just going ahead and doing this, totally ignoring everyone else's opinions. Instead, we're proposing and discussing it on this list to get input from other people. If you think there's a more appropriate place to discuss this, just point us there; don't go around blasting us because we failed to read your mind.
Roan Kattouw (Catrope)
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 9/25/09 1:18 PM, Robert Rohde wrote:
Are the XML specifications intended as?
A) A required addition to current and future templates
OR
B) An optional addition to aid / facilitate the functioning of some advanced tools
The latter case seems far more achievable than the former case.
-Robert Rohde
On Fri, Sep 25, 2009 at 12:49 PM, Roan Kattouwroan.kattouw@gmail.com wrote:
2009/9/25 BrianBrian.Mingus@colorado.edu:
Also, I am quite serious about my point that an entirely new language interface specification will be added to MediaWiki and that it will be widely adopted and propagate throughout the wikisphere, much like parser functions, and in the end will make the job of fixing MediaWiki much, much harder.
Whatever wikitext ends up becoming, it will probably still have templates in some form. If the XML language is designed properly, it won't make any assumptions about the current state of wikitext and templates, other than that:
- there are such things as templates
- they accept parameters
- parameters can, but need not, have names, types, descriptions, etc.;
types may or may not be enforced
This very limited set of assumptions will hold in any language that implements templates in a remotely sane way.
From what I have heard, there was a meeting about how to solve this problem among core devs and a few others at wikimedia headquarters, they decided what the solution would be
That's news to me; I'd very much like to hear from these people what their proposed solution is.
, and now you guys are moving forward on implementing it, totally ignoring the strategy wiki.
You make it sound like we're just going ahead and doing this, totally ignoring everyone else's opinions. Instead, we're proposing and discussing it on this list to get input from other people. If you think there's a more appropriate place to discuss this, just point us there; don't go around blasting us because we failed to read your mind.
Roan Kattouw (Catrope)
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
The latter case for sure. Without the additional information, editing a template call will just be a list of field names and text inputs.
- Trevor
Brian wrote:
On Fri, Sep 25, 2009 at 12:30 PM, Trevor Parscal tparscal@wikimedia.orgwrote:
- The topic is supposed to be on Template Editing which is, at least in the way it's being proposed, a little less of a stale topic - so where is all the energy on that front? We have an XML format to design and complex problems to sort out. Help is really needed. Let's all take a look at the link provided at the beginning of this thread http://usability.wikimedia.org/wiki/Template_forms
- Trevor
I do think that sufficient energy has been directed at this topic. People have complained that xml is harder to edit that wikitext and that it is too complicated, among other things. Additionally, several people have pointed out that solving this little part of the problem doesn't make sense in the context of the larger problem at hand here. You are trying to separate the issue of template editing from the larger issue of wikitext, and that doesn't make sense. Also, I am quite serious about my point that an entirely new language interface specification will be added to MediaWiki and that it will be widely adopted and propagate throughout the wikisphere, much like parser functions, and in the end will make the job of fixing MediaWiki much, much harder. As it is very important developers already thing the problem is so hard as to be impossible. I disagree with that, but at the same time I don't think it's a good idea to make it even harder.
So I don't think help is needed in designing a new xml interface specification for mediawiki right now. I'm also a bit confused, because I thought we had this new strategic planning wiki, but it looks like the strategy aspect of this proposal is being largely ignored. From what I have heard, there was a meeting about how to solve this problem among core devs and a few others at wikimedia headquarters, they decided what the solution would be, and now you guys are moving forward on implementing it, totally ignoring the strategy wiki.
AFAIK, the strategy wiki is designed to help formulate a 5-year strategic plan. According to the timeline, actual execution may not begin for at least another 4 months.[1] The usability project has its own timeline and deadlines and is more concerned more with short and medium term projects. I don't know if there is any plan to continue funding the usability initiative after the Stanton Foundation grant runs out.
[1]http://strategy.wikimedia.org/wiki/Process#Timeline_.282009_-_2010.29
On Fri, Sep 25, 2009 at 2:14 PM, Alex mrzmanwiki@gmail.com wrote:
Brian wrote:
On Fri, Sep 25, 2009 at 12:30 PM, Trevor Parscal <tparscal@wikimedia.org wrote:
- The topic is supposed to be on Template Editing which is, at least in the way it's being proposed, a little less of a stale topic - so where is all the energy on that front? We have an XML format to design and complex problems to sort out. Help is really needed. Let's all take a look at the link provided at the beginning of this thread http://usability.wikimedia.org/wiki/Template_forms
- Trevor
I do think that sufficient energy has been directed at this topic. People have complained that xml is harder to edit that wikitext and that it is
too
complicated, among other things. Additionally, several people have
pointed
out that solving this little part of the problem doesn't make sense in
the
context of the larger problem at hand here. You are trying to separate
the
issue of template editing from the larger issue of wikitext, and that doesn't make sense. Also, I am quite serious about my point that an
entirely
new language interface specification will be added to MediaWiki and that
it
will be widely adopted and propagate throughout the wikisphere, much like parser functions, and in the end will make the job of fixing MediaWiki
much,
much harder. As it is very important developers already thing the problem
is
so hard as to be impossible. I disagree with that, but at the same time I don't think it's a good idea to make it even harder.
So I don't think help is needed in designing a new xml interface specification for mediawiki right now. I'm also a bit confused, because I thought we had this new strategic planning wiki, but it looks like the strategy aspect of this proposal is being largely ignored. From what I
have
heard, there was a meeting about how to solve this problem among core
devs
and a few others at wikimedia headquarters, they decided what the
solution
would be, and now you guys are moving forward on implementing it, totally ignoring the strategy wiki.
AFAIK, the strategy wiki is designed to help formulate a 5-year strategic plan. According to the timeline, actual execution may not begin for at least another 4 months.[1] The usability project has its own timeline and deadlines and is more concerned more with short and medium term projects. I don't know if there is any plan to continue funding the usability initiative after the Stanton Foundation grant runs out.
[1]http://strategy.wikimedia.org/wiki/Process#Timeline_.282009_-_2010.29
-- Alex (wikipedia:en:User:Mr.Z-man)
The vision for the strategy wiki is much, much broader than that. Here is a recent e-mail from Sue on the subject:
On Tue, Sep 22, 2009 at 7:35 PM, Sue Gardner sgardner@wikimedia.org wrote:
2009/9/22 Eugene Eric Kim eekim@blueoxen.com:
On Mon, Sep 14, 2009 at 3:49 PM, Pavlo Shevelo pavlo.shevelo@gmail.com
wrote:
"Who will decide what the strategy will be, and what will be the decision-making process?"
this page explains nothing about (or explains in no detail if somebody prefers) how main stakeholder - Foundation will make decision about said strategy. The huge, extremely intensive (and effective, if we will do our best) Earth-wide pipeline for proposal preparation - it's good. But what will be in the very end? How Foundation will decide what idea is good enough to stand behind it (and to put money in it)?
Sorry for taking so long to respond, Pavlo. I'm not sure I'm the right person to respond to this. I'll do my best, you can tell me if you think it's clear, and hopefully other folks from the Foundation will jump in.
I just saw this thread; I'm happy to jump in.
What Eugene says is all accurate -- let me expand a little.
Essentially, the purpose of the project is to develop a strategy for the Wikimedia movement, not just for the Wikimedia Foundation. What that means is that no single entity will be able to approve and drive forward the whole thing: individual players will drive forward the pieces that compel and engage and inspire them.
So for example:
- If it looks like it makes sense to stage a lot of events aimed at
broadening participation in developed countries, the chapters would logically take the lead on that.
- If it looks like it would make sense to conduct a massive awareness
campaign in India, that would probably be moved forward in partnership between the Wikimedia Foundation and what might be -by then- an approved, new Indian chapter.
- If it looks like a very strong focus on mobile makes sense, I expect
that would be something driven forward by the tech staff at Wikimedia, in partnership with individual volunteer devs, and possibly supported by relationships with for-profit firms such as Orange.
- If there is a simple thing that looks sensible, and one person wants
to, and is able to, achieve it by him or herself, they would just do that. They wouldn't need to wait for anyone's goahead.
You see what I mean? Essentially, the goal is that each player will make its own decisions based on its own context -- its own capacity, its skills and abilities and interests, its own goals and priorities. People will be able to do that however they want, in whatever process works for them.
With regards to the Wikimedia Foundation, as Eugene said, if the process works well, it (the process) will deliver to the Board a set of high-level recommendations in key areas. By that time work will have been done, especially in the later stages of the task force work, to try to ensure the recommendations are synched up with each other and make sense together as much as possible --- but there will probably be a few areas in which incompatible (mutually exclusive) recommendations are submitted. The Board of Trustees will then work to resolve whatever contradictions are present, and to prioritize the work it wants to get done. And then, if all has gone well, it will approve the strategy plan.
Hope that helps. And -- Board members should please speak up here also, especially if there are nuances to their understanding that differ from mine or Eugene's.
Thanks, Sue
-- Sue Gardner Executive Director Wikimedia Foundation
415 839 6885 office 415 816 9967 cell
Imagine a world in which every single human being can freely share in the sum of all knowledge. Help us make it a reality!
http://wikimediafoundation.org/wiki/Donate
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
On 9/25/09 11:39 AM, Brian wrote:
I do think that sufficient energy has been directed at this topic. People have complained that xml is harder to edit that wikitext and that it is too complicated, among other things.
You seem to be talking about something utterly unrelated to this thread...
The only XML under discussion here is an internal back-end representation of template metadata to drive a sane template invocation user-interface:
* field names and descriptions (localizable) * field types/validation info * field grouping and optional/required info * other documentation & display info
This would not be exposed to editors, viewers or readers; nor is it in any way related to whether, how, or when we might some day alter or replace wiki markup.
-- brion
On Fri, Sep 25, 2009 at 3:13 PM, Brion Vibber brion@wikimedia.org wrote:
On 9/25/09 11:39 AM, Brian wrote:
I do think that sufficient energy has been directed at this topic. People have complained that xml is harder to edit that wikitext and that it is
too
complicated, among other things.
You seem to be talking about something utterly unrelated to this thread...
The only XML under discussion here is an internal back-end representation of template metadata to drive a sane template invocation user-interface:
- field names and descriptions (localizable)
- field types/validation info
- field grouping and optional/required info
- other documentation & display info
This would not be exposed to editors, viewers or readers; nor is it in any way related to whether, how, or when we might some day alter or replace wiki markup.
-- brion
You have conveniently ignored the rest of my points, which are not, as you have claimed, off topic. (and you love to jump into threads and claim they have become off topic, historically, with only the points that you are considering being on topic.)
To wrap them up for you:
* This will fundamentally change mediawiki and the consequences of this feature have not been considered * It will support the creation of new interfaces from interfaces, simply by creating templates that create new templates and using the interface to that template to create the new interface. Is this correct? * We cannot evaluate the repercussions of this feature with respect to our broader vision for mediawiki because we (by which I mean we, not you personally) do not have one.
2009/9/25 Brian Brian.Mingus@colorado.edu:
- This will fundamentally change mediawiki and the consequences of this
feature have not been considered
- It will support the creation of new interfaces from interfaces, simply by
creating templates that create new templates and using the interface to that template to create the new interface. Is this correct?
Wait, what? Can you explain this better or provide an example?
Roan Kattouw (Catrope)
On Fri, Sep 25, 2009 at 3:29 PM, Roan Kattouw roan.kattouw@gmail.comwrote:
2009/9/25 Brian Brian.Mingus@colorado.edu:
- This will fundamentally change mediawiki and the consequences of this
feature have not been considered
- It will support the creation of new interfaces from interfaces, simply
by
creating templates that create new templates and using the interface to
that
template to create the new interface. Is this correct?
Wait, what? Can you explain this better or provide an example?
Roan Kattouw (Catrope)
Roan, sorry that the idea is pretty hard to convey, I'll try again. The basic idea is that you can create templates using templates (just using current tech). It's easy, you just pass parameters to a template that control its output, and this output is a new template. The parameters that you passed determine what the new template looks like, and what it's output will be.
We can imagine a master template on Wikipedia that is used to generate all infoboxes. It could work in arbitrary ways, but suppose it works this way: The master infobox template creates a template for each wikiproject. The template that it creates for each wikiproject further creates templates representing every kind of infobox that this wikiproject uses. So you have a master template that creates baby templates that create infobox templates.
Using current tech this isn't exactly feasible, only advanced users will do it since you have to directly interact with the templates and it would be tough to code up. But if you make such a feature highly usable, by, for example, tacking an easy to use interface on top of it, the usage of such techniques will proliferate.
More general kinds of interface builders that build all imaginable kinds of interfaces are conceivable.
Is this not possible within the scope of the suggested system?
2009/9/26 Brian Brian.Mingus@colorado.edu:
Roan, sorry that the idea is pretty hard to convey, I'll try again. The basic idea is that you can create templates using templates (just using current tech). It's easy, you just pass parameters to a template that control its output, and this output is a new template. The parameters that you passed determine what the new template looks like, and what it's output will be.
Right, so basically this is just templates calling other templates, right? This already happens to some degree already.
We can imagine a master template on Wikipedia that is used to generate all infoboxes. It could work in arbitrary ways, but suppose it works this way: The master infobox template creates a template for each wikiproject. The template that it creates for each wikiproject further creates templates representing every kind of infobox that this wikiproject uses. So you have a master template that creates baby templates that create infobox templates.
Using current tech this isn't exactly feasible, only advanced users will do it since you have to directly interact with the templates and it would be tough to code up. But if you make such a feature highly usable, by, for example, tacking an easy to use interface on top of it, the usage of such techniques will proliferate.
To use the master infobox example: such a template would have about a dozen usage modes, each with dozens of parameters. Such constructs are actually /easier/ to call by hand than with a form, because you'd either have to store all the relationships between the parameters and usage modes in the XML file and let the form handle all that (which is a degree of complexity I personally would not like to see in a template forms implementation) or just throw a couple hundred parameters in the user's face.
Also, this being tough to code up would not change: again, we're not simplifying the *writing* of templates *themselves* in any way. The fact that these templates include template calls doesn't change that, because 1) you're gonna be using #if constructs all over the place anyway, 2) you'd need to use stuff like {{{2|{{{1|}}}}}} as arguments to template calls, which the GUI doesn't simplify and 3) if you're skilled enough to do 1 and 2 and familiar enough with the templates you're calling to be writing a master templates, you don't need an editor or form to build the template calls for you.
More general kinds of interface builders that build all imaginable kinds of interfaces are conceivable.
Is this not possible within the scope of the suggested system?
Yes, but it's also possible within the scope of the current system. You don't /need/ a template editor to be doing this kind of monkey business. In fact, I think a template editor would actually discourage these practices, because relatively unexperienced users must be able to build a reasonable template call using the template editor. For the latter to work out, templates need to be simpler rather than more complex.
In short, I don't think introducing a template editor would encourage master templates and similar complexification of templates; in fact, I believe it will actually encourage simplification, because a nice-looking GUI for a big incomprehensible parameter soup is worth the soup.
Roan Kattouw (Catrope)
On Fri, Sep 25, 2009 at 4:49 PM, Roan Kattouw roan.kattouw@gmail.comwrote:
2009/9/26 Brian Brian.Mingus@colorado.edu:
Roan, sorry that the idea is pretty hard to convey, I'll try again. The basic idea is that you can create templates using templates (just using current tech). It's easy, you just pass parameters to a template that control its output, and this output is a new template. The parameters that you passed determine what
the
new template looks like, and what it's output will be.
Right, so basically this is just templates calling other templates, right? This already happens to some degree already.
We can imagine a master template on Wikipedia that is used to generate
all
infoboxes. It could work in arbitrary ways, but suppose it works this
way:
The master infobox template creates a template for each wikiproject. The template that it creates for each wikiproject further creates templates representing every kind of infobox that this wikiproject uses. So you
have a
master template that creates baby templates that create infobox
templates.
Using current tech this isn't exactly feasible, only advanced users will
do
it since you have to directly interact with the templates and it would be tough to code up. But if you make such a feature highly usable, by, for example, tacking an easy to use interface on top of it, the usage of such techniques will proliferate.
To use the master infobox example: such a template would have about a dozen usage modes, each with dozens of parameters. Such constructs are actually /easier/ to call by hand than with a form, because you'd either have to store all the relationships between the parameters and usage modes in the XML file and let the form handle all that (which is a degree of complexity I personally would not like to see in a template forms implementation) or just throw a couple hundred parameters in the user's face.
Also, this being tough to code up would not change: again, we're not simplifying the *writing* of templates *themselves* in any way. The fact that these templates include template calls doesn't change that, because 1) you're gonna be using #if constructs all over the place anyway, 2) you'd need to use stuff like {{{2|{{{1|}}}}}} as arguments to template calls, which the GUI doesn't simplify and 3) if you're skilled enough to do 1 and 2 and familiar enough with the templates you're calling to be writing a master templates, you don't need an editor or form to build the template calls for you.
More general kinds of interface builders that build all imaginable kinds
of
interfaces are conceivable.
Is this not possible within the scope of the suggested system?
Yes, but it's also possible within the scope of the current system. You don't /need/ a template editor to be doing this kind of monkey business. In fact, I think a template editor would actually discourage these practices, because relatively unexperienced users must be able to build a reasonable template call using the template editor. For the latter to work out, templates need to be simpler rather than more complex.
In short, I don't think introducing a template editor would encourage master templates and similar complexification of templates; in fact, I believe it will actually encourage simplification, because a nice-looking GUI for a big incomprehensible parameter soup is worth the soup.
Roan Kattouw (Catrope)
* wizards, workflows, meta-interfaces, these are accidental implications of a feature whose only purported design goal is to make editing templates on articles easier. and i haven't been at all convinced that the new system won't make it possible to create really elegant interfaces that are easy to use. e.g., that make it really easy to create monstrosities of templates and parser functions that no human can conceivably understand. :* historically, if it can be done on the wiki it will be done :* and it will be spread and copied, hundreds of thousands to millions of times, within just a few years
* nobody intended to make template syntax turing complete - it was an accident
* the obvious solution to templates is *not* to hack on an interface for editing them. wikipedia is supposed to be the encyclopedia that anyone can edit. it was a poor design decision to enable (or indeed, to create) a template system on wikipedia that allowed people to create, in the first place {{qif}}, and other things like it. the only reason even worse things weren't created is that it was hard. :* and the result of this accident was not just to put limits on recursion and the things that could be done with templates, but to further enable those use cases (without much discussion or regard to long term strategy and usability).
* so not only were templates bad, but this Incrementalism, otherwise known as [[Feature creep]], which brion just described as his guiding "strategy," led us to kludge something even worse on top. and now here we are, further incrementing the size of the snowball with no clear long term vision to guide us as we increment. we continue to achieve "consensus", a.k.a several people at wikimedia headquarters, for kludges on top of this core problem because nobody there has any vision about where the software should go let alone the will to actually fix it. it's been several years off for several years now.
Hello.
Heres a screenshot of me editing the wikipedia:
http://zerror.com/unorganized/crap/nogoodenough.png
All the webmasters on this mail list will spot the problem with this text in 1 second: is unreadable. The space betwen lines, the lines length, the complexity of the text... Is really hard to read. A HTML textarea can server for writting emails, and simple text, but on this image fail short. Textareas are not designed for this, or are not good enough.
How a webmaster can make that text better? well.. you need to stop using the HTML textarea widget. And emulate it with divs, css and javascript. You need to colorize the code. Nowdays *ALL* good code editors colorize code. If our code editor don't colorize the wiki sintax, or don't even try, our editor is bad. I could be wrong, but maybe [[links]] and {{templates}} can be detected and colorized. And since you are emulating a editor, you can add a bit of usefull beaviors: make so some areas are read only, so the cursor skip then. Oh.. and you can make the whole think AJAXified,.. so wen you click [Edit section] this section become editable, and wen you "save", the edit view send, and is replaced by the result. Why would you want to people bounce here and there to post stuff in 2009?
He... our computers support 24 M colors, and we are showing text with 2 colors? pfff....
How a webmaster can make that text better? well.. you need to stop using the HTML textarea widget. And emulate it with divs, css and javascript. You need to colorize the code. Nowdays *ALL* good code
Or use a canvas.. enter Bespin!
On 9/25/09 6:07 PM, Daniel Schwen wrote:
How a webmaster can make that text better? well.. you need to stop using the HTML textarea widget. And emulate it with divs, css and javascript. You need to colorize the code. Nowdays *ALL* good code
Or use a canvas.. enter Bespin!
Bespin is *very* cool, and we've definitely looked at it. (Even aside from the excellent syntax highlighting editor widget there are some *realllllly* neat capabilities like the multi-user realtime editing, which if framed appropriately and combined with good chat tools could be insanely useful for Wikipedia.)
Right now it's quite an experimental project, though, and doesn't have a good way to support IE, so for our key efforts on syntax highlighting and content-folding we're looking mainly at using the browser-provided rich text edit widgets. This can unfortunately have performance problems so we may be limited in what we can do well, but hopefully that'll tide us over for a couple years. ;)
The wikEd editor gadget is an example of using this method to do syntax highlighting, though we'd want to scale it back to the key elements and avoid going overboard on the interface:
http://en.wikipedia.org/wiki/User:Cacycle/wikEd
-- brion
* Tei oscar.vives@gmail.com [Sat, 26 Sep 2009 02:40:06 +0200]:
Hello.
Heres a screenshot of me editing the wikipedia:
http://zerror.com/unorganized/crap/nogoodenough.png
All the webmasters on this mail list will spot the problem with this text in 1 second: is unreadable. The space betwen lines, the lines length, the complexity of the text... Is really hard to read. A HTML textarea can server for writting emails, and simple text, but on this image fail short. Textareas are not designed for this, or are not good enough.
How a webmaster can make that text better? well.. you need to stop using the HTML textarea widget. And emulate it with divs, css and javascript. You need to colorize the code. Nowdays *ALL* good code editors colorize code. If our code editor don't colorize the wiki sintax, or don't even try, our editor is bad. I could be wrong, but maybe [[links]] and {{templates}} can be detected and colorized. And since you are emulating a editor, you can add a bit of usefull beaviors: make so some areas are read only, so the cursor skip then. Oh.. and you can make the whole think AJAXified,.. so wen you click [Edit section] this section become editable, and wen you "save", the edit view send, and is replaced by the result. Why would you want to people bounce here and there to post stuff in 2009?
He... our computers support 24 M colors, and we are showing text with 2 colors? pfff....
I am very much supporting you! Both code colorizing and AJAX editing preview. And maybe a links "code completion" - when yuu press [[ it will open an JS-generated dialog with drop-down title search list. It's not that wikitext is too hard (with the huge exception of templates) but the editor is very much restricted.. Though templates surely aren't nice and it's probably is better to keep them separate and XML-ize them. Dmitriy
2009/9/26 Dmitriy Sintsov questpc@rambler.ru:
I am very much supporting you! Both code colorizing and AJAX editing preview.
The usability initiative intends to do both, in addition to code folding (compressing long and complicated things such as templates, table calls and references into a small placeholder than can be expanded at wish).
And maybe a links "code completion" - when yuu press [[ it will open an JS-generated dialog with drop-down title search list.
We've done something similar to this idea, and hope to deploy it on Wikipedia soon. Basically it's a toolbar button that launches a link dialog with title suggestions for internal links.
Roan Kattouw (Catrope)
On Sat, Sep 26, 2009 at 10:14 AM, Dmitriy Sintsov questpc@rambler.ru wrote:
- Tei oscar.vives@gmail.com [Sat, 26 Sep 2009 02:40:06 +0200]:
Hello.
Heres a screenshot of me editing the wikipedia:
http://zerror.com/unorganized/crap/nogoodenough.png
All the webmasters on this mail list will spot the problem with this text in 1 second: is unreadable. The space betwen lines, the lines length, the complexity of the text... Is really hard to read. A HTML textarea can server for writting emails, and simple text, but on this image fail short. Textareas are not designed for this, or are not good enough.
How a webmaster can make that text better? well.. you need to stop using the HTML textarea widget. And emulate it with divs, css and javascript. You need to colorize the code. Nowdays *ALL* good code editors colorize code. If our code editor don't colorize the wiki sintax, or don't even try, our editor is bad. I could be wrong, but maybe [[links]] and {{templates}} can be detected and colorized. And since you are emulating a editor, you can add a bit of usefull beaviors: make so some areas are read only, so the cursor skip then. Oh.. and you can make the whole think AJAXified,.. so wen you click [Edit section] this section become editable, and wen you "save", the edit view send, and is replaced by the result. Why would you want to people bounce here and there to post stuff in 2009?
He... our computers support 24 M colors, and we are showing text with 2 colors? pfff....
I am very much supporting you! Both code colorizing and AJAX editing preview. And maybe a links "code completion" - when yuu press [[ it will open an JS-generated dialog with drop-down title search list. It's not that wikitext is too hard (with the huge exception of templates) but the editor is very much restricted.. Though templates surely aren't nice and it's probably is better to keep them separate and XML-ize them. Dmitriy
For templates you can use a "Code beatiffier", that unofuscate the code. Templates can be hard to write, but theres no reason to let then be hard to read. Maybe MW already do that..
Here is a example using another template language (bbcode):
[uRL]lalala[/URL] => [url]lalala[/url]
[quote=Dan]blabla bla bla[/img] =>
[quote= Dani ] bla bla bla [/quote]
I know that this maybe is a bad idea, If this may cause other problems, and theres one million others things that are worth our time :-I
A serverside "Code beatifier" can also helps a clientside colorizer. He can massage the template code first, and be smarter than the colorizers and prevent problems before hit the colorizer. A code beafifier can be implemented in a incremental way, the first version can "just" lowercase all letter. The colorizer can also be implemented in a incremental way, starting colorizing simple stuff. If a colorizing or a beatifier become a problem, can be deactivated, and things will continue smoothly.
Guys, Why are we talking XML? Yaron's Semantic Forms survived without XML - yes, it's definition language is not English, but it's good enough and works relatively good with the rest of MW syntax.
I think using XML will not necessarily do good here as form creators would want the language to be close to the rest of the wiki.
Here's the example of the form which is the mix of wikitext, HTML and regular wiki formatting http://www.techpresentations.org/w/index.php?title=Form:Presentation&act...
It worked for me. Maybe this kind of definition can be merged with Template pages, but frankly SF's model works pretty well (of course, SF is also smart about data because of SMW, but it can be more "manual").
Thank you,
Sergey
-- Sergey Chernyshev http://www.sergeychernyshev.com/
On Sat, Sep 26, 2009 at 8:11 AM, Tei oscar.vives@gmail.com wrote:
On Sat, Sep 26, 2009 at 10:14 AM, Dmitriy Sintsov questpc@rambler.ru wrote:
- Tei oscar.vives@gmail.com [Sat, 26 Sep 2009 02:40:06 +0200]:
Hello.
Heres a screenshot of me editing the wikipedia:
http://zerror.com/unorganized/crap/nogoodenough.png
All the webmasters on this mail list will spot the problem with this text in 1 second: is unreadable. The space betwen lines, the lines length, the complexity of the text... Is really hard to read. A HTML textarea can server for writting emails, and simple text, but on this image fail short. Textareas are not designed for this, or are not good enough.
How a webmaster can make that text better? well.. you need to stop using the HTML textarea widget. And emulate it with divs, css and javascript. You need to colorize the code. Nowdays *ALL* good code editors colorize code. If our code editor don't colorize the wiki sintax, or don't even try, our editor is bad. I could be wrong, but maybe [[links]] and {{templates}} can be detected and colorized. And since you are emulating a editor, you can add a bit of usefull beaviors: make so some areas are read only, so the cursor skip then. Oh.. and you can make the whole think AJAXified,.. so wen you click [Edit section] this section become editable, and wen you "save", the edit view send, and is replaced by the result. Why would you want to people bounce here and there to post stuff in 2009?
He... our computers support 24 M colors, and we are showing text with 2 colors? pfff....
I am very much supporting you! Both code colorizing and AJAX editing preview. And maybe a links "code completion" - when yuu press [[ it will open an JS-generated dialog with drop-down title search list. It's not that wikitext is too hard (with the huge exception of templates) but the editor is very much restricted.. Though templates surely aren't nice and it's probably is better to keep them separate and XML-ize them. Dmitriy
For templates you can use a "Code beatiffier", that unofuscate the code. Templates can be hard to write, but theres no reason to let then be hard to read. Maybe MW already do that..
Here is a example using another template language (bbcode):
[uRL]lalala[/URL] => [url]lalala[/url]
[quote=Dan]blabla bla bla[/img] =>
[quote= Dani ] bla bla bla [/quote]
I know that this maybe is a bad idea, If this may cause other problems, and theres one million others things that are worth our time :-I
A serverside "Code beatifier" can also helps a clientside colorizer. He can massage the template code first, and be smarter than the colorizers and prevent problems before hit the colorizer. A code beafifier can be implemented in a incremental way, the first version can "just" lowercase all letter. The colorizer can also be implemented in a incremental way, starting colorizing simple stuff. If a colorizing or a beatifier become a problem, can be deactivated, and things will continue smoothly.
--
ℱin del ℳensaje.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
* Sergey Chernyshev sergey.chernyshev@gmail.com [Sat, 26 Sep 2009 21:23:25 -0400]:
Guys, Why are we talking XML? Yaron's Semantic Forms survived without XML - yes, it's definition language is not English, but it's good enough and
works
relatively good with the rest of MW syntax.
I think using XML will not necessarily do good here as form creators would want the language to be close to the rest of the wiki.
Here's the example of the form which is the mix of wikitext, HTML and regular wiki formatting
http://www.techpresentations.org/w/index.php?title=Form:Presentation&act...
It worked for me. Maybe this kind of definition can be merged with Template pages, but frankly SF's model works pretty well (of course, SF is also smart about data because of SMW, but it can be more "manual").
Hi Sergey, To me it seems that MediaWiki is moving from pure wiki towards CMS, thus, broaden it's usage (in contrary to what's been stated in bold at meta and other sites that MediaWiki is not CMS). Semantic* extensions and Wikia to me looks like a step towards CMS. Many well-made CMS use XML because there are good XML libraries which allows various processing and transformations.
Also, I believe that XML was proposed to define names, type and description of template parameters and that's also a good idea. Maybe even implementing the whole templating in XML?
But, when it comes to NS_MAIN, I like wikitext, because I am a coder and I like to edit a source. I don't like visual tools, like Dreamweaver, MS Word and so on. Probably the power users, who contribute the most at wikipedia also like wikitext? I don't know whether there was any survey. To these who types fast and knows wikitext, it allows to produce formatted articles quicker than by using the GUI.
But, Wikipedia probably requires an enlargement of it's user base, so wysiwyg is also very important. To me it seems that it would be great if Wikipedia was both friendly to these who likes source wikitext and to these who would love the GUI. But, I don't know whether anyone really likes wikitext, besides me. If nobody likes it, then it will be dropped. Dmitriy
"Brian" Brian.Mingus@colorado.edu wrote in message news:9839a05c0909251423j7152ae51y34a6a9e586f4f56c@mail.gmail.com...
You have conveniently ignored the rest of my points, which are not, as you have claimed, off topic. (and you love to jump into threads and claim they have become off topic, historically, with only the points that you are considering being on topic.)
Considering that you're addressing the person who is ultimately responsible for drafting technical strategy for MediaWiki development, I'm not sure that asserting that his view of what comprises useful discussion is fundamentally flawed is a particularly constructive approach.
--HM
On Fri, Sep 25, 2009 at 4:06 PM, Happy-melon happy-melon@live.com wrote:
"Brian" Brian.Mingus@colorado.edu wrote in message news:9839a05c0909251423j7152ae51y34a6a9e586f4f56c@mail.gmail.com...
You have conveniently ignored the rest of my points, which are not, as
you
have claimed, off topic. (and you love to jump into threads and claim
they
have become off topic, historically, with only the points that you are considering being on topic.)
Considering that you're addressing the person who is ultimately responsible for drafting technical strategy for MediaWiki development, I'm not sure that asserting that his view of what comprises useful discussion is fundamentally flawed is a particularly constructive approach.
--HM
I don't believe the technical strategy for MediaWiki has been drafted, literally speaking.
On 9/25/09 2:23 PM, Brian wrote:
You have conveniently ignored the rest of my points, which are not, as you have claimed, off topic. (and you love to jump into threads and claim they have become off topic, historically, with only the points that you are considering being on topic.)
I felt no reason to address them since they're stuck in the tangent discussion about redoing the entire markup system from top to bottom... again...
My experience based on 7 years of MediaWiki development is that this line of discussion has consistently lead to nothing useful being produced.
Rather than go in circles for the millionth time, I recommend sticking to definable, achievable goals which can build on each other -- such as the original topic of this thread.
To wrap them up for you:
- This will fundamentally change mediawiki and the consequences of this
feature have not been considered
The direct consequence is that in the short term we'll actually be able to achieve the situation that normal people will be able to edit articles containing templates.
Having this infrastructure in place further means we're in a better position to someday make a major markup transition (say to a different markup system or not exposing markup at all in a pure-WYSIWYG environment)... something we're now very far from... but doesn't commit us to any markup changes in the near or medium term.
Morever this is all based on existing discussion, knowledge, and experience, not some sudden invention that's never been considered before.
The current work here is most directly inspired by existing systems in the German Wikipedia's Vorlagen-Meister gadget and the Semantic Forms extension... We're hardly creating an idea from whole cloth here; this is real stuff that's been done before in parts and needs to be cleaned up and modernized for Wikipedia's needs.
- We cannot evaluate the repercussions of this feature with respect to our
broader vision for mediawiki because we (by which I mean we, not you personally) do not have one.
Broadly, our strategy is as it always has been: to identify and implement real, measurable benefits to the reading and editing experiences of Wikipedia and other sites.
-- brion
Brion Vibber wrote:
... Having this infrastructure in place further means we're in a better position to someday make a major markup transition (say to a different markup system or not exposing markup at all in a pure-WYSIWYG environment)... something we're now very far from... but doesn't commit us to any markup changes in the near or medium term. ... -- brion
On that note, what happened to Creole? I looked at the Creole wiki some time ago, and I remember a good deal of notes on how MediaWiki could handle Creole implementation.
I haven't heard anything about creole on the wikitech list though.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
On 9/28/09 12:56 PM, Daniel Friesen wrote:
On that note, what happened to Creole? I looked at the Creole wiki some time ago, and I remember a good deal of notes on how MediaWiki could handle Creole implementation.
I haven't heard anything about creole on the wikitech list though.
Dead as a doornail; there was never a clear benefit or incentive for anyone to move to it. You just end up with different confusing squiggly characters, and to get there you've had either an ugly transition or some kind of bizarre translation that's likely to break.
If you're going to go through the pain, you should get some tangible benefit out of it.
-- brion
Brian wrote:
On Fri, Sep 25, 2009 at 12:30 PM, Trevor Parscal wrote:
- The topic is supposed to be on Template Editing which is, at least in the way it's being proposed, a little less of a stale topic - so where is all the energy on that front? We have an XML format to design and complex problems to sort out. Help is really needed. Let's all take a look at the link provided at the beginning of this thread http://usability.wikimedia.org/wiki/Template_forms
- Trevor
I do think that sufficient energy has been directed at this topic. People have complained that xml is harder to edit that wikitext and that it is too complicated, among other things.
I think this is an important point.
XML is hard to edit. That's the reason wikitext was created, to "fix" the issues with the, even easier, html. Now, it is being proposed to add a XML processing on top of wikitext to describe templates.
Those descriptions will have to be edited by the same user base that edit all other pages. Even if they are power users, it's not easy to write correct XML on the wiki textarea. We would need to create an editor for the language being created so a template editor can be made.
Look at http://strategy.wikimedia.org/wiki/Call_for_participation/Task_force_applica... It is a form definition, but the fields were defined like * Name [SMALL TEXT FIELD] * Email [SMALL TEXT FIELD]
It doesn't have a formal definition and is thus ambiguous, but it's an example on how to make an user-friendly forms.
I advocate for a simpler syntax for form definition (but we shouldn't on the way reinvent wikitext).
What about creating a <documentation> tag extension, with the elements defined as a list? It would implicitely be <noinclude> If there're several instances, they are equivalent as one instance whose content is the concatenation of all of them (so parameters can be documented inline).
For the example template, we could have: <documentation> *Author: Person who made the work. Anonymous works not allowed.
*License: License under which the work can be used. The license must be determined by the copyright holder, if in doubt, ask on the [[WP:Village Pump|]]. </documentation>
We have two parameters: Author and License, with a short description suitable as a caption, and a longer description available. Both fields can allow wikitext (except list items for obvious reasons).
The syntax is simple to understand, and even with no special software, it can be consulted by anyone.
Now we add parameters and form typing: <documentation> *Author:[TEXT] Person who made the work. Anonymous works not allowed.
*License:{GFDL|CC-BY-SA}[Dropdown] License under which the work can be used. The license must be determined by the copyright holder, if in doubt, ask on the [[WP:Village Pump|]]. *Restrictions:[TEXTAREA] Additional restrictions imposed by the author. </documentation>
As expected, it gets a bit uglier, but it's still straightforward.
2009/9/25 Platonides Platonides@gmail.com:
Those descriptions will have to be edited by the same user base that edit all other pages. Even if they are power users, it's not easy to write correct XML on the wiki textarea. We would need to create an editor for the language being created so a template editor can be made.
Since the XML file describes the template, it need only be changed when the template is changed. Realistically, newbie editors don't edit templates; anyone skilled enough to edit templates can handle some simple XML.
I advocate for a simpler syntax for form definition (but we shouldn't on the way reinvent wikitext).
Exactly. XML is a decent choice here because it has a well-defined, pre-existing grammar with parsers already available, which means it's easy to parse and easy to learn (assuming you've got some shred of a technical background; see my earlier point about newbies not editing templates).
Roan Kattouw (Catrope)
On 9/25/09 3:39 PM, Roan Kattouw wrote:
2009/9/25 PlatonidesPlatonides@gmail.com:
Those descriptions will have to be edited by the same user base that edit all other pages. Even if they are power users, it's not easy to write correct XML on the wiki textarea. We would need to create an editor for the language being created so a template editor can be made.
Since the XML file describes the template, it need only be changed when the template is changed. Realistically, newbie editors don't edit templates; anyone skilled enough to edit templates can handle some simple XML.
I advocate for a simpler syntax for form definition (but we shouldn't on the way reinvent wikitext).
Exactly. XML is a decent choice here because it has a well-defined, pre-existing grammar with parsers already available, which means it's easy to parse and easy to learn (assuming you've got some shred of a technical background; see my earlier point about newbies not editing templates).
My preference is that we shouldn't actually expose the template definition markup at all during the normal course of events, even when changing a template.
The field metadata can be fairly straightforwardly displayed and edited through a nice web interface. XML as such is simply a conveniently well-defined structured data tree format which can be used both for storing the field metadata in the DB and exposing it to the template invocation editor interface (whether client-side JS or server-side PHP or a custom bot-based tool speaking to our API).
Of course if template creators *want* to dive into the raw field metadata definition as humans, we do love to expose such things to power power users for them to play with. :)
-- brion
On Fri, Sep 25, 2009 at 6:48 PM, Brion Vibber brion@wikimedia.org wrote:
The field metadata can be fairly straightforwardly displayed and edited through a nice web interface. XML as such is simply a conveniently well-defined structured data tree format which can be used both for storing the field metadata in the DB and exposing it to the template invocation editor interface (whether client-side JS or server-side PHP or a custom bot-based tool speaking to our API).
Depending on what features are added, exactly, I'd imagine a lighter-weight markup language would be more than sufficient. Something where you can describe the syntax in less than a page and write a correct implementation in half an hour or less would probably be good enough. Like maybe just newline-delimited key=value pairs, or something like JSON at worst.
Like YAML?
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
Aryeh Gregor wrote:
On Fri, Sep 25, 2009 at 6:48 PM, Brion Vibber brion@wikimedia.org wrote:
The field metadata can be fairly straightforwardly displayed and edited through a nice web interface. XML as such is simply a conveniently well-defined structured data tree format which can be used both for storing the field metadata in the DB and exposing it to the template invocation editor interface (whether client-side JS or server-side PHP or a custom bot-based tool speaking to our API).
Depending on what features are added, exactly, I'd imagine a lighter-weight markup language would be more than sufficient. Something where you can describe the syntax in less than a page and write a correct implementation in half an hour or less would probably be good enough. Like maybe just newline-delimited key=value pairs, or something like JSON at worst.
On 9/27/09 4:25 AM, Aryeh Gregor wrote:
Depending on what features are added, exactly, I'd imagine a lighter-weight markup language would be more than sufficient. Something where you can describe the syntax in less than a page and write a correct implementation in half an hour or less would probably be good enough. Like maybe just newline-delimited key=value pairs, or something like JSON at worst.
I don't see any point to inventing yet another markup language for internal data transfer; I'd much rather use something that:
1) is a known, implemented standard 2) has standard support in PHP 3) has standard support in JavaScript
If you feel the need to describe the syntax, you've already lost time and gained nothing. :)
-- brion
On Wed, Sep 30, 2009 at 8:29 PM, Brion Vibber brion@wikimedia.org wrote:
I don't see any point to inventing yet another markup language for internal data transfer; I'd much rather use something that:
- is a known, implemented standard
- has standard support in PHP
- has standard support in JavaScript
If you feel the need to describe the syntax, you've already lost time and gained nothing. :)
You've gained ease of use, because people don't have to bother learning how to use their language's standard library for the language, if it even has one. Is XML reliably supported in JavaScript? And didn't we have problems with PHP on RHEL not supporting the XML library that was supposed to be standard?
If you can describe the language with a one-line regex, you're using a parser that's in *every* language out there, and that *every* programmer should already be familiar with. Not to mention they could just copy-paste the regex even if they don't know regex, modulo some slashes if their language prefers POSIX. If it can be described by one or two explode()s (like key=val;val;val), even better.
Of course, this can get ugly if you later want to add more capabilities to the format, so JSON or YAML might make sense, but XML is overboard IMO. I'd use XML for text markup only, if that.
But no point in bikeshedding -- if this gets done, whoever does it gets to decide the format.
On 9/30/09 5:59 PM, Aryeh Gregor wrote: [snip]
Of course, this can get ugly if you later want to add more capabilities to the format, so JSON or YAML might make sense, but XML is overboard IMO. I'd use XML for text markup only, if that.
But no point in bikeshedding -- if this gets done, whoever does it gets to decide the format.
Yep. :) The main reasons to look at XML specifically (vs say JSON which is also available built-in for both our server and client sides) is that building a structure that's localization-friendly is straightforward, since you can easily tack on a 'lang' attribute. This could be done in JSON but probably with a different tree structure.
Given we already had a proposed XML structure designed at the start of this thread (based in part on the previous work on German Wikipedia), I don't see much reason to continue talking formats unless there's an alternative structure proposal with solid benefits.
-- brion
-----Original Message----- From: wikitech-l-bounces@lists.wikimedia.org [mailto:wikitech-l-bounces@lists.wikimedia.org] On Behalf Of Roan Kattouw Sent: 25 September 2009 23:39 To: Wikimedia developers Subject: Re: [Wikitech-l] Proposal for editing template calls within pages
2009/9/25 Platonides Platonides@gmail.com:
Those descriptions will have to be edited by the same user
base that
edit all other pages. Even if they are power users, it's
not easy to
write correct XML on the wiki textarea. We would need to create an
editor for the language being created so a template editor
can be made.
Since the XML file describes the template, it need only be changed when the template is changed. Realistically, newbie editors don't edit templates; anyone skilled enough to edit templates can handle some simple XML.
I advocate for a simpler syntax for form definition (but we
shouldn't
on the way reinvent wikitext).
Exactly. XML is a decent choice here because it has a well-defined, pre-existing grammar with parsers already available, which means it's easy to parse and easy to learn (assuming you've got some shred of a technical background; see my earlier point about newbies not editing templates).
Roan Kattouw (Catrope)
One thing I think might be missing from the example template description is all the implicit parameters it depends on, like language.
Jared
Roan Kattouw wrote:
2009/9/25 Platonides:
Those descriptions will have to be edited by the same user base that edit all other pages. Even if they are power users, it's not easy to write correct XML on the wiki textarea. We would need to create an editor for the language being created so a template editor can be made.
Since the XML file describes the template, it need only be changed when the template is changed. Realistically, newbie editors don't edit templates; anyone skilled enough to edit templates can handle some simple XML.
But why make it harder? You could also stat that anyone skilled enough to edit templates can handle <new complex syntax>. I wouldn't feel comfortable mannually editing XML. Or worse, reviewing XML written by others that is invalid (How are you going to handle that?).
I advocate for a simpler syntax for form definition (but we shouldn't on the way reinvent wikitext).
Exactly. XML is a decent choice here because it has a well-defined, pre-existing grammar with parsers already available, which means it's easy to parse and easy to learn (assuming you've got some shred of a technical background; see my earlier point about newbies not editing templates).
Roan Kattouw (Catrope)
However, it's not easy to type. It's convenient just for developers. XML has the advantage of having many editors available, but if I need an external editor, the system is broken.
On Fri, Sep 25, 2009 at 2:57 PM, Platonides Platonides@gmail.com wrote:
Brian wrote:
On Fri, Sep 25, 2009 at 12:30 PM, Trevor Parscal wrote:
* The topic is supposed to be on Template Editing which is, at least in the way it's being proposed, a little less of a stale topic - so where is all the energy on that front? We have an XML format to design and complex problems to sort out. Help is really needed. Let's all take a look at the link provided at the beginning of this thread http://usability.wikimedia.org/wiki/Template_forms
- Trevor
I do think that sufficient energy has been directed at this topic. People have complained that xml is harder to edit that wikitext and that it is too complicated, among other things.
I think this is an important point.
XML is hard to edit. That's the reason wikitext was created, to "fix" the issues with the, even easier, html. Now, it is being proposed to add a XML processing on top of wikitext to describe templates.
<snip>
Unless expressly forbidden by the software implementation, I would assume that "helpful" Wikipedians would very quickly write template description templates to replace the XML and give it a "nice" wiki interface. So, in practice, the question of whether XML is hard to edit will probably be moot and reduced solely to the issue that templates are hard to edit.
-Robert Rohde
On 9/25/09 6:11 PM, Robert Rohde wrote:
On Fri, Sep 25, 2009 at 2:57 PM, PlatonidesPlatonides@gmail.com wrote:
Brian wrote: XML is hard to edit. That's the reason wikitext was created, to "fix" the issues with the, even easier, html. Now, it is being proposed to add a XML processing on top of wikitext to describe templates.
<snip>
Unless expressly forbidden by the software implementation, I would assume that "helpful" Wikipedians would very quickly write template description templates to replace the XML and give it a "nice" wiki interface. So, in practice, the question of whether XML is hard to edit will probably be moot and reduced solely to the issue that templates are hard to edit.
It's unlikely that many people will ever see or edit the XML as there'll be a perfectly good structured user interface.
-- brion
wikitech-l@lists.wikimedia.org