We just released Wallice, a budget app / expense tracker that we have been working on on our spare time. We thought we could share a few insights from that experience.
This was our first ever mobile app and the form factor is radically different from what we was used to. On top of this there is Metro, the design system for Windows phone 7, which was all but familiar. Need less to say, we made mistakes – lots of them. One reason for this was that from the start we only had the emulator and Google to figure out how to design a Metro application. We didn’t have a Phone to download apps to and get a feel for how others leverage the Metro design language.
In retrospect, we would have saved a lot of time by studying other applications and get a feel for how to design a WP7 app before we started.
One of the boring things about most apps on the Marketplace at this stage is that there is not differentiation between apps. They all look the same, they use the same controls, the same graphing components (that includes us unfortunately). If your think about it this was the case with iPhone apps in the beginning so recon this will improve over time.
Make your app look different from the rest from day one. Make your own graphical profile, design and code your own custom controls that best leverage phone form factor. Do this with the Metro guide lines in mind and design your profile based on it. Think out of the box. This probably what will earn you a star or two more than your competition. This will be a focus area for us in vNext of Wallice.
Even if the phone specs are three times as fast as a Pentium box a couple of years back was, it’s still dead slow in some areas. Today user don’t like to wait, because they are not used to it anymore, after a second of waiting they will probably get bored, exit and uninstall your app. We all know we shouldn’t be doing long running tasks on the UI thread and that we should inform the user that something is happening in the background.
This is all good but its not good enough – cause it is still waiting. Of course you can’t do much about latency in the mobile network but you should definitely profile your own code and reduce bottle necks you find. And it doesn’t hurt to be a bit proactive in this area when you add new features.
In Wallice we had serious problems with I/O. After doing profiling we completely redesigned the way we stored data which effectively solved the problem all together. Another trouble area was rendering and more specifically rendering of Silverlight toolkit charts. This ended with us writing our own charting controls and without all the extra fluff they were blazing fast. All in all, this saved our users several seconds of “loading ProgressBar of death”.
Its easy to get carried away and over designing a mobile app. You need to question if you really need all that layering that you are used to in desktop/server apps. Ayende has been ranting about this for some time but its even more true for mobile apps.
We implemented tombstone behavior among the last things before we released. Beside being excruciatingly boring to do all that work at once it had some other negative implications. When we finally got around to implement tombstone we realized we had a hard time do differentiate between a Page and a Screen transient UI (as the Application Page Model document on MSDN calls them). The difference from a tombstone viewpoint is that a screen transient UI should be closed when the app is resurrected. They way we had designed some of our transient screens it was difficult to implement that behavior. If we implemented tombstone from the start this and other things like it would have surfaced earlier. Today we have tombstone as a done criteria.
This is of basically self explanatory but of course we did a last minute fix before we created the package for release, a fix that created a bug in a minor function. Even if we hadn’t failed in our discipline the smallest of bugs can create a great amount of pain due to long cycle times at the testing at Microsoft. It took us 8 days to get the bug fix out to or users, while the actual fix took ten minutes of coding. Add the fact that you don’t have unlimited number of free of charge submits a last minute can cause pain to your end users and an unnecessary expense for you. First impressions last!
We just created a link in the application to a page on Get Satisfaction don’t rely on e-mail and/or reviews on Marketplace. There is a lot of free alternatives for handling feedback in a nicer way then e-mail on the Internet, use them!
Write a short intro text that explains your applications unique selling points and functions. Take self-explaining screenshots of those. Make sure that the screenshots are taken in the correct resolution (480×800). We used the WP7 Screenshot Tool from Cory Smith. Also include the future plans of the application, if it’s a update don’t forget to include a short changelog at the end of the presentation text. Remember the long cycle time mentioned earlier? A really annoying thing is that if you only want to update the text or the screenshots, the application must go thru the certification once again. So be sure to proofread the information and let a couple of non users read them before you submits your application!
In our experience its quite a big difference between building for mobile and the desktop. Just be aware of the difference and you’ll be just fine!