Technovangelism

Not what I was expecting.

Who knew Dogpile still exists.

Well, that may not be 100% accurate. Unobtrusive JavaScript is likely to weigh less in a Rails application, but that doesn’t get fan boys riled up enough.

In a standard Rails application, Prototype is included by default as the JavaScript library and several of the html helper methods used in the views will generate Prototype code for you. A great example of this is link_to_remote which generates a link that will make an AJAX request to the desired url.

This Rails view snippet was found in my forum app:

<%= link_to_remote "delete", :update => nil,
  :url => post_path(post), :method => :delete,
  :confirm => "Are you sure you want to delete this post?" %>

And it generates this html mixed with some very obtrusive JavaScript:

<a onclick="if (confirm('Are you sure you want to delete this post?')) {
    new Ajax.Request('/posts/1', {asynchronous:true, evalScripts:true,
      method:'delete', parameters:'authenticity_token=' +
      encodeURIComponent('abcde')
    });
  }; return false;" href="#">delete</a>

There is nothing really wrong with this code. It works fine and did the job while it was in production. The problem is this one link is found in every single post on a thread page. This means the giant link can be repeated on the page hundreds of times.

After I made the switch to unobtrusive jQuery, I wanted to see exactly what kind of a difference it made in page sizes. I looked at three different thread pages, one with 1 post, one with 94 posts, and one with 306. Here are the page sizes (in bytes) and they show a pretty remarkable difference.

The difference ended up being quite a bit bigger than I was expecting and really helps sell me on jQuery. Unobtrusive Prototype could no doubt have dropped the page size just as much, but I’ll be sticking with jQuery from now on.

Why won’t Apple make a tablet that is just like a bigger iPod Touch? Ask Steve Ballmer. The experience for developing for the iPhone is so awesome compared to other phones because there is only one screen size and resolution. Removing that part of the equation will place the iPhone on par with its Android and Blackberry competitors. One screen size across every device isn’t the only competitive advantage the iPhone and iPod Touch have, but is it worth it to find out exactly how important it is?

At JavaOne this year, a new design tool (similar to Expression Blend) for JavaFX was demoed and the developer showed off how easily you could change the view to match several different cell phone or desktop resolutions. I could feel the groaning as other developers in the room began to imagine themselves trying to develop like this. It looked like one of the most painful experiences possible (yes, even worse than making your site look perfect in IE6). I’m sure Apple could come up with some fantastic design tool that would be the best multi-resolution design tool in the market. It might even make life easier, or should I say “less difficult,” but it won’t fix the underlying problem.

Don’t expect to see the rumored tablet unless it runs normal OS X. Apple has made enough poor decisions already (with the App Store at least), that it doesn’t need to make any more and ruin a great development experience.

Updates are an important part of the software industry, but for some reason, they are extremely feared. This guy who is switching away from Lotus Notes lists his reasons for leaving:

…
3. No more waiting for the AdminP guy/gal to do his/her work.
4. Way too many fixes on Lotus Fix List databases.
5. Killnotes.exe should be more of an attitude than a program.
…

I can’t understand why “way too many fixes” would be a problem. Certainly, way too many bugs, or way too much time to install fixes could be an issue, but those likely aren’t the problem because they weren’t mentioned. Far too many people have an irrational fear of software updates. When it comes to operating systems, updates mean the vendor did a poor job writing the software and is now finally getting around to fixing bugs that you never experienced anyway. In the web world, updates are agile and mean new features are being released. Why does such a dichotomy exist? Perhaps it stems from the interaction with the actual update process. If something is obtrusive and sucks, people hate it (and they should), but if something is so seamless and transparent that you might not even realize it’s happening, then what is there to hate?

Joel and Jeff discussed updates in their latest podcast and Jeff recommends the Firefox model where updates are as close to transparent as possible (for a desktop application). This is a great strategy and makes a lot of users happy, but unfortunately, it doesn’t always work for all companies, especially when they are trying to update someone else’s software. Read the first page of search of “microsoft firefox silent update” and you’ll be blasted with words like “sneak, sabotage, infiltrate, and invade” because a plugin was installed silently.

The best update model is the no-control model. Don’t give users the ability to see that an update is happening, let alone stop it from happening. This is basically the model of the web. When website owners decide it’s time for you to upgrade, you are getting that upgrade. But if you are using this model, you must be very confident that an update is going to work every where it is used. Having never written a piece of software that is used by millions of people, I can only assume this is a monumental task, but with some practice, it is no doubt achievable.

You don’t necessarily have to have a web application to get this model either, although it certainly helps. When every user is always running the latest version and doesn’t have the option to go back to previous versions, you save so much effort on support and maintenance. The benefits of supporting only one version of software far outweigh the risks taken to do so.

Maybe hating software updates isn’t such a bad thing after all. You have to know an update is happening to hate it.

I have been reasonably happy with Webbynode, where HappierHour is hosted, both in functionality and service and was happy to see some new features the last time I logged in. While poking around the new pages, I found this on the “Close Account” page:

Bad dialogs and button combinations have always existed and will probably continue for quite some time, but this one surprised me coming from Webbynode. It is not so bad, but I am disturbed by “Otherwise, click cancel.” There is not a “Cancel” button, and the only button with the word cancel on it does the opposite of what the user wants.

Luckily for Webbynode, it is probably not an oft-visited page, but one accidently canceled account will make it an expensive mistake.

In the first chapter of every beginner’s Java book, the reader is introduced to code like this:

public class MyClass {

    public static void main(String[] args) {
        System.out.println("Hello world!");
    }
}

Its simplicity is important to not discourage the reader and its brevity allows for quick and continuous enhancement. But within the first line, it has started the reader down the wrong path in what is considerably more important long term.

Later, a code snippet like the following might be used to explain some features in greater detail:

MyClass myObject = new MyClass();
myObject.myMethod();

Again, the deterioration of good programming skills has started before those skills were allowed to develop.

Why are beginners taught these bad habits when it is just as easy to teach with proper programming styles? The use of the prefix “my” does not provide any insight to what that class/object/method actually does. Despite the difficulty of naming things, it is far better to demonstrate good programming practices and have a 90% intuitive name, than to have a name that is simple but meaningless.

Java is the most notorious for this, but other languages are equally guilty. If you are writing a tutorial somewhere, especially if it is for beginners, take extra care to ensure your code is portraying proper style, so first-time programmers will not have to dig themselves out of any deeper of a hole.

When developing a software project in a short amount of time (less than 6 months), demonstrating often that you are providing value to your customer is essential. Of course it is important for long-lasting projects, but if you only have three months to complete your project, you cannot afford to miss a demo.

I have learned this over the last two major software projects I have completed. On both projects, the team did not just “demo often,” but we demoed every week. (When you only work 2 hours a day, that is a bigger feat than it might seem.) We were not following the extreme programming methodology or specifically trying to program quickly, we simply found that we could provide enough value in one week’s time that it was worth presenting to the customer. These constant demos had some other beneficial side effects like keeping the build in an extremely stable state. Some people use an automated test suite for that kind of security, but having to demo the code once a week forced us to do more manual user testing that uncovers usability issues that an automated test suite is incapable of discovering.

Agile methodologies preach having shippable code at the end of each iteration/sprint, but how often is that the true outcome? When you demo your code to customers, you are essentially shipping your code. The customer has a chance to look at and try out the code and provide some instant feedback. In the most recent project, we actually did ship the code to the customer each week and they performed their own user testing on site. The amount of benefit gleaned from these each week was incredible and no doubt increased the success of the project. From now on, all projects I am apart of will have regularly scheduled demos in front of the customer or stakeholder. They are that important.

After running a web site that has forums as one of its main components, I have discovered that users are much more likely to delete threads and posts they are dissatisfied with rather than edit them. On the forum, all post revisions are saved, including deleted posts, so I can easily how many times a user actually tried to edit a post. When I post on the forum and do not like what I said, I edit the post, but I also have a very deep understanding of exactly how the forums work and the rest of the users are far less technically savvy than I. On the forums, there are 13,561 total posts, 236 of which are deleted and 854 have been edited at least once. That means out of the 8 percent total post that have been modified in some way, over 25 percent of them are deleted posts.

For the most part, deleting posts does not make sense. The edit and delete buttons are equally prominent and right next to each other in each post. When you edit your post, your original text is already included in the post, making it much easier to change the grammar or fix a typo instead of trying to remember what you wrote earlier before you deleted your post. And finally deleting posts results in more mouse clicks. So why are so many users more likely to delete their posts rather then edit?

Users on the forum are allowed to enter certain html tags in their posts, and the most likely cause of post deletions, is poorly written markup. If a user writes out a post with bad markup and submits it, the post will show up on that thread page for all to see. In order to prevent all other users from seeing this incomplete post, the easiest course of action is to delete the original post and start over.

So to save my users from the painful process of posting, deleting, revising, and reposting, I have added a live preview of new posts. As users type their posts, the preview will display exactly what will be seen when the post is finally submitted, markup included. Any errors will be instantly obvious, and there is no threat of embarrassment of submitting incomplete posts.