There is no SEO

I think it may be time for a new acronym for the idea of optimizing your site for Search Engines. The current term "SEO" has a problem because while it's clear to everyone what the goal is (a higher rank in search engine results), it's vague about how to achieve that goal. As a result SEO has been broken into two different categories:

"White Hat SEO" - Generally meaning anything done to modify a website to make it more readable and searchable by Search Engines.

"Black Hat SEO" - Pretty much anything and everything else done to improve search result positioning. 

The colored hat term is drawn from the security/hacker community, where "White hat hackers" are people who disassemble and attack systems with the goal if improving them, while "Black hat hackers" are people who attack systems to steal information (both of which should be separated from the general term "hacker" - which are just people who do cool stuff with technology). While the transgressions of a "Black Hat SEO" specialist won't usually run afoul of any state or federal laws, they will usually end up running afoul of the terms of use of any particular search engine, which might be just as bad in pratical terms. Or they may just end up doing nothing and calling you names (As this guy found out). 

Why should you avoid Black Hat SEO? Well, the goal of any search engine is to provide results that are userful to their users. If you somehow manage to convince a search engine that your site is useful for a set of search terms when it actually isn't, your are essentially taking advantage of flaws in a search engine's algorithm. As search engines continually refine their algorithms to get rid of sites like yours, at some point your site will fall back down the results list. If you did the hacks yourself, not a big deal, but if you paid $5000 to a SEO Company to get you a #1 Ranking for motivational office wall-art and are now on page 10, you are SOL. Even worse, Search engines maintain blacklists of sites that try to game the system and so you may not even show up on page 10. 

What's option B? First, make sure your site isn't just a 1-off get rich quick scheme. If it is, see option A. That's your best bet, milk it for as long as you can then go take advantage of people in another god-aweful pyramid scheme.  If your website is actually has a worthwhile niche that you think should be at the top of search results, you need to sit down and figure out with your web developer the best way optimize your site's content in a way that actually provides value to it's viewers. As such I propose that term SEO has been misused and bastardized that it is no longer really a good term to describe the many subtle varients of the business. Here are my favorite replacements for the White/Black Hat SEO's:

"SEA" - Search Engine Accomodation - Accomodating search engine spiders by making it as easy as possible to succesfully find and index the content of you site.

"SEM" - Seach Engine Maniuplation - Taking advantage of flaws in a search engines to try to gain a temporary boost in ranking.

The next time you're talking to someone trying to sell you a SEO package, ask them what their strategy is to give your site a boost. 

Turning Something into Nothing

Recently we finished up a couple of E-commerce sites with the integrated webiva shop running off of a standard merchant account. One of the things that must be taken care in most case is to make sure you're site is in PCI (Payment Card Industry) compliance before the merchant account will be activated.

PCI Compliance for websites is great idea. It makes sure that merchant are securely encrypting data transmissions, notifying users of their privacy policy and letting users know of shipping and their refund and cancelation options (some of these thing I believe are beyond the scope of basic compliance but are requirements of the merchant account we were using). It's a great idea, but you can always count on great ideas to get screwed up somewhere along the way when corporations are involved. 

After sending the site over with a carefully crafted privacy policy (ok, not carefully crafted, but reasonably well written) and a concise refund policy, I received a message back that the pending application might be disallowed because it made no mention of shipping costs or returns. That would make sense, of course, if the site sold any actual products that needed to be shipped or returned. As it didn't, adding language about shipping and returns wouldn't make a lot of sense. 

As this was one of the requirements for "PCI Compliance", any sort of discussion would be out of the question. A few emails back and forth, along with some boiler plate language passed along, the site now has a fully non-sensical return and shipment policy. Much like a warning label on a Penut Butter : "Warning contains nuts", adding additional non-useful language just to make some legal-type happy does more than just add useless cruft to a site, if lowers the all important "signal-to-noise" ratio of a site, making it less likely visitors will find the information they need because of all the extra stuff needed.

On a happier note, if the site starts shipping goods sometime in the future, we'll have that boilerplate policy already in place..

Feedback Cycles

When my wife and I are forced to leave our Condo / Office (despite my best efforts, this usually happens a least once every couple weeks), we need to crate our dog Oscar lest we come back to an apartment full of destroyed footwear. Although Oscar willingly spends plenty of time in his crate otherwise, happily sleeping there when our tossing at night kicks him off the bed, the command 'Kennel up', immediately puts Oscar into soulfull, sad eyes mode - letting us know that we are taking all the joy from his life.

At least, that was my anthropomorphic explanation of his behavior. Turns out, by standing completely still, and looking up at us with puppy-dog eyes, Oscar will immediately get himself picked up, apologized to, petted for a little while, and lovingly placed in his cage. 

As it turns out - my wife and I were screwing up the feedback cycle.

Oscar wasn't responding to the command, but instead to our reaction of it. The problem wasn't him, it was us. In order to fix the cycle, we secretly placed a treat into his kennel before commanding him to 'Kennel up', and coax him into his kennel without picking him up. In a short period of time, we managed to correct his behavior by fixing our reactions to it.

What does this have to do with Web Development? Nothing really, but it has everything to do with managing clients (No, I'm not calling clients Dogs). Letting clients get away with over-the-top last minute demands, while it may seem like the right idea,will invariably land you in hot water with them and other clients. There's only so many hours is the day, and pushing off scheduled work to make an ill-considered, ill-advised change to a website or piece of code may placate one client temporarily, but will almost guarantee something else gets left in the destructive wake of that last minute job. It might be QA testing, it might be another client's Milestone (nicely scheduled two weeks previously), or it might be a meeting with a potential client that you are forced to reschedule. In my experience, most often it is actually that client's work that ends up taking the hit because there isn't time to go through the normal design/development, approval, testing and deployment cycle. It might be a little thing, like an incorrect phone number on an ad. Or a big thing, like a crucial website failure over the weekend that gets everyone riled up and pointing fingers. But without anyone stepping back, it's easy to let the cycle repeat itself over and over again (A la Deploy! Deploy! Deploy! ).

By allowing clients to get away with this behavior on a consistent basis you are letting your clients harm their business and your business for no good reason. The client doesn't necessarily benefit either, as errors and bugs will creep into the final product and your client's reputation can suffer. Clients won't necessarily be able to see that big picture, all they see is your quick turnaround time and assume everything is good to go. Unless you can convince them that slowing down is better for everyone, the last minute demands won't stop. 

Sometimes a client's last minute work can't be helped for some reason or another, but as you're throwing together that needs-to-be-done email campaign and corresponding landing page at 3:30 on a friday, ask yourself if it really needs to be this way, or if you haven't created the proper feedback incentive. 

Design DRM

There's been a significant hub-bub in the past few months regarding the DRM in a number of recent or upcoming PC games, specifically Electronic Art's Spore and Mass Effect, that resulted in a loosening of restrictions (See Slashdot Post), as well as some anger over Microsoft's decision to potentially lock some users out of legally purchased music after the Licensing server is retired (See Engadget summary). "DRM" for the small percentage of people who haven't had their lives made less enjoyable by it, stands for Digital Rights Management, and is nicely defined by the people at Defective by Design (an anti-DRM effort promoted by the Free Software Foundation ) as:

 Big Media describe DRM as Digital Rights Management. However, since its purpose is to restrict you the user, it is more accurate to describe DRM as Digital Restrictions Management. DRM Technology can restricts users’ access to movies, music, literature and software, indeed all forms of digital data. Unfree software implementing DRM technology is simply a prison in which users can be put to deprive them of the rights that the law would otherwise allow them.

One of the largest criticism of DRM is that because it only affects legal users of software and media, it places an undo burden on those who are actually legally using your product. If my mother, for some bizarre reason buys a media player that isn't an Ipod, then all her music purchased via Itunes becomes worthless unless she jumps through a bunch of "gray area" hoops. Someone who downloaded all the same music from a p2p site illegally faces no such problems. Same goes for software registration of Shareware, many times it's more difficult to register software than it is to download a cracked copy. Does this mean that it's ok to do so? No. But if you are creator of any type of Intellectual Property (IP)- be it media or software - it's important to be aware of other people's failures.

In the case of digital content creators, such as ourselves, we have options as how to you present your work, whether it be your portfolio, concepts or client work-in-progress. Some agencies choose to only present their work during face-to-face meetings on concept boards, and hoard developed software behind a multi-page NDA's. These agencies are guilty of causing the same issues that the developers of the aforementioned DRM schemes are: they are significantly impacting their paying customers to gain a slight protection of their IP. As a constrast, we generally present concepts online or via Email, where if a someone really wanted to they could rip us off and refuse to pay for our work. We present a demo of Webiva CMS to anyone who's interested - even though there a number of propriatery features that don't exist in other CMS's on the market. Does operating this way have the the possabiltiy of  coming back to harm our bottom line? Theoretically, of course it does. But in our experience with actual clients, giving them the greatest opportunity to take in our work and allow and open flow of ideas and reactions will bring about the highest quality end product the quickest.  

The bottom line is that even with whatever restrictions your put in place, much like a determined software pirate, if someone trully wants to use rip off your IP they will find a way to get at it. There's not that much you can do except document the issues, send a C&D and put it to the courts. Putting additional restrictions on the 99%* of your clients who have no intention of ripping you off will limit your ability to over-deliver and grow your business. 

* This advice, of course, only really applies to businesses like what we're doing at Cykod - Shareware software developers and PC game programmers are probably seeing greater than 50% of their user base using their product without paying for it (Now anyone who thinks those represent 100% lost sales probably works for the RIAA accounting department, but there is very real, significant lost revenue in software piracy), so by all means - protect your software in whatever way you can, hopefully minimizing the impact to the legal users. 

Just Try it or "is there a fly in your soup?"

To badly paraphrase from memory the joke told during the credits of the classic Eddie Murpy comedy Coming to America (back before Eddie's live acting carreer became pretty darn irrelevant):

Customer : Waiter come taste my soup.
Waiter : Is there there a problem with the soup?
Customer : Just taste the soup.
Waiter : Is it too hot ? Is it too cold ?
Customer : Just taste the soup.
Waiter : Is there a fly in the soup ?
Customer : Just taste the soup.
Waiter : Ok, fine I'll taste the soup! Where's the Spoon?
Customer : Aha!

 This joke illulstrates the sort of rut that it's important to avoid as a Developer when dealing with complaints and Bug reports from clients and users. In an ideal world, any web-related user-reported* bug should always include at least the following info:

What url did happen at and what were you doing? When did it happen? What did you expect to have happen? What actually happened? What browser are you using? What account are you using? [ Also helpful: What "Ad Supported Toolbars" do you have installed? How many different P2P Clients have your children installed on your computer? ... ]

But 90% of the time the bug report consists of:

It didn't work. 

Playing the Jerk Programmer card isn't the best way to build repeat business. Sometimes, the right thing to do is just try the soup. Take what little information you are given and do your best to replicate the problem - provided you're not wasting hours of time -  and then gently prod the submitter for the additional information you need.

I've found that more often that I would like to admit, a quick attempt to replicate the problem myself will turn up the bug without too much back and forth. And everyone will be happier for it. Feel free to send over that detailed "Bug Report" form to the client for next time. They won't actually use it, but it will make you feel better.

*As an aside, I say user-reported because if your system is generating an exception you should already have all that information wrapped up in a nice package yourself - In our case using Rails' rescue_action_in_public lets us drop exception data into the Db and send an email with a stack trace directly to an administrator.