“If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization.” – Weinberg’s 2nd Law
If this was Weinberg’s 2nd law, his first must have been a real humdinger.
The Cause of WordPress.Com's Misery
Weinberg was a prophet – a prophet of uncertain origins. It isn’t clear when this famous adage was first coined or if Weinberg was a even real person. I’ve been quoting his (her?) words for at least 20-30 years, so they must certainly be older than that. Googling the quote turns up lots of references but no clear biographical information or dating. It has been a source of amusement for many since it first appeared, but it’s also a warning to those who, when they stop chuckling, wisely ponder its deeper meaning. I have, and whenever I’ve experienced a calamatous failure of trivial origin, there is Weinberg, softly whispering in my ear, “Dipshit!” I’ve heard the words and grasped the point, but, like everyone else in the industry, I haven’t always heeded the call for change.
It seems certain that this adage dates to a time when software was, more or less, the entire system; before systems had reached the multi-layered level of complexity that is now the norm. Computers have always been complicated, but in Weinberg’s time, there was probably only machine failure and software failure: networks; routers; switches; clustered web servers; load balancers; multi-master, replicated database servers; and all the other components that constitute a modern web site didn’t even exist. Weinberg blamed programmers because, then at least, they were likely the only ones to blame. Now, our problems are bigger and there are more potential culprits.
So, Weinberg’s law, while remaining fundamentally true, needs some revision. Programmers took the brunt in his era, but today the fault could just as easily lie with the database administrator who inadvertently drops the wrong table, the system administrator who power-cycles the wrong server or a system architect who failed to foresee a critical design weakness that brought an otherwise finely crafted system to its knees, like an orchestra with half its instruments out of tune and a conductor who has lost control of what is being played. [read more…]
I call this blog The Well Run Site because I tend to write about a subject near and dear to my heart: how to run web sites properly, by forgetting the small stuff and stressing the importance of testing and monitoring, among other things. I’ve even published a prioritized list of things you should look after.
I’m no hypocrite, and I always do my best to practice what I preach. But shit happens.
I don’t post here as often as I should, mostly because I’m so busy handling tasks for my clients. I suppose that’s a good thing: with so many people out of work, I’m thankful there is a demand for what I do. The downside is that The Well Run Site doesn’t get as much attention as it should.
This afternoon, I discovered a problem with this blog that meant for the past several weeks I’ve been serving up readable but very ugly web pages, all because of a plugin conflict that generated mangled CSS. The problem was entirely my fault: I installed a new plugin and didn’t completely test the site afterwards. I should know better, and the irony of being caught not doing something on my own site that I fervently advocate to others is embarrassing.
This brings to mind a problem I had about six months ago with a client’s site. Not long after a redesign that was, in part, created to improve that site’s SEO, I began to notice a very dramatic decline in its search traffic. ‘Dramatic’ actually understates the scope of the problem: after a little digging in Google Analytics and testing search results, I realized that the site had been virtually erased from Google’s index.
My first inclination was that we’d been blacklisted for some unknown reason, perhaps for serving up malware or who knows what else. After spending the better part of a day looking at just about every possible thing I could think of and finding nothing out of the ordinary, I checked the site’s robots.txt file and found this:
User-agent: *
Disallow: /
That’s a doozy. The robots.txt file tells search engine spiders what should and what should not be indexed. The directives in this example say, “No spider should index any page on this site.” Ouch! Though not every spider honors the directives in robots.txt, Google certainly does – and they faithfully removed every one of that site’s pages from their index. That explained why search traffic had disappeared.
But knowing what this would do, who in their right mind would add that file? I certainly hadn’t put it there. With a long background in system administration and general security matters, my first impulse was that the site had been breached and that the attacker had replaced the default robots.txt file with the malicious one shown here. But before assuming the worst, I checked the modification date of the file and found it was identical to the date we’d rolled out the aforementioned SEO-related changes. That was too coincidental to ignore.
I called the developer who’d worked on the project with me, explained the situation to him and asked if he had any idea how that file had gotten there. After a long pause, he replied (with pain in his voice), “That was my fault. I didn’t want the pages on the development server to get indexed so I added the file. I forgot about it when we copied the source to the live site.”
Mystery solved. It wasn’t malicious; it was simply an oversight. And there was nothing I could say to the guilty party that would make him feel worse than he already did upon learning of his own mistake. I replaced the bad robots.txt file with the correct version and within days search traffic returned. For a small error, though, the consequences had been pretty large: thousands of search engine visitors had been lost.
Over the years I’ve seen lots of things like this happen, things that are usually the result of careless mistakes. No one sets out to make mistakes like this; they just happen. There are quite literally thousands of things you need to remember if you want to have a site where everything is done according to best practices and nothing is left to chance. No one person can remember them all. No one. Even large teams sometimes miss things, like forgetting to renew a domain name or SSL certificate. At my last startup, I put together monitoring server that literally made tens of thousands of quantitative and qualitative checks on our network every hour, and still things would occasionally creep through our web of detection.
The problem is vexing and widespread. I’m sure I don’t know anyone who hasn’t had something similar happen to them. I’ve been thinking quite a lot about this subject recently and I’ve come to some conclusions about how to address the issue. In a few weeks, I’ll post on this subject again.
When was the last time you looked your site through your visitors eyes?
I’m not talking about subjectively evaluating your design to grade it on how you think your visitors may see it; I mean actually loading the page to find out how it really looks at different screen resolutions. Are you visitors truly seeing what you think they’re seeing; or, do they have to scroll to see your most important page elements? If it’s latter, then you’ve already lost a good number of eyeballs.
With widescreen LCDs as cheap as they are, it’s easy to forget there are still lots of devices in this world with small screens. But don’t ignore screen resolution in your testing regimen. Without it, you could increase your bounce rate and reduce your conversions. You can’t count on users scrolling the page to see it all; and when they don’t see your message, it’s as if it isn’t there to begin with.
Clearly, this is a situation you want to avoid. Fortunately, there’s a very simple tool that lets you look at how much of your pages is seen – one that doesn’t require lots of tedious iterations through screen resolutions. You can make quick work of the problem with Google Browser Size : just give it a URL and it loads the page and shows you the percentage of visitors that will see the parts of your page at various resolutions.
Here’s how two of the most widely used home pages on the Internet look:
Amazon.com as shown in Google Browser Size
Google's home page loaded in Browser Size
This is one tool you should bookmark and make part of your test plan. It only takes a few seconds to use and the difference it makes could be substantial.
A few weeks ago I conducted a small study of the performance of Facebook’s new like button and its suitability in different publishing environments. When I finished, I wrote an article that discussed my findings. It was published on ProBlogger.Net today.
If you run an e-commerce site you probably measure your sales conversion ratio, which is simply the percentage of visitors who end up making a purchase. This crucial bit of information helps you to determine the cost effectiveness of advertising and the general effectiveness of the site overall. You can’t – or, rather, you should’t – run an e-commerce store without it.
Many site managers begin and end their conversion tracking efforts right there. But looking at just that one metric doesn’t provide complete picture of how well a site is really doing. Aren’t there other actions users take on your site that you should measure and consider a conversion, such as subscribing to your newsletter or asking to be notified when a product is in stock?
On sites that I manage, I like to know how well I’m doing in every measurable aspect. (Within reason, of course; it’s easy to get carried away and fall victim to analysis paralysis when you have too much information.) When it comes to tracking my total conversion ratio, I always combine sales and newsletter signups before dividing by the number of visitors.
Since I use Google Analytics for tracking web metrics, getting a sales conversion ratio is pretty easy. Most e-commerce packages include integrated Google Analytics support, and if they don’t it’s usually just a simple edit of the site footer to add it.
Tracking newsletter signups is a different matter. I use Mailchimp for managing my newsletters, and there things are a bit more complicated because Mailchimp doesn’t support Google Analytics – at least not yet. I could get around the issue if I could just embed the tracking code in my signup forms, but I’m foiled there because Mailchimp doesn’t yet allow hand edits of form HTML in the same way they do for campaigns.
Fortunately, there’s a way around the problem. [read more…]
Finally, Jobs delivers a comprehensive, coherent and reasoned response to criticisms of Apple’s refusal to support Flash on iDevices. I give him credit for responding at length, instead resorting to the one-liners that have been his habit since the brouhaha erupted.
The bottom line is that Apple is flexing their muscles to alter the way the web works, whether anyone likes it or not. Does it make sense? For several compelling technical reasons, yes. Could Adobe have come out with a version of Flash that would have satisfied those complaints? Probably. Would Apple have then allowed it on the platform? Probably not.
The sub-text here is this: self-serving business interests have conveniently intersected with some important technical considerations, the net effect of which is that Flash is dead as a platform – unless Apple buys Adobe.
Time to start thinking about the alternatives.
Yesterday Facebook gave site owners another way of leveraging social media by introducing the ‘Like’ or ‘Recommend’ button. They managed to do it in a way that makes integrating it into most sites a snap. Since I run the WordPress Thesis Theme on a bunch of sites, I set out to integrate the new feature into several of them.
Adding the Like button to Thesis turns out to be fairly straightforward, thanks to the Thesis Hooks system. The problem with the code Facebook provides, however, is that it is specific to a particular URL. Making it work with any blog page is the challenge. The code shown below does the trick.
This solution was created by Ruhani Rabin for generic WordPress installations. Putting the code in the correct place in Thesis was all that was required to enable it.
You’ll want to add the code shown below to your theme’s custom_functions.php file
Add this first bit to the top of the file, where you may already have other actions added:
add_action('thesis_hook_before_post','facebook_like_button');
Then, toward the bottom of the file, where your custom functions would go, add the following:
function facebook_like_button(){
global $post;
?>
<iframe src="http://www.facebook.com/plugins/like.php?href=<?php echo urlencode(get_permalink($post->ID)); ?>&layout=standard&show_faces=false&width=450&action=like&colorscheme=light" scrolling="no" frameborder="0" allowTransparency="true" style="border:none; overflow:hidden; width:450px; height:60px"></iframe>
<?php
}
If you want the button to appear somewhere other than the top of the post, alter the add_action line accordingly, using one of the appropriate Thesis hooks.
UPDATE: For generic WordPress installations or for those not needing the fine grained control Thesis provides, this plugin is probably a quicker, simpler solution.
UPDATE 2: I’ve evaluated the performance of the Like button on three different sites and have concluded the buttons may be wrong for some sites.
Web pages that render properly in some browsers and not in others are a big headache for site managers – and a pet peeve of mine. In a perfect world, pages would look and work the same in all major browsers; of course, in the real world, that simply just doesn’t happen. To uncover these flaws before users do, cross-platform and cross-browser testing is customarily performed before the new pages go live. Too often, though, it is a step that gets less rigorous attention than it should.
With many years of experience under my belt, I take it with a grain of salt whenever a member of my development team provides me with completed web code and assures me that ‘it works’. I begin by opening the site in Safari (my preferred Mac browser) or Firefox, both of which seem to handle standards-based web code well. Sure enough, the page nearly always renders perfectly. So far, so good. Tempting fate, I turn my attention to testing it in Internet Explorer 7 or 8, the preferred browser of the majority of web users.
Then everything goes to hell: font’s don’t look right, the spacing of text might be off or items are completely misplaced on the page. It almost never fails. Why is it that a finished product that is said to work so often doesn’t? [read more…]
If you do any email marketing, chances are you’re familiar with your newsletter open rate, which is simply the percentage of people who view the email you sent. Naturally, the goal is to have an open rate that is as high as possible.
Although there are lots of factors to consider when sending promotions, such as timing, sender name, and so forth, the subject line of the newsletter is perhaps the most important. With an enticing subject, the reader is more apt to open the email. For example, a subject line like, “Check this out,” almost guarantees your message will be deleted and/or flagged as spam. But a good subject line, such as “Invitation to Our Next Event,” stands a better chance of being opened and read.
Writing good subject lines is simply good copywriting. It takes time to master, but that doesn’t mean trial and error is the way to go about it. If you spend just a little time researching the dos and don’t you’re apt to find yourself reaping much better returns from your e-mail marketing efforts. A short but sweet article on this subject can be found on Mailchimp’s website, where they’ve spent a good deal of time analyzing what works and what doesn’t.
For those who feel they could use a little help, today Mailchimp announced their subject line suggester. As the name, ahem, suggests, you provide Mailchimp with phrases from the subject line you’re thinking of using and they provide you with examples of wording changes that will likely make it more effective. The suggestions are based on their analysis of subject lines used by their customers and the open rates those subject lines garnered.
As with any automated tool, use good sense when considering the recommendations.
Always be honest with people if you want their trust. This is as true in life as it should be on the Internet.
Today, while visiting the site of one of the leading Mac OCR vendors, I saw a link labeled ‘Demo,’ which I clicked, assuming it would take me to the page where I could download a demo version of their software. I landed on a page that requested my name and email address, and I assumed that after handing over that information I’d get an emailed link where I could grab the software. It seemed like a fair trade.
But that didn’t happen. After I provided my personal contact information, I was taken to a page where I could view a Flash-only demo of the product – no download in sight, and certainly not what I was expecting or what I believe most people would reasonably have expected. I was so incensed by this blatant bait-and-switch that I no longer care about their product. (I’m also so irritated that I’m not even going to mention the company’s name)
This example demonstrates the type of tactic that will backfire all the time. Don’t do it.
Often the most confusing thing about running a website is knowing what to do first. With so much to do, and without a clear set of priorities, you can end up devoting too much attention to things that don’t matter and completely forget the things that do. But if you have your priorities in order and adhere to them, there is zero chance you will fall victim to this common pitfall. At the end of the day, it’s a very liberating feeling to know you have’t forgotten anything important.
So how do you know what your priorities are? Over the years I’ve developed the following rules for managing websites. Remember, these are general rules I use to dictate the order in which I perform site-related tasks; my specific rule is that people who really know their business can get away with shifting the order from time to time, with one caveat: Rules 1,2, and 3 must always come first. [read more…]
