WebForms aspired to insulate us from those inconveniences. Promising rapid, drag ‘n drop layout and event-driven programming, WebForms was an attractive choice for anyone struggling with web development closer to the metal. Unfortunately, it has become apparent over the years that the WebForms abstraction, while convenient, can easily cause more problems than it solves.
Specifically, I want you to consider three areas that are negatively impacted by overzealous use of Silverlight: Usability, accessibility, and maintainability.
The Microsoft Thrive for Developers site (which has some great content) is what originally motivated this post. I’ve been percolating these concerns for some time, but my initial experience there served as a lightening rod for them.
After landing on the page, I was greeted by this progress indicator and watched it load for several seconds:
Expecting something worthy of using Silverlight, I was content to wait on the Silverlight to load. Unfortunately, the entire thing turned out to be nothing more than a simple horizontal accordion:
Even forgiving the excessive load time, these Flash/Silverlight-based horizontal accordions are a plague on usability. If you put something in my browser that looks like links and images, it should behave like links and images!
A partial list of the various usability problems that arise include:
Context Menus – When I right click a button intent on opening a link in a new tab or window, seeing a context menu with a single “Silverlight” option is not a good experience. Eliminating the standard context menu defeats several features that you may not use, but some of your users do.
Similarly, when your site thwarts the gesture plugin I use, you’re only hurting yourself. When I can’t drag a site’s links into background tabs without interrupting what I’m doing, I’m far less likely to view as many pages as I normally would.
Browser History – Just as with WebForms before, fully Silverlight based sites break the browser’s expected history, navigation, and bookmarking features by default. There are workarounds, but it’s uncommon to see them actually used.
Text Field Interop – Because Silverlight TextBox controls are not HTML input elements, they sacrifice a wide range of functionality, from password managers to the ability to drag ‘n drop selected text to and from these fields.
Using these islands of Silverlight reminds me of the usability of WebForms Buttons and LinkButtons used for navigation, which have the same problems. It wasn’t a good idea to break the browser’s basic functionality then and it still isn’t now.
It’s no secret that plugin-based technologies like Silverlight obscure their content in an inaccessible manner. Tempting as it sometimes is to turn a blind eye to this problem, accessibility is something that everyone should care about.
Though Microsoft is taking great steps to mitigate Silverlight’s accessibility issues, by embracing the W3C’s ARIA initiative, ARIA is no panacea. It is a compromise to improve the situation, but not a solution to the fundamental problem. In fact, the W3C’s first recommendation when building an ARIA compliant application is:
Use native markup when possible.
Use the semantic elements that are defined in the host markup language. For example, with HTML or XHTML, it is better to use the native checkbox than to use a div element with role
checkboxas these should already be accessible through your browser.
Even if every one of your site’s users are without physical impairment, accessibly designed sites yield a variety of other benefits as byproducts. For example, what do you think a search engine spider will glean from this markup?
<object data="data:application/x-silverlight-2," type="application/x-silverlight-2" style="width: 775px; height: 273px;"> <param name="source" value="xap/ThriveSilverlight.xap"/> <param name="background" value="transparent" /> <param name="windowless" value="true" /> <param name="minRuntimeVersion" value="2.0.31005.0" /> <param name="autoUpgrade" value="true" /> </object>
Probably not much. At least it might rank well for application/x-silverlight-2.
<ul> <li id="Advance"> <h2>Advance Your Career</h2> <p>Take control of your career path. We've got industry experts and developer community leaders to give you a hand.</p> <a href="Advance/CareerResources"> <img src="GetCareerResources.png" alt="Get Career Resources" /> </a> <a href="Advance/TrainingCert"> <img src="GetTrainingResources.png" alt="Get Training Resources" /> </a> </li> <li id="Enhance"> <!-- More content here --> </li> <li id="Connect"> <!-- And again --> </li> </ul>
The difference speaks for itself.
In the same vein, an application that exposes its content accessibly is one that is resilient to change. The ability to easily screen-scrape HTML sites has led to some of the most interesting and useful applications online.
Where an accessible app out often matures into something of a loosely coupled data source toward its end of life, walled gardens of Java, ActiveX, Flash, and/or Silverlight are too opaque to offer that lasting benefit after they’ve become dated.
Speaking of accessibility, take a look at this same site on an iPhone, which has arguably the best default mobile browser currently available:
With the growing ubiquity of devices like the iPhone, Palm Pre, and Android-based handsets, catering to mobile browsers is becoming an important consideration. Even if it’s still a minority use case (for now), users gravitate to sites that do work well with their mobile devices in that occasional pinch.
Long-term maintenance is a critical consideration when using plugin-based tools.
Think about all of the decade-old web applications that your business or clients are still keeping alive today. How many of them encapsulate important functionality within ActiveX controls? Probably almost none, and there’s a good reason for that.
If segregating functionality into plugin-based walled gardens was a good idea, we’d still be using Java applets for rollovers in navigation menus.
Silverlight and WebForms aren’t the problem
To be perfectly clear, I think Silverlight is great.
Given the choice between Flash or Silverlight video, I’ll choose Silverlight every time. The video playback is smoother and Microsoft’s great development tooling tends to encourage feature-rich player applications. Even with HTML 5’s <video> element, browser-native video can’t currently compete with Silverlight.
Given the choice between developing an internal dashboard in Flash or Silverlight, I’ll choose Silverlight every time. The charting controls already available even after Silverlight’s short time on the market are awesome, and only getting better. HTML 5’s <canvas> may eventually become the best solution for this, but it’s going to be years before that’s a feasible reality.
There are plenty of scenarios where I think Silverlight is perfectly valid. Though it might be easy to take it that way, this is not an anti-Silverlight (or Microsoft) post.
In fact, I think WebForms is fine too.
Used responsibly, WebForms is still a useful and productive abstraction – especially with the great improvements coming in ASP.NET 4.0. There are plenty of times when something like Dynamic Data to scaffold an administration interface is a smart choice.
Having keenly watched the ebb and flow of web technologies over the past fifteen years, I’m comfortable predicting that an investment in learning the underlying basics is crucial if you’re serious about developing for the web. Anything used to avoid this fundamental understanding is a crutch, not a tool.
5 Mentions Elsewhere
- Tweets that mention Is Silverlight the new WebForms? | Encosia -- Topsy.com
- DotNetBurner - Silverlight
- Steven Gardner Blog :: stevengardner.net » Blog Archive » Silverlight – The New WebForms?
- Visoft, Inc. Blogs | Data Access and Silverlight 4