This Hosted Life

I recently gave the following talk to the Chinese Institute of Engineers on the Microsoft campus.  The talk is an introduction to Search Engine Marketing (SEM), focusing on Search Advertising and Search Engine Optimization. I also explain the search business model and ranking algorithm to the extent that is needed to effectively implement SEM.

Much of the detail comes from my experience at Faves.com, where we were able to achieve over one million visits originating via organic search each month.

As a side note, the audience was great — asking lots of questions and validating the broad applicability of SEM to a variety of businesses.  Enjoy!

I recently started using Blueprint, a CSS framework “which aims to cut down on your CSS development time”, for a Web development project. I have found I can whip up a nicely laid out site that works across all browsers *much* faster with Blueprint than I could without it. As a result, I spend more time on creating business value and less time dealing with the many obscure bugs in Internet Explorer 6.

Having said that, I’ve had the opposite experience with other frameworks. This got me thinking, “What makes a good framework?”

Note: In the below examples, I compare Blueprint with Microsoft’s ASP.Net. Admittedly, this is sort of an apples-to-oranges comparison: ASP.Net is for server-side Web development whereas Blueprint is for client-side Web development. Nonetheless, they are two frameworks I am actively using and hence enable me to give personal examples.

Note 2: Even though I seem to suggest otherwise below, much of ASP.Net is great. In fact, we use it to power Faves.com. We just stay away from the parts of the framework that violate the following criteria.

With that out of the way, I think a good framework is one that ultimately saves time and/or cuts costs in meeting business objectives because it

• Avoids reinventing the wheel: This is arguably *the* point of choosing a framework instead of coding something directly. For example, the Blueprint framework gives me the following that I would otherwise have to create myself:
  
  • An easily customizable grid
  • Sensible typography
  • Relative font-sizes everywhere
  • A typographic baseline
  • Perfected CSS reset
  • A stylesheet for printing
    
    
• Still lets me do things the “raw” way: All frameworks have their limitations, and I often have to revert to doing something outside the framework. When using Blueprint on a page, I can still mix in my own non-Blueprint CSS styling and layout. On the other hand, if I want to use some of my favorite ASP.Net controls on a page, I am forced to adopt the ASP.Net Web Forms model and its associated evils for the entire page.
  
  
• Takes less time to learn than how much it will ultimately save: Blueprint *is* a subset of XHTML and CSS. ASP.Net, in an effort to make things easy for the novice user, actually makes me understand a completely different model. Ironically, this can make things more difficult for the seasoned developer.
  
  
• Creates consistency across the team: Implicit in using Blueprint is a set of naming conventions. This makes it much easier for a team of developers (or if using a Blueprint with a CMS, the content creators) to specify and read each others’ layouts.
  
  
• Follows best practices: The framework should deliver as is “generally expected”. For example, there are a number of SEO best practices for having your site properly indexed by search engines. But, ASP.Net violates a number of these, including this one. I need to find creative ways to work around each violation, costing me time and money. Ideally, best practices compliance is just included.
  
  
• Lets me view the source code: There are times I need to know what exactly the framework is doing in order to diagnose or prevent bugs.
  
  
• Is high performance: Slow performance is an issue if it *meaningfully* degrades the customer experience or *meaningfully* increases server and support costs as compared to how much time and money I am saving by using the framework.

In the past month or so, I’ve spent some time with two content management systems: Drupal and Wordpress. Both products make it easy to build and edit relatively sophisticated Web sites from within the browser.

However, only Wordpress gave me that “Aha! moment” you get when a product so seamlessly fits your functional needs and is fun-to-use at the same time. In fairness to Drupal, this is not particuarly surprising since:

• Wordpress is designed for a more specific scenario. In Wordpress, you have Blog Posts and Pages. In Drupal, you have a very abstract concept of a Node. While an instance of a Node can be a Blog Post or a Page, it can also be many other things.
• Wordpress comes pre-packaged with the plugins that meet this scenario. While both products have a robust plugin architecture, Wordpress is good to go out-of-the-box whereas Drupal requires you to install modules (once you figure out what they are) to have a system comparable to Wordpress.

Anyways, the takeaway should *not* be that Drupal sucks. On the contrary, it powers some of the largest sites on the Web, including FastCompany.com. The takeaway here is that there is an opportunity to turn Drupal’s “weakness” into a strength, by leveraging the generic architecture and wide availability of plugins to create Drupal distributions for specific customer scenarios and segments.

One such customer segment is non-profit and volunteer organizations. As an example, I am a fan of Seattle Works‘ Web site. The event planning features of the site are arguably what make the organization so active. For another time, I’d like to see a) if there already is a hosted Drupal distribution that serves this segment as *well* as the Seattle Works site does for its members and b) if not, what it would take to create one.

I have included widgets from two “microblogging” services, Faves.com and Twitter, in the sidebar of this blog. Not surprisingly, I use these microblogging services to broadcast “stream of consciousness” thoughts whereas I plan to use this blog for hopefully more thought provoking and “on-topic” posts.

But, why *two* microblogging services?

• I use Twitter to broadcast what I am doing and to watch what others are doing.  It simply helps me be “in the know”.  The no-frills format of a Tweet on Twitter, specifically the 140-character limit and SMS compatibility, is ideal.
• I use Faves.com to share items such as news articles, videos, and recipes that will be beneficial (educational or entertaining) to others and myself.  The automatically generated tags and thumbnail in a Fave, combined with the rich permission system, make Faves.com ideal for this scenario.

I recently setup Openads for Faves.com. Openads is a powerful ad server that lets your manage how ads are delivered on your site. It is similar to Google’s Doubleclick except that a) Openads is free and b) you can host it yourself.

You begin by telling Openads about your inventory. This is done by defining zones and then assigning the appropriate advertising campaigns to these zones. You then customize delivery (i.e. with what frequency or under what conditions a specific campaign for a zone is shown) by defining delivery rules.

While the documentation is reasonably good, I had trouble getting my head around the terminology without a real-life example. So, I am including our configuration, slightly simplified and modified, over my next few posts. Enjoy!

For this post, here is how Openads terminology maps to our scenario:

• Advertiser: Google
  • Campaign: AdSense
    • Banner: 468×60
    • Banner: 728×90
• Advertiser: Amazon
  • Campaign: Omakase
    • Banner: 468×60
    • Banner: 728×90
• Advertiser: AcmeMediaGroup
  • Campaign: FunnyWigs.Com (Direct Ad Sale)
    • Banner: 468×60
    • Banner: 728×90
• Publisher: Faves.com
  • Zone: 468×60 - Top
  • Zone: 728×90 - Top
  • Channel: shopping - Allows the publisher to request ads specifically targeted to shopping inventory.
  • Channel: nonshopping

In my next post, I will talk about delivery rules. These tell Openads when to show each of your banners.