Sine of the times

Silverlight Deeplinks and Redirection

2009-03-31T08:58:00Z

An interesting thing comes about with RIA applications and deep-links. Say a user arrives at a deep-link:

http://hexadecimate.com/SilverlightStore/Product.aspx?Name=Office+Professional+2007

Note that we're representing the deep-link state in the URL as "Product.aspx?Name=Office+Professional+2007". After the Silverlight XAP loads, any subsequent Silverlight navigation will update the URL fragment as to not refresh the page. So you could easily run into a nasty URL like this:

http://hexadecimate.com/SilverlightStore/Product.aspx?Name=Office+Professional+2007#/Products$Office%20Small%20Business%202007

Now we see two pieces of state in the URL; the (1) original deep-link value in the URL query and the (2) updated application state in the URL fragment. We can't change #1 because that would refresh the page so what do we do?

Aside
It's worth pointing out that everything in the URL before the fragment can be cleaned up by making use of ASP.NET Routing. Similarly, the URL fragment can be cleaned up by making use of Silverlight UriMapping.

The answer depends on how important clean URLs and search engine ranking are to you. (If your app is intranet-only, nix the SEO angle.)

One way to get around this is by doing client-side redirection. On the "Products.aspx" page, we can detect in JavaScript whether or not the client has Silverlight installed and redirect them back to the site root, passing along the deep-link information as a URL fragment. A user who visits such a deep-link might see a brief flash as they are redirected but gains a cleaner URL during the application lifetime. (To avoid the "double-click back" problem, you may want to consider using the location.replace() method.)

Client-side redirection seems like a great option! So what's the catch? First off, you'll be taking an additional server hit. Second, the user sees a brief flash during redirection. They may even hear the IE "click" sound twice.

These drawbacks are really very minor if a clean URL is important to you. But there is another point to consider: how such redirection behavior appears to search engines. While client-side redirects are fairly common, you need to tread lightly. The reason being that search engines could potentially view such behavior as malicious. If that happens, you risk losing traffic and visibility! If you choose to perform redirects, take precautions and avoiding redirecting across domains and ensure that your redirection URL exists in your down-level markup as well.

Google has published guidelines on this and related matters that are worth a read. Unfortunately, there isn't an "official" rule to follow with redirection. When in doubt, make sure that the richer JavaScript and Silverlight experience presents the same content and information seen by down-level clients.

Search Engine Optimization for Silverlight Applications – Part 2

2009-03-25T00:24:00Z

Last time, I spoke a bit about the general process of enabling search engines to index content in a Silverlight web application. This time, I’d like to deep-dive into the SilverlightStore SEO Example application available online.

Overview of the Sample Application

The SilverlightStore application is a super simple application that is light on functionality and really intended to provide a clear overview of how to SEO-enable a Silverlight site. It uses Silverlight 3, ASP.NET and the new .NET RIA Services.

Figure 1 – screenshot of the SilverlightStore sample application.

The sample application uses a simple XML file (“/App_Data/Products.xml”) containing information about Microsoft products. This information is used to populate a collection of POCO Products (via LINQ) that are exposed to our Silverlight client using a .NET RIA Services DomainService.

The DomainService exposes product information to our Silverlight client and also to our ASP.NET controls (via the DomainDataSource control).

Figure 2 – Logical separation of components in the sample application.

The beauty of this flow is that our content comes from 1 centralized source: the DomainService. One could replace the DAL with ADO.NET Entity Framework, LinqToSQL, nHibernate, etc without breaking the flow. Similarly, one can bring on new clients (such as an AJAX client) and plug those into the DomainService.

The example application contains a bit of Silverlight code to consume the DomainService and display products and product details—I won’t be getting into those details here*.

^{*Unless one would find it interesting, in which case please do let me know.}

Generation of Down-Level Content

Let’s dig into the good stuff. This application uses the same Master to Content Page relationship described in part one so I won’t dwell on that point. What I do want to review is the use of the ASP.NET DomainDataSource control used to query our DomainService for entities and generate the corresponding down-level content.

If you crack open the Default.aspx page, notice the use of the DomainDataSource and how it refers to the ProductsDomainService.GetProducts() method. We then use this DataSource control with a traditional ASP.NET ListView control to render all of our products inside of the Silverlight <OBJECT> tag defined in the MasterPage.

<%@ Register TagPrefix="ria" 
    Namespace="System.Web.DomainServices.WebControls" 
    Assembly="System.Web.DomainServices.WebControls" %>
<asp:Content ID="DownLevelContent" 
    ContentPlaceHolderID="SilverlightDownLevelContent" runat="server">
    <h2>Products</h2>
    <ria:DomainDataSource runat="server" ID="ProductsDomainDataSource" 
        DomainServiceTypeName="SilverlightStore.ProductsDomainService" 
            SelectMethod="GetProducts" />
    <asp:ListView runat="server" DataSourceID="ProductsDomainDataSource" 
        DataKeyNames="Name">
        <LayoutTemplate>
            <ul class="product-list">
                <asp:PlaceHolder id="itemPlaceholder" runat="server" />
            </ul>
        </LayoutTemplate>
        <ItemTemplate>
            <li class="product">
                <span class="image">
                    <a href="Product.aspx?Name=<%# Eval("Name")%>">
                        <img src="<%# Eval("ImageSmall")%>" 
                             alt="<%# Eval("Name")%>" />
                    </a>
                </span>
                <br />
                <span class="name">
                    <a href="Product.aspx?Name=<%# Eval("Name")%>">
                        <%# Eval("Name")%>
                    </a>
                </span>
                <span class="summary"><%# Eval("Summary")%></span>
                <span class="price"><%# Eval("Price", "{0:c}")%></span>
            </li>
        </ItemTemplate>
    </asp:ListView>
</asp:Content>

The Default.aspx page renders a product listing that contains links to the Product.aspx product detail page. If you dig into the Product.aspx page, you’ll notice that it uses the DomainDataSource control in a similar fashion but displays all of the product details.

If you disable JavaScript (or Silverlight specifically), load the Default.aspx page in your browser and notice that the down-level experience provides you with the same content as you’d see in Silverlight. You’re able to review all of the products and dig into the details—you just miss out on some of the fancy transitions and effects. Not only are we making this content indexable by search engines, we’re also broadening our client reach.

Sitemaps and Robots

Indexable content is all fine and well … but how do you let the search engines know you exist? An organic approach is to have external sites link to you and search engine crawlers will naturally stumble upon your site and begin indexing it. (In fact, this will happen no matter what you do.) By why leave things to chance?

If you’re serious about SEO, there are two components you must add to your site:

A Robots.txt file.
One or more XML sitemaps.

Robots.txt

The Robots.txt file is used to define directives for search engine crawlers to obey. (Note: they are not required to obey these—but most will.) You can define what user-agents are allowed access to what areas of your site. You can even declare the location of your sitemaps. (We’ll get into sitemaps in a moment.)

For a real world example of a robots.txt file, I’d recommend you check out Amazon’s robots.txt here: http://www.amazon.com/robots.txt. You’ll notice that it defines a few areas of the site that should not be indexed and also provides some sitemap links.

XML Sitemap

Sitemaps are used to provide search engines with … well, a map of your site. :) You can define all of the important entry point URLs that you want search engines to index.

You should definitely provide links to your common entry points in your sitemap as well as additional information to indicate the update frequency and priority. That’s not to say crawlers won’t continue to crawl your site without sitemaps—they will, but using a sitemap allows you to express more information about your site than crawling offers.

If you look at the “Sitemap.aspx” page inside of the SilverlightStore sample application, you’ll notice that it makes use of the DomainDataSource and an ASP.NET Repeater control that are used to iterate through all of the products and generate XML (conforming to the sitemap standard) with links to all of the product detail pages.

<%@ Register TagPrefix="ria" 
  Namespace="System.Web.DomainServices.WebControls" 
  Assembly="System.Web.DomainServices.WebControls" %> 
<ria:DomainDataSource runat="server"
  ID="ProductsDomainDataSource" 
  DomainServiceTypeName="SilverlightStore.ProductsDomainService" 
  SelectMethod="GetProducts" />
<asp:Repeater runat="server" DataSourceID="ProductsDomainDataSource">
  <HeaderTemplate>
    <urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  </HeaderTemplate>
  <ItemTemplate>
    <url>
      <loc>
        <%= new Uri(this.Request.Url,"Product.aspx?Name=").ToString()%><%#
            HttpUtility.UrlEncode((string)Eval("Name"))%>
      </loc>
      <lastmod><%# Eval("LastModified")%></lastmod>
      <changefreq><%# Eval("ChangeFrequency")%></changefreq>
      <priority><%# Eval("Priority")%></priority>
    </url>
  </ItemTemplate>
  <FooterTemplate>
    </urlset>
  </FooterTemplate>
</asp:Repeater>

Putting It All Together – Deep Links

Now we have a Silverlight application with content, the corresponding down-level HTML content, a robots.txt and sitemap to help guide search engine indexing. What’s left? We need a good deep-linking story!

Now that search engines can index the down-level deep-links to our product detail pages, how do we respond to those deep-links if a user visits with Silverlight installed? We need to convey the deep-link information contained in the URL to the Silverlight application.

We do this in the SilverlightStore application by passing the deep-link information to our Silverlight client by using InitParams.

If a user arrives at our site via a link like http://<site>/Product.aspx?ProductID=123, we can handle this inside of the Products.aspx by passing the query information to the Silverlight control. (This is done in the sample application by appending to the SeoSilverlightApplication.InitParams property---but if you’re rendering your own <OBJECT> tag, you’ll want to handle this <PARAM> modification yourself.)

The InitParams values are treated as a dictionary collection inside of the Silverlight application and you can access these by either listening to the Application.Startup event or by registering your own application service. (The sample application uses an application service called DeepLinkService.)

The only thing left is to determine how to map URL deep-link information to Silverlight state. In the sample application, we pass the product name as a deep-link and the Silverlight application understands that it must construct it’s own internal XAML Uri to load the product. There are plenty of other ways of doing this such as making use of the HttpRequest PathInfo string in coordination with UriMapping inside of Silverlight 3.

Conclusion

Once again, we see that using Silverlight 3, ASP.NET and .NET RIA Services together provides a powerful array of tools that can be used to quickly build a compelling Silverlight application that is indexable and discoverable.

Resources

Search Engine Optimization for Silverlight Applications

2009-03-24T09:28:00Z

Introduction

Silverlight 3 provides a myriad of reasons to use it for your next rich web application. But one drawback to using Silverlight is that search engines cannot index the content presented by XAPs. This is a deal breaker if you rely on search results to drive traffic to your site. The good news is that there are existing techniques you can make use of to get the best of both worlds: rich user experiences and search engine index-able content.

Before we get into the good stuff, I want to comment on what it means to make a Silverlight application index-able. In the context of this article, I'm going to speak specifically to techniques that improve search engine visibility but there is another aspect that needs to be taken into account: viable down-level user experiences. What the search engine sees is exactly the same as what users without Silverlight see. I'd strongly advise against going down the path of creating down-level content specifically for search engines--a better approach is to create viable down-level experiences that users without Silverlight can use.

Theory

Search engines, for the most part, use static analysis of HTTP responses to parse and index page contents. That means when a search engine crawler comes across your Silverlight application, it's only cares about the source.

When the browser attempts to render a Silverlight <OBJECT> tag but is unable to instantiate the plug-in, it will continue on and render the contents within. If the client has Silverlight installed, they'll see the Silverlight application instead of the HTML content within.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" 
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <title>Silverlight Application</title>
  </head>
  <body>
    <div id="content">
      <object data="data:application/x-silverlight-2," 
              type="application/x-silverlight-2">
        <param name="minRuntimeVersion" value="3.0.40305.0" />
        <param name="source" value="ClientBin/MyApp.xap" />
        <div class="down-level">
          <h1>Down level content goes here.</h1>
          <p>Lorem ipsum dolor sit amet...</p>
        </div>
      </object>
    </div>
  </body>
</html>

And that's pretty much it. Want your Silverlight application to be index-able? Put the appropriate down-level HTML markup within the <OBJECT> tag. Easy enough, right?

Practice

The theory is easy but practice takes a bit of work. We'll use ASP.NET Master Pages to facilitate deep-linkable down-level content.

Let’s assume we’re building a simple website that display product information. This site has a home page that contains links to “featured” products as well as links to categorical listings of products.

Figure 1 - Example Site Structure.

One simple approach is to create a MasterPage for your site (similar to the HTML example above) and place a ContentPlaceHolder control within the <OBJECT> tag.

<%@ Master Language="C#" ... %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" 
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <title>Silverlight Application</title>
  </head>
  <body>
    <div id="content">
      <object data="data:application/x-silverlight-2," 
              type="application/x-silverlight-2">
        <param name="minRuntimeVersion" value="3.0.40305.0"/>
        <param name="source" value="ClientBin/MyApp.xap"/>
        <asp:ContentPlaceHolder ID="DownLevelContent" runat="server"/>
      </object>
    </div>
  </body>
</html>

Now we can add the following content pages:

Default.aspx – this is our landing page.
Products.aspx – this is used to list products.
ProductDetails.aspx – this is used to display the details of a particular product.
… we could add additional pages if needed, you get the idea…

The important thing to note is that all of our content pages are now acting to provide down-level content. Users that visit with Silverlight installed will see the Silverlight experience.

Figure 2 – Master and Content Page Relationship.

Conclusion

With a little bit of elbow grease, it's possible to create a rich Silverlight application that provides a compelling user experience without sacrificing search engine visibility.

Resources

Silverlight 3