It’s a bird. It’s a plane. No, it’s a visual text editor for MediaWiki!

Vte mediwiki

Update: Not exactly a full-featured visual text editor 🙂

Just found this little hack for MediaWiki that adds a more comprehensive visual text editor to the coolest wiki application going. How long have we been waiting for this? What’s more is that the features are pretty comprehensive. All you wiki purists be damned, I got mine baby! Thanks and praise go to El Guapo, whose del.icio.us bookmarks showed me the light. Scott Leslie rules the edtech school!

This entry was posted in Uncategorized and tagged . Bookmark the permalink.

8 Responses to It’s a bird. It’s a plane. No, it’s a visual text editor for MediaWiki!

  1. Andy Rush says:

    Just keep in mind this is Firefox/Mozilla only ( a bad thing? maybe not) hack.

  2. If you’re cool with Firefox-only, there’s the Wikipedia extension…

    http://wikipedia.mozdev.org/

  3. Martha says:

    Is it actually wysiwyg? I mean, does the editor display the markup visually, or do you still see all the wiki syntax? From the screenshot, it looks like the latter.

    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. . .

  4. jimgroom says:

    @Andy -Good point. Also worthy to note is that it is only compatible with MediaWiki versions 1.8.x and higher.

    @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.

  5. Alan says:

    Hmmm, tried it, was not all that crazy with it. You are replacing a need to remember wiki codes (which not everyone does) with a need to remember which one of 50 cryptic icons does a task. I don’t find the little buttons all that intuitive and spend just as much time rolling over them to figure out what they do. If I use this I would end of customizing to remove some of the button clutter.

    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.

  6. jimgroom says:

    Alan,

    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? 🙂

  7. Martha says:

    Okay, the comments here are forcing me to rethink a few things. . .

    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. . .

  8. Brian says:

    Hmmm, a pointer to a nifty MediaWiki feature turns into a pretty interesting discussion on the relationship between authoring environments and authoring practice… go Bava!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.