For the Content Hungry: The Eat Media Blog

The “Related” content section is one of the many page design elements carried over from the print world to the web. It’s implemented in different shapes and forms, but the goal is the same: Increase reader engagement and keep them clicking.

Every serious content management system has some sort of module to generate relevant content, from simple tag cross-referencing to complex algorithms that weigh a mix of taxonomy, title, content, and user data. Services from third-party companies like Outbrain not only index your content but also offer a distribution channel for publishers. Think AdSense for content. Taboola even offers a similar service for video, or what it terms “personalized video recommendations.”

With all the technology being thrown at it, the related content section still feels like an afterthought. For example, here’s a round-up from publishing heavyweights (clockwise from top left) The Daily Beast, The Wall Street Journal, Harvard Business Review, and Bloomberg. Aside from Harvard Business Review’s sliding box in the footer (recently popularized by the New York Times), all are a blur of links, some with questionable relevance. How effective are these, really?

But wait, what have we here? Techcrunch has a deceptively simple but quite useful variation. It looks interesting at first glance:

First, we’re informed that articles listed are associated by the main subject, Amazon. Then, the links follow — clearly dated, listed by publish date, with the current article highlighted in its chronological position. Instant context. Suddenly, the lowly related content box is useful again.

We’ve all been there. You’re sending an application at the eleventh hour, making a last minute payment, or just trying to reach customer service, that bane of our existence. So you browse to some information page to find the cutoff or closing time.

Boom! You’re met with a jumble of opening and closing hours, weekend and holiday exceptions, followed by an alphabet soup of time zones: EST, PT, UTC, GMT, etc. If the company is foreign, has that country’s daylight savings time kicked in yet? Is that minus or plus one hour?

CloudAccess.net seems to have a downright ingenuous solution: Show the current time in whatever timezone the company is based. Simple, no? Note how showing the current time provides context for the support hours on the left (image below; original page here).

Bonus idea: Add the local time for the user — trivial enough with a few lines of client-side code. Why exactly isn’t this standard practice already?

In a world where every self-respecting software product or service has an API, it’s surprising how convoluted it is to get simple result counts from the leading search engines.

While working on a recent coding project, I needed total results counts for a particular word or phrase. So I turned to the 800-pound gorilla, expecting that with its dozens of API projects, Google would be a walk in the park. Apparently not.

Jumping through hoops

First, you have to request an API key, then create a Custom Search engine. Considering the small data I wanted, pure overkill. And it doesn’t get any better. Next, you have to specify at least one site to search — although I don’t want to restrict the search, I want the entire web. Google says you can’t do that.

But wait, there’s actually an option to “Search the entire web but emphasize included sites.” Huh?

What you see is not what you get.

Well, let’s select that option and compare results with regular search:

• Google search for ‘tintin’: 30,700,000 results
• Google CSE search for ‘tintin’: 2,080,000 results

What?! That’s less than 7 percent — not even remotely close. Going by comments from users in the API forums, Google supposedly uses different indexes for its custom search engines. Not cool. Yahoo, here we come.

Brother, can you spare a key?

At first, Yahoo seems promising, providing good ol’ RSS feeds for any keyword searches without needing an API key, which Google does not have. Unfortunately, no result count is available in the data returned.

Turning to Yahoo! Search BOSS, the equivalent of Google’s Custom Search, we run into a paywall immediately. Fine for a larger project, unnecessary to programmatically get the occasional result count. At least Google gives you 100 queries per day free.

Oh well, on to Bing which, by the way, now powers Yahoo Search.

Salvation comes from Redmond

Microsoft surprises sometimes, in a good way. Then again, Bing itself got generally good reviews when it was released and its Cure for Search Overload Syndrome ad campaign did hit the spot. Like Yahoo, Bing provides no-API access to RSS versions of search results. (Good.) Like Yahoo, the feed is missing result counts. (Bad.) But unlike Yahoo, full API access is free (Very Good!) and unlike Google, the result count matches regular Bing Search. (Very Very Good!)

• Bing search for ‘tintin’: 3,820,000 results
• Bing API search for ‘tintin’: 3,820,000 results

Phew! Who knew getting a search count could be so complicated?

A better approach

To put this whole experience in perspective, let’s consider how two other services provide API functionality: Topsy (a Twitter search engine) and Tumblr (well, you know, Tumblr):

1. Basic access is free and has reasonable limits: Topsy allows 3,000 free API calls per day, no questions asked, no API key needed.
2. Graded access level: Tumblr has three options — No authentication for open information, and for higher level calls, an API key or OAuth authentication depending on the request.

Done. Seems the smaller companies are thinking this through better.