Technovangelism

The most frustrating part of surfing the web on my iPhone isn’t lack of flash. It isn’t sites that don’t have a mobile optimized version or native interface. It is sites that spent all their time and effort building a great mobile web interface, and not a second of actual user testing.

Often when reading articles, I am force redirected to the mobile-optimized version of a site. I find this perfectly acceptable and appreciated until to I am directed to one of those sites. Those sites redirect all mobile browsers to the mobile version of the homepage. Not the page I was on or want to see, but a page that leaves me completely stranded and helpless. There is a good chance that the page I want is linked to from the homepage, but how I am supposed to know which is the right link? Odds are I arrived there from a direct link via Twitter or RSS and now have close to zero context in helping me find what I was looking for.

What makes my helplessness even more frustrating is knowing how easily this problem should have been caught. Whoever made the site probably viewed it and “tested” it plenty, but never got around to actually using it.

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.

In the original implementation of my forum site, times were all displayed as absolute times. The server sits in the Central Time Zone and at least 90% of the users, including me, are in the same time zone. I never found this a problem, until I spent a few months outside Central Time. My first reaction was to let users set their own time zone and then adjust the times automatically for them. Before implementing this, I found this post from http://blog.stackoverflow.com and decided to rethink my plan. Relative times would provide a simple solution to my problem and would help users in the future as more and more move out of the Central Time Zone.

Everything was working great until a few months in, when old posts were marked as made “about 3 months ago.” By itself, this was not a problem, but edited posts are tagged as edited and would read “about 3 months ago and edited about 3 months ago.” Users are only allowed a 30 minute window to edit posts after they are made, so old, edited posts will always read like they were posted and edited at the same time. Fixing this now requires even more relative time. By marking posts as made “about 3 months ago and edited 4 minutes later” I can still provide the important information that a user is looking for, and not have to worry about time zones.

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!

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.

After the iPhone/iPod Touch 2.0 firmware was released, I had fun searching for and downloading apps from the App Store. I initially downloaded them via iTunes and everything worked fine. Then I tried downloading them via my iPod itself. When it was time to sync my iPod, I plugged it in the my computer and walked away, hoping to find it properly synced in time for work. When I came back to pick it up, I was very annoyed to find that a dialog had popped up and required me to click through it before the sync would begin. The dialog asked me if it was ok to sync my apps that were not downloaded via iTunes.

I’m a big advocate of opinionated software and convention over configuration, and by these principles it seems one could make the assumption that most, if not all, users would like to sync their apps. But I’m willing to give Apple the benefit of the doubt and let them ask users if they would like to sync their apps, but wouldn’t a compromise work? If the dialog asking for permission had a time limit on it and gave the user 60 seconds to answer, it would work fine for those who don’t want the sync to happen automatically, and would please users like me who use the default setting and should not have to answer a question that Apple already knows the answer to.

This kind of dialog can be found when trying to shutdown the OS. This dialog understands that when I choose “Shut Down” I probably mean I want to shut down my computer and it can answer the question without any further interaction from me, saving me the hassle of having to double-check that my computer did indeed shut down.

A dialog that knows your answer

I had an interesting experience last week at a Smithfield’s restaurant. I walked up to the cash register and was asked for my lunch order by the cashier and before I could answer, another employee behind the counter asked me what I wanted to drink. I was a bit confused for a few seconds because I hadn’t made any sort of order yet. How did the other employee know I was going to order a drink or what size I wanted? After being lost for a couple seconds, I turned back to the cashier and ordered the way I order at any other restaurant. While waiting for my food, I watched some local customers handle the same situation much better than I. They managed to order a drink and their lunch in parallel with two different employees without any hesitation.

Of course the first thing this made me think of was software. I can’t stand it when I start using some software for the first time and have no idea what to do. Even though you eventually learn how to use the software, your experience is still tainted from the initial difficulty. If the software is a website, the developer would be lucky if the user stuck around long enough to attempt to learn. Software that caters only to the advanced user is never going to have one. Luckily for Smithfield’s, my experience wasn’t bad (at all) enough prevent me from going back, but it is a potential risk they might not realize they are making.

Another restaurant with a strange user experience is Gates Bar-B-Q. Here cashiers take your order while you are only half way through the line. Normally this would not be a problem, except they do it by yelling to the entire line and not looking directly at the person whose order they are trying to take. So if you were not paying attention to when the people ahead of you ordered, good luck figuring it out.

When trying to advertise your website, particularly on television, how should your url be displayed? There is a big debate about whether or not a site should be accessible without the www subdomain and that should apply to displaying your url as plain text as well. If the homepage of your site is at www.example.com, should you advertise your site exactly as it will be seen in the browser (http:// included), as www.example.com, or can you get away with just example.com? And what about the styling of your url when it is displayed in text? Is it ok to use multiple colors? Will different colors and combinations affect readability or a reader’s ability to recall the url?

I recently saw a commercial advertising the Art Institute of Raleigh-Durham. In the ad, the url was displayed like this aidurham.com. I assume they do this because the red “ai” matches their logo, but at first glance in the commercial, all I saw was durham.com. Only after it flashed on screen a few more times did I notice it was really aidurham.com. I suppose the red “ai” prevents me from thinking I’m visiting “aid ur ham.com,” but the price paid in losing a visitor to the wrong url is not worth having your url match your site logo simply for styling purposes. I’ve never seen a flickr add on television, but do you think it would display the url like this flickr.com? With a different colored “r” it would be far too easy to completely miss it and think the website address is flick.com.

A website address should only be displayed in one color. Even if the address is made of multiple words, it needs to be in one color so parts of it are not lost. If you are worried the words won’t show through and will make memorizing the address difficult, saying the address aloud will let the viewer know how to break up the address properly so he can remember it for later. The aidurham commercial repeatedly said “a-i-durham.com” and this would have been plenty to let the viewer discern the correct url, but using different colors was enough to undo all of the work saying the address aloud did.

When building a web site where each page is roughly mapped to a row in your database, what do you do when the requested row is not found? When using Rails, I found the standard method of handling such a situation is to rescue the ActiveRecord::RecordNotFound exception, and display a flash message explaining what happened to the user. When writing a Django application, I found myself raising the Http404 exception, which would render the 404 page, whenever the requested record could not be found. Of course there is no reason why the Rails approach couldn’t be used in a framework like Django. I just simply found it easiest to raise an exception and let the framework handle the rest of the work.

Which is the better approach? Raising an exception to display the 404 page is certainly easy and it also seems most accurate with regard to the meaning of HTTP error pages. But does it provide the right experience for a user? With the Rails approach, a more useful message error message can be displayed on a page that could help a user try to find what he is looking for. This would also help your application crash responsibly, although a 404 is not exactly the same as a crash. Giving the user more information than simply “not found” should improve the experience of using your website. And although I expect you to code perfectly so that the only way to get a 404 is type manually type a bad url into the browser, a good recovery mechanism is well worth the effort.

And don’t forget the MediaWiki approach to pages that are not found: a page is not found because you have not edited it yet!