Jim, I completely agree with you that having a visual editor would make it a LOT easier to walk into a classroom and ask students and faculty to begin to experiment in a wiki. Having to remember the wiki code IS a pain — and I’m one who suffers from that pain regularly.

Alan, I’m sure you’re right that WYSIWYG environments tend to push people to valuing formatting instead of content, and that’s just never good…

So, now I’m thinking that this kind of tool is *exactly* what is needed. Make the insertion of code more transparent, but don’t make the visual aspect *so* tempting that users prefer to tweak font styles over scintillating prose. And, in the process, you could argue, you’re providing a system that also helps users to more easily and clearly see the connections between markup and formatting. In the end, could that create users who are more deeply engaged with the tool because they have some deeper understanding of how they are using it and controlling it?

Of course, I also hate to be prescriptive about these things (“We will not give you WYSIWYG because WE know it’s bad for you!!”). So, in the best of all possible worlds, we’d probably also let people choose the view that works best for them. . .

Oh, and yeah, I agree that the buttons on these systems tend to be very cryptic. So, better buttons are good. Unfortunately, “better” probably means they look just like Word’s buttons, because that’s what everyone’s familiar with.

PS: As I re-read this, it occurs to me to mention that sometimes seeing the visual formatting of my text actually helps me to write better. So, there’s another contradiction for you. I’m full of them this morning. . .

No right or wrong here, just the truth What attracted me to this immediately was the fact that I can be a bit more comfortable talking to students and faculty about using MediaWiki because of the text editor. Perhaps a false sense of security, but a bit more leverage when introducing them to a wiki, than just giving them a list of markup tags to remember. I myself have to often retreat to the wiki markup cheat sheet for creating tables, including images, etc. I agree it is far from intuitive, but the scroll over hints help, and it costs a lot less time than searching for documentation, and I think you have already blogged about how easy that is for MediaWiki, right?

That said, the current editor is so minimal and a poor excuse for one at that.

I also do not like that it achieves its functionality by a remote fetch for the JS code from far away. Sure, I know browsers can cache the stuff, but I’d rather have my code libraries local to the server.

And while I understand the desire for true WYSIWIG, they end coming at a tradeoff too. Might people spend more time twiddling the format buttons as opposed to building content?

I’m fence sitting, eager to be right or wrong.

@D’Arcy -Thanks for yet another cool tool for Wikis.

@Martha -Not WYSIWYG, but getting there. What is so important about this one for me is that it quickly offers a lot of wiki code I would otherwise have to look up -like tables, definition lists, converting word docs, superscript, subscript, in-text references, etc. It may not be the whole WYSIWYG enchilada, but it really bridges an important gap of more extensive usability for MediaWiki and a more general user base. Also, there is a preview feature for your edits, which kind of fakes the visual editing features.

I think for this to really work, the editor needs to be wysiwyg. I still find a lot of users are putt off by the wiki syntax. While it’s helpful to have a tool that allows them to add that syntax more easily, ultimately they want to be able to visualize the effects of what the formatting their changing.

I don’t know — maybe people are too hung up on the wysiwyg thing, but at this point, I think most people’s expectations of a M$-word like editing environment are so deeply ingrained, that they can’t let go of them. . .

http://wikipedia.mozdev.org/