Archive for April, 2008
A Fully Mobile-Enabled Magazine
What do you think of this? Every (print) ad in the upcoming (July/August) issue of Men’s Health will be mobile-enabled.
http://adage.com/mediaworks/article?article_id=126529
SEO Part 4, Progressive Enhancement (for Rich Content Search)
The concept of Progressive Enhancement with regards to SEO implementation is easy to understand. Basically, you start by creating a base experience – which any user, using any browser, with any connection, can access the content of. Then, while still accessing the identical content (this is key), you change the presentation (aka “chrome”) to provide greater functionality and design features for users who have more robust systems (i.e. more browser functionality, faster connections, etc.) In other words, “progressively enhance” the experience depending on the user’s capabilities; this way we don’t leave anyone out AND we don’t sacrifice creativity, functionality or experience.
Why is this important for SEO? Because search engines only see the base experience – they can’t understand fancy Javascript or CSS and they cannot see into complex binary files (Flash, video, images) . Therefore, we can use this method to create an experience for everyone to see, including any browser, search engine or mobile device as well as devices used for disability (line readers).
So how does it work?
1). Follow Web Dev Best Practices. First, start by architecting your site with standard web dev design principals in mind: specifically, separating the content (copy, images, movies, etc.) from the presentation (HTML, CSS, Flash). For SEO, it is extremely important that the presentation is the only thing that “changes” based on the user’s system. For example, if you serve different content to the user than what you show the search engine, you run the risk of getting banned by the search engine for cloaking.
2). Base Presentation. Use semantic HTML. Remember in part 3 of my SEO discussion I mention using semantic HTML? This is how our base experience is created and, (without any styling, it may not look “pretty”) it is what the search engine and screen readers will “see.”
3). Improved Presentation. Add CSS to give the base experience some life (using the same data source as the base experience). Ideally, your CSS can be device specific. For example, using the “media” property, you can define styles for screen or print. Now things start too look nice. For example:
<link rel="stylesheet" type="text/css" media="screen" href="styles.css"/>
4). Rich Presentation. Add rich content/functionality. Flash, Silverlight, AJAX, DHTM – using the same data source as the base experience.
5). Show the user the appropriate presentation. Using SWFObject() (for example), we can detect if the user has Flash installed and show him/her the corresponding version of the presentation:
- Search Engine, Screen Reader, User with no Javascript == gets Base Presentation
- User with no Flash, Mobile device == gets Improved Presentation
- User with Flash == gets Rich Rich Presentation
The code could look like this:
<head>
<!--snip-->
<script type="text/javascript" src="/script/SWFObject.js"></script>
</head>
<body>
<!--non-Flash visitors-->
<div id="non-flash" align="center">
<p>Non Flash Content goes here...make sure it is the exact same
content that is read in by the Flash application</p>
</div>
<!-- Flash visitors-->
<script type="text/javascript">
var hasFlash = new SWFObject("myFlash.swf",
"flash", "680", "390", "5", "#3a403c");
hasFlash.write("flash");
</script>
As you can see, a simple <div> is created to wrap the non-Flash content. Then, using SWFObject, we detect the user’s Flash player, create a new SWFObject, and embed our Flash swf. The search engine will ignore the javascript/SWFObject/Flash stuff, and only recognize and index the non-Flash content. Be sure that the non-Flash content is identical to the content that Flash uses.
The ideal approach would be to create a page-centric structure for your Flash and non-Flash content and build the Flash application to support deep links (links that go to a specific page/section within your Flash app). For example, as the search engine (or non-Flash user) navigates from page to page within the HTML site, the Flash site mirrors with the same page/content. As the HTML content is what is “understood” from the Search engine POV, it (the search engine) will create it’s links to the HTML “page” based on the user’s search query. Therefore, you want to point the user to the same page within the Flash site. Example: your site talks about “German Shepards” only in the “dog” section of the site. When a user searches for “German Shepards”, you want to create a URL that takes the searcher straight to that section of the site. This can be done via query string or even folder structures/page names that create deep links into your Flash site. Example:
1). Google search for “German Shepards”
2). Returns URL: www.mysite.com?page=dogs
3). www.mysite.com/dogs is a HTML page that contains all the copy (in HTML) related to the dog section, as well as a deep-link instruction for the Flash app.
4). Within the Flash app, the deep link parameter (dog) is consumed and triggers the app to load the dog page.
Another interesting tool, and one that avoids the chance for abuse/cloaking altogether, is called sIFR. It reads the HTML content on the page, and automatically creates Flash files of that content to embeds on the page. Therefore, it is not possible to serve one piece of content to the search engine and a different piece of content to the user. However, sFIR can only be used on small headlines and simple text. It is not able to recreate elaborate animations or menus, etc.
No comments
