Driven By Curiosity

I am involved with several sites that work very well with AdSense. At this point, these are sites that are strictly HTML, with no dynamic content whatsoever (purely content). The question I have been asking myself is whether I can use GWT to possibly improve my AdSense performance.

I have seen a few questions about how one might add AdSense to AJAX or GWT websites. Is this question asked backwards? Should it really be how to add GWT to AdSense sites?

I think part of the answer lies in the language used on the AdSense site, namely ‘AdSense for content’. What really draws the reader attention, providing the context for ads in which they will have an interest? Keywords? Sort of. More generally it is content. As a website publisher, I feel that providing solid content for viewers is what draws readers and builds popularity. From a web tools perspective, this leaves two questions:

1. How can I maximize indexibility?
2. Can I augment my static content with dynamic information to improve visitor exposure to ads?

“AJAX, promise or hype?” by Peter-Paul Koch on quirksmode.org is great. His links provide a lot of good reading. I agree with his conclusions. ‘Old ideas’ is right on the mark, and made even better because the post was from March of 2005. Independent of the current acronym, be it GWT, AJAX or whatever else gets popular, the important considerations come down to accessibility and usability.

Since I am interested in contextual advertising, I really have two users: human and spider. Ideally, a single site should provide access to everyone. It is probably good for discipline that search engines are basically lynx++. It provides a strong incentive to develop sites that will work for less-capable browsers such as cell phones or text readers.

I believe that gmail provides the best example I’ve seen yet for combining high usability optimizations with wide accessibility. If you want to see awesome accessibility in action, fire up gmail, disable javascript in your browser and reload. You can then experience the site with either basic HTML or in a format suited for mobile devices. Talk about an awesome solution addressing both accessibility and usability.

It may sound crazy, but the advances in client-side dynamism are largely irrelevant from a content perspective. Certain cases, such as games, chat programs and forms appear to be exceptions to this rule, but I would argue that this is because the content is irrelevant to advertising. If your users have any expection of privacy of their data on your page, ads are inappropriate without taking further measures to guarantee this privacy.

So what does this leave us? Usability. This is where gmail shines, in many subtle and incredibly clever ways. Basic HTML provides a great user interface that works well. The scripted version provides extra features and works even more intuitively. Scripting provides a level of polish that isn’t otherwise available.

The chat function is a perfect example of the sort of enhanced experience GWT can provide to users. It is irrelevant for advertising (unless you view archived chats) but gives users another reason to use the service. I know I’ve used several invites to get friends on gmail since I hugely prefer the zero footprint chat to other IM services.

I plan to explore several possibilities for adding GWT features to my existing sites. Some ideas are:

• Convenient picture gallery interface for vBulletin when users are writing posts. Provide scrollable thumbs to automatically insert links into posts. Plug-ins exist, but the concept is the same. If the script can’t run, fall back to dialog box asking for a URL.
• A dynamic navigation section for a static site based on search terms in the HTTP request. Use some method to recommend related pages.
• A better user feedback method than email, while still leaving email in place if the script fails.

A navigational aid is the most applicable of these ideas to AdSense. By providing a list of pages related to the user’s search terms, I can maximize the users exposure to my site. Since they have chosen to look at it, I now have the opportunity to tell them everything I can about what I have on their topics. I know that they are looking for something since they are visiting the site. The trick is to figure out exactly what based on limited information (i.e. search terms and URL). The more on-site options I can provide them, the more likely it is that they will be served an ad that is relevant to their needs.

I could implement the same feature on the server, but I’m not concerned with the search engines indexing these links. The site has a clear navigation path for spiders, and spiders don’t come in with search terms. For them it is already usable. The only purpose of these links is to encourage readers to stay on the site longer and to see as many ads as possible. If a user has no search terms, a default set of links (based on page keywords) could be shown. This is all intended to increase the value of my site to the user by ensuring they are fully aware of site contents.

Accessibility needs are met by providing solid information (and ads as possible) regardless of the browser used. If scripts fail to execute, the site returns to its static presentation. Usability is enhanced with clearer navigation to topics that may be remote on the site tree.

How might a “pure” GWT application be built to maximize accessibility and usability for both humans and search engines? To do this effectively, it is necessary to remove the majority of DOM modifications from application and make them directly in HTML. This could be viewed as “pre-instantiation”. The majority of DOM modifications for content sites are known at design time, meaning they could be made in HTML directly. Extra features and changes can always be made by the application once it starts.

Links to any content containing pages should have URLs with the ‘#’ in history tokens replaced by ‘?’ so that search engines know there are multiple pages and your server can handle the requests properly. When the GWT module loads, it can then wrap these links (or replace them altogether) with GWT functionality.
Making these changes will move GWT code from UI creation to invisible functionality enhancements.  This will achieve a higher degree of separation between structure and function, which is highly desirable.  It could create a maintenance problem for the developer, since the HTML pages need to be kept consistent with the Java source or additional content will be hidden, but there is not an automated way to accomplish this yet.  It could be extremely useful to develop a solution for compiling widgets into HTML and placing it in the final HTML file in the www directory.  Widget sprites?  Adding this level of accessibility would be a HUGE benefit to almost everyone using GWT, whether a user or a developer.

By moving DOM structure out of GWT applications and back into HTML, it becomes possible to create an application that maximizes exposure to interested traffic.  Search engines can index content and send you readers.  More readers mean more ad clicks, and therefore greater success with AdSense and GWT.

This entry was posted on Wednesday, August 30th, 2006 at 11:19 am and is filed under Google Web Toolkit. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.