On 22 December 2010 12:29, wiki doc.wikipedia@ntlworld.com wrote:
- WYSIWYG would be fantastic, but I've no idea what that would meet in
practice.
It's been desperately wanted for years and is no closer now than it ever was.
Just some thoughts. I suspect to solve these problems would need some serious investment - but I just see Wikipedia slowly becoming dated. (Of course those who grew up on it will say it is "fine" - but then that's the way with everything.)
I have on occasion thought the best thing to do about the Wikipedia community would be for it to implode as fast as possible. I've thought this since about 2006 and the encyclopedia has vastly improved in that time, so I might be wrong. The community does, however, frequently sum the total of human stupidity.
- d.
on 12/22/10 7:42 AM, David Gerard at dgerard@gmail.com wrote:
I have on occasion thought the best thing to do about the Wikipedia community would be for it to implode as fast as possible. I've thought this since about 2006 and the encyclopedia has vastly improved in that time, so I might be wrong. The community does, however, frequently sum the total of human stupidity.
It must be very lonely out there where you are, David.
Marc Riddell
On Wed, Dec 22, 2010 at 4:42 AM, David Gerard dgerard@gmail.com wrote:
On 22 December 2010 12:29, wiki doc.wikipedia@ntlworld.com wrote:
- WYSIWYG would be fantastic, but I've no idea what that would meet in
practice.
It's been desperately wanted for years and is no closer now than it ever was.
I am not 100% convinced of this, but my current overwhelming inclination is to state that WYSIWYG is incompatible with existing MediaWiki markup, and therefore requires a Flag Day conversion to a new encoding scheme which is less compact but also unambiguous and properly specified from the beginning.
Which may not be community practical, given how much people invested in existing markup customization to get little graphics benefits now.
On the other hand, that question has never been presented as such to the community in general and the markup coder wizards who did a lot of the complex templates and such in particular. It might be worth the Foundation and CTO taking a run at discussing it with the community writ large.
So the question is, is lack of WYSIWIG in the mid to long term a painful enough problem to justify the short to mid term disruptions that converting away from Wikitext would require? I don't know the answer to that.
I have to disagree strongly with the calls for WYSIWYG editing, not that it's likely to materialize anytime soon. Wikipedia needs to encourage people to concentrate on meaningful content, not dick around with cosmetic matters.
Inline citations seriously hamper editing, however, and ways of keeping such clutter out of the edit box can and should be developed. Doing so would help editors to concentrate on content.
I largely agree with most of Doc's other suggestions, and sadly agree that it's too late to roll back the jargon. The time to curb that tendency was before the population explosion of 2005/2006.
I would honestly say that the existing markup has long outlived its usefulness. Editors should not only be free from dealing with intricate markup, they should actually lack the tools and markup to do such complex formatting because it is detremental to writing an encyclopedia.
Instead of wysiwyg how aboud wysiwym (what you see is what you mean) with clean symantic markup and all the issues of styling handled out of site by the software through stylesheets. This would not only make editing easier but also hold us to a high standard of consistancy while enabling us to reach better quality standards and allowing us to build better tools on top of that framework.
Of further concern to me is that we have far exceeded the limits of a wiki as an effective collaboration platform. Collaboration at small scale remains possible but talk pages dont scale well at all to tens of thousands of users.
Further the software was never designed to be used in the way we use it to implement process on wiki. Complex template based processes and conversations based around heavy template usage are unnatural, inefiicent, error prone, and have too steep a learning curve for newcomers.
These issues are critical to fix if we are to scale but there is so much inertia that i fear it would only be possible if changes were forced. There are a lot of well established editors that actually benefit from the status quo - the complexity and confusion inherent to policy process and discussion tend to create a sort of inner circle of editors that can effectively leverage the situation to their advantage through the combination of knowledge and persistance.
On 12/22/10, Tony Sidaway tonysidaway@gmail.com wrote:
I have to disagree strongly with the calls for WYSIWYG editing, not that it's likely to materialize anytime soon. Wikipedia needs to encourage people to concentrate on meaningful content, not dick around with cosmetic matters.
Inline citations seriously hamper editing, however, and ways of keeping such clutter out of the edit box can and should be developed. Doing so would help editors to concentrate on content.
I largely agree with most of Doc's other suggestions, and sadly agree that it's too late to roll back the jargon. The time to curb that tendency was before the population explosion of 2005/2006.
WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
On Thu, Dec 23, 2010 at 3:18 AM, Stephanie Daugherty sdaugherty@gmail.com wrote:
Of further concern to me is that we have far exceeded the limits of a wiki as an effective collaboration platform. Collaboration at small scale remains possible but talk pages dont scale well at all to tens of thousands of users.
Most articles don't have tens of thousands of users. Most only have tens to fifties. Only the very largest discussions need to involve all active users, and even there the numbers taking part are not in the tens of thousands.
Further the software was never designed to be used in the way we use it to implement process on wiki. Complex template based processes and conversations based around heavy template usage are unnatural, inefiicent, error prone, and have too steep a learning curve for newcomers.
I agree templates can be confusing, but they provide great flexibility. If you are going to move to a different system, it has to be one that editors can make changes to and not rely on developers to make requested changes.
These issues are critical to fix if we are to scale but there is so much inertia that i fear it would only be possible if changes were forced. There are a lot of well established editors that actually benefit from the status quo - the complexity and confusion inherent to policy process and discussion tend to create a sort of inner circle of editors that can effectively leverage the situation to their advantage through the combination of knowledge and persistance.
Most policy discussion and process doesn't affect articles, surprisingly enough. Not directly, anyway. To be able to edit articles well, all you really need is a general sense of how things work (using examples from other articles that are clearly good examples), a willingness to learn and discuss with others, some good sources to work with, a basic ability to write and organise your thoughts, being able to balance what different sources are saying, and some common sense.
Everything else is instruction creep, but often useful instruction creep as long as you don't pay too much attention to it. Pay attention to it when you need to, but at other times just use common sense and ask yourself if what you are doing will improve, or lead to an improvement in, an article or set of articles.
Carcharoth
On Thu, Dec 23, 2010 at 2:44 AM, Carcharoth carcharothwp@googlemail.comwrote:
On Thu, Dec 23, 2010 at 3:18 AM, Stephanie Daugherty sdaugherty@gmail.com wrote:
Of further concern to me is that we have far exceeded the limits of a wiki as an effective collaboration platform. Collaboration at small scale remains possible but talk pages dont scale well at all to tens of thousands of users.
Most articles don't have tens of thousands of users. Most only have tens to fifties. Only the very largest discussions need to involve all active users, and even there the numbers taking part are not in the tens of thousands.
I agree with you there. However, at any given time, that's a good
guestimate of how many editors we have that can reasonably be considered "active". The typical numbers are probably in the neighborhood of 25-500 depending on the issue, and those discussions fall apart even at that scale. Current "archiving" and "hatboxes" can be extremely disruptive to discussions at project-level, but they are absolutely necessary under the current system in order to keep the page readable. Project-scale discussions are important because they do affect "everybody", in that every participant in the project is a stakeholder, and they are vitally important in guiding our future, yet, in most cases, they break down long before anything resembling consensus can be reached. The combination of talk page structure and a vigorous discussion can make it very easy to keep growing a conversation without ever making progress towards consensus, and with only a little persistance required to take part, we have our own form of fillibuster that allows only a very small handful of editors to preserve the status quo on almost any issue by keeping the discussion moving away from consensus. The process of large discussions is so painful and stressful that it's been a major factor in retirements and wikisuicides - editors that are passionate enough about the project to participate in these sort of discussions tend to be scarred pretty badly by the experience.
Further the software was never designed to be used in the way we use it to implement process on wiki. Complex template based processes and conversations based around heavy template usage are unnatural, inefiicent, error prone, and have too steep a learning curve for newcomers.
I agree templates can be confusing, but they provide great flexibility. If you are going to move to a different system, it has to be one that editors can make changes to and not rely on developers to make requested changes.
For it to be an improvement over the current system, I think it needs to be
an in-between. There needs to be enough "cost" to implementing and changing a template that it's not a trivial thing to do, otherwise we'll see "template creep" continue to be a problem. Templates simply shouldn't work in a lot of the ways they are now used. Our AFD process is an example of "template creep" going too far. It's a heavily template driven process, that's confusing and unwieldy enough that the "regulars" tend to use javascript tools just to navigate through it. Templates weren't built to do things that complicated, and using them in a way like that is prone both to breakage, and to scaring users off.
As a radical solution, define templates at the page level. One article, one template. Give us a form-based interface to move through a template-based article. Make heavy use of advanced formatting within the templates themselves if you must, but advanced formatting should be completely absent from articles themselves - in other words, templates should have access to more markup than articles, and articles should lose the ability to use the more complex markup features.
This sort of approach has a few advantages to us. The biggest is that it allows us to impose a consistent style on articles. which would give us a more professional feel, and would allow us to make changes across the project in a consistent manner. The second advantage, is that it gives editors a framework, to know what kind of information we want to see within an article. Templates become a sort of standard outline for an article as opposed to the sort of templates we are used to.
Aside from that, move the articles towards semantic markup, and define styles for that markup across the project. A new "what you see is what you mean" editor for that markup would completely remove any need for formatting considerations from the average editor, make it easy to produce content for that markup, and would enable software tools to be used more effectively (and in many cases, more safely) for the advanced users. It may even make it possible to validate content to some degree for accuracy as well as spelling, grammar, and style.
These issues are critical to fix if we are to scale but there is so much inertia that i fear it would only be possible if changes were forced. There are a lot of well established editors that actually benefit from the status quo - the complexity and confusion inherent to policy process and discussion tend to create a sort of inner circle of editors that can effectively leverage the situation to their advantage through the combination of knowledge and persistance.
Most policy discussion and process doesn't affect articles, surprisingly enough. Not directly, anyway. To be able to edit articles well, all you really need is a general sense of how things work (using examples from other articles that are clearly good examples), a willingness to learn and discuss with others, some good sources to work with, a basic ability to write and organise your thoughts, being able to balance what different sources are saying, and some common sense.
Everything else is instruction creep, but often useful instruction creep as long as you don't pay too much attention to it. Pay attention to it when you need to, but at other times just use common sense and ask yourself if what you are doing will improve, or lead to an improvement in, an article or set of articles.
Good point. IAR is something a lot of us need to be reminded of. I think a
lot of the problems that happen are where someone tries to move from working at an article or topic area into policy areas. This happens for various reasons. Sometimes an editor gets drawn into the issue when they get "bitten" by another editor applying that policy too forcefully. Sometimes they see something done a certian way and ask "why can't we do it this way, it would be better". Sometimes they have an interest in the janitorial aspect, or they may just truly take interest in policy. Swimming in a river of piranhas would be more pleasant than many of the first experiences people have with project-wide collaboration, and if they care enough to stay in that river, they keep getting bitten for their efforts. That's the sort of thing I'm most concerned about - editors that have a genuine interest in making the project better often end up pushed to retirement or wikisuicide. The "Beware of the tigers" essay is a good read here, but the problem is that, where policy is concerned, it's often a jungle full of them.
Consensus decisionmaking is an important part of our heritage and our future as Wikipedia, but at this stage, and at this scale, we need to look hard at how we implement it as a process, particularly at how we resolve the stalemates, deadlocks, and fillibusters. We are often paralyzed where it comes to the sort of technical and policy reforms that we need to preserve and improve effectiveness, editorial integrity, and fair process, and that has lead to a Wikipedia that can't sustain the sort of growth we've experienced without a high rate of attrition. The people we lose from this are too often our best editors - highly skilled article writers, wikignomes, tool authors, and janitors, and that hurts us badly - even if the project will go on without them, we lose tremendous opertunities to be better every time we chase off someone dedicated.
It would be worth reconsidering some sort of community leadership position going forward. In the early days, that was Jimbo's role, but as the project matured, that was diminished, and we developed into a huge community without much in the way of a clear vision or direction. I don't think we need to create another "GodKing" type position, but we do need someone in a position to guide us gently in the right direction when high-level conflicts would otherwise stall us. I'd say the role needs to have some functions for conflict resolution and moderation, as well as for determining consensus. This would keep ArbCom from having to become involved in many high-level disputes. It doesn't necessarily have to come with any special software permissions, and doesn't even require that someone be an administrator, but it does need to come with enough authority to break up conflicts and deadlocks relatively early, and could take the shape of an elected committee structured similarly to ArbCom. For a start, the job would primarily be that to mediate. Where mediation fails, the authority would need to exist to interpret whether or not consensus exists, and to determine or implement processes for moving a deadlocked discussion towards consensus - imposing structured discussions at first, and if there's agreement for that sort of thing, administering advisory and official polls when there's no other way to reach a decision. The ability to impose an interim solution to an editing conflict would be nice, but I'm wary of that as I'm sure others will be, so I think we'd need to see how it went first. The idea is that community leaders would deal with conflict, while arbitrators would continue to deal with misconduct.
Anyway, I'm already bordering on TL:DR material here, but I think there's plenty of food for thought here :)
Carcharoth
WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
On 23 December 2010 02:37, Tony Sidaway tonysidaway@gmail.com wrote:
I have to disagree strongly with the calls for WYSIWYG editing, not that it's likely to materialize anytime soon. Wikipedia needs to encourage people to concentrate on meaningful content, not dick around with cosmetic matters.
I think our current markup is one of our biggest barriers to participation.
I don't have WMF numbers, but one contributor on mediawiki-l, who runs an intranet covering a large public service organisation in the US, reported a remarkable uptake in wiki participation just by going to FCKeditor. The users are smart, capable and competent people in their fields, but were seriously put off by wikitext.
- d.
On 23 December 2010 08:41, David Gerard dgerard@gmail.com wrote:
I don't have WMF numbers, but one contributor on mediawiki-l, who runs an intranet covering a large public service organisation in the US, reported a remarkable uptake in wiki participation just by going to FCKeditor. The users are smart, capable and competent people in their fields, but were seriously put off by wikitext.
I took a look at this:
While that demo doesn't really match what a fully integrated Mediawiki-based WYSIWYG editor would look like (no internal links so you have to enter the full URL for every link, for instance), it does give a taste for how ckeditor would differ from the plain text and markup we use now.
Personally I find that kind of stuff hopelessly confusing and off-putting, and I would hate to have to use it, but I take your point that it might improve takeup for people who find to messing with complex toolbars easier than learning half a dozen simple text markup rules ([[a|b]], [a b], ''italic'', ''bold''',' <ref name=></ref>, ==section==).
On 23 December 2010 10:33, Tony Sidaway tonysidaway@gmail.com wrote:
Personally I find that kind of stuff hopelessly confusing and off-putting, and I would hate to have to use it, but I take your point that it might improve takeup for people who find to messing with complex toolbars easier than learning half a dozen simple text markup rules ([[a|b]], [a b], ''italic'', ''bold''',' <ref name=></ref>, ==section==).
To clarify my skepticism, the complexity of Wikipedia doesn't arise at the user interface level at all but at the level of social interaction. This is unavoidable because you're dealing with other human beings, not a machine. The complexity is necessary, even desirable, for exactly the same reason.
On 23 December 2010 10:43, Tony Sidaway tonysidaway@gmail.com wrote:
To clarify my skepticism, the complexity of Wikipedia doesn't arise at the user interface level at all but at the level of social interaction. This is unavoidable because you're dealing with other human beings, not a machine. The complexity is necessary, even desirable, for exactly the same reason.
True. However, the markup is really an important way to put off the n00bs. People who are used to wikitext don't believe it, and say "but I'd think that XXX" - but here's the data point:
http://lists.wikimedia.org/pipermail/mediawiki-l/2010-May/034062.html
"I have to disagree with you given my experience. In one government department where MediaWiki was installed we saw the active user base spike from about 1000 users to about 8000 users within a month of having enabled FCKeditor. FCKeditor definitely has it's warts, but it very closely matches the experience non-technical people have gotten used to while using Word or WordPerfect. Leveraging skills people already have cuts down on training costs and allows them to be productive almost immediately."
http://lists.wikimedia.org/pipermail/mediawiki-l/2010-May/034071.html
"Since a plethora of intelligent people with no desire to learn WikiCode can now add content, the quality of posts has been in line with the adoption of wiki use by these people. Thus one would say it has gone up.
"In the beginning there were some hard core users that learned WikiCode, for the most part they have indicated that when the WYSIWYG fails, they are able to switch to WikiCode mode to address the problem. This usually occurs with complex table nesting which is something that few of the users do anyways. Most document layouts are kept simple. Additionally, we have a multilingual english/french wiki. As a result the browser spell-check is insufficient for the most part (not to mention it has issues with WikiCode). To address this a second spellcheck button was added to the interface so that both english and french spellcheck could be available within the same interface (via aspell backend)."
The main problem with WYSIWYG on WMF sites is fidelity with the existing body of wikitext, which has editors exploiting every horrible edge case you can imagine to get an effect. Tim said a few years ago that any solution has to account for the existing body of text.
Oh, and that FCKeditor (now CKeditor) in MediaWiki is all but unmaintained ...
- d.
On 23 December 2010 10:55, David Gerard dgerard@gmail.com wrote:
On 23 December 2010 10:43, Tony Sidaway tonysidaway@gmail.com wrote:
To clarify my skepticism, the complexity of Wikipedia doesn't arise at the user interface level at all but at the level of social interaction. This is unavoidable because you're dealing with other human beings, not a machine. The complexity is necessary, even desirable, for exactly the same reason.
True. However, the markup is really an important way to put off the n00bs. People who are used to wikitext don't believe it, and say "but I'd think that XXX" - but here's the data point:
You've convinced me. This in particular:
"[CKEditor] very closely matches the experience non-technical people have gotten used to while using Word or WordPerfect. Leveraging skills people already have cuts down on training costs and allows them to be productive almost immediately."
For me WYSIWYG is synonymous with annoying stuff that gets in the way of the code I want to write, and of course I take it as read that the code stands for a procedural or functional abstraction of what the computer is supposed to do. I don't find it difficult, but then I've been doing it since I was in the lower sixth at school when I had to type computer instructions on a teletype connected to a land line by acoustic coupler.
Not everybody works that way. Most of us don't. To those people the buttons I find annoying may be the only thing they *do* understand, they're the most accessible way of using a computer, and a user interface lacking those buttons is alien and incomprehensible. With the buttons, these people are intuitively able to produce a reasonable minimal subset of tasks immediately as long as the result of their work is displayed immediately (WYSIWYG).
It's still annoying, though.
On 23 December 2010 11:48, Tony Sidaway tonysidaway@gmail.com wrote:
Not everybody works that way. Most of us don't. To those people the buttons I find annoying may be the only thing they *do* understand, they're the most accessible way of using a computer, and a user interface lacking those buttons is alien and incomprehensible. With the buttons, these people are intuitively able to produce a reasonable minimal subset of tasks immediately as long as the result of their work is displayed immediately (WYSIWYG). It's still annoying, though.
Yeah. It won't be a happener on WMF sites, I think, until WMF has money to throw at developers to develop something that actually works and has fidelity with wikitext as it's used. This is a *big and hairy* problem that interested parties have been dashing their foreheads against for *years*.
- d.
On Thu, Dec 23, 2010 at 3:51 AM, David Gerard dgerard@gmail.com wrote:
On 23 December 2010 11:48, Tony Sidaway tonysidaway@gmail.com wrote:
Not everybody works that way. Most of us don't. To those people the buttons I find annoying may be the only thing they *do* understand, they're the most accessible way of using a computer, and a user interface lacking those buttons is alien and incomprehensible. With the buttons, these people are intuitively able to produce a reasonable minimal subset of tasks immediately as long as the result of their work is displayed immediately (WYSIWYG). It's still annoying, though.
Yeah. It won't be a happener on WMF sites, I think, until WMF has money to throw at developers to develop something that actually works and has fidelity with wikitext as it's used. This is a *big and hairy* problem that interested parties have been dashing their foreheads against for *years*.
Right.
The social stuff which is complex is something which is a barrier, but one that all western society members who are modern communications literate are fundamentally equipped to handle. Some will fail at it but you really just need to be good at electronic communications, functionally literate, and social enough to handle basic give and take discussions.
Very few people master the markup; very many fewer than that can hack or understand the underlying code. I'm a coder; I've dived into the MW parser on and off, and other parts of it, to understand functional behaviors better. But I also do outreach and computer training at times, and most normal people could never approach that level, and find wiki markup onerous when I ask them about it...
It appears from recent debates that Wikipedia shifted from a problem of Scientology promotion, to a situation where some editors were using Wikipedia to document every negative aspect of the cult, and unbalancing/violating BLPs as a consequence.
For those not following it see stuff like: * http://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion/List_of_deaths_ related_to_Scientology *http://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion/Stacy_Meyer_%2 82nd_nomination%29
I have particular concerns with BLPs in categories like: http://en.wikipedia.org/wiki/Category:Former_Scientologists
Coatracks and questionable notability issues abound.
I've started a page to review our coverage of this and particularly of BLPs. As ever: help wanted; wages negotiable.
http://en.wikipedia.org/wiki/Wikipedia:Neutrality_in_Scientology
I think trying to bolt on WYSIWYG to the current parser is a mistake. Even if it "works" there will be complex markup cases still that are beyond a WYSIWYG editor (and way beyond 99% of potential editors). Either replace the current parser, or strip out the complicated parts systematically.
If you want to strip down the current parser, you could do this by making articles a small subset of the markup, and letting full markup be used in templates. Gradually depreciate, and then turn off features that are too complex. A good start would be HTML code in articles, it's not necessary, and it lets people introduce inconsistencies that look unprofessional, as well as leaves text in an article that's hard to edit.
If you want to start over, start simple, and think "WYSIWYM" (What you see is what you mean) rather than "WYSIWYG". That is, the editor should make it easy to see the structure of the text and edit it without concern for the final formatting. LyX is a good example of this sort of interface, although the underlying LaTeX markup probably isn't what we want (just as complex as what we have now, it's still too presentation oriented, etc).
If we end up replacing the parser, the only way to do that smoothly, would be to run both parsers at the same time during the transition period. Those articles that can be converted automatically are converted early on. Software restrictions (perhaps an edit filter) can prevent starting an article with the old markup, and discourage reverting to versions with the old markup. There would be a large number of articles that couldn't be automatically converted. There are a few ways to handle that. A large manual conversion effort would be needed. At some point, we should disallow saving changes to the old markup (forces editors to convert the article to edit it, or allow an automatic conversion that could break the article after a certian deadline.
In either case, the process would be painful, but would pay off in the end with improved editorship, and I suspect greatly improved article quality. Editors that aren't familiar with the more advanced markup constructs tend to have to dance around them when editing, and that makes editing harder, as well as leaves behind broken markup. That means a lot of fixes end up either not happening, or happening anyway, and doing more damage than what they are meant to fix.
This would amount to the largest usability project we've undertaken no mater how we go forward, but the payoffs would be enormous.
On Thu, Dec 23, 2010 at 4:31 PM, George Herbert george.herbert@gmail.comwrote:
On Thu, Dec 23, 2010 at 3:51 AM, David Gerard dgerard@gmail.com wrote:
On 23 December 2010 11:48, Tony Sidaway tonysidaway@gmail.com wrote:
Not everybody works that way. Most of us don't. To those people the buttons I find annoying may be the only thing they *do* understand, they're the most accessible way of using a computer, and a user interface lacking those buttons is alien and incomprehensible. With the buttons, these people are intuitively able to produce a reasonable minimal subset of tasks immediately as long as the result of their work is displayed immediately (WYSIWYG). It's still annoying, though.
Yeah. It won't be a happener on WMF sites, I think, until WMF has money to throw at developers to develop something that actually works and has fidelity with wikitext as it's used. This is a *big and hairy* problem that interested parties have been dashing their foreheads against for *years*.
Right.
The social stuff which is complex is something which is a barrier, but one that all western society members who are modern communications literate are fundamentally equipped to handle. Some will fail at it but you really just need to be good at electronic communications, functionally literate, and social enough to handle basic give and take discussions.
Very few people master the markup; very many fewer than that can hack or understand the underlying code. I'm a coder; I've dived into the MW parser on and off, and other parts of it, to understand functional behaviors better. But I also do outreach and computer training at times, and most normal people could never approach that level, and find wiki markup onerous when I ask them about it...
-- -george william herbert george.herbert@gmail.com
WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
Just to add, If we go with a new markup, make it XML based, please, and validate. There are existing tools for working with XML that can be leveraged both in building a parser, and in building interfaces and tools. XML assures that the markup is machine readable AND writable in all cases, which eliminates a lot of hell with using automated tools. Being easy to validate also eliminates a lot of hell with manually editing the code - you can make sure at the time text is saved that it will parse, even if it won't parse as expected, it will be easy to fix. We could even reuse an existing XML application like DocBook if so desired. Making it XML also means that upgrading the markup can be done less painfully in the future, even if the markup completely changes, XSLT offers a means to convert one XML markup to another predictably.
There's also a side benefit. Almost all modern browsers can parse, style, and display XML natively, either by directly applying CSS styles or by applying XSLT to render the XML as XHTML. That means we can offload the parsing to the browser if so desired, and we could eliminate a lot of overhead for the site in doing so.
The only major downside is that XML is much more verbose than wikimarkup. The learning code to produce basic documents directly (without a WYSIWYG or WYSIWYM editor) is a tad steeper, but becomes shallow after that, as once you understand the basics, everything else is easy. More verbose markup means more typing for those of us that do things by hand though, which does present a disadvantage. A good editing interface though with code completion, and a strong WYSIWYM or WYSIWYG editor with keyboard shortcuts would mostly negate this disadvantage.
On Sun, Dec 26, 2010 at 10:43 AM, Stephanie Daugherty sdaugherty@gmail.comwrote:
I think trying to bolt on WYSIWYG to the current parser is a mistake. Even if it "works" there will be complex markup cases still that are beyond a WYSIWYG editor (and way beyond 99% of potential editors). Either replace the current parser, or strip out the complicated parts systematically.
If you want to strip down the current parser, you could do this by making articles a small subset of the markup, and letting full markup be used in templates. Gradually depreciate, and then turn off features that are too complex. A good start would be HTML code in articles, it's not necessary, and it lets people introduce inconsistencies that look unprofessional, as well as leaves text in an article that's hard to edit.
If you want to start over, start simple, and think "WYSIWYM" (What you see is what you mean) rather than "WYSIWYG". That is, the editor should make it easy to see the structure of the text and edit it without concern for the final formatting. LyX is a good example of this sort of interface, although the underlying LaTeX markup probably isn't what we want (just as complex as what we have now, it's still too presentation oriented, etc).
If we end up replacing the parser, the only way to do that smoothly, would be to run both parsers at the same time during the transition period. Those articles that can be converted automatically are converted early on. Software restrictions (perhaps an edit filter) can prevent starting an article with the old markup, and discourage reverting to versions with the old markup. There would be a large number of articles that couldn't be automatically converted. There are a few ways to handle that. A large manual conversion effort would be needed. At some point, we should disallow saving changes to the old markup (forces editors to convert the article to edit it, or allow an automatic conversion that could break the article after a certian deadline.
In either case, the process would be painful, but would pay off in the end with improved editorship, and I suspect greatly improved article quality. Editors that aren't familiar with the more advanced markup constructs tend to have to dance around them when editing, and that makes editing harder, as well as leaves behind broken markup. That means a lot of fixes end up either not happening, or happening anyway, and doing more damage than what they are meant to fix.
This would amount to the largest usability project we've undertaken no mater how we go forward, but the payoffs would be enormous.
On Thu, Dec 23, 2010 at 4:31 PM, George Herbert george.herbert@gmail.comwrote:
On Thu, Dec 23, 2010 at 3:51 AM, David Gerard dgerard@gmail.com wrote:
On 23 December 2010 11:48, Tony Sidaway tonysidaway@gmail.com wrote:
Not everybody works that way. Most of us don't. To those people the buttons I find annoying may be the only thing they *do* understand, they're the most accessible way of using a computer, and a user interface lacking those buttons is alien and incomprehensible. With the buttons, these people are intuitively able to produce a reasonable minimal subset of tasks immediately as long as the result of their work is displayed immediately (WYSIWYG). It's still annoying, though.
Yeah. It won't be a happener on WMF sites, I think, until WMF has money to throw at developers to develop something that actually works and has fidelity with wikitext as it's used. This is a *big and hairy* problem that interested parties have been dashing their foreheads against for *years*.
Right.
The social stuff which is complex is something which is a barrier, but one that all western society members who are modern communications literate are fundamentally equipped to handle. Some will fail at it but you really just need to be good at electronic communications, functionally literate, and social enough to handle basic give and take discussions.
Very few people master the markup; very many fewer than that can hack or understand the underlying code. I'm a coder; I've dived into the MW parser on and off, and other parts of it, to understand functional behaviors better. But I also do outreach and computer training at times, and most normal people could never approach that level, and find wiki markup onerous when I ask them about it...
-- -george william herbert george.herbert@gmail.com
WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
-- Faith is about what you really truly believe in, not about what you are taught to believe.
On 12/23/10 1:31 PM, George Herbert wrote:
The social stuff which is complex is something which is a barrier, but one that all western society members who are modern communications literate are fundamentally equipped to handle. Some will fail at it but you really just need to be good at electronic communications, functionally literate, and social enough to handle basic give and take discussions.
This seems to beg the question: How do you define "modern communications literate"?
Ec
On Tue, Dec 28, 2010 at 4:47 AM, Ray Saintonge saintonge@telus.net wrote:
On 12/23/10 1:31 PM, George Herbert wrote:
The social stuff which is complex is something which is a barrier, but one that all western society members who are modern communications literate are fundamentally equipped to handle. Some will fail at it but you really just need to be good at electronic communications, functionally literate, and social enough to handle basic give and take discussions.
This seems to beg the question: How do you define "modern communications literate"?
Facebook, Gmail, Twitter, smartphone user.
Those are a 95%+ solution for kids and young adults, if not 99%, and are easy enough for older adults (my parents, etc) to the point that they're arguably better than an 80% solution for the US population.
If we were that good, we'd be golden.
On Tue, Dec 28, 2010 at 5:16 PM, George Herbert george.herbert@gmail.com wrote:
On Tue, Dec 28, 2010 at 4:47 AM, Ray Saintonge saintonge@telus.net wrote:
On 12/23/10 1:31 PM, George Herbert wrote:
The social stuff which is complex is something which is a barrier, but one that all western society members who are modern communications literate are fundamentally equipped to handle. Some will fail at it
<<
This seems to beg the question: How do you define "modern communications literate"?
Facebook, Gmail, Twitter, smartphone user.
Those are a 95%+ solution for kids and young adults, if not 99%, and are easy enough for older adults (my parents, etc) to the point that they're arguably better than an 80% solution for the US population.
Those examples are also widely used all over the world, including in regions where the Internet is still new.
Most highly popular services start by letting each participant define themselves, and the default contribution that people are encouraged to make is usually permament and not subject to removal by others.
One of the unkind and awkward aspects of the Wikipedia experience is, that the default requested contribution is an edit, new page, or upload, all of which may be reverted or followed by warnings and challenges, by people who expect you to RTFM to learn how to behave.
Some possible improvements: - add new things that all users are encouraged to contribute (first-class citizens of the list 'ways to further the project'), which are entirely within the user's control: information about themselves and their environment, joining wikiprojects and work groups, taking part in polls and usability studies, answering questions from other users and readers - make a user's contributions permanently visible to them, if not to others (modulo vandalism), taking advantage of permalinks and file histories, even when those contribs have for now been removed from the default public view(s) of an article, or when they have been quarantined from view by other users for concerns about copyright status. this improves on the crude tool of deletion and keeps contributors from feeling that their hard work has been destroyed or disrespected, often due only to it being incomplete or not-yet-proven-notable. - develop better sandboxing policies, tools, and effective sandbox environments, so that new users can truly experiment and get used to editing before they are challenged, reverted, deleted, and blocked.
Sam.
On Tue, Dec 28, 2010 at 6:09 PM, Samuel Klein meta.sj@gmail.com wrote:
Those examples are also widely used all over the world, including in regions where the Internet is still new.
Most highly popular services start by letting each participant define themselves, and the default contribution that people are encouraged to make is usually permament and not subject to removal by others.
One of the unkind and awkward aspects of the Wikipedia experience is, that the default requested contribution is an edit, new page, or upload, all of which may be reverted or followed by warnings and challenges, by people who expect you to RTFM to learn how to behave.
Some possible improvements:
- add new things that all users are encouraged to contribute
(first-class citizens of the list 'ways to further the project'), which are entirely within the user's control: information about themselves and their environment, joining wikiprojects and work groups, taking part in polls and usability studies, answering questions from other users and readers
- make a user's contributions permanently visible to them, if not to
others (modulo vandalism), taking advantage of permalinks and file histories, even when those contribs have for now been removed from the default public view(s) of an article, or when they have been quarantined from view by other users for concerns about copyright status. this improves on the crude tool of deletion and keeps contributors from feeling that their hard work has been destroyed or disrespected, often due only to it being incomplete or not-yet-proven-notable.
- develop better sandboxing policies, tools, and effective sandbox
environments, so that new users can truly experiment and get used to editing before they are challenged, reverted, deleted, and blocked.
Sam.
Soft deletion. I'm still a fan actually. While we still have way too many deleted revisions both from before and after oversight and revision deletion were introduced that are not fit to be seen, I think it would be worth revisiting a default form of deletion that preserves a public history, and reserving hard deletion and oversight-ish things for things that really need to go away forever.
With regard to copyright though, unfortunately, those deletions do need to be "hard". We can't knowingly let Wikipedia be used as a store for copyright violating materials, even if they are stored just for the benefit of one user, otherwise WMF could face legal liability issues.(Disclaimer: I'm not a lawyer, just an open source advocate with some personal interest in copyright law.) However, we should at least preserve a personal record of those contributions without the actual content, so that the user can understand why they were removed and learn from it.
-Steph
On 12/23/10 12:41 AM, David Gerard wrote:
On 23 December 2010 02:37, Tony Sidawaytonysidaway@gmail.com wrote:
I have to disagree strongly with the calls for WYSIWYG editing, not that it's likely to materialize anytime soon. Wikipedia needs to encourage people to concentrate on meaningful content, not dick around with cosmetic matters.
I think our current markup is one of our biggest barriers to participation.
I don't have WMF numbers, but one contributor on mediawiki-l, who runs an intranet covering a large public service organisation in the US, reported a remarkable uptake in wiki participation just by going to FCKeditor. The users are smart, capable and competent people in their fields, but were seriously put off by wikitext.
Wasn't the whole idea of wiki markup to have something simple that anybody can learn? It should continue to be the case that the essential wiki markup can fit onto a single page that an editor can print ans pin to the wall beside his computer as a cheat-sheet. What doesn't fit on that page isn't basic.
Templates are only useful if you know which are there if you need them, and have the advanced skills needed to manipulate them to desired effect.
Ec
On 28 December 2010 12:33, Ray Saintonge saintonge@telus.net wrote:
Wasn't the whole idea of wiki markup to have something simple that anybody can learn? It should continue to be the case that the essential wiki markup can fit onto a single page that an editor can print ans pin to the wall beside his computer as a cheat-sheet. What doesn't fit on that page isn't basic.
There's various levels here, all of which need to be removed:
* What doesn't fit on a single-page printed cheat sheet isn't basic. * What doesn't fit in a pop-up box on a single screen isn't basic. * What doesn't fit in a line under the edit box isn't basic. * Wikitext isn't basic unless you assume HTML, which you can't.
Wikitext is however powerful, and there are 160,000 editors in any given month on en:wp who cope with it. But that's a drop in the ocean.
- d.
On Tue, Dec 28, 2010 at 7:40 AM, David Gerard dgerard@gmail.com wrote:
There's various levels here, all of which need to be removed:
- What doesn't fit on a single-page printed cheat sheet isn't basic.
- What doesn't fit in a pop-up box on a single screen isn't basic.
- What doesn't fit in a line under the edit box isn't basic.
- Wikitext isn't basic unless you assume HTML, which you can't.
Wikitext is however powerful, and there are 160,000 editors in any given month on en:wp who cope with it. But that's a drop in the ocean.
Moving in the right direction. If we did this to articles, but not to
templates, we'd at least have the confusing parts "contained" in their own little "magic black box" (or green box, or however else you want to express a template in the editing interface.). We could reasonably get that down to Section tags, emphasis tags, table tags, image tags, hyperlinks, lists, and template transclusions, plus the nowiki and comment functions. Some may argue, but everything else is superfluous to editing an article, or could be wrapped up nice and neat as a template to hide the "deep magic" of wikitext from the layperson.
-Steph