Setting up a Sandbox Domain

The first step in trying out WordPress was to set up a new domain just for testing out the WordPress installation.  This way, I wouldn’t affect the taskforest.com domain during my experiments.  I happen to run my own name servers using Daniel Bernstein’s tinydns, so I decided to create a new domain called tf.enoor.com, a subdomain of my defunct company’s domain.  Since I use bluehost.com’s WordPress hosting service, I had to make their name servers responsible for the domain.  All that’s needed is adding the following two lines to /etc/tinydns/root/data:

&tf.enoor.com:74.220.195.31:ns1.bluehost.com:300
&tf.enoor.com:69.89.16.4:ns2.bluehost.com:300

Selecting a Theme

After setting up WordPress, the next step was to select a theme.  I wanted something similar to TaskForest’s current design, so I chose the remarkably customizable Suffusion theme.  After some tinkering I was able to get a site that was quite similar to the original, with one compromise – I could get either the logo or the site’s name in the header, but not both.  Not the way they are on the current site.  It’s quite important that the site’s name appear in the header, because that helps with Search Engine Ranking.  So with a heavy heart I decided to omit the logo.

The Problem with Content

TaskForest ships with its own web server to support REST interface.  As part of the included website is all the documentation for the system. Just like the code, this documentation is under source control, and it’s also used to populate the taskforest.com website.  This way, I can ensure that both the taskforest.com website and a user’s local install have the most up-to-date docs, as long as the user is running the latest version of the software.  What this also means is that I have a few dozen webpages that need to be transfered to WordPress before the new site can go live.  I was already resigned to the fact that the URLs of these pages would be different – the current site has URLs that look like http://www.taskforest.com/about.html, but the default WordPress installation would use URLs that look like http://www.taskforest.com/about/.  It’s not a huge deal, but I prefer my way.

The bigger issue is that when a new version of the software is released, the pages change.  The current build process ensures that the client website and the taskforest.com website stay in sync.  Now if I use WordPress, I don’t want to manually edit the pages using the WP admin site.  I need to install a new plugin that handles inclusion of files.  So, I installed the WP Include plugin.  I’d have to change my build process, but I could get it to work.

Putting It All Together

Okay, so I got the themes and plugins installed, and I’ve got the process worked out.  It was then time to try a proof of concept with a single page.  It worked just as expected, but the site seemed very sluggish.  I made sure I didn’t have anything enabled that I didn’t need.  Still, the site was noticeably slower than the existing site, and that’s with only one non-blank page and zero blog posts.  I thought that maybe the problem was that the bluehost.com shared server was too slow.  I just happened to have an unused server in the same data center that hosts taskforest.com.  The same kind of server as well. It took the better part of the morning, but I installed PHP, mysql and WordPress on that server.  In installed PHP as a static module within Apache, for optimal performance.  Even then, on a pristine machine running nothing else, it was slow.

How Slow is Slow?

Anyone who knows me knows that I’m an Engineer, and as an Engineer I like metrics.  I wanted to know that it wasn’t just my own bias that was penalizing WordPress over my established way of doing things.  So, I looked at the Safari web browser on the Mac.  Safari has a really useful feature called the Web Inspector that, among other things, displays the amount of time it takes for different parts of a page to load.  The numbers were very surprising.  With WordPress, a new page would take 1.75 seconds to load – an eternity on a high-speed broadband connection.  A subsequent request of the same page would take about 700ms. Switching to the TaskForest website’s strategy would take about 800ms for a new page, and 275ms for a cached page.  That’s more than a 200% increase in speed!  The TaskForest website used a preprocessor that allowed for including header files.  It ran under mod_perl.  I decided to write a spider that crawled the website and convert everything to static pages, and serve those pages without mod_perl.  With this enhancement, the results were even better.  I saw a 400% to 800% speed increase, with cached pages taking just 140ms to load.

One of the reasons WordPress’s numbers were so poor is that if articles like this one are still correct, WordPerfect does not cache the content of pages by default.  Resources within the HTML page, like images or javascript files seem to be cached, but every page still does upto 120 database accesses depending on the setup.  Apache is a lot better at caching requests for static HTML pages.  Even the TaskForest webserver used for the REST API, caches data very intelligently using the HTTP headers.

What Does This All Mean?

Given the amount of compromises I would have to make in the design, layout and build process, switching to WordPress would have been very painful.  However, with the performance hit the site would be taking, it seems unlikely that I’ll switch to WP any for the TaskForest website any time soon.  I think I’d rather write a script to generate RSS feeds on demand and automatically submit the feed to feed notification sites like pingomatic. I think this was a great learning experience that will help me with similar decisions in the future.  And I also got to write a cool spider and increase the speed of the TaskForest web site.

Safari's Web Inspector

190 S. La Salle St. - Downtown Chicago

The #grid website has a great tool for web designers -it “inserts a layout grid in web pages, allows you to hold it in place, and toggle between displaying it in the foreground or background.”  Go to their website and have a look.  It’s pretty impressive.  Simple, but impressive.  I think I’m gonna give this a shot for the next web site I design.  I think it would be really useful in development, not as much in a production environment.

I am certain Google tested their application thoroughly.  They’ve been known to do extensive usability tests for the seemingly tiniest of changes to their web site.  But even the most well-implemented tests are incomplete if they’re not performed on a statistically representative sample of the audience.

But today, the BBC reported that Google has admitted that they only tested Buzz internally, and bypassed their regular rigorous testing procedures — possibly in an attempt to get it out the door as soon as possible. I’ll let the pundits decide if it did more harm than good to the firm, but it’s a warning to other software developers: skipping testing can lead to embarrassing failures.

Google Buzz

Almost immediately after Google started rolling out Buzz to its Gmail clients various blogs reported that there was an egregious flaw in the system that exposed people’s private contacts to the rest of the world.  When a Gmail user logged in, they were presented with a dialog box that asked them if they wanted an introduction to Buzz or not.  If the user declined, it didn’t mean that Buzz was disabled – it only meant that they didn’t want the intro.  What Google did behind the scenes was that they scanned the user’s emails and collected the emails of the people with whom the user corresponded most often.  Then, it automatically modified the user’s Gmail account to ‘follow’ those people in Buzz.

But here’s the thing that infuriated most people – it made that list of the people that user’s following public: Anyone who looked at the user’s public Google profile could see who that person was following.  In other words, anyone looking at that user’s public profile could see who that user emailed most often.

Now pretend you’re a reporter who’s communicating with dissidents in Myanmar or Iran.  Would you want your heretofore anonymous sources made public?  In one reported case, a woman’s most frequent contacts were her boyfriend and her mother.  Her third-most-frequent contact (with a lot fewer emails) was her abusive ex-husband, from whom she had kept her email address hidden.  But what Google did when they released Buzz is automatically have her follow her ex, and share her shared Google Reader messages, including her location and workplace with her ex.

Another blogger reported that her Android phone uploaded to her public profile a photo that she had taken, but not uploaded. She thought her photo was private, but Google’s assumption was that if the photo was on her phone, it would be okay to upload it to her public profile.

The third problem that surfaced in the two days after Buzz was released was that in some cases users thought that they were referencing a person’s public email address in a buzz (think of it as a retweet or a reply) but in reality were referencing a private email address.  When they selected a person by their name, it wasn’t clear which email address was linked to that name.  For example, if John Smith’s public email address is john_smith@example.com, and his personal address is js_123@example.com, and the public address is associated with a Google profile, a Buzz user may inadvertently select the private email address in a buzz, thus exposing John’s private address to everyone he follows.

The iPad

In the minutes after Apple’s Steve Jobs announced the new mobile appliance’s name, people started making very funny, original and sometimes vulgar jokes about the name iPad.  I could post them here, but the jokes are old by now.

Salacious Texts On Samsung Virgin Mobile Phones

According to this article, a 49 year old man from Winnipeg can no longer have a relationship with the woman he loved because she accused him of cheating on him.  Her proof?  Sexy text messages on his cell phones.  He denied the affair, but couldn’t explain how they got there.  Only later did he learn that the messages were pre-loaded by Virgin Mobile.

What Do These Cases Have in Common?

As an outsider it appears to me that in each of the three cases the problem was that the population for whom the system was designed wasn’t necessarily the only population actually using the system.  Let’s look at the Google Buzz case.  If we claim that Google is neither evil nor stupid, what went wrong?  I think there were several assumptions that the Google developers and designers made that were incorrect.

Buzz seemed to have be designed for people who collaborate together in tightly knit groups.  The assumption is that people who want to share information with each other communicate a lot with each other.  In real life that isn’t always true, and neither is the converse.  In many cases the people that I want to share the most with are people with whom I have so many channels of communication (including the dinner table) that any single channel like email contains a fraction of the actual communication taking place.  Similarly, as in the case of the lady who was hiding her online identity from her ex, the people we communicate with aren’t always the people we want to share information with.  If Google’s designers approached their product with that bias, they could have made (and did make) a technically excellent product that worked as they intended, and whose test cases passed, but which did exactly the wrong thing.

I think that that’s essentially the core problem with the issue of the publication of private photos and email addresses.  The joke in the blogs was that Buzz was designed for an people like engineers at Google, not for people who go to parties and take pictures that they would regret the next morning (and I know they’re not mutually exclusive groups).  Unlike in the business world and the networks of sites like LinkedIn, people sometimes guard their email addresses jealously and do not want them published without their authorization.

I am certain Google tested their application thoroughly.  They’ve been known to do extensive usability tests for the seemingly tiniest of changes to their web site.  But even the most well-implemented tests are incomplete if they’re not performed on a statistically representative sample of the audience.

The same can be said for Apple and Virgin Mobile.  On of the most insightful questions asked after the iPad announcement was, “Did Apple not have any women on the product naming committee?”  Did Virgin Mobile think that their only consumers would be teenagers who would find the default text messages cute and funny and have the technical expertise to realize that these messages were pre-loaded?  While Apple seemed to have failed to consider about half of the human race while naming their product, Virgin failed to consider the less savvy part of the population who are their customers.

What I don’t know is this: Let’s assume I’m wrong, and that in all three cases a statistically-representative portion of the population was tested or considered.  If that’s true, then could these three cases be considered edge conditions?  While a problem could exist in theory could the actual problems be so few that they’re statistically insignificant?  If you’re the person whose lost a relationship or now have to worry about being stalked by an ex it doesn’t really matter.  It’s affected your life in a significant way.

What Can Software Developers Learn From This?

I don’t think anyone or any company (not even Google) can make the perfect application that pleases everyone.  But I think that there are a few rules of thumb that we should follow, to prevent embarrassing and distressing problems.

First: Applications like these should not take action on behalf of the user.  The system should assume that the user always knows what’s best for them.  The most the program should do is make suggestions that the user can then decide to obey or ignore.  This is exactly what Google did (among other things) to change Buzz after the huge public outcry.

Second: Features, no matter how well-intentioned, no should never be opt-out.  They should always be opt-in.  Buzz was essentially an opt-out system.  You could be vulnerable by not doing anything. It isn’t that way now, but it was for those two days when Google’s reputation took a massive hit.

Third: Designers and service providers need to pay careful attention to who their users actually are.  They’re not necessarily men, not necessarily tech-savvy teens or professionals looking to increase their network.  They could include people very different from us.

As developers and designers we need to realize that the products we make will be used in manners that we never imagined, by people who we don’t understand.  If we give our customers the ability to control how our products and services are used, we’ll be helping them and thus helping ourselves.

This got me thinking about the benefits of using third-party libraries in our own code.  Why should a program depend on so many external modules when it could implement what it needs itself?

The answer, in one word, is “Testing.”  A well-written piece of software isn’t considered complete if it doesn’t have well-documented tests that exercise every part of the program.

There are many common tasks that most programs perform – such as reading configuration food, performing date arithmetic and writing to log files.  Every popular language has third-party libraries that perform these tasks correctly and reliably.  If I were to try to duplicate them, it would almost certainly result in inferior code; the mature libraries have had the benefits of extensive testing as well as enhancements and fixes of bugs reported by users.  Using third-party software allows me to focus on my program and what makes it unique.

Perl can be a little stubborn, sometimes.