Let’s go over the affected browser features one by one, and discuss ways of getting them working in Silverlight apps.

Feature 1: Bookmarking and deep linking

Users like to be able to copy the link from the address bar, email it to a friend, bookmark it, or post it on Twitter or Facebook.

A Silverlight app will typically transition between different views without redirecting the user to a different URL. This makes the user experience smooth and polished. As an unfortunate consequence, a user that copies the URL from the address bar or bookmarks the page will not get a link to the current active view, but instead a link to the initial view of the app.

Thankfully, there is a solution in Silverlight. A Silverlight app can modify the “bookmark” section of the URL, which is the part of the URL following the # character. The app can update the URL each time the user transitions to a different view, and read the bookmark on startup. See this article for details on how to implement this.

The Navigation Framework feature in the upcoming Silverlight 3 release will provide an easy-to-use solution to this problem.

Feature 2: Search engine discoverability

If your Silverlight app links to another page, that link is invisible to search engines. As a result, pages on your site that cannot be reached via traditional HTML links will likely not get listed in search results.

The solution is simple: list all pages on your site in an XML document called a Sitemap. Host the Sitemap on your site, and submit the Sitemap link to search engines. Once you do that, the search engines should include all pages on your site in their indexes.

For details, see the Wikipedia article on Sitemaps.

Feature 3: Back and Forward browser buttons

The Back and Forward browser buttons do not work in Silverlight apps. Switching to a different view in a Silverlight app does not insert a bookmark into the browser history, so the user can’t go to the previous view by clicking the Back button.

The problem is similar to the bookmarking issue (Feature 1), except that the solution is more complicated. If the Silverlight app modifies the bookmark part of the URL, the previous bookmark does not get recorded in the browser history, so the user still cannot use the Back button to return to the previous view.

It is in fact possible to get the Back and Forward buttons working. As of SP1 3.5, ASP.NET exposes a History Control that simplifies the solution significantly (see Control Silverlight by Using Browser Back and Forward Buttons). There is a variety of solutions available online in case you are not using ASP.NET 3.5 SP1, but beware that they typically involve hacks that don’t necessarily work in all browsers.

Or, you can wait until Silverlight 3, because browser history is properly handled in the Navigation Framework.

Feature 4: Support of external tools (translation, accessibility, …)

Automated translation, special browsers for people with disabilities, automated RSS aggregating… these are just some examples of useful tools that consume web content. These tools typically process HTML, but don’t peek inside Silverlight applications.

Since HTML is the standard representation of online documents, consider whether it would make sense to expose a simplified version of your content as a simple HTML page, in addition to your Silverlight application.

Feature 5: Printing

Silverlight does not currently have much support for printing. In Internet Explorer 7, Silverlight applications show up on the printout, but in Firefox or Safary they do not.

So, a Firefox or Safari user will not be able to print out the information displayed by your Silverlight application (at least not without taking screenshots, etc).

If you need to support printing, you can try two different solution approaches. If you only need to print content that can be represented using HTML (e.g., no Silverlight-generated charts and such), see this solution. An alternate approach is to convert XAML to an image format on the server.

Feature 6: Open link in new tab

There doesn’t seem to be a very good way to implement the ‘Open link in new tab’ feature in Silverlight. You can use a HyperlinkButton with a Target set to _blank, which seems to open a new tab in Firefox and a new Window in IE 7. But that still won’t allow the user to choose whether to open the page in the same or different tab/window.

If you are committed enough, you can probably implement a HyperlinkButton with a context menu allowing the user to open the link in a new tab/window. Right-clicking is not directly supported in Silverlight, but workarounds do exist.

Or, use hyperlinks sparingly in Silverlight apps.

Feature 7: Find on this page

I use the ‘Find on this page’ feature (CTRL+F) extensively when browsing the web. But, content inside Silverlight apps is not searched by the browser.

A mitigation is to carefully design the app UI in a way that minimizes the user’s need to search. Data should be sortable and searchable in various ways, and important information should be shown prominently (e.g., the user’s own position on a scoreboard should be highlighted).

These are all good practices regardless of your development platform, but unavailability of the ‘Find on this page’ feature makes them even more important.

Conclusion

Hopefully you’ll find these points helpful when designing your next Silverlight application. If you have other tips on extending browser features into Silverlight apps, let me know in the comments!

One solution to this performance problem is to use a “precomputed view”. Unlike an ordinary view, a precomputed view is stored in a table rather than computed on demand. When data in one of the aggregated tables changes, the update operation also updates the precomputed view table.

A great thing about precomputed views is that they can be implemented fully in SQL. Any code that accesses the database sees a precomputed view as a regular table. Also, if you have an existing regular view, you can change it into a precomputed view without having to modify any code that queries the view.

To explain the precomputed view pattern, let’s look at an example loosely inspired by the reddit social news site. Users submit articles to reddit and the articles receive up and down votes from other users. User’s “karma” is computed as a sum of votes on positively-voted articles submitted by the user.

To store the reddit data, you can store users in one table, articles in another table, and votes (+1 or -1) from users on articles in a third table:

Now, say that we want to find the top 10 users with highest karma. To compute a user’s karma, we need to sum up the scores of all articles submitted by the user. And to compute each article score, we need to aggregate the votes for that article. It should be clear that this query is going to be very expensive, no matter how much you tune and optimize it.

Views could be used to factor the complex query into simpler pieces, but not to decrease its overall cost:

It is easy to find the top 10 users, simply by querying User_View. Unfortunately, if the database contains millions and millions of votes, the query will take a long time to run. The query will have to group all votes by article, group all articles by user, and then pick the top users. Imagine the impact on performance if you wanted to show the top users on every page of your web app!

However, by changing the views into precomputed views, we can make the query for top users cheap:

Let’s walk through the conversion of Article_View to a precomputed view. First, we’ll create a table for the precomputed view:

    CREATE TABLE Article_PView(
        ArticleId int NOT NULL,
        Title varchar(40) NOT NULL,
        Url varchar(250) NOT NULL,
        VoteSum int NOT NULL,
    )

Second, we’ll need two triggers. This trigger inserts a row into Article_PView whenever a new row is inserted into the Article table:

    CREATE TRIGGER TRG_ArticleInsert
        ON  Article
        AFTER INSERT
    AS
    BEGIN
        SET NOCOUNT ON;

        INSERT INTO Article_PView (ArticleId, Title, Url, VoteSum)
        SELECT Id As ArticleId, Title, Url, 0
        FROM Inserted
    END

And this trigger recomputes a row in Article_PView whenever a vote is inserted, updated or deleted:

    CREATE TRIGGER TRG_Vote
        ON  Vote
        AFTER INSERT, UPDATE, DELETE
    AS
    BEGIN
        SET NOCOUNT ON;

        WITH articleIds(ArticleId) As
        (
            SELECT ArticleId From Inserted
            UNION
            SELECT ArticleId From Deleted
        )
        UPDATE Article_PView
            SET VoteSum = (
                SELECT SUM(Vote) FROM Vote
                WHERE Article_PView.ArticleId = articleIds.ArticleId)
        FROM articleIds
        WHERE Article_PView.ArticleId = articleIds.ArticleId
    END

And finally, we’ll populate the precomputed view with data that is already in the database:

    INSERT INTO Article_PView (ArticleId, Title, Url, VoteSum)
    SELECT Article.Id, Title, Url, ISNULL((SELECT SUM(vote) FROM Vote WHERE ArticleId = Article.Id), 0)
    FROM Article

Article_PView precomputed view is now ready, and User_PView can be created in a similar fashion.

Remarks

Note that my example assumes articles never get removed or updated. Adding support for that functionality is straightforward: you’ll need to extend the TRG_ArticleInsert trigger to also handle updates and deletes. This will be very similar to what TRG_Vote does, but I left it out from the sample for simplicity.

There are several interesting variations of how Article_PView could be implemented. In the implementation above, the trigger aggregates the votes for an article each time someone votes on it. If you want to avoid this cost, you can change the trigger so that it only adjusts the article score instead of recomputing it. For example, if a vote was updated from -1 to +1, the trigger would add 2 to the score of the article. Avoiding concurrency issues may be tricky with that approach, though.

Another interesting variation is adding the VoteSum column to the Article table instead of creating a separate table. Choose the approach that better fits your table design.

Hope you find this pattern useful!

1. Live Writer clears its undo history when you switch between views. So, if you mess up your article in the HTML view, you won’t be able to revert the change when you notice the disaster after switching back into the Normal view.
2. In the Preview view, Live Writer looks a lot like Internet Explorer. If you are not careful, it is not too hard to close Live Writer by accident. And, the confirmation dialog looks somewhat like IE’s closing dialog.

Thankfully, I found a way to recover Live Writer posts, and saved myself some wasted work.

Every time you switch Live Writer to the Preview or the Normal View, a copy of the post will be written as a HTML file into a temporary directory. On my machine, each snapshot is saved under C:\Users\Igor\AppData\Local\Temp\WindowsLiveWriter1286139640:

Sorting the snapshots by ‘Date modified’ column gives you the history of your edits, so long as you regularly switch between the different views in Live Writer.

With a bit of luck, you will find the right version of the lost article somewhere among the snapshots.