Midnight Oil

I’ve never pretended to be good (or even decent) at Photoshop. I just don’t have the eye or the patience for it. All the fonts look the same to me, the only colors I understand are ROYGBIV, and things just never seem to line up.

That being said, I’ve always wanted to get better. Lack of design skill is a major hole in my web developer skillset. So, whenever I get the chance, I try to grit my teeth and force myself to learn something new.

Behold, my latest creation:

Disgusting, huh? Check out my new campaign, and follow along with these morally impure creatures.

If you allow rich text from your users in a Rails app, then you’re probably familiar with Textile. Either that or you’ve chosen the dark side, aka. Markdown. If that’s the case, I hate everything you stand for and I’ll bet you put your curly braces on the wrong line!

Assuming you’re one of The Chosen who has selected Textile as your input syntax of choice, you’ve probably got plenty of users who are turned off by the syntax. It may be easy for your average web developer to pick up yet another new syntax, but there are lots of people on the web who have never clicked the edit tab on Wikipedia, or think that links are specified with [URL=http://bbcode.com].

For these people, some sort of help is necessary. Quick tip sidebars, tutorials, and help pages only go so far. To make it truly useful you’ll probably have to dip into your Javascript bag of tricks. Luckily for you, a few others have already blazed that trail and created a handful of Textile utilities.

Textile Editor Helper (TEH)

NOTE: We’ve forked the Textile Editor Helper plugin to have more features and to conform to Rails 2.1 conventions. Our fork is available on github here:
http://github.com/felttippin/textile-editor-helper/tree/master

The Textile Editor Helper is a very simple toolbar that sits at the top of your textareas, much like the Wikipedia toolbar. It provides many of the most basic Textile options, like bold and italics, plus some text alignment. Unfortunately, it doesn’t include linking and image includes, which are really easy to do with Textile.

Supposedly, you can add your own buttons, but I haven’t confirmed this. Plus, I think the whole plugin is based around the idea of prefixes/suffixes for text (like * for strong, or _ for em), so anything that requires more than that might not be possible. So, TEH is a good solution if all you need is some basic formatting help.

Live Textile Preview

The Live Textile Preview (aka SuperTextile) is simply a Javascript implementation of the Textile parser. So, you can convert Textile to HTML on the client side. This allows users to experiment with the syntax and quickly see what the changes will look like.

Unfortunately, from my cursory testing, it only implements most of the Textile syntax. Basic text changes, images, and links are covered. However, advanced text alignment and CSS styling elements seem to be beyond its capabilities. So, it’s not perfect. Still, if you only need the basics, SuperTextile can make life bearable for your users.

Sanskrit WYSIWYG editor

Sanskrit is a true WYSIWYG editor, and the only one I’ve seen for Textile. However, it only does the absolute basics, so I can’t recommend it. Plus, I don’t think it’s a great idea to hide the raw Textile from your users. I’m a fan of the Wikipedia / Mediawiki way of things, where you provide some editing help, but your users are always looking at the raw text. Eventually, they’ll get the hang of things and won’t need the crutch of the editor buttons anymore.

markItUp!

markItUp! could be the most promising of all the solutions. A general purpose syntax parser written on top of jQuery, markItUp! can translate any syntax into HTML, provided you write the correct parser. Further, someone has already gone through the trouble and created a Textile parser!

I haven’t installed or tested markItUp!, but I was very impressed after playing around with the Textile demo. It seemed capable of most of the Textile syntax (including links and images), and even included a handy-dandy preview feature (you must render on the server side and return the HTML, I believe). So, it includes the best of all worlds: users work on raw Textile, but can get a live preview at the click of a button.

Update I finally got a chance to play with markItUp and it is hands down the best editor out of the bunch. Unless you need a true wysiwyg (in which case Sanskrit is the only one, AFAIK), then skip all the others and go straight to markItUp.

More?

Well, that’s all the Textile help I’ve found so far. Each one has its plusses and minuses, but any of them is probably better than a bare textarea with little or no help.

If I’ve left anything out, please let me know and I’ll add it to the list. With a little help, we can put together a comprehensive list of all the Textile tools available for Rails programmers.

For a while, I’ve been kicking around in my head a version of The Ontological Argument as applied to programming.

The Ontological Argument for the Existence of God is an attempt to prove that God exists by playing around with definitions. It requires no data and no experimentation, just a little armchair thinking, perfect for your lazy philosopher. I’ll lay it out as specified by Wikipedia:

1. God is, by definition, a being greater than anything that can be imagined.
2. Existence both in reality and in imagination is greater than existence solely in one’s imagination.
3. Therefore, God must exist in reality: if He did not, He would not be a being greater than anything that can be imagined.

Besides the definition of God, the whole argument comes down to the second assumption:

Existence both in reality and in imagination is greater than existence solely in one’s imagination.

In layman’s terms, this breaks down as: Something that exists is better than something that does not exist. Would you rather have a real piece of cake, or an imaginary one? A real X-Box 360, or an imaginary one? That’s the basic idea.

This principle applies remarkably well to computer programming. A program that runs is simply superior to one that does not. Program foo may be better architected, better designed, more scalable, and more extensible, but as long as bar runs and foo does not, then bar is better.

In other words: No matter what nasty hacks or deals with the devil you had to make, the fact that you have working software trumps everything else. UML diagrams, n-tiered architectures, and design patterns work well in our minds, but running software is the ultimate goal. So, do your best to get things right, but do whatever it takes to get things running. In the end, working software is all that matters.

Am I crazy? Is St. Anselm (the author of The Ontological Argument) spinning in his grave? Leave a comment and tell me what you think.