Impressive Designs

Search Engine Optimization can be tricky to master.  How your website ranks is important to your business, but it is also the trade secret of another company (namely Google).  Thankfully, it’s not a total guessing game.  Testing, trial and error, as well as experience can go a long way.  Unfortunately, there is plenty of SEO misinformation floating around and there are several ways these myths get passed around as true.  The following myths all came about in the same way; an observation that somehow became an SEO truism. Put another way, correlation does not imply causation. If we add that to Occam’s Razor we can do some serious SEO debunking.

The Infamous Sandbox

Myth: New sites do not rank well because of the “Google sandbox”.
Reality: New sites can be indexed within minutes, and even rank well.
The Google sandbox refers to a time based ranking penalty that is given to new websites.  More than likely, however, a new site just doesn’t deserve a higher ranking. It can be painful to hear, but just because it’s your website doesn’t mean it should be listed at the top right away.  If you are in a competitive market, everyone above you in the rankings has spent years promoting their site, adding new content (more on this later) and building up their rankings.  It’s a continuous process that can take some time. Just because low rankings often correlate with new sites, that doesn’t mean there’s a cause outside of proven and traditional SEO techniques.

.Edu Links

Myth: Links from a .edu domain have more weight than a link from a .com site.
Reality: You would take a link from the Google.com homepage over little Joey’s high school website any day.
Yesterday, the Business Insider reported that overstock.com got penalized because “Google’s algorithm assumes that links from .edu domains are from academic sites and gives them more weight than links from other kinds of sites.” Putting aside the anthropomorphism of having a bot going around assuming things, what makes academic results more relevant or more important anyway?  If a university announces a football victory on their website, everyone searching for NFL scores has to wade through college football results?  Even if this myth were true, wouldn’t the Google algorithm “assume” schools give out free publishing tools like blogs to their students; opening the floodgates of cat-blogging and black-hat link spamming.  Links from university sites are valuable because they generally have authoritative, quality, and established websites.  Not because they have .edu domain names.

It’s easy to see how these myths spread out of control too.  On the same article you can read comments like, “I never knew that .edu backlinks were more powerful than other backlinks for search engines. Looks like I’m gonna have to change my search engine optimization strategy to building backlinks on .edu sites.” (Insert sigh of perpetual sadness here.)

Fresh Content

Myth: Google loves websites with fresh content.
Reality: This one is actually true (except the fresh content part).
Users like fresh content (or unique content, or useful content, or interesting content) and Google loves to deliver what users are looking for. A ten year old, unedited Wikipedia page may outrank anything new that comes along.

The opposite can be equally true as well.  To demonstrate this, let’s run through a hypothetical experiment.  Website A is about cooking exotic meats.  (Pass the Gorilla, yum!) Website B is also about cooking exotic meats.  Website A has three pages about what is safe to eat and how to prepare it.  Website B posts a new recipe everyday on the blog, has active discussions on the forums, has helpful resources, lets users create a custom recipe book, writes articles about what is particularly delicious, etc, etc.  Website B ranks higher because of all the fresh content? No! Website B is just better and probably more relevant to what people are searching for.  (People who eat exotic meats are obviously always looking for something new.) What happens when your website is better?  More people visit it, link to it, share it with social media, talk about it, blog about it, news outlets cover it, and traditional SEO comes into play.

If this myth was true, creating a page on your site that generates random gibberish everyday would improve your rankings.  That would make the web a very bad place indeed.  Anything that makes the web a bad place wouldn’t be encouraged by Google.  Sometimes it helps to consider the perspectives of the search engines.

Bonus Myth Spin-off

Myth: Google loves Wordpress too!
Reality: Google would rather just be friends with Wordpress.
Doing a search for Google Loves Wordpress returns lots of results claiming this alleged love. This myth is really “Google loves fresh content” with a twist.  After all, what is Wordpress but a platform to deliver fresh content?  Unfortunately, claiming Google prefers a particular platform over another just lowers the credibility of the claim even more.  For a moment, let’s forget that Google owns Blogger, a service in direct competition with Wordpress.  One platform can be better optimized than another, that is true.  However, Wordpress “out of the box” is not especially optimized for search engines.  If it was, the All in One SEO Pack plug-in wouldn’t have over 7 million downloads.  To make this myth true, one would have to say, “Google loves quality blogs and you can create a quality blog with Wordpress. Also, custom programming or using a good SEO plug-in will help a great deal as well.” Just not as catchy, huh?  The reality seldom is…

It’s an SEO Jungle Out There

Ultimately, these myths are just conclusions that are poorly drawn yet highly referenced. It’s understandable how people could draw these conclusions, but they all stem from a lack of SEO fundamentals.  As Isaac Newton once said, “We are to admit no more causes of natural search results than such as are both true and sufficient to explain their rankings.” (Well, certainly he would have said that if he was alive today.)

“Hello sir, my name is Joseph,” said the very un-Joseph sounding individual. “I’m representing [insert impressive sounding non-company name here] and I’d like to speak with whoever is in charge of your website.”

“Well, Joseph, that’d be me,” I replied.

“Sir, our company has authorized me to offer you an exclusive opportunity to increase the performance of your website. For a limited time I can offer you tremendous discounts on our ground breaking technology. For only....”

“Excuse me… Joseph, is it?”

“Yes sir, I am Joseph...”

“Joseph, have you even looked at our website?”

“Um. Excuse me sir?”

“Have you seen our website? I’m just wondering because I believe a company as important as yours should be sure of who they’re doing business with. I mean, how can you be sure your ground-breaking product will work on our website?”

The sound of furious clicking comes to me over the phone as poor Joseph tries in vain to circumvent the proxy access his cubicle has to the internet. “Um, sir… I’m uh… having a little problem here...”

“We’re not just a name on a list are we, Joseph?”

“Um, well sir… to be honest...”

“...Because I’m not sure I could be persuaded to do business with a company that doesn’t take the time to get to know their possible clients.”

“Well… um… I could take you off our calling list...”

“WHAT!? Take me off your list? Why would you do THAT?”

“Um… I didn’t intend to bother you sir… I just have you on my list and...”

“SO! Now we’re not good enough for you?”

“Sir, I never… “

“WELL. If we’re not good enough for you… if you’re SO willing to hastily remove us from your calling list, then I think that’s JUST what you should do. GOOD DAY, sir.”

My only regret is that I haven’t the skill to deliver the last line in a clipped, proper British accent. 

Very recently Facebook and Twitter have changed to (or added) new URI structures that contain a shebang.  A shebang looks like this: #!
(I know technically it’s not a shebang.  It’s just easier to say than a hash with exclamation point after it.)

Naturally, this threw many SEO’s like myself into a raging panic.  “Search engines ignore everything after a hash”, we proclaimed.  “All of our SEO work in social media has been for not!  Oh the humanity!”

Fortunately, this is not the case.  These major social media outlets are using Google’s spec to make AJAX crawlable.

That’s right, web apps can be as crawlable and optimized as static content.  Well… in theory.

If we take a look at what Google has indexed for these Twitter profiles with the new URI structure, we get a single result, and about 100 in the supplemental index.  For a major pagerank site like Twitter, that doesn’t look too promising.  Google even says in the FAQ, “Just as with static web pages, Google makes no guarantee about search rankings.” A bit of an understatement, no?  Granted, the change on Twitter is still rolling out and is still opt in at the time of this writing.

In any case, I think these results will improve vastly going forward.  More and more web apps using asynchronous javascript are popping up on the web everyday, combine that with Facebook’s adoption of Google’s spec, and you have something that will be going the distance.

So all that is the cat’s meow, but how is crawlable AJAX accomplished?  Well, it turns out that crawling through AJAX ain’t like dusting crops, boy.

Here’s the basics of how it works.  You want to have your regular AJAX app look like this: www.example.com/ajax.html#!key=value and then a canonical version that is a static snapshot.

When users hit your site, nothing will happen.  However, Googlebot automatically knows (it is their spec after all) to modify each AJAX URI to fetch a static snapshot of that page.

The static HTML snapshot must be generated when this URI is accessed: www.example.com/ajax.html?_escaped_fragment_=key=value.

So, you grab it:
$escapedfragment = $_GET[’_escaped_fragment_’];
or you grab it:
Dim escapedfragment As String = Request.QueryString("_escaped_fragment_")
depending on your favorite flavor, and if it’s not null, spit out an HTML snapshot.

How do you create an HTML snapshot? Just use some type of headless browser.  It’s not as scary as it sounds, just use something like HTMLunit or crawljax.com to grab it.

If you’ll forgive the personification, Google hates it when Googlebot sees something different than what users see.  I mean hate, with a capital H.  So be very careful to match your HTML snapshot with your AJAX app or you could find yourself filling out re-inclusion requests all night long.  Also, I believe only Google has a spec for this type of thing, so if your SEO strategy requires Yahoo! and Bing you might want to consider an alternate implementation.

For more info, check out http://code.google.com/web/ajaxcrawling/ and happy SEOing!

Here at Imp Designs, we develop sites either in Ruby on Rails or ExpressionEngine. With Ruby on Rails, everyone has a running copy of the app on their local machine; changes are visible immediately and testing browser compatibility is largely just a matter of firing up Parallels and perhaps editing a hosts file so you can see it. With ExpressionEngine, it’s make a change, commit the changes, push to the server, then start testing. Why not just run EE locally? Well, because EE isn’t very portable. You see, ExpressionEngine stores a pant-load of configuration settings in it’s database. Frustration about this situation is well documented, but ExpressionEngine’s features and flexibility still make it our first choice for relatively simple sites. Still, it’d be nice to be able to run an EE site locally and avoid a bazillion cycles from the development environment to the server. So after a bit of trial and error and with a couple of caveats (which I’ll list at the end of this article), here’s how to make it happen with ExpressionEngine 1 (we’ll get to EE2 in another post, honest).

What you’ll need. This isn’t for the wysiwyg set. If the terminal scares you and you’re afraid to poke under the Mac OS hood, run away. You’ll need to install MySQL, enable PHP, and set up a virtual host for your site. Installing MySQL and enabling PHP aren’t in the scope of this article… JFGI (Don’t know what that means? Google “JFGI"). You’ll need a copy of your EE install, a dump of the database in .sql format, comfort working with the terminal and a willingness to poke about in EE’s config file. Oh and one more thing… you should be running EE 1.6.9 or higher. Earlier versions of EE aren’t compatible with the PHP version Mac 10.6 has installed. You can make it work with earlier versions, but it’s almost as much trouble as simply upgrading.

First Step: Setting up a Virtual Host. Your first task is to get a virtual host set up so that your local machine can serve up the site. You can either painstakingly edit a variety of apache config files… or you can cheat. I have access to Jerrod the code ninja and his incredible talent for automating mundane tasks, so I’m proud to introduce a new Ruby Gem: blavoshost. This nifty little gem automates setup of virtual hosts. To install, open your terminal and type:

sudo gem install blavoshost

Be ready to enter your password. All done? Great! Now we’ll use blavoshost to automate the virtual host set up. Get the name of the directory your EE files are in and type this into the terminal:

sudo blavoshost add name-of-directory

Stuff should have just happened. Restart Apache with this command:

sudo apachectl restart

Now you should have a virtual host set up that will serve your site locally at http://name-of-directory.local.

Next Step: Set up your database. To accomplish this, you’ll need to have a copy of your EE database in .sql format. If you’re hosted on a WHM/cPanel managed server, use PHPMyAdmin to export a copy to your local drive. Most likely it’ll drop into your downloads folder. Assuming that’s the case, use these commands to set up your database:

mysqladmin create database-name
mysql database-name < ~/Downloads/database-name.sql

Now the jiggery-pokery… editing the config file. Here’s the tedious part, editing the config file. And there’s a few things you should know about ExpressionEngine 1 and the importance of this little file. By default, ExpressionEngine stores a bunch of configuration information in the database. This is crazy inconvenient if you wish to run the site in multiple locations. And the way EE stores the config information makes it difficult to edit manually in the db. Fortunately, the system/config.php file gives us a way to override all sorts of settings that are stored in the EE database (For a full list of what you can manage with this file, click here.) Warning: When updating ExpressionEngine, the updater overwrites the config file, so always keep a copy of the system/config.php file… I just copy my work over to the system/config-bak.php file.

A typical config file looks like this:

<?php

if ( ! defined('EXT')){
exit('Invalid file request');
}

$conf['app_version'] = "169";
$conf['license_number'] = "hell yeah you should buy it";
$conf['debug'] = "1";
$conf['install_lock'] = "1";
$conf['db_hostname'] = "localhost";
$conf['db_username'] = "user_name";
$conf['db_password'] = "password";
$conf['db_name'] = "db_name";
$conf['db_type'] = "mysql";
$conf['db_prefix'] = "exp";
$conf['db_conntype'] = "0";
$conf['system_folder'] = "nrlg";
$conf['cp_url'] = "http://somesite.com/site/index.php";
$conf['doc_url'] = "http://expressionengine.com/docs/";
$conf['is_system_on'] = "y";
$conf['allow_extensions'] = "y";
$conf['multiple_sites_enabled'] = "n";
$conf['cookie_prefix'] = "";

What we want to do is modify this file so that it’ll set the configuration properly regardless of where the files are ‘living’. We’re going to set up an if statement to check which environment the site is running on and store environment specific configuration, and we’re going to use standard php variables to set up common paths in a manner that will allow the site files to work regardless of their location. Here’s an edited config file:

<?php

if ( ! defined('EXT')){
exit('Invalid file request');
}

$conf['app_version'] = "170";
$conf['license_number'] = "seriously, buy it";
$conf['debug'] = "1";
$conf['install_lock'] = "1";
$conf['db_hostname'] = "127.0.0.1";

if($_SERVER['HTTP_HOST'] == 'name-of-directory.local'){
  $conf['db_username'] = "root";
  $conf['db_password'] = "";
  $conf['db_name'] = "local_db_name";
  
} else {
  $conf['db_username'] = "username";
  $conf['db_password'] = "password";
  $conf['db_name'] = "production_db";
}  

$conf['cp_url'] = "/system_name/index.php";
$conf['theme_folder_url'] = "/themes/";
$conf['theme_folder_path']= $_SERVER['DOCUMENT_ROOT']."/themes/";
$conf['tmpl_file_basepath']=$_SERVER['DOCUMENT_ROOT']."/template_dir_name/";
$conf['site_url'] = "/";
$conf['db_type'] = "mysql";
$conf['db_prefix'] = "exp";
$conf['db_conntype'] = "0";
$conf['system_folder'] = "system_name";
$conf['doc_url'] = "http://expressionengine.com/docs/";
$conf['cookie_prefix'] = "";
$conf['is_system_on'] = "y";
$conf['allow_extensions'] = "n";
$conf['multiple_sites_enabled'] = "n";

So here’s what’s going on. First, the db_hostname needs to be changed to 127.0.0.1. Curious why? JFGI (see above). Next check out the start of the if statement. We’re checking to see if our site is located in our local directory. If it is, we’re feeding EE the database settings for the local environment. If it’s anywhere else, we’re loading the production settings. Next are a series of settings you will probably use, but you may not use all of them. Note the use of PHP variables to either define the document root or the server host depending upon whether you’re setting a path or a url. Some of these settings shown are specific to how we develop—we save templates as files and hide the index.php using .htaccess— so you may need to modify some of these settings accordingly. Refer to this site for a complete explanation of all config settings.

Them Thar Caveats. Running the site locally makes checking template codes, stylesheet tweaks and such much easier. But anything you might do that requires writing to the database will have to be duplicated on the live site… things like adding a field to a weblog, adding a member group, editing categories, adding entries. You’ll have to work out the best way to work with a site in development. Maybe it’s making that sort of edit in the live site, then exporting the updated database and replacing your local copy. Maybe it’s getting your code ninja to write you a script to do that for you.

Conclusion. Is all this worth the effort? I guess that depends… if you enjoy the Ruby on Rails ‘develop on your desktop’ experience, this brings working with EE a little closer to that vibe. During the stylesheet setup cycle and for testing javascripts and such, this is a much easier way to test changes.

NOTE: The latest version of blavoshost assumes we’re dropping the files into a hosting account and appends /public_html to the file path in the /etc/apache2/sites-enabled/nameofyourdirectory.conf file. You may have to open this file and edit it to view your site properly. Assuming you have textmate and you’ve configured it to work with your shell, type

sudo mate /etc/apache2/site-enabled/nameofproj.conf

to edit.
Addendum: If you’re using a module/plugin/extension that stores a file path in the ExpressionEngine database, you’ll have to manually set that path for whatever environment you’re working in. For example, if you’re using any of the Pixel & Tonic add-ons that utilizes fieldtypes, you’ll need to set a path for that. How will you know you need to do this? The EE tags will render instead of the desired content.

For our second Rally Point meeting, Gabe Kessler did a presentation on ExpressionEngine 2 and JQuery. The long awaited version 2 introduces a lot of changes in how the ExpressionEngine deals with javascript—since the admin relies on jquery the developers put in place a mechanism for managing jquery so you have one place to deal with libraries and plugins and such. Gabe demonstrated the essential tags for the module and showed us where in the directory structure to drop plugins.

The real cool stuff was his walk through of the JQuery UI. He demonstrated how easy it is to set up customized JQuery UI elements using the jquery theme roller. Go ahead… click the link and dink around for a little while… I’ll wait here.

Back? Cool. Not satisfied with that bit of marvelous-ness, Gabe went on to demo some Google API tools. The code playground, web fonts, translation tool and other goodies were demoed to the accompaniment of oooos and ahs (most genuine). For a list of links to the items he displayed, visit Gabe’s delicious bookmarks group for Google API.

What the heck is this all about? Twice a month one of the Imps presents a topic of interest to everyone at lunch. Currently we’re doing this on the second and fourth Wednesday of the month.

A few weeks ago Sheila, Gabe and I met and discussed coding and CSS strategies. We enjoyed the exchange of information so much we decided to make the forum official. Now we’re holding a Rally Point meeting the second and fourth Wednesday of each month. Each Rally Point meeting will have one of our team present on a subject of interest to all the Imps and allow for a free exchange of information about the subject.

Our first Rally Point meeting was all about Rails 3 and Bundler and was presented by our code ninja, Jerrod Blavos. Jerrod demonstrated some of the coolness of Rails 3 by building an app that pulled images from a Flickr account using the Flickr API, stored them locally, then processed various thumbnails and displayed them on a web page. He built this app in a matter of minutes… a feat made possible by the awesome-ness of Ruby on Rails!

Jerrod also talked about Bundler, a gem that helps manage Ruby on Rails application dependencies. It’s a part of Rails 3 and massively simplifies the process of keeping gems in sync across an app’s environments (development, staging, production, etc.). Any Rubyists out there have certainly experienced the error message-gem install-restart-error message cycle that can occur when deploying an RoR app. If you know what I’m talking about and want to make your life easier, check out Bundler… it’s a godsend.

As with the first unofficial Rally Point meeting, everyone left feeling a little smarter… and perhaps a little challenged. Thanks to Jerrod for taking the time to put together a great presentation… now go out and download Rails 3 and Bundler and get yer Ruby on!

Additional Notes:
Mac OSX users should install RVM to aid in managing multiple versions of Ruby. Get it here. An excellent tutorial on Rails 3 is available here. I think they’ve kept up with the notes and such, but if you’re not comfortable dinking with the under the hood stuff on your machine, don’t.

When someone asks us to prepare a proposal for a site redesign, I do a five-point analysis of the site that includes researching the status of the site’s domain name. It’s shocking how many times I discover the site owner doesn’t have direct access to their domain name controls.

Most of the time this is a simple oversight. The existing web vendor obtained the domain name for the client under their registrar account and just never got around to transferring it to the site owner. Every once in a while, I see web developers attempting to use the domain name registration to trap their client. That’s totally uncool. There’s almost never a good reason for the web developer to keep your domain name in their registrar account. We encourage our clients to create their own registrar accounts and simply give us the login information. If for any reason we don’t live up to their expectations, they simply change the password and choose another vendor.

If you’re a business owner that’s reading this and wondering who’s in control of your domain name, visit DomainTools and check out your domain information. Check to make sure there’s an email address listed that you check regularly, that you are the “Registrant”, and that you have access to the account listed in the Registration tab. If you don’t find a valid email address or you don’t have access to the registrar account, fix it right away.

Whoever controls the registrar account ultimately controls your website. Check your domain registration status today!

We are pleased to announce the launch of an internal project TweetSack.  The site is a joint diversion between Chris(UI) and Jerrod(Nerdery) that aggregates and categorizes linked-to content from twitter, eliminating the short-url-itis that we all hate about tweets.

By ‘watching’ some tags, you will be given your own custom site navigation and a never ending, constantly updated stream of articles, blog posts, and content specific to your interests. We also provide a simple re-tweet tool for content you deem interesting enough that you would like to share with your friends.

Thats it for now. Check it out and let us know what you think.

When developing new features for existing (or new) Ruby on Rails applications, our UI people like to have some real content to use to optimize the design for an interface that works with the actual data.  It’s classic chicken and egg syndrome.

“I cant design that area because I dont know what the content is, but I cant put content there until I know what the design looks like.” - designers everywhere

My solution to this problem has always been to make a dump from the production site and import it locally, then tar up the system directory and pull that down. This works great since I am comfortable with scp and ssh and the mysql command line interface. The ui guys are not comfortable with this, but they do know how to deploy using capistrano, so there are two potential solutions to this particular problem:

1. Move into all of my coworkers offices, babysitting their database content and assets and loading these in for my command-line-fearing friends every time they need new data.
2. Write a tool that allows my command-line-fearing friends to run a single command to get said assets and db. Something simple and built on existing battle tested tools.  Something as simple as cap local:sync.

Obviously #1 doesnt scale, so we’ll hop right on to the second option. Introducing BlavoSync.  I’ll not reproduce the README here, but instead will go through basic setup and requirements.

Requirements:

1. A reason to have your production stuff on your development machine.
2. A production server running mysql and sshd.
3. A valid $RAILS_ROOT/config/database.yml file with entries for both production and development.
4. The latest capistrano2 and a valid $RAILS_ROOT/config/deploy.rb file with either a :domain or :rsync domain entry.
5. The blavosync rubygem, available at http://gemcutter.org (sudo gem install blavosync).

Hopefully you already have a nice little app running somewhere that has some decent data and assets. In your $RAILS_ROOT/config/deploy.rb file add this line to the top:

require “blavosync/recipes”

In addition, ensure that you have an entry either for :domain or :rsync_domain like so:

set :domain, “my.awesomedomain.com”

or if you are using some custom deployment location:

set :rsync_domain, “my.awesomedomain.com”

This covers the basic requirements, on to usage.  As long as your $RAILS_ROOT/config/deploy.rb file is working, the only action you need to take is to run the following on your local machine.

cap local:sync

This will dump the production database and load it into your local mysql database, defined in your $RAILS_ROOT/config/database.yml, and then rsync anything in your $RAILS_ROOT/shared/system directory on production into your $RAILS_ROOT/tmp directory in a new system directory. Once this is done, the $RAILS_ROOT/tmp/system directory will be symlinked into $RAILS_ROOT/public/system.

There are some considerations you should take before using this tool, such as do you have enough disk space or bandwidth to pull down all the assets. You may already have a $RAILS_ROOT/public/system directory full of assets, in which case if you want to keep those you should back them up somewhere and delete the system directory, otherwise the symlink may not work.

If you are on OSX you may need to enable FollowSymLinks in your virtualhost entry for these assets to be served by apache.

I met with a new prospect this week and their story about their previous web firm inspired me to create this list. If you’re a web development company and you’d like to drive your clients to Imp Designs, be sure to follow this list of practices carefully.

Tell your clients they can’t have access to their files. Nothing makes a client happier to move to Imp Designs than being told that their site files are held in a magic box on the internet that they may never have access to. Make sure to point out that they are obviously incompetent about the web or they wouldn’t have hired you in the first place. At Imp Designs, we gladly give our clients full access to their hosting account. We educate our clients about what they can freely edit and what they may need us to edit. If our clients inadvertently break the site, we bill them to fix it… but in the end it’s our operating philosophy that our clients own their website; we are just the site’s caretaker.

Completely ignore your client’s input about their business. We love working with clients that have worked with ‘know it all’ web firms. The ‘know it all’ firm already knows everything about every business ever created and can shoehorn any business into a cookie cutter web solution. Imp Designs feels every business has unique qualities and goals and that their website should reflect these qualities and function to attain these goals.

When you don’t know how to do something, tell your clients that what they are requesting is stupid. Yessiree, nothing like hiding a weakness with bluster. At Imp Designs we believe in honest answers to clients’ requests. If we are asked to perform a task that we’ve never done before, we ask for a day or two to research and then reply with an informed response.

Use lots of catch phrases, technical terminology and buzzwords to describe what you’re doing. Nothing endears your client to Imp Designs like making them feel really stupid. We can geek-speak with the best of them (it’s a hobby), but as Jerrod our code ninja says, “Sometimes people just want the sausage. They don’t care how it’s made.” We realize not everyone shares our passion for high tech geekery, so we’ve learned to identify the eyes glazing over stare that goes with “I don’t really care about that” and will quickly switch to simplify mode.

Deliver a poorly coded product and demand more money to fix the flaws. An extremely effective device for driving your clients to Imp Designs is to deliver a site with broken links and malfunctioning scripts and then state boldly that you require additional funds to fix the site. This is a proven method for ridding yourself of pesky, gotta have their site working, demanding clients.

Tell your client that Internet Explorer 6 compatibility is just something you won’t do… regardless of their site visitor stats. There isn’t another web firm in the business that will be happier than Imp Designs the day IE 6 dies a gruesome death. We plan to have a day long party on the happy day that we officially discontinue IE 6 support. But the fact of the matter is that some market niches don’t upgrade equipment very quickly. If you refuse to support a browser that a significant number of your client’s target audience uses, please help them out by sending them our way. We’ll grit our teeth and make it happen.

I hope you find the above tips helpful in your quest to drive clients to Imp Designs!

Whenever we get a call or e-mail for a site redesign job, we always perform a 5-step analysis of the existing site. We look at 1) technical issues with code, 2) esthetics, 3) usability and organization, 4) domain name registration, and 5) accessibility. Of these the one that usually gets questioned the most is accessibility. “What’s that mean?” we’re asked. “It’s a measure of how accessible your site info would be to a disabled person,” we’ll reply. “What? You mean like blind people? We don’t have any blind customers. I don’t want to pay extra for THAT,” sadly is a typical response.

I’m getting better at responding to this thoughtless reply. In truth, there are a variety of reasons to pursue at least minimal compliance with accessibility guidelines. First there’s a legal precedence; in 1998 Section 508 of the Rehabilitation Act (29 U.S.C. 794d) was modified to include guidelines pertaining to the accessibility of electronic media. As a matter of fact, since 1998 any website funded by federal monies need to “give disabled employees and members of the public access to information that is comparable to the access available to others.” Because this is a federal standard, several lawsuits have been filed on the basis that certain sites do not comply. Second, it’s pretty easy to hit the minimum requirements as outlined by the World Wide Web Consortium’s Web Accessibility Initiative. Simply having a site who’s code validates with the W3C’s validator usually meets the minimum guidelines. Third, it’s the right thing to do. Why not make life a little easier for a less fortunate fellow human being?

“Well sir, actually you DO have at least one blind vistor that comes to your site frequently and is extremely important to your site’s overall success. Google is a blind visitor. It comes to your site being able to do nothing but read the code just as a visually impaired individual would with a screen reader.”

UX Booth has an excellent article that challenges the mythical 3-click rule, the assumption that nothing on your site should be more than 3 clicks away. This misguided bit of “common knowledge” has resulted in a variety of user interface travesties such as drop-down menus with flyouts (brrrrrrrr) and other clever-with-a-"K" navigation methods.

The truth is that a well organized and clearly labeled navigation system will invite exploration and, as long as your visitor can see a clear set of choices, the number of clicks it takes to get to a bit of data matters not one whit. Usability is about ease of use, not some arbitrary rule. Read the article here.

Imagine you’re sitting at home and an unannounced visitor rings your bell. “I’ve been looking at your neighborhood and noticed that your house isn’t as attractive as it could be,” the visitor says. “If you’ll simply give me the keys to your house and $200/month, I’ll see to it that your house becomes the most noticed house on the block.” So.... in this scenario, how many of you are looking for the spare key and the checkbook? Not many, I’m sure.

Recently several of our clients have reported being contacted by an out of state search engine company. They state that they’ve been researching the market and discovered deficiencies in the keywords or coding of a site and that if you’ll simply sign up for a package and hand over all access to your website, they’ll make sure your site ranks on the first page of Google. Perfectly rational people who would never consider giving their house key to the visitor in the home scenario have called us asking if this is a good idea.

First of all, when’s the last time you even considered doing business with a telemarketer? No legitimate, ethical search engine company is going to cold call you. They don’t have to. Second, giving a third party total access to your website is a very bad idea. In the case of the company referred to above, I’ve discovered that they typically install hidden link farm pages on their client’s sites. Lastly, this company requests your credit card information over the phone for payment. A quick Google search of this company has revealed an enormous number of complaints concerning unauthorized charges.

There are plenty of legitimate search engine companies in the area. When choosing a firm, exercise the same discipline you would to hire any other vendor. Ask for references, follow up with calls to those references, and get everything in writing. Be aware that search engine optimization is an on-going process that takes time to see results. Stay away from firms that guarantee results or promise quick fixes; Google’s Webmasters pages state that you should be wary of such firms.

In other words, just think before acting!

Yep… just as I’m beginning to feel like I have mastered all the new stuff in CS3, Adobe has come along with CS4. I learned a long time ago not to be a big ol’ whiny butt about shelling out big bucks for an Adobe upgrade. Having the latest and greatest is part of what makes this career exciting and you can’t have that without buying new computers and software. Upgrading at every opportunity isn’t for everybody—I usually fall into the every-other-version category of upgraders myself—but when it comes to the Creative Suite and Mac OSX upgrades, I’m the born sucker Adobe and Apple thrives on.

My adventure with CS4 began with a frustrating trip to the Adobe website. The new online store is unnecessarily flashy (pun intended) and it steadfastly refused my attempts to login while stubbornly insisting that my account already existed. A phone call to Adobe’s support line, which is obviously outsourced these days, revealed that their latest site upgrade has resulted in a few glitches in their user databases and my account needed some behind the scenes rejiggering. Two hours later, I gladly parted with an absurd amount of money and headed anxiously for the download page.

...where I discovered no less than nine downloads which would require a combined 23 hours to download. Now all experienced Mac owners know that downloads almost always take less time than the “time remaining” indicator displays, but 23 hours?! I decided to postpone my new software bliss and made a trip to the office on Saturday to queue up the mass of downloads.

Monday morning I went to work early in anticipation of experiencing geek nirvana. Unfortunately, the download had failed sometime over the weekend and I was back to square one. This time, I chose to download only the essential application installer and Tuesday morning I was able to successfully install CS4. So far I like what I see. There was a lot of hand wringing over the new windowing system in Photoshop, but I’ve found it to be very useful and give it a bigs thumbs up.

I’ll add more to this post as I find time to experiment, so check back!

Update
So far my experiences with CS4 have been in the “oh cool” category, not the “oh-my-freaking-god-how-did-I-ever-live-without-this!!!” category. Overall CS4 seems to be a huge collection of little tweaks… things like auto guides that REALLY work in Indesign, type setting controls in Illustrator that seem finished instead of half ass, documents opening in tabbed windows, the save for web dialog box in Photoshop… you have to use it to understand the glory of how this little irritating beast has been polished. Good stuff…

By this time tomorrow night, all our stuff will be sitting in the Coastal Federal Building on St. Albans Drive. Hopefully, our T1 line will be moved without a hitch, Time Warner will have successfully installed an upgraded service, and I’ll be back in my chair breathing a sigh of relief at the smooth transition that was our move.

Sadly we won’t be able to gauge the success of a movie’s opening, walk to a coffee shop when we need a pick me up, or grab a mexican pastry. Our old office space was in a pleasant little strip of buildings located across the street from a Carmike Theater and our neighbors provided significant entertainment factor. We’ll miss chatting up the Rainbow Vacuum cleaner folks and telling confused wanderers, “No, the hairdresser is down two doors,” but we’ve outgrown the space.

I’m sure over time we’ll meet new friends at our new offices. The parking lot seems less frantic than our old location, and Christine has worked out her route to the smoking area already. It’s also perilously close to Bahama Breeze. I foresee staff meetings with foo foo drinks in our future. Tiny umbrellas anyone?

By the way… biggest crowd ever for a Friday at noon movie debut: the third Matrix movie. I am not at liberty to divulge whether or not I recognized any of the droves of work skipping geeks.