Let me start by saying that I love Windows Phone 7 (wp7); it’s a modern, well-throughout, and refreshing OS. However, in as many good things there are about it, and there are many, it suffers from a metaphorical “death by a thousand cuts”. Nonetheless, I think all the issues are correctable by either technical or strategy changes, and looking from a developers perspective the following ten suggestions (in particular order) could change the game for Microsoft in so far as being able to match the best-of-the-best:
1. UI Virtualization
As everyone knows, most of the time within the screen confines, we are privy to only a part of total viewable UI – and so the idea with UI virtualization is that we only have to realize visuals for the view-elements that are (at the time) viewable on the screen. It’s not a new concept by any means, but it’s a critical piece of technology for a limited resource device – and the problem is that Silverlight’s support for UI virtualization is very anaemic. For example, out-of-the box we don’t get UI virtualization support for things like wrap-panels, pivot/panoramic panels, elements with non-similar heights, grouped items etc.
Like above, the potential field of view is one panel to the left and one to the right, everything else could be (optionally) virtualized. Furthermore, one of the other related issues is scrolling, either because of lack of UI virtualization or container recycling performance – which let’s be honest is a prevalent usability failing on wp7 apps. So what I’d like to see is that we get across-the-broad and optimized UI virtualization support for wp7 out of the box. And, this is critical because for one thing, resources are limited on phones, and virtualization-performance or even the lack-of-virtualization issues are particularly perceptible with touch-based input.
2. Hardware Acceleration
The other big ticket item that must be addressed is that Silverlight’s rendering should be done on the GPU, and not on the CPU – and unlike the desktop version, where the excuse that user might not have some sort for compatible hardware is null and void on wp7, as it only runs on a well-known hardware. The potential performance gains from hardware acceleration are in such order of magnitude that this shouldn’t even be debatable, even though technically it might not be the simplest thing in the world to achieve.
In terms of the benefits, having the rendering done on the GPU will speed up other things like networking, data-processing etc. because as of now the CPU is being overtaxed; furthermore, it will also improve the memory footprint, and even help with extending the batter life. All big wins in my book.
3. Improve Navigation and Navigation State Management
Navigation is a topic close to my heart, and I’m not particularly happy with the way navigation is done on wp7. For one thing the navigation model must be truly asynchronous, to have the ability to cancel, confirm, delay etc. And the current recommended approach to delay passing the event argument to the base class is one the weirdest view-related pattern I’ve ever seen. And the other thing is it’s not MVVM friendly, because most of the logical reasons as to proceed or cancel with navigation should be taken in the ViewModel.
Further, the hydration and de-hydration of the visual tree as a tool to manage the navigation state is simply spurious. It’s actually quite similar to the much-hated ViewState model in asp.net, and consequently I think it’s wasteful, it has a significant memory footprint, and just hits performance. The right navigation state model should do two things, one, only store the visual-cues that matter to the experience at hand and this has to be determined by the developer, and second, it should allow storing of the logical state which in my books means it should be MVVM friendly. If done correctly, it would both improve performance and reduce the memory footprint, because remember navigation is just another form of UI Virtualization.
4. Fix Push Notifications
In wp7 push notifications are serious broken, especially from a usability perspective. For example, the channel identifiers required for sending notifications are temporary, because they get reset every time the device is restarted (which because of how the marketplace app locks-up is almost a daily exercise for me). This is such an unintuitive and unexpected behaviour, that it defies any privacy arguments for resetting the identifiers – especially for people coming off iOS. Then there is the issue of capping the number of apps that one can receive notifications from (16 I believe) – again this is a usability disaster; because it is counter-intuitive (again as compared to iOS), it’s an arbitrary limit which I don’t understand the reasons for, and also just because a user has no central place to either know or manage such subscriptions.
In terms of improvements, I think we could have the idea of public and private notifications channels – such that if one is subscribe to a public channel then notification goes to all those who’ve subscribed to that channel (in a broadcasting kind of way). And private channels would be the ones that target a particular user. And I think, with a little bit of thought, Microsoft can extend the notification infrastructure to allow intra-application communication – this is something that, if done well, can bring to bear a lot of interesting apps mash-ups.
5. Design for Extensibility
I’ve already done a rant on this, but in many other ways there is still a case to be made that because wp7 is a managed platform the onus is on Microsoft to provide infrastructural capabilities for apps to built-upon. Now the problem lies with the fact that you have to wait on the underlying platform to be updated as a whole, to a gain a new capability. That I think is a fundamentally flawed approach, especially keeping in mind how fast the market and hardware capabilities are moving – so how about, if we could have independent trusted/certified dlls, that could be added to the xap and used to consume additive capability in isolation – like say NFC capabilities that might be introduced by one set of phones.
Essentially, what I’m talking about is embedding interops that are smart-enough to test if the capability can be availed on the device, and if true then wp7 gets the necessary installers and install it from Microsoft directly (into maybe something like a GAC). So lets take an example of sockets capability – in such a setup, Microsoft can in isolation make an interop available and apps can avail them before they are introduced into the platform as a whole itself – and just to note, once the capability has been subsumed in the underlying platform then Microsoft could just disallow any app from including the interop. With something like this the time-to-market can be significantly cut-down because you can test and add capabilities in a piece-meal fashion. And the benefit being wp7 as a platform can potentially be on the cutting-edge of hardware/services – without the negatives of dll hell or the delays with moving the platform as a whole.
6. Introduce Pseudo Multitasking using Tomb-stoning
Multi-tasking, or pseudo multi-tasking (or apple’ish multi-tasking), has two facets – one the ability to do certain tasks in the background (like play music) and two, resume from where you left. The second facet is essentially what we call tomb-stoning in wp7, so how about availing the state whenever an app starts – why should it be only restricted when accessed by navigating back. This is so easy to avail that I was surprised it wasn’t in the box, because we already have the application-side of the infrastructure in place. So the only thing that is really needed is a task-switcher kind of UI (as shown on the right), which again taking cues from iPhone, could be triggered by double-clicking the home button. The running apps tiles too could be made “live”.
And with respect to the other capability of having certain tasks execute in the background is again not difficult, all that is needed is to provision “named” background threads that can only do non-visual tasks. And in Silverlight we already have a background-worker approach, and we could foreseeably use something very similar to that – with the main idea being you have a qualified interface that does dispatching back-and-forth. Technically, I don’t think it’s a big challenge – especially because apple has put in the though-process already in so far as the types of background tasks we need.
7. Improve the Home Screen
Tiles are an excellent idea, but the current implementation of the home-screen comes at the expense of application discovery and limited usability. In as much as Microsoft parades the grid’ish approach to apps listing, the one thing they do provide, in terms usability, are big bold graphical hit-targets that are conducive to developing muscle memory. However, in wp7 because live tiles and apps listing require heavy scrolling and in the other case we have text-oriented targets, the muscle memory ability is severely diminished, and consequently it takes longer and requires more metal involvement to get to any app. And I can feel that extra effort’s pinch when I compare it to my experience on my iPad, not exactly fair but still, where I’ve put everything into folders in just one screen and it doesn’t take me more than two touches to get to any app; plus you also get the speed because of the muscle memory you’ve developed over time.
Without radically changing the home screen, I think one of the things that can really help is having multiple sets of live-tiles. I can imagine organizing various live-tile sets – one of people I contact often, one for games I play often, apps by category etc. Yes, it adds lateral scrolling/swiping but that not necessarily a bad thing, it’s same idea of an “infinite canvas” in play. Secondly, it’s so ironic that despite having a hardware search button you can’t search for your apps – that needs to be corrected, a press on search button should allow you to search for apps when on the home screen, period.
8. Update Back and Search Buttons Behaviour
I seriously think Microsoft got the back button and search button functionality somewhat wrong. I think the back-button should only navigate within the context of an app. Hoping apps by walking up the back-stack is counter-intuitive, it might work for task-like application hops, but it’s just not right in terms of app-to-app usability. So my suggestion is this, one, let the back-button only work within the boundaries of an app (i.e. it shouldn’t cause one to exit an app – when was the last time your browser kicked you out when you backed-up? or where is the forward button to recover from an accidental exit?), and second, introduce a long-press on the back-button that takes you to the previous application (with tomb-stoning and all). Using the long-press, as opposed to backing up n-times, would also preserve the back-stack on the running application, and that is sometimes important with things like the browser (plus we won’t end-up backing up over POST actions, which is bad bad bad!).
Similar to the back button, the search button should be contextual to the app running – and in cases where the application doesn’t handle it, it should do nothing. This behaviour would be consistent with the use of the search button in native apps, plus it would also allow its use within the home screen. Now as for accessing Bing, introduce a long-press on the search-button to get to Bing – like the back button, this would consistently hop the app-boundary and also maintain the availability of Bing from basically anywhere in the phone. And for those like me with fat fingers, we won’t constantly be jumping out games and apps because of unintended hits.
9. Introduce Built-in SkyDrive API for Apps
One of the big visions of the mobile era is that of apps that fully “live in the cloud” – we’re somewhat there in an ad-hoc and patchy kind of manner, but not quite there in a truer sense of a platform. This is a vision that wp7 can take the mantle for, since Microsoft already has a lot of the technology and assets in place – namely, the 25GB provided through Sky-Drive and Live Mesh / Live Sync technology. Imagine, having a cloud version of IsolatedStorage that could be shared across devices and Microsoft platforms – I reckon it would have a profound impact on how app’s user experiences flow across platforms and devices.
10. Introduce a Companion WP7 based Tablet
Of all the points here, nothing riles me the more than Microsoft’s inane tablet strategy, it’s like they just can’t grasp the failing of windows mobile – and the consequent ceding of billions-of-dollars worth of market to Apple and Google. What was the single biggest problem with windows mobile? Not features, not app count, rather it simply wasn’t designed for a touch device and it just didn’t work from a touch UX perspective. Now, contrast iPad with a Windows 7 tablet device – was Win7 primarily designed for a touch device? No. Does it work well from a touch UX perspective? No. It’s history repeating itself, Microsoft is ceding time and market to both Apple and Google again – and this is all despite, again like with smartphones, having a unique heritage in the tablet form-factor. Insane!
The Windows 8 System-on-a-Chip (SoC) is a laudable goal, if you can unify multiple form-factors – wonderful, it’s what sci-fi looked liked couple of years back. But, this strategy has got two problems, by the end of 2012 you will be three years out from the introduction of the iPad (ahem, just like 3+ years from iPhone to wp7’s introduction), and two, you could potentially hit a fundamental/technical issue(s) that could make it less than an idea solution (maybe like jack-of-all-trades but master-of-none) because really it is a such a challenging undertaking (Longhorn anyone? Pesky little history again). So why not take a path that has proven to be successful, take your phone OS and scale it up. And I believe, Silverlight, because of it’s awesome layout sub-system and MVVM type separation capabilities, would make for a wonderful application platform for tablets. And this can be achieved rather so quickly and cheaply (ironically on the back of Android tablets coming out now), that conceivably devices can be made available in time for holidays.
Lastly, from a developer’s perspective – iOS and Android developers get a one-for-two deal, in that they can at the same time make apps for two platforms. That’s twice the monetization opportunity with minimal effort – yet, don’t forget the fact some apps are just about only practical on a table-form factor which totally isn’t even an option for wp7 developers. That’s a handicap, that’s a loss-of-mindshare, and that makes the wp7 platform less attractive. These are just simple business 101 facts, and so it boggles my mind how does the biggest software company in the world miss the boat by such a large margin – and mind you this is not some iffy stuff, this has a profound and real effect on the long-term vitality of the windows eco-system.
Wrapup
Windows Phone 7 is a beautiful beautiful platform, there is no denying that – and that in itself is a big surprise because Microsoft has outthink everybody else in terms of the UX. However, in the current era of iPhone, Android, and iPad, this only takes them so far, it needs to be backed up a lot more substance, and a lot more functionality – neither is improbable, it’s just a matter of execution and strategy. And I just hope Microsoft can take input from the community and aggressively take the leaps required to make wp7 the platform of choice – and I like other developers will do our part.