The Microsoft Dynamics GP team, when considering the creation of our upcoming web client user experience, looked at many technologies that would offer us an architecture for future growth, a feature set that was strong with controls and flexibility, and one that provided us a performance model that benefitted our customers.
Silverlight was a clear standout product in this research. In fact, we’ll be using Silverlight 5 features as it ships, specifically Silverlight 5 has been architected to deeply support business application development far deeper than other similar toolsets.
Windows 8 is an amazing product and has gained a lot of recent attention, especially around Tiles and Apps. Those work particularly well in the consumer experience, such as playing media, checking on the local weather, or browsing websites. Metro-styled apps, with their “clean” interface and open feel, might not be the best interface for a business application that has deep functionality sets, complex transaction windows, and deep reporting requirements. What is great about the Windows 8 operating system is that it supports multiple styles of applications, and we are making a conscious decision to develop on the one we feel is best suited for business applications.
The Windows 8 platform has also garnered a lot of press around the new browsing experience that currently is slated to not have plug-in support, such as Silverlight. What might not be evident to everyone is that XAML, the rendering technology for Silverlight is an integral part of the Windows 8 operating system. And this really flows with where the browsing experience is likely heading – where the browser experience is inherent to the operating system and no longer remains a separate application to run.
The current usage of Internet Explorer as an application running inside of the OS is something that is being re-architected into the always-on, always-connected metaphor where a program such as Internet Explorer becomes irrelevant. In the future, you’ll be browsing right from within the operating system itself, which means the choice of browser, or technology that it supports, will change to that of what the operating system inherently contains. In our case, it will have XAML. We are focused on those technologies that, when market focus shifts to those devices running an always on, always connected OS, we’ll be able to minimize our efforts to get on that platform. By supporting the toolset that we are supporting today, we are using the Microsoft development platform to deliver a solid experience today, but also giving us the path to upgrade to those devices in the future.
Jonathan Allen explains this well:
“The companies most invested in Silverlight are actually in the best position. These companies have been adopting Silverlight, and Flex, for use in internal applications. This sort of application generally have no HTML and simply use the browser as a delivery mechanism. As such these applications can be ported to the Metro runtime with surprisingly little effort. A new distribution mechanism will be needed, but something like the Windows app store for enterprises is undoubtedly in the works.”
All great news and I'm equally excited about the upcoming versions of Microsoft Dynamics GP and Windows 8 (I've been avidly following the Build 8 blog!).
However, in discussing the upcoming version of Microsoft Dynamics GP with a prospect, he knew it is going to be rendered in Silverlight and made mention that from the IT perspective Silverlight is not a "light" application. He said that it still takes a lot of processing power on both the server and client sides. Since, unfortunately, I know very little about Silverlight, I could really have no conversation surrounding this topic.
Can you please either address this issue in a future blog post or send me some links to point me in the right direction of rebutting this argument (firstname.lastname@example.org)? I'm sure this will be a topic that arises in the future, especially as we near the release date of the new version.
In closing, I'd like to add that you and the rest of the Microsoft Dynamics GP team do a fantastic job, not only with GP, but on the blog, as well. Keep up the great work!
Todd M Bowlsby
InterDyn - Remington Consulting
Silverlight doesn't require any server processing after the initial download of the application to the client machine. Once the client has the Silveright application, all processing happens on the client side except for places where you explicitly contact the server. You only need to call back to the server when you need to either send user input or request new data from the server, and these are things that you would have to do with ANY web application. A well-written Silverlight app will put LESS load on a server than an web app that requests new web pages to do things, because the Silverlight app isn't required to talk to the server to perform complex UI tasks.
We have a reasonably complex Silverlight application as part of our web site. The typical user with a broadband connection downloads it in about 3-5 seconds. The whole thing is pretty lightweight. Any client machine build in this century (and probably before) can easily run it. I can't imagine why anyone would be overly worried about client processing time. Unless your clients are rendering HD videos in the background at the same time that they are using your site, I can't imagine anyone having a problem. Any usage scenario where you assume your website is the primary task of the user, the user will have more than enough client processing headroom to run most anything you create in Silverlight.