Tales from the salt mine

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.

Get comfy with Metro UI language

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.

Do your own thing

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.

Be quick or be dead

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”.

Keep it simple

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.

Have a tombstone strategy

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.

Don’t do last minute fixes

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!

Give users the possibility to submit feedback directly to you

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!

Wrap it up nicely

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!

Wrapping up

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!

We are pretty psyked right now since we just had Wallice approved for the Windows Phone 7 marketplace. Wallice is a budget / expense tracking application that we made in our spare time.

At the moment it has all the basic functionality you would expect from an expense tracker. You add expenses and get rewarded with statistics. What we think that we do differently than the competition is that we make this dead simple and we provide you with the tools to generate insights from your spending patterns and how these change over time. In addition we paid careful attention to the design guidelines of the platform and this resulted in an app that looks and feels like Windows Phone 7.

Lets look at some of the features and our thinking behind them.

New expense

No surprises here, its sort of an required feature and a boring one as such. That why we tried making it as painless as possible. For example, we made this is the very first screen you see when you start the application since this is what you will be using the most. We help you with a few “quick categories” which are are based on your usage patterns. Categories you use often will show up here as well as recently used categories.

Categories are optional, as well as title, but we recommend at least using categories since this enable you to generate more insight from your spending when using the other features. We provide you with a set of predefined categories but you are free make your own categories and sub categories to them. The categories are later on the different aggregations for statistics and different reports.

So far

So far is a dynamic snapshot of a specific period of time that the user chooses. Wallice remembers the chosen period and shows it until the user chooses another one. An example is that the user selects Swedish Pay Date as his period of choice, Wallice then calculates the snapshot based on the transactions made between last pay date and today’s date. When he gets his next salary so far restarts with a new snapshot. There is a couple of different strategies for the snapshot period; month, year, day in month, date range and Swedish pay date.  It’s also possible to drill down in the categories, sub categories and finally down to the actual entries.

Category comparison

One the first things that you probably are interested in after tracking your expenses for a while is where the heck your money is going. The “category comparison” feature helps you with just that and you get a nice little purple pie chart showing you how much is spent in each category. We figure that armed with this feature, you will discover those hidden expenses that add up to a pile of money in a month – just like Erik did when he found out he spent over $150/month on 7-eleven coffee.

Spending over time

Now, after you released that you spend too much money on coffee and booze and tried to cut down for a while, you probably want to see how you are doing. Spending over time also provide a neat little “sparkline” chart along with some stats showing you how much was spent in a category in the last 12 months. Clicking the chart brings up yet another chart showing the same data as the sparkline but with more detail.

Other features

Other features worth mentioning is “recurring transactions” where you create a expense that will recur on fixed dates, like the rent for example.

Future

The next steps is to differentiate the application with user experience and adding different ways of analyzing data for finding your own buying behavior, its only thru insight you could get the possibility to change your habits. Later on we will probably add support for budgeting etc. depending on that the users says that they need.

So if you have a WP7-phone, please download Wallice and give us some feedback!

I’ve plowed thru gigabytes of log files these last few days trying to identify a problem we have been having with our app. That made me start thinking of what a log and awesome log output should contain.

I came up with these points, some trivial, some are perhaps not.

• Use a logging framework
  I’ve always used log4Net but what ever works for you.
• Use the log levels correctly (I’m using the log4Net levels). This makes it possible to hide output you are not interested in.
  Debug is for trace messages – intended for a developer or administrators.
  Info is for positive events that successful – Eg “Created user ‘Anders’”
  Warning is for negative events that may occur but does not prevent the application from function correctly. Eg “User ‘Anders’ is already logged on.’
  Error – Is for negative events which prevented a action from being performed. “Unable to create new user ’Anders’. User already created.”
  Fatal – When unhandled exception occur and your app will have to roll over and die.
• Name that thread 
  If your application more than one thread (which I hope it does these days) remember to set the Name property when you spawn new threads. It makes it easier to follow a flow if many threads are running in parallel.
• Include meaningful data in your output.
  For example, “User changed favorite color” does tell you what the new or old color is.  “User changed favorite color to blue, old was yellow”. Although it might not seem useful now it probably is when the user gets a yellow promotion t-shirt sent home to his house. In this case we know that the user had the color updated correctly and that the problem is downstream.
• Differentiate between instances
  If you have multiple instance of a object. It is crucial to know which one is doing the logging. “User changed favorite color” doesn’t tell you which user object now has a now favorite color. Better is ‘”User ‘Anders’ changed favorite color.”.
• Include details about the endpoint when logging about communication
  ”Unable to contact server” doesn’t tell you much if you are talking to 10 different servers. “Unable to create user on remote server ‘192.168.1.1’ is better.
• Don’t log sensitive data
  What’s sensitive data is up to you but passwords are a big no no.
• Use common id in the output to create a flow.
  If several operations are performed as a result of a single user action it can be a good idea to include a common ID when logging the operations. This is very useful if the operations are not executed in sequence by the same thread. In addition, if something goes wrong then it might be a good idea to show this to the user so it can be provided to support for investigation.

A benefit of working as a software consultant is that you get to see how differently companies work in terms of practices, processes, management etc. However, one thing that I’ve found to be common is that most development teams are lacking one particular set of skills. Despite that team members are carefully chosen for their particular competences one person is usually left out. The only exception to this observation seem to be when the application is targeted at end-users where competition is fierce. I’m talking about the usability guru.

Perhaps this is rooted in the fact that many product owners do not see any clear business value in usability, especially if the app is to be used with in their own company. Requirement specification rarely contain any concrete testable requirements that has to do with user experience. Too often usability activities are filed under the “nice to have” section far down in the spreadsheet. If there is time at the end of a project some of the tasks might actually be completed but usually new features are favored instead. With these priorities it is no surprise that when the time comes to man the project there is no need for a usability specialist. In the end it is the tradeoff between cost and usability that is the problem.

These priorities are wrong. In fact I’m quite convinced that if usability activities are a part of the whole design and implementation of an application that there is time and money to be saved both for the development project and the receiving organization/customer. To achieve this you need to start manning projects with a developer with usability skills. So – here’s the case for his/her existence.

Usable functions save time

A feature can be implemented in many ways and believe me – most of them are pretty horrible. Designing a feature in such a way that a user can effectively carry out their task can yield big savings in time for the users and their organization. The difference in effectiveness between two implementations of a feature could add up to massive amount of time in the long run. Remember that a particular use case can be executed daily by hundreds of people for the full life time of the application.

Its easy to do the calculations in order to build a business case for improving the usability for a particular feature or use case. Take the number of users multiply by the frequency of use and the savings in terms of time if implemented a different way.

The hard part is of course finding a way that makes it easier and faster for users to perform a task. To be able to this you have to have a understanding of your users, you have to know what they are trying to accomplish, what their underlying motivations and what information they need and so on. Only after this is achieved then can you creatively come up with new ways of doing things. Who has the experience and know-how to make this visible to product owners? You guessed it – the usability specialist.

Experience counts

Just as an experienced solution architect would steer a project in the right direction so would a usability specialist. Time and money would be saved by avoiding common pitfalls drawing from experience in similar projects.

A person with interest in usability would of course be familiar with different interaction patterns and knows where they can be applied with most benefit. He/she effectively evaluates designs with pen and paper to identify potential problems early and formulate strategies to mitigate these.

Of course anyone can make a UI but only a few have the interest and knowledge to do it efficiently. Manning a team with the usability specialist will prevent time spent redoing the UI because of bad choices from the start.

Keep users focused

Interfaces that don’t get in the way and look good keeps users happy. How many times have you used an application that get you aggravated almost to the point that the keyboard got a proper bashing? How much time is spent looking for that feature you know is in there somewhere, how much time is spent trying to reverse the result of some function you accidentally triggered, how much time used to talk to the colleagues about how bad the application is behaving, how many quit because they can’t stand the application any longer?

On the commercial side, a risk with shipping a subpar UI is of course that it can cause badwill. Needless to say, it won’t have an positive effect on how well this and future applications sell.

Despite that the actual cost of unhappy/unfocused users is hard to quantify it is still something to take seriously never the less.

Wrapping up

Usability is just as important as any other discipline in software development – if not more. To users the interface is the application, it doesn’t matter if you architecture rocks when the UI looks like early version of Netscape. Now, there is business value in good usable applications it just takes a someone knowledgeable in this area to do the math for you. Manning teams with a developer that has an interest in usability is not much more expensive and it’s a good start to make the whole team think about usability.