Hi. I'm DJ Schwend, a product designer working on the OWA team here in Exchange. I've put together this overview of the best new features in our Beta 1 release. We've made huge strides to improve t...
Updated Jul 01, 2019
Version 2.0
Blog Post
Thanks for the feedback Joe!
I agree with you it would be dangerous for us to use statistics like “how many customers/users use OWA2003 with IE” and “how many customers/users use OWA2003 with Firefox” as the determining factor of whether we add Firefox support or not. If we were doing that I agree that we wouldn’t be understanding how our customers _want_ to use OWA. We would only be understanding how our customers use OWA today because of limitations/designs we currently have in the product.
Our goal is to understand how our customers _want_ to use OWA, and make decisions based on that. So we don’t look at the browser statistics for “browsers hitting OWA” to make the prioritization decisions about browser support. We look at the browser statistics for “browsers used on the Internet” and “browsers used within our customer organizations” to make those prioritization decisions.
We also listen to what customers are asking for as a good measure of what they want since statistics never tell the full story no matter how many surveys, site logs or research firms we draw from.
On the other topic of “browser specific hacks” you mention, we actually already went down the path of not using any IE-specific mechanisms in OWA2007. OWA2003 made use of a few mechanisms like that, but since we were doing a rewrite we had the luxury of replacing those with mechanisms more generally supported among different browsers. So there’s not big piece of browser infrastructure OWA relies on which works only in IE. The decision about the browser matrix of OWA is all about the investment we allocate to OWA, and the need of additional browser support as compared to the need for all the other OWA features our customers want. Even now that we use only browser infrastructure commonly supported by more browsers there is a significant development and (even larger) test cost associated with supporting more browser types and versions.
/K
I agree with you it would be dangerous for us to use statistics like “how many customers/users use OWA2003 with IE” and “how many customers/users use OWA2003 with Firefox” as the determining factor of whether we add Firefox support or not. If we were doing that I agree that we wouldn’t be understanding how our customers _want_ to use OWA. We would only be understanding how our customers use OWA today because of limitations/designs we currently have in the product.
Our goal is to understand how our customers _want_ to use OWA, and make decisions based on that. So we don’t look at the browser statistics for “browsers hitting OWA” to make the prioritization decisions about browser support. We look at the browser statistics for “browsers used on the Internet” and “browsers used within our customer organizations” to make those prioritization decisions.
We also listen to what customers are asking for as a good measure of what they want since statistics never tell the full story no matter how many surveys, site logs or research firms we draw from.
On the other topic of “browser specific hacks” you mention, we actually already went down the path of not using any IE-specific mechanisms in OWA2007. OWA2003 made use of a few mechanisms like that, but since we were doing a rewrite we had the luxury of replacing those with mechanisms more generally supported among different browsers. So there’s not big piece of browser infrastructure OWA relies on which works only in IE. The decision about the browser matrix of OWA is all about the investment we allocate to OWA, and the need of additional browser support as compared to the need for all the other OWA features our customers want. Even now that we use only browser infrastructure commonly supported by more browsers there is a significant development and (even larger) test cost associated with supporting more browser types and versions.
/K