Learning from (the failures of) Metro UI
Microsoft's Metro Design Language (MDL) was beautiful. Many of its parts are still in Windows 10 today. However, some of the things that made it great already disappeared. Let's try to analyze them and the reasons why.
Windows 10's current start screen is a carry over from the original MDL. The only thing that disappeared, which I thought was a good feature, is the tall tile size (the wide tile size is retained). New features have been added since and more will be added in future updates. The start screen can be considered as MDL's strongest success. The following, though, just had to die, either because of flaws by design and/or because of Microsoft's own doing.
First, you wouldn't know what were available in the app until you visited all screens. Discovery meant that you had to scroll through everything first. As such, once you found what you wanted, the design assumed you would remember it. Besides testing your memory skills, it also assumed you were good at it. By design, it was assuming that you would take the time to discover and that you would actually try to remember where things were. It was immediately "challenging".
Second, you always had to scroll left and right to reach the screen you want. There was no way to jump to a screen even if you knew where you wanted to go. As it turned out, it required "too much navigation" and, therefore, was too tiring and unnecessarily time consuming to use.
The fix was simple. Two popular approaches could be applied: (1) fit more of what 's available for navigation in a horizontal menu or tab bar; and/or (2) organize navigation in a hamburger menu. These two approaches could be combined and used in the same app. You should find many Windows apps in the Store applying these approaches, including those authored by Microsoft.
The hub was initially limited to Microsoft specific hubs for people, photos, music, videos, games and Office. When Windows Phone 7 was launched, developers had to conform to specific requirements that would let their apps "join" any of the existing hubs. The main problem was that it would also mean that the developers' apps could lose their own branding. Any unique experiences that developers might want for their users could be "hidden" by the existing hub. To say the least, the hub was anti-competitive by design.
It took a while for Microsoft to open up custom hub development to developers. By that time though, the damage was done. The hub concept was already generally disliked. It was too late to sell the hub as a way for developers to build their own brand's portal. It would've been great to have Adobe Hub, Steam Hub, Disney Hub, EA Games Hub, Rovio Hub, etc. In the end, no one bothered.
In addition, hub development was clearly different from how other better performing platforms were selling apps. The hub's extra developer effort was specific to Windows phones, which was not really selling well. Not surprisingly, developers dismissed it. The Windows-specific nature of the hub, the concept, the technicalities of it, and how it was implemented, unceremoniously killed it.
The hub was a smart idea and it still is. It's not totally dead, but it's no longer something that needed to be specific to Windows. It's exactly how it should be. In this regard, it would have been better if the hub concept was sold as an application design template, not as something specific to a platform's design language/system. If the hub was just a guidance without any platform lockdown, it might have had a better chance of attracting more developers.
There was just one magnificent flaw: it assumed that the user knew they had to pinch in or pinch out. It would've been great if it was a feature advertised better. The experience was fantastical, but it was almost impossible for the user to know if it's there or not. If not all apps offered it, UI/UX consistency would be lost, and that was enough to put this great and wonderful idea six feet under.
To developers, semantic zoom was just additional coding specific to a non-selling platform. It was purely eye-candy. And even if eye-candies could sell, Microsoft's Windows Phone 7 wasn't. The formula just didn't add up. The extra effort had no real value.
In this regard, it would have been better sold as an application design template, not as something specific to a platform's design language/system. The semantic zoom is ahead of its time. It needs more exposure to users. Over time, I still believe in the potentials of semantic zoom.
All things considered, Microsoft rushed itself in to the mobile business. It was playing catch-up after all. There were awesome ideas, yes. However, Microsoft did not plan well enough to make the overall package convincing to both developers and users. As Microsoft would unfortunately demonstrate after Windows Phone 7, uncertainties with their mobile plans diminished trust in the brand.
MDL had a good run. MDL2 came soon after. Now, Microsoft is pushing for the Fluent Design System. Microsoft took risks. Microsoft had to learn and move on. Hopefully, Microsoft picked up the right lessons from Metro's past.
Windows 10's current start screen is a carry over from the original MDL. The only thing that disappeared, which I thought was a good feature, is the tall tile size (the wide tile size is retained). New features have been added since and more will be added in future updates. The start screen can be considered as MDL's strongest success. The following, though, just had to die, either because of flaws by design and/or because of Microsoft's own doing.
Discovery and Navigation
The left and right navigation design of the original MDL had mostly disappeared. The original design featured a screen title and a hint of the next title showing at the top right. You would scroll to the right to reveal the next screen. If there was another screen to the right, a hint of it was shown as well. You scroll to the left to return to the previous screen. Paired with some parallax effect as you scroll left and right, it was visually appealing. However, in usage, there were two major flaws.First, you wouldn't know what were available in the app until you visited all screens. Discovery meant that you had to scroll through everything first. As such, once you found what you wanted, the design assumed you would remember it. Besides testing your memory skills, it also assumed you were good at it. By design, it was assuming that you would take the time to discover and that you would actually try to remember where things were. It was immediately "challenging".
Second, you always had to scroll left and right to reach the screen you want. There was no way to jump to a screen even if you knew where you wanted to go. As it turned out, it required "too much navigation" and, therefore, was too tiring and unnecessarily time consuming to use.
The fix was simple. Two popular approaches could be applied: (1) fit more of what 's available for navigation in a horizontal menu or tab bar; and/or (2) organize navigation in a hamburger menu. These two approaches could be combined and used in the same app. You should find many Windows apps in the Store applying these approaches, including those authored by Microsoft.
The Hub
The hub was not just a left and right navigation portal. It was an attempt to centralize and to somehow "standardize" certain experiences for related or similar content. If you think about making things simple for users, the concept of the hub seemed heroic. Regardless of what app or services you use, they can all share the same hub experience. Although it seemed user-friendly, it was actually not developer-friendly.The hub was initially limited to Microsoft specific hubs for people, photos, music, videos, games and Office. When Windows Phone 7 was launched, developers had to conform to specific requirements that would let their apps "join" any of the existing hubs. The main problem was that it would also mean that the developers' apps could lose their own branding. Any unique experiences that developers might want for their users could be "hidden" by the existing hub. To say the least, the hub was anti-competitive by design.
It took a while for Microsoft to open up custom hub development to developers. By that time though, the damage was done. The hub concept was already generally disliked. It was too late to sell the hub as a way for developers to build their own brand's portal. It would've been great to have Adobe Hub, Steam Hub, Disney Hub, EA Games Hub, Rovio Hub, etc. In the end, no one bothered.
In addition, hub development was clearly different from how other better performing platforms were selling apps. The hub's extra developer effort was specific to Windows phones, which was not really selling well. Not surprisingly, developers dismissed it. The Windows-specific nature of the hub, the concept, the technicalities of it, and how it was implemented, unceremoniously killed it.
The hub was a smart idea and it still is. It's not totally dead, but it's no longer something that needed to be specific to Windows. It's exactly how it should be. In this regard, it would have been better if the hub concept was sold as an application design template, not as something specific to a platform's design language/system. If the hub was just a guidance without any platform lockdown, it might have had a better chance of attracting more developers.
Semantic Zoom
Semantic zoom could've made fancy data navigation and views the new standard. With a pinch here and there, you could see more about your data, potentially allowing you to find them easier and faster as well.There was just one magnificent flaw: it assumed that the user knew they had to pinch in or pinch out. It would've been great if it was a feature advertised better. The experience was fantastical, but it was almost impossible for the user to know if it's there or not. If not all apps offered it, UI/UX consistency would be lost, and that was enough to put this great and wonderful idea six feet under.
To developers, semantic zoom was just additional coding specific to a non-selling platform. It was purely eye-candy. And even if eye-candies could sell, Microsoft's Windows Phone 7 wasn't. The formula just didn't add up. The extra effort had no real value.
In this regard, it would have been better sold as an application design template, not as something specific to a platform's design language/system. The semantic zoom is ahead of its time. It needs more exposure to users. Over time, I still believe in the potentials of semantic zoom.
Office Was Not in Metro
It was Microsoft's responsibility to showcase MDL to inspire developers. The fact that Microsoft's own major product like Office was not using MDL did not help. If Microsoft itself couldn't apply MDL to their own main products, why would developers? Besides, there were not enough good examples to pattern after. There was no existing sample of success. Benchmarking was impossible.Hopefully, Microsoft picked up the right lessons from Metro's past.The overall marketing of MDL was premature. Developers were not convinced. MDL became just an exciting study. Unfortunately, for developers in serious app businesses, MDL was a risk that most, if not all, did not want to take.
All things considered, Microsoft rushed itself in to the mobile business. It was playing catch-up after all. There were awesome ideas, yes. However, Microsoft did not plan well enough to make the overall package convincing to both developers and users. As Microsoft would unfortunately demonstrate after Windows Phone 7, uncertainties with their mobile plans diminished trust in the brand.
MDL had a good run. MDL2 came soon after. Now, Microsoft is pushing for the Fluent Design System. Microsoft took risks. Microsoft had to learn and move on. Hopefully, Microsoft picked up the right lessons from Metro's past.
Comments
Post a Comment