As I continue to work on a reference project (basically building my portfolio site out in Silverlight) I keep going back to what it takes to put a Silverlight application "out there." When is it really "code complete?" There are tons of blog posts and articles about unit testing, frameworks, line of business, etc, but often I believe people miss some of the smaller points and nuances that go into making the application "application-ready." Here's a few tips and pointers that may help out.
Is SEO Important?
If it's an internal application, or even one hosted on the cloud that performs a business function and doesn't generate revenue via search engine discovery and click throughs, then search engine optimization is, of course, not much of a concern. What about if I'm presenting a portfolio or some other type of application that I want the search engines to uncover? Then we have to worry about it.
The introduction of deep-linking navigation certainly helps, but as someone pointed out in an earlier post of mine, search engines won't necessarily take the time to load XAP files, run them in a virtual environment, and see what they spit out. So we have to host the application creatively. Some shops will build two different versions. I'm working on an engine I think is a compromise, and am currently testing how the search engines like it. If it works, I'll blog about it ... if not? Back to the lab.
Essentially, you can host the website to parse out the current URL and present a set of default title, description, and other meta tags based on the URL. In other words, if I navigate to page.aspx#/Home I'll send out different tags and data than page.aspx#/Bio. The question is whether I need to generate this server side, or if I can parse it via javascript, update the tags, and the search engines will recognize the update. If I put a "site map" or legend on my pages that link to these "relative" nodes, the theory is that the engines will crawl those nodes and index at least the title and description for the content.
Most applications in Silverlight, however, function "inside the box." They don't rely on SEO. The only reason you use the deep linking and HTML DOM integration is to give the user consistent browser feedback and the ability to bookmark and return to pages.
Splash Page
It seems like a trivial step, but it is very important to promote your brand and create a seamless experience for the user. Mike Taulty has a nice video and rant in this post about the default progress animation. Take the time (about 2 minutes) to build a nice, branded experience for the user.
Here's a tip: I've seen lots of exotic ways people use to "test" their splash screen. Here's something I think will help, and will also give you good feedback for your application as a whole.
- Download Fiddler, a web-debugging proxy.
- Publish your website locally
- Run Fiddler. Go into Rules -> Performance and check "Simulate modem speeds" and "Disable caching"
- Run your application. Instead of localhost use your machine name. My laptop is called
jeremyliknesspcso I navigate tohttp://jeremyliknesspc/testappto test
That's it. Fiddler will slow down your connection enough that you can see the screen. What's better, if you are using dynamic module loading, you can also see how the application behaves when those modules take a long time to load. It might prompt you to add some nice progress indicators or other user feedback to manage the case when their connection is slow. We always test our applications locally (either on our machine or the local intranet) so it's very important to throttle the speed down and check out how it behaves in the worse case scenarios.
As an added bonus, you can start to see the internals of how the engine works: when it requests the XAP files, the additional modules, resources, etc. This will help you tune your application.
The Dead Plugin
It's going to happen. Believe it or not, as enthusiastic as we are about the way Silverlight has been growing, there will be end users who do not have the plugin. This is another branding choice in line with the splash screen. You can either give them a nice, boring, default logo provided by Microsoft, or you can spruce it up a bit. Connect with the consumer, explain why you are using Silverlight. Delight them with the benefits they'll receive after installing it and assure them it won't take long.
You can manipulate what's inside the object tag to your heart's desire. For the portfolio that I'm building, I welcomed the user, thanked them for visiting, then mentioned that as a Silverlight developer, I chose to build my portfolio in Silverlight. I indicated it is a safe plugin and that they simply need to click on the link to install it. I included the standard Microsoft icon and then put a little set of breadcrumbs linking to my relative pages beneath it.
Testing this is simple and easy, too. In Internet Explorer, you simply go into Tools -> Manage Add-ons. Navigate to Silverlight and set it to disabled. Refresh the page and see what the users will see when they don't have the plugin installed. (Re-enable it later, of course, or your Silverlight development career may end abruptly).
That's it: nothing earth-shattering or ground-breaking, but a little common sense to sprinkle along the way as we all forge ahead with our applications and anticipate how Silverlight 4 will change the landscape.
