Last time, I was in the middle of plotting and scheming the addition of UJS to my search form and decided that now would be a great time to stop procrastinating my test harness. I’ve had some experience with TDD in the past, but as I’m the sole developer with limited time I can commit, I’m going to be hard pressed to work it in to the capacity that I’d like, make rapid progress, and blog along the way.

If you’re just joining, this is Part 5 of N. You can catch up here:

• Part 1: Setup and Data Import/Export via CSV
• Part 2: Adding Custom Authentication
• Part 3: Advanced Search Form
• Part 4: ERB to Haml

In the end, I decide that I’m going to start with some solid functional tests and backfill with unit and integration tests as time permits. My data model is not particularly complex, so pragmatism wins out.

I know I’m jumping into a rather in-depth foray, so I revisit Code School to get the overview via Rails Testing for Zombies. Seems reasonably straightforward for straightforward tasks, but I can see where some bits of code will be tricky.

Luckily, if I can just catch up on tests now, writing new ones moving forward should be considerably easier and I’ll fall into a rhythm. Filling in tests for existing functionality I don’t yet have coverage on is going to be a bit of a tedious exercise in brainstorming, which I imagine to be much of the inertia that prevents test suites from being retrofitted on many existing projects.

By the end, I have a few addition gems in my Gemfile:

group :test do
  gem 'shoulda'
  gem 'mocha'
  gem 'capybara'
end

group :development, :test do
  gem 'factory_girl_rails'
end

…and Capybara requires some extra code added to test/test_helper.rb:

require 'capybara/rails'

class ActionDispatch::IntegrationTest
  include Capybara::DSL
  
  def teardown
    Capybara.reset_sessions!
	Capybara.use_default_driver
  end
end

And so, I start hacking away at some tests for my Listings page, which is the most complex of the set thus far. I run into trouble early, as I have custom authentication residing in my application_controller.rb that’s being called from the listings page via before_filter for any destructive operation.

I spend a ton more time on this than I want to. In the end, it’s only a scant couple lines of code, but getting there is hairy:

(test/test_helper.rb)

class ActiveSupport::TestCase
  fixtures :all

  def load_user(user)
    @user = users(user)
    @controller.stubs(:current_user).returns(@user)
  end

  def load_admin_user
    load_user(:one)
  end
  
  def load_regular_user
    load_user(:two)
  end
end

(Not shown: in fixtures/users.yml, I have “one” and “two” users, where “one” has the admin bit set.)

Then, anywhere I want to test a specific user type, I can just call the appropriate load_x_user method first and it does what it needs to. I saw some recommendations that I just use the Capybara/integration side of testing to simulate user browser interaction with the page (and I’ll get to implementing those tests in time) but I really want to be able to write good functional tests for my roles as well.

I spend some time writing up (what I believe to be!) good tests around the authentication and also authorization (to the limited degree that I have it!) and decide to move on. TDD purists wouldn’t be pleased, but the best tools are those that help developers, right? What I’ve written so far helps me plenty!

Next up: Fetch latitude/longitude on save or update of the listing address, and switch over to Mongo for the free geospatial indexing!

Everybody’s happy with a little extra cash in their pocket, and we’re happy building great websites and applications! Let’s work together and make some happy!

Announcing Wagger’s New Client Referral Bonus Program

Throughout the months of August and September, Wagger is offering a $250 referral bonus to anyone who brings us a new prospective client leading to a signed agreement for $1,000 in work or more. We also aren’t putting a cap on the number of referral bonuses you can collect, so feel free to send us anyone you think could benefit from our services!

Note: This installment was planned, originally, to cover a twofer of topics. I’ll talk about why I chose not to at the end of the article.

Haml ALL the ERBs!

I have a couple of lingering hesitations over adopting Haml, which are reinforced by an article from Chris Eppstein. However, he provides several workarounds, the easiest of which is to just go ahead and inline HTML where you need to. Huh! Who knew? Chris Eppstein, apparently.

Aside from the minor oddities when it comes to formatted text, Haml is a particularly graceful markup language that mirrors the presentation CSS — even more so when using Haml together with Sass, also created by Hampton Catlin.

So! I’ve come this far in my Rails application using ERBs. How can I change direction now?

I find a Rake task to do this with almost zero effort. I need to refer back to the original referenced post to figure out that I’m missing the [code]ruby_parser[/code] gem, but there isn’t any more to it than that.

It converts all of the files recursively in the app/views directory of my Rails app, but continues using the ERBs by default. This means that I can verify the conversion for each file and then remove the corresponding ERB, and everything should just continue to work.

Running through, I find a few cases where indentations aren’t correct (my advanced search form) or the html2haml parser escapes things where it shouldn’t. I fix, smoke test, and check in!

Speaking of Testing

And now to why I’m not tackling the UJS topic I promised last blog: I’ve been neglecting putting test harnessing in place. This is going to come back and bite me soon if I don’t get tests set up and backfill for the limited functionality I already support.

Who’s up for a detour? Next installment: ramping up on testing in Rails!

On to my next task! An advanced search form.

Following along to the revised version of RailsCasts Episode #111, I find that most of my newbie stumbles are around what to pluralize and when (between the classes themselves and the collections of instances themselves) and so much of my debugging effort ends up focused on adding or removing an ‘s’, rather than what the rest of the code is doing. Ruby is pretty awesome that way.

If you’re just joining, this is Part 3 of N. You can catch up here:

• Part 1: Setup and Data Import/Export via CSV
• Part 2: Adding Custom Authentication

Back on Track (Sorry!)

Some of the fields on my search form are for geolocation: address, zip code, and radius in miles; at some point in the looming future, I’ll need to dig into online mapping tools to get those pieces assembled, and geolocation stuff will be its own episode. I’ll also need to get some client-side validations involved so that I have enough information (ideally!) to actually perform the search.

In addition to location fields, I also have a set of boolean values I’m tracking. In the context of a search form, checkboxes do a poor job of representing a boolean true/false properly. To be completely accurate, I’ll also need to capture an “I don’t care whether this value is true or false” field here — which, hey! — is succinctly represented as a blank first entry in a drop-down select control.

Along the way, I get the chance to tinker with some Rails Form helpers: text_field, number_field, select, and collection_select. You can find more information in the API, under ActionView::Helpers::FormHelper, ActionView::Helpers::FormOptionsHelper, and ActionView::Helpers::FormTagHelper. It was initially a tad confusing as to why the helpers were separated out that way; as the API has plenty of pontification and less materialization on how these work in practice, I look a few things up on StackOverflow to fill in the gaps. Building your form views doesn’t get much easier!

I drop a constant array into my Search model to represent the Yes and No options (and their associated values) for reuse across the form. The select Form helper handles choosing my blank option by default, so it’s literally a single statement to wire up each of the drop-downs.

All of the criteria on the form may eventually become (as I mentioned before) a tree view where the user can filter listings one criteria at a time, but it will depend — it may not be great usability once we expand to many listings and geographical regions. Whatever we build will end up being solid and fancy, nonetheless!

The Advanced Search RailsCast I’m referencing specifically creates a new DB-backed model for the Search object, which then queries the Listing collection and filters based on what the user is searching on. Austin Schneider, in the revised episode’s comments, writes about an approach that uses the session to store the most recent search parameters, versus storing each search as a record in the DB.

Normally, the RESTful, CRUDdy way to go about this in Rails is along the path of New (the form) -> Create (validating and saving the model to the DB) -> Show (attractively present the newly created record.) This is the approach the RailsCast takes with the Search model.

Switching Tracks

There’s no practical reason for us to store searches in the DB at this point (in fact, there may even be PII concerns!) Austin’s idea is to substitute a PORO instead of an ActiveModel, and then store/retrieve the search form parameters in the user’s session using YAML. The alternative would be to let user searches fill up the DB (including their street addresses…) and run a cron job fairly frequently to clear them out; that approach has a serious smell!

FAILING! FLAILING! I run into trouble and try to hack my way out of it. Using a PORO in place of an ActiveModel, Rails starts complaining about things it expects normal models to know how to do already. I look a couple of them up (ActiveModel::Naming provides at least model_name and param_key, ActiveModel::Conversion provides to_key) and add some appropriate includes. Part of the session-converting instructions entail singularizing the resource name (because we’re now doing a one-off search each time rather than tracking and saving searches) but that throws a monkey wrench in my whole business.

I spend some time trying to do additional work in routes.rb, tinker with parameters to the form_for helper on my search form, and eventually give in and email Austin. He offers reassurances that I’m on the right track. I spend some more time fiddling and don’t get very far.

It eventually occurs to me that I can simplify this whole process by using the form_tag helper (instead of form_for) and just build the search functionality into the existing Listings controller. form_tag allows you to define an arbitrary HTML form without binding to a model. I sit down to implement it, and it makes my Spidey sense tingle in that “there has to be a cleaner way to do this!” way. I’ll take one more stab at fixing up the session-based approach.

Working debugger in place, I have most of the problems figured out in an hour’s time with a couple of interesting solutions. Since I’m cramming YAML from the dehydrated search form into the session, I get the bright idea of doing some unpacking of search attributes back onto the Search object itself. This then allows me to treat the Search object more like the ActiveModel equivalent, since passing a hash to an ActiveModel’s constructor will set instance variables appropriately wherever attr_accessible matches.

The problem with this approach? I don’t really know what’s coming across the HTTP wire in the hash I’m being sent. I could check to make sure that the class already knows about what it’s assimilating, but it still wouldn’t take much evil to start overwriting things by manipulating the form post. Argh!

Also, the default code for serializing/deserializing with YAML isn’t saving my types, which is messing up the way the parameters are being evaluated against the listings. I do some halfhearted searching and end up overriding the String class by adding a to_b (boolean cast) method to parse back the checkboxes. It works ok, but it seems cheap to have to explicitly cast them. ActiveRecord::Base infers type from the DB table itself; wouldn’t that be handy instead?

In the meantime, my routing problems won’t go away. I’m trying to have a singular “/search” resource, a “searches” controller (it’s mentioned in the Rails routing guide that singular models still map to plural controllers), and a “Search” model. Should work, but rails keeps looking for “searches_path” instead of “search_path” when I hand it my Search object. What’s going on here? Is it me? RAILS, WHY DON’T YOU LOVE ME?!

The Light at the End of the Tunnel

(I’m running out of train euphemisms, and there’s a long way to go. That’s the last one, promise!)

Nope, it’s not me. It’s a known outstanding bug, seemingly only documented in a github issue and there are plenty of comments in regard to this fact. Ouch.

I’m getting ready to accept that a PORO isn’t an ActiveModel and just fudge the rest. But wait! I find ActiveAttr, which will largely protect my delicate sensibilities. There’s even another RailsCast for putting that in place!

Looking through the comments (lest I paint myself into a bit of a corner again), there’s another project — ModestModel — which may be better and cleaner. This is the one I’m going to try first, and hope. I really need to move on!

It works like a charm. I don’t get the type inference for free, so I still have to explicitly cast a few ints and bools; big deal! The rest of the code works great, and I manage to simplify back down to something that looks very much like the Rails way to do things. I opt to simplify the New -> Create -> Show page flow into New -> Create/Show instead. This takes the YAML and session code out of the picture entirely, and I’m now just handling the search request and displaying results. Far more graceful for what it needs to be.

This session has certainly been longer than I had expected or hoped. But I’m excited over the progress made (in a concise and elegant amount of code) and the things I’ve learned along the way.

Next time: I’m going to convert the ERBs to HAML and wire up the search form to use AJAX via UJS. This will support my geolocation code and allow me to update maps client side.

The team and I think the best approach would be to present a serious of presentations starting with basic introductions to the IR interface, IR querying and section types, before working our way up to advanced dashboard development, performance tuning, and system automation. Also, with the recognition that developers have specific and immediate concerns that they are dealing with right now, I’m wondering if providing web conference blocks to brainstorm ideas or train specific to issues unique to your workplace challenges would be a service our IR community would gain further value from.

What are your thoughts? Would you take Hyperion Interactive Reporting online training and/or would you be interested in one-on-one IR online consulting sessions? You can leave comments on this post or send me an email (emily(at)waggerdesigns.com) to let me know!

Alas; work happens! I also took time out to skim some of the UC Berkeley SaaS class. The quality of the course is good, but I found myself ahead of many of the software engineering concepts and ended up toying with several of the exercises instead of following every moment.

Back Down to Brass Tacks

Last time, I left off on authentication and authorization. There are a ton of canned options available, but upon further reading, they all appear to be overkill for where we want our product to start.

In context, what we’re building is a directory of sorts, with listings based on public data which people will be able to claim either through email verification or manual process. Once a listing has been claimed and when the associated user is logged in, there will be a handful of functions available for correcting/updating information or subscribing to paid services. Outside of additional support for a couple of administrative users, the scope of the user authorization model (i.e. who can do what, and when) is actually very limited.

So! We can investigate migrating to a more robust solution if we eventually find the need, but for now, the practice of setting it up from scratch in Rails will do me good. I check out a new branch in git and go to town.

At Last! A Town!

Falling back on letting someone do the heavy lifting for me again, I’m definitely getting my money’s worth from my RailsCasts subscription. I check out their Authentication from Scratch screencast (well, the revised edition) and implement as directed. It’s definitely just enough for me to then wrap a couple of helper methods to restrict the destructive operations to admins only.

The neat part about letting Rails 3 handle the details is that simply by declaring has_secure_password on an ActiveRecord class, the password digest and salting magic is taken care of via BCrypt. It’s not that these things are actually that difficult to implement, but it certainly saves some time to be able to roll in the security and have it just work.

I only hit one snag while following along with the screencast: the Rails 3 scaffolding doesn’t seem to include a block for flash notifications in application.html.erb. I add one above the <%= yield =%>:

<% flash.each do |name, msg| %>
  <%= content_tag :div, msg, id: "flash_#{name}" %>
<% end %>

I finish implementing the basic authentication and add some nifty email address validation while I’m at it. I run into the invalid multibyte escape error referenced in the comments… and I have a little trouble interpreting the fix. No worries! After reading up on the available encodings and what’s up with that, it was easy enough to add:

# encoding: BINARY

…to the top of the EmailValidator class to let the pesky regexp definition slide. The only other hitch is that Rails 3 doesn’t, by default, automatically load the root/lib directory contents anymore (this is apparently a change from the past!) Also an easy fix. Add to application.rb:

    config.autoload_paths += %W(#{Rails.root}/lib)

Next Up

Authentication and authorization are glued together sufficiently for the moment; next time, I’ll be walking through the setup of the advanced search form as a separate model and attempt a nice, shmexy AJAX interface using Unobtrusive JavaScript!

We at Wagger Designs have been brewing up a custom web application for some time now.  This blog series, in several parts, will follow my research and development process of taking our app from idea to reality. I’ll be sharing techniques and workarounds to issues that arise along the way.

Finding the Tracks

A couple of years ago, I did some preliminary tinkering with Ruby on Rails and took Code School‘s excellent free online course, Rails for Zombies.  I was extremely interested in the technology at the time (having been a Lisp geek in college, I’m a little all over the place) but due to my full-time and after-hours commitments at that point, not much traction was made.

More recently (on a related tangent), I started working more with git for SCM during some internal iOS development, and become quite comfortable with it for revision control.

In the first week of May, I decided that Rails would be a good candidate for our new web application, and found myself interested in returning to Code School to take Rails for Zombies 2.  Some of the reasons I pegged Rails as a contender:

• It’s a mature, well-structured MVC framework
• Rails features robust ORM with quite a bit of convenience functionality built in
• REST- and SEO-friendly routing with little effort
• Huge, active, knowledgeable community
• Do you really need a reason to [re-]read why’s (poignant) guide to ruby?

There was a slight problem, in that I didn’t really remember anything from the original Rails for Zombies course.  After a refresher, I went back over our collective app brainstorming notes and hobbled together a first swipe at the data model.

Raring to go, I subscribed to Code School.  Rails for Zombies 2 was such a great class that I also powered through Rails Best Practices and finished CSS Cross-Country for dessert.

If you’re looking to follow along but don’t have any experience with Rails, I highly recommend Code School’s classes; however, there are also plenty of other free resources available, including rubyonrails.org’s own Getting Started with Rails guide.  There are, in fact, a large number of useful guides there, which you can even download from the main Rails Guides page in .mobi format for Kindle reader apps.

Get This Train Rolling!

After a couple more meetings to sort out a few details and prioritize, we were ready to start writing real code.  First things first, we needed a way to import and export batches of spreadsheet data.  Our initial data sources will largely be coming from public records and require a decent amount of manual massage to be useful; therefore, it doesn’t make sense to over-architect a solution when CSV via Excel will work just fine in the initial stages.

I go ahead and checkout a new branch for this purpose, and start looking up CSV import/export functionality I can borrow.  One of the very first projects I find is database.rake from Synbioz.  This project provides the ability import directly into a model table, or allows export of one/all tables in a single shot.  I get nervous when I see that it’s over 2 years old, but it’s so close to what I need that I throw caution to the wind and push forward; after all, if it doesn’t pan out, I can just discard my git branch and try again.  I clone it per the README into /lib/tasks/database and try to run rake:

cannot load such file -- fastercsv

Oh, right!  I forgot to add it to the Gemfile.  I do so, and run “bundle install” from the root project folder.  Trying again, I discover that my initial fears of the project being stale may have been founded after all:

Please switch to Ruby 1.9's standard CSV library.  It's FasterCSV plus support for
Ruby 1.9's m17n encoding engine.

That actually sounds… hopeful!  I do a simple find/replace in the rake task code, changing “fastercsv” to “csv” and “FasterCSV” to “CSV” — and it works like a charm!  We’re in business. I export my main model to CSV and upload it to Google Docs. I remove a few fields (autogenerated id and the created_at/updated_at timestamps) and add the column types into the second row for reference purposes; now we have a spreadsheet import template we can just clone off to add data as needed. Allons-y!

I check in the changes (commit -am ‘message here’) and receive a funny message:

# On branch csvIOTask
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#   (commit or discard the untracked or modified content in submodules)
#
#       modified:   lib/tasks/database (modified content)
#

Git is seeing the cloned “database” repository as a submodule of sorts.  (More specifically, it’s reading the .git in that directory.)  Since I didn’t add it properly as a real submodule, I can’t just hide the changes and go about my merry way.  I eventually just remove the .git directory from /lib/tasks/database, and that fixes the problem as well.

Data import/export is up and running!  Next time, I’ll be working through our authentication model.

While anyone can make a website, our team specializes in truly cultivating the growth your business’ website.  What does cultivating a website even mean?  Excellent question!  Our process of website cultivation is an end-to-end process to continually evaluate the needs of your customers, your business, and — very importantly — your budget to maximize the Return On Investment (ROI) a website can bring to the success of your business.  The constant assessment of our website cultivation process is especially important in the Northern Virginia DC Metro area where so many start-ups and small businesses are competing for the attention of the same customers.

1. Interviews & Information Sessions

I’ve always thought this first phase to be the most important of all, as it sets the tone for everything else moving forward.  This phase is a lot like a first date because we want to know about you, your business, your customers, and anything else you feel like sharing, along with answering as much as you want to know about us.  Among the questions you should expect us to ask:

• Where did the name of your business come from?
• Why did you start a business, and what sets you apart from your competitors?
• What types of customers do you currently attract and do you want to attract other types?
• How do you currently advertise, and how successful to do you think that is?
• What are your expectations from a website?

These questions help us gain a better understanding of your goals and help you to get to know us better.  This type of interview will be ongoing throughout each phase to ensure the process, progress, and project milestones are understood and agreed upon by all involved.   Our stance of open communication, supported by our customer portal, helps avoid unnecessary changes down the road caused by uncomfortable requirement and functional misunderstandings.

2. Website Design and Web Architecture

Once we’ve got an idea of the design and functional requirements of your site, our graphic artists come aboard to start creating website design mocks while our web architecture team gets the ball rolling with technical specifications and wireframes.

For the majority of websites, this will be the most time-consuming phase of development because this is where the website is actually designed.  While large scale revisions can and should occur in this phase, we’re experienced with empowering you to make the decisions required to move smoothy and efficiently through the process.

3. Functional Specifications

With the big concerns tackled in the website design and web architecture phase, this phase is the nitty gritty details such as navigation effects, CSS enhancements, JavaScript and jQuery behaviors, and advanced enhancements such as Flash.  While we are hashing out these details, our development team is busy staging your testing environment, identifying hosting requirements, and readying the troops for the next phase: Website Development.

4. Website Development

With the other phases behind us, the website development is surprisingly fast.  Historically, this marks is a little more than the 3/4 point of a project budget and is a lot like approaching 3rd base on the diamond.   With the design mocks, wireframes, and functional specs in-hand our team of industry-leading developers translate the site requirements into an actual website.

Starting with a Content Management System (CMS), such as WordPress, our application developers and graphics designers work in parallel to execute on the website design and functional requirements to build the site to our agreed-upon specifications.

As this phase progresses, our usability team steps up to make sure the site meets usability standards and is easy for your customers to use.  Depending on the scope of the website, this may include marketing surveys and beta testing to make sure your customers can find your services and ultimately do business with your company.

5. SEO/SEM and other Marketing

Towards the halfway point of the website development phase, our Search Engine Optimization (SEO) and Search Engine Marketing (SEM) team kicks into high gear to identify content and editorial requirements and begin optimizing the site for search engine visitors.

While SEM and other marketing – such as email marketing or print media – are optional site enhancements, we do not believe that SEO is an option for business in the Northern Virginia, DC Metro area.  As this area is especially ripe for entrepreneurs and is therefore rife with competition, we include a base SEO package with all of our websites and launch you with the best chances of being found.   Learn more about our SEO and SEM services from our Digital Marketing Service page.

6. Cultivation

This is what happens after your site goes live and is a lot like growing grass.  Up until this point, we readied the earth for your site by laying the foundation, placing the seeds, and preparing it to thrive.  The next step is to maintain the website by performing traffic analysis, providing regular updates, and performing routine maintenance.  While we will train you to keep your site up and running, we’re here to fill in any gaps or clear to-do’s off your list along the way.

Happy growing!

Remember Your Audience

Don’t forget that as a pediatric dentist, your website design should appeal primarily to parents with children — not the children.  Don’t fall into the trap of ignoring the needs of your patients’ parents while trying to make something childish and fun.  This means that a pediatric website must be easy to read and navigate, but should still be as fun and creative as your practice.  A website that balances the same fun-but-professional atmosphere your practice does will go a long way to setting you apart from the fierce competition amongst pediatric medical and dental professionals in Northern Virginia.

Show REAL Pictures

While seemingly cost-effective, the use of stock imagery is something that tends to turn off parents. Those parents researching professionals through their pediatric websites will pick up on reoccurring generic children very, very quickly and wonder what’s wrong with your people or practice that makes you not want to show real pictures.

Quality webdesign firms, such as Wagger Designs located in Northern Virginia, have photographers on staff who will take pictures of your actual staff and practice to alleviate the need for stock photography.

Show Images of Your Practice

Showing actual pictures of the examination area, operatories, waiting areas, and exterior location is very important for a pediatric website.  Parents who visit your site want to see that the areas are clean and in good repair.  Beyond knowing you keep up with your physical location, a sneak peak of your kid-friendly facilities also allows parents to get a feel for how you will interact with the children in your care.  Practices with kid-friendly features will leave a great impression with parents and a pediatric website is a excellent place to show these features to the parents of perspective patients.

Typically forgotten, an exterior shot, great on a directions or contact pages, make it easier for parents to find your pediatric practice by giving them a visual idea of your practice’s exterior.

Show Pictures of Your Team

Never substitute stock-imagery for your actual team members or actual patients.  One way to get great action shots of your staff interacting with children is to host an open house night for children you know well.  Throw a little party and provide exams for them while you and your staff operate like you would in a typical day.  The pictures from this event will yield incredible shots of your friendly staff and happy children throughout your practice.  When parents researching pediatric professionals arrive at your website, they will notice the uniqueness of these pictures and will appreciate having the opportunity to see you in action.

Easy on the “Fun” and “Cute”

Some “fun” deigns elements are usability nightmares for parents.  One prime example is the use of a mouse cursor trails.  These seem SO CUTE! — but they are not only incredibly annoying when browsing a site, but are also horrible for parents browsing pediatric websites with disabilities.

Another element that gets professionals in trouble is a pediatric website that plays sounds. Having a pediatric website automatically play safari noises is the quickest way to encourage a parent to leave your site — especially if they are at work.

The last “fun” and “cute” example to stay away from is overly creative navigation.   Having stared at a few pediatric websites trying to find the navigation, I can attest that parents who cannot find the information they are looking for will quickly move on.

Wagger’s Pediatric Website Packages

Contact us to learn more about how our team can partner with you to build a pediatric website that compliments the uniqueness of your practice and encourages parents to convert from a website visitor to a patient.  We know technology and also understand how to integrate with leading third-party vendors, such as Dentrix, to get new patients into your practice systems quickly.

Find out how our strategy of levering a modern website design, SEO techniques, and fully customized graphics and photography will contribute to your practice’s success today!

During SXSW, Matt Cutts (a high profile search engine quality member of Google), was interviewed about a new algorithm change directed towards addressing people who are optimizing a site to “trick” the search engines into ranking the site well.

Now before we all get our panties in a twist, chances are, if you’re considered to be a “white-hat” SEO, you probably don’t have to worry about any “over optimization penalty.”  However, if you find you’re asking yourself, “Am I really doing something sketchy even though it’s getting me to Page 1?” The most likely answer is yes; yes, you are, and you bet your ass Google is going to figure it out.  But what exactly is “over optimization” anyway and how does one avoid such a penalty?

Here at Wagger Designs, we’ve compiled a checklist of issues and examples that may trigger Google’s over optimization penalty.

1. Excessive Internal Linking in Content

For years, SEOs have been talking about keyword to content ratio, but what they fail to mention is the importance of the internal anchor text link to content ratio.  While content on a page is one of the most essential elements of SEO, it’s also just as important — if not more so — not to make the mistake of having a high percentage of links vs actual HTML content.  This general HTML content is considered to be anything located within <p> (paragraph) tags.

In the “Women’s Cardigans” example below, the link to content ratio is approximately 51%.  This means that 51% of all words in this paragraph are internal links.  This is something search engines could easily red flag and penalize the site for over optimization.

2. Highly Targeted Links in Footer

Historically speaking, web designers have used footers to display only the very most important pages on the site such as an HTML sitemap or an “about us” page since top-level navigation will include most if not all sub-navigation pages.

In order to increase the relevance of internal page topics, websites will place an excessive number of keyword stuffed anchor links at the bottom of a web page.  These “over optimized” websites try to position deeper pages as the “footer.”

A prime example of keyword stuffed footers can be found on the screenshot of a wedding site below.  Not only does it contain optimized links within the footer, the site lists out a highly detailed list of links at the bottom of every page.

3. Link Stuffed Navigation

Over optimizing primary navigation to be filled with targeted keywords may also flag search engines that the site was intended to optimize against search engine algorithms and not be tailored to the end user.  We uncovered two primary examples of navigation “over optimization”:  Sub-Categories and Breadcrumb structure.

Breadcrumbs were initially created with the intent to help a user find their way back to the home page or go back to a higher level category.  Later on, search engines began to use this breadcrumb navigation as a cue and began to utilize the keyword category structure within search engine listings.  Some websites have begun to take advantage of this breadcrumb navigation and create more than one path home.  While this type of navigation may ultimately help search engines associate products with multiple categories, users may become confused.

For example, the screenshot of the clothing site below uses three separate link paths for users and search engines to retreat backwards.

A more common “over optimization” technique for navigation is targeting and creating a page for every product under the sun and then labeling it using optimized keywords with a clear intent to boost search engine rankings and no regards to the user.  The funny thing about this technique is search engines understand category relations.  In other words, search engines understand that if the primary navigation is “Women’s Wakeboard Shop,” all links placed underneath are related to “Women’s” and do not need to contain “Women’s.”  This technique also makes it harder for a user to browse the site, which is something a search engine, like Google, may counter with this new “over optimization” penalty.

4. Keyword Stuffing

One may say, “Wow… keyword stuffing?  People really do that?  Isn’t that sooooo 1999?  …Even more importantly, it works?”  Yes, people still do it on the sly, and it seems to still help websites (coupled with other optimization tricks) rank in the Top 30 to this day.

For example the footer on this Northern Virginia/DC Metro Web Design site lists out top targeted keywords.  While it’s not entirely hidden and done in a classy way, these are the kinds of things the “over optimization” algorithm may intend to target:

5. Keyword Filled Title and Meta Tags

Another issue related to “keyword stuffing” as noted above, is injecting a long line of keywords into title and meta description tags.  Title tags should always be limited to include just one primary keyword and 2-3 supporting keywords when relevant.  Titles should look natural to entice the searcher and meta descriptions should be written to promote a call to action while occasionally including keywords.  Since search engines want all aspects of a site intended for a user and not the search engine, the new Google algorithm may begin to identify when too many words are stuffed into a title or meta description and deplete the value of such a site.

The example below attempts to target every “Green Tea” related keyword into the Title and Description.

6. External Linking

Historically speaking, Google has come down hard on individually high-profiled cases noted in sources such as the NY Times about abusing external link algorithm.  Such examples include JC Penny’s paid link buying or discounts offered by Overstock.com in exchange for a link.  Smaller businesses have managed to shield themselves in the fact they don’t have the amount of budget or customer leverage to drastically increase links to the scope of JCPenny or aren’t big enough to gain the spotlight for shady schemes.  However, Google’s new “over optimization” algorithm may be coming to get these smaller players in the upcoming months.

The thing that has always baffled me is how the all-mighty stock-splitting Google has enough money to investigate these notorious link-buying companies and their web networks, but has clearly never taken action to detect them and wreak havoc.

For example, many websites and their targeted backlink anchor text are featured under a WordPress blogroll and other similar side bar of links:

What Would Wagger Do?

While Wagger Designs believes SEO is a core component of web design, we believe it’s most important every website we build is intended for the end user.  While it’s important to get users to your site, it’s even more important not to forget that your users are your customers.  After all, search engines aren’t going to pay your rent.