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.)

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.

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!

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.

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.