Hi everyone,
There appear to be two separate discussions going on here... 1) whether wikiwyg is good/bad and all the permutations thereof, and 2) what's up with wikiwyg and SocialText/Wikia?
There are many pros and cons for #1 and it looks like this is a pretty healthy debate to which I'm not qualified to add anything. However, I can definitely shed some light on #2.
SocialText has developed a pretty nice wikiwyg interface for simple editing that they wanted to donate to MediaWiki... the issue was that they aren't currently using MediaWiki so they wanted some help in bringing it over and they also wanted a demo to show at WikiMania to demonstrate proof-of-concept. The idea was to get feedback on it at WikiMania to determine if this would be something the community would be interested in before trying to submit it to svn, etc. The good news is that there was plenty of interest.
We (Jimmy/Wikia) offered to help and so Jason was helping to make their code MediaWiki friendly and also put it into its own extension to make working on it cleaner (not yet complete). The main participants in this were Ingy and Gugod (SocialText), Travis (wikiHow), and Jason (Wikia). In order to make a proof-of-concept demo practical, we reduced the scope of what the wikiwyg editor would do so that we'd have something to show by the time WikiMania rolled around. Currently, it does the following:
* Basic in-page rich text editing (bold, italics, bullets, links, etc) which is saved as wikitext. * Recognizes when there is wikitext on the page that it can't parse and defaults to an in-page editor that just lets you edit the wikitext like normal. * Defaults to "disabled" on the page and you can enable it via a left-nav bar option.
The plan was also to have a drop-down list of simple templates that users could choose from and, as time permitted, start expanding that list as the wikiwyg functionality was increased. Obviously, this sort of thing will not spring out of Zeus' head full-grown, so this seemed like a good compromise to start with. One thing I do want to clear up is that we're not "being paid" to do this... we have *plenty* of other stuff on our to-do lists. This is a really interesting project so we decided to volunteer some time for it... same with SocialText and good for them to throw in code they'd already written.
As for the current discussion about whether wikiwyg is good or not, I can't contribute anything from the technical side but one thing to consider is that when introduced to some sites, wiki page editing went up 30% per month after introduction. So there are definite benefits to having a simpler editing interface. My own personal opinion is that with new tools come new ways of maintaining the quality of the content. Making things more available does not have to correlate to lesser quality. Actually, I believe the essence of the "lower barrier to entry = lesser quality" argument was originally applied to the concept of Wikipedia itself, wasn't it? (Not trying to be flippant... it just struck a similar chord for me). That's not to say that the introduction of wikiwyg won't pose new challenges, but I would argue that Wikipedia has had greater challenges and managed to come out the better for them... I wouldn't expect anything different here.
As for what's going on now with it .... we don't pretend to know the best way to proceed with this... the next step of functionality isn't an easy or straightforward problem. So I would sum it up this way... proof-of-concept is done and the next phase is that we put this in the right place in the repository so that any further development is done in the right way by people who know MediaWiki best.
Can you please tell us what we should do next and who can help us to further this effort and do the right thing here??
Thanks, John Q.
p.s., to clear up something said earlier... Wikia is primarily GFDL although a few wikis are Creative Commons because they started that way. Any code contributions made would of course be GPL.
On 8/15/06, John Q. johnq@wikia.com wrote:
- Basic in-page rich text editing (bold, italics, bullets, links, etc)
which is saved as wikitext.
- Recognizes when there is wikitext on the page that it can't parse and
defaults to an in-page editor that just lets you edit the wikitext like normal.
This probably isn't the right place to comment, but long term, it'd be good if it could simply mark a "blob" in place of the uneditable text, rather than barfing on the entire section.
<snip>
p.s., to clear up something said earlier... Wikia is primarily GFDL although a few wikis are Creative Commons because they started that way. Any code contributions made would of course be GPL.
Thanks for clarifying.
Steve
On Tue, 2006-15-08 at 00:15 -0700, John Q. wrote:
There are many pros and cons for #1 and it looks like this is a pretty healthy debate to which I'm not qualified to add anything. However, I can definitely shed some light on #2.
John, you did a great job on explaining; thanks a lot.
One thing I do want to clear up is that we're not "being paid" to do this... we have *plenty* of other stuff on our to-do lists. This is a really interesting project so we decided to volunteer some time for it... same with SocialText and good for them to throw in code they'd already written.
I think I was the one who mentioned payment. I hope it didn't sound disparaging -- that wasn't my intention. Rather, I wanted to point out that the project had momentum since Wikia and SocialText were allocating the time of their professional programmers to it.
I'm surprised to find out that Wikia and SocialText employees are working on wikiwyg on a volunteer basis. The impression I got from meetings with Wikia, from Jimmy's talk at Wikimania, and from the press notices from SocialText, was that the wikiwyg project had the backing of the two companies and that employees were applying work hours to it.
If that's not the case, I'm sorry for the error. Thanks to all the Wikia and SocialText employees who are doing this work and to the companies for supporting them.
~Evan
wikitech-l@lists.wikimedia.org