The Exchange UI team is investigating possible technologies we could use in future releases of management tools. One potential technology we could use is Silverlight. This would provide the ability...
Updated Jul 01, 2019
Version 2.0
Blog Post
I'm going to take a non-end-experience approach to commeting on this.
I'm not enthusiastic about Silverlight as it doesn't have, for example, real windowing. I would say that using Silverlight as the interface is a great idea if it means greater development productivity for the MS Dev and MS QA teams to produce the same (or more/better) UI. If DHTML/AJAX is more productive and quality-testable for the same basic tasks, stick with it.
I come from a mindset where I believe that a product is only as good as the developers' experience was, because the end product its their fruit. For example, a *good* DHTML/AJAX developer not hampered by the oil+water scenario of ASP.NET Web Forms + custom Javascript can get much done very fast and produce a very high quality product. Silverlight's developers are new to productive development workflow because Silverlight itself is still relatively new.
I'm not enthusiastic about Silverlight as it doesn't have, for example, real windowing. I would say that using Silverlight as the interface is a great idea if it means greater development productivity for the MS Dev and MS QA teams to produce the same (or more/better) UI. If DHTML/AJAX is more productive and quality-testable for the same basic tasks, stick with it.
I come from a mindset where I believe that a product is only as good as the developers' experience was, because the end product its their fruit. For example, a *good* DHTML/AJAX developer not hampered by the oil+water scenario of ASP.NET Web Forms + custom Javascript can get much done very fast and produce a very high quality product. Silverlight's developers are new to productive development workflow because Silverlight itself is still relatively new.