Technovangelism

In my quest to get users to stop deleting posts, I have spent a significant amount of time researching different rich text editors. I was hoping to find a visual editor that allowed users to write their posts exactly as they would see them once submitted. There are lots of editors out there: TinyMCE, WysiHat, FCKeditor, the YUI editor, etc. Each of these editors has its strong and weak points, but none stood so far above the rest that it was an obvious choice. I had a very limited and strict set of requirements that I wanted the editor to do: insert images and links, allow for basic heading and paragraph formatting, and the ability to drop into HTML mode so the savvy users could add whatever they wanted, like lists and tables. None of these editors gave me exactly what I wanted out of the box, so they would all have required some configuration.

I finally decided on tinyMCE. It didn’t take long to figure out where I needed to change things to get exactly what I wanted. My final configuration gave the user everything I needed plus a few extra basic formatting options.

I continued using tinyMCE for a while and posting trends didn’t change. Users now had a way to be reasonably sure they knew what their posts would look like, and yet they were still making and deleting unsatisfactory posts.

The problem clearly doesn’t have to do with knowing what your posts will look like, so I revisited the issue and tried to find what my the users were posting. I found over 90% of all posts were devoid of any formatting/HTML. They were just a few words of text and that was it. Having a custom tinyMCE editor didn’t make life any easier because the posts were so plain. Out of the remaining posts that did have formatting/HTML, the most common HTML to find was making clickable links. My latest solution is to remove the tinyMCE toolbar altogether and not use any kind of markup language besides HTML. Most users don’t know HTML at all, but it doesn’t matter. They weren’t using it when it was easy, so I took it out.

Now that tinyMCE is gone, I needed to make it easy for users to add clickable links to their posts. I thought about providing some help text next to the textarea that would teach a user how to correctly use <a> tags, but that’s a little bit of a pain for users who don’t want to learn any HTML. Even when tinyMCE was in use and users could easily add clickable links, they were still just pasting urls into their posts, hoping others would copy and paste the url into their address bars. While the extra copy and paste is not much of a pain point, if I could make those plain urls into clickable links, I would have the optimal solution. So a simple regular expressions to detect urls and now I can parse posts and automatically link urls.

The final solution ends up being very simple and provides all the functionality required by users. There is no unused toolbar, the most common posts are dead simple to make, urls are automatically linked, and one more side benefit, a reduction in total page size of about 50%. Success!

I recently asked a question and was pleased to receive an answer that was simple, concise, and worked perfectly.

I was asking about the best design pattern for handling several tiny, but separate scripts to run on page load. Most of these scripts were just providing focus for a specific input element. I didn’t want to write a new javascript file for each tiny chuck of onLoad code, but I also didn’t want to embed javascript directly into the HTML where it is obtrusive and easy to lose track of. An astute Stackoverflower presented me with an option that I consider to be about as perfect as it gets. Please excuse my Prototype, I am slowly working my way into the jQuery world.

Element.observe(window, 'load', function() {
    $$('.focusOnLoad').each(function(item) {
        item.focus();
    });

$$('.disableOnClick').each(function(item) {
    item.observe('click', function() {
        item.disable();
    });
});

});

Now most, if not all of my onLoad code that used to be scattered about my project, is nestled neatly into a single function, located in my project’s main javascript file. Doing this has also increased the usability of my app as before this solution, the amount of time it took to go through the painful task of writing duplicated code everywhere was great enough that not every page with an input had it auto-focusing. Now that I only have to add a single class name in each of those files, it is much easier to go through the project and make each page that much more usable.

Usability of programming languages is not something you think about all the time. I am not talking about the learning curve or whether or not it uses pointers usability, but the usability of a language for a variety of purposes. One such purpose is web programming, and specifically writing code embedded in HTML. Out of all the languages that are used to do it, I have not come across any better than Ruby. Compare these examples:

PHP

<?php foreach($array as $val) { ?>
    <li><?php echo $val ?></li>
<?php } ?>

C#

<% foreach(var val in array)
   { %>
       <li><%= val %></li>
<% } %>

Ruby

<% array.each do |val| %>
  <li><%= val %></li>
<% end %>

The PHP code is similar to ruby, but the curly braces always tend to get lost when they are surrounded by so much else. They are so skinny compared to other code, and they are usually not given any sort of syntax highlighting to help identify them.

The C# code is close to PHP, but Visual studio will adjust your code to fit C# coding style standards. Dropping the open curly brace to new line looks code in the C# editor, but not so much in the HTML editor. I have never been a fan of line-wrap in any code, and with the indent-happiness of HTML, line-wrap can quickly lead to code that doesn’t follow the visual hierarchy and becomes much less readable.

Finally, the Ruby code. While it does require fewer keystrokes to type the equivalent code in this case, Ruby has other benefits. Instead of curly braces, Ruby uses the keywords do and end. When writing this code in an editor, the keywords have syntax highlighting making them all the more easy to distinguish from the surrounding HTML.

Small differences in the design of a programming language can make big differences in its usability. The ease of embedding Ruby in HTML is just one of the many reasons why this language rocks.