
Rails, Textile, and javascript WYSIWYG roundup - MicahWedemeyer
http://blog.aisleten.com/2008/09/11/rails-textile-and-javascript-wysiwyg-roundup/
======
jharrison
Why would anyone make Joe Average use Textile anyway when there are plenty of
rich text editors available? Many (most?) have button bars Joe would be
familiar with if he's ever used MS Word (which most Joes have). And again,
many are cheap, free, and/or Open Source.

A properly configured app that filters user input doesn't need to require
users to know any markup languages at all. So why?

Stop thinking like geeks and think like users.

~~~
MicahWedemeyer
I've found that many power users prefer the precise control that Textile (or
bare HTML/CSS) provide. They really take advantage of the ability to specify
floats, margins, and the like.

I've tried supporting both Textile and 3rd party wysiwyg, but it just gets to
be a hassle when multiple users try to edit the same thing. They wysiwyg
outputs some pretty gross HTML, which the Textile users then have to deal
with.

Still, if all you offer is very basic formatting, then a wysiwyg rich text
editor is an excellent choice.

------
MicahWedemeyer
Anyone else find that users out-and-out HATE Textile? My users complain about
it constantly. Does anyone get the same reaction with other markup languages?
I want to make sure that it's across the board discontent, and not that
there's anything particularly wrong with Textile.

~~~
edb
I definitely second that, and the source of the problem is the same as that
with WYSIWYG editors: tables.

I've solved the problem by making things like tables editable in another
content management module and including it in the WYSIWYG editor as
%%%DATA_TABLE1%%%.

WYSIWYG seems to only work for me when I only allow the client to choose
h1,h2,h3,etc.. and bold and italic. If you're just doing that, the WYSIWYG
editor is fine and there's no need to try to teach your clients Textile.

Of course, this all depends on who your client is...

