FindaPad is the first App to be built from the ground up using the WP7Contrib. In fact, the process of building FindaPad led to the creation of the WP7Contrib. FindaPad is a property searching experience that provides users with the ability to view the available properties in a chosen area and also allows users to gain a better understanding of the facilities and demographical information of the area. It’s more than a list of properties.
My plan is to do a small series of blog posts that cover off particular areas that caused some degree of pain during the experience of creating FindaPad. The solutions for such problems have been added into the WP7Contrib allowing other WP7 App creators to use these building blocks and enable them to create high performance, and high quality apps faster.
In this post I want to take you on a journey through the App and touch on some of the more technical aspects of what’s happening behind the curtains. I will also cover off some of the UI interactions and layout used and the reasons why.
The initial startup screen was designed to be as simple as possible allowing the user to immediately start searching for properties. We also took into consideration recent searches. This area of functionality moved around a bit, it was also ditched at one point, and then finally reincarnated and came to rest on this initial page.In order to keep the page clean, on initial startup we decided to hide the recent searches area, as it provides no real useful information at this time and leaving the recent search title on the page was confusing. Recent searches is therefore only displayed after the user has started searching.
In order to perform a search the user has a number of options; search by current location; search by postcode; search by place name; and if you really want to then you can use a Latitude and Longitude. Repeat users can use the recent searches area to jump straight back to a previous search. The page does have some other options in the app bar which, provide quick access options. Remember this is all about navigating as efficently as possible – because of this we have provided a settings and favourites button. Functionality needs to be thumb friendly. Again, the controls moved around a bit during iterations but they now live on the home page to cater for the repeat usage scenarios. We could have removed the favourites button on initial startup however we made the decision that adding buttons to the app bar was confusing. Stateful buttons are cool and great for feedback.
For this experience the functionality provides the user with the ability to change the country where they want to perform a search and the default check box for Geo Location based apps. The other options provide the ability to change the amount of data that is received by the user based on the type of connection.
A very important note for other people developing mobile applications which take advantage of 3rd party services, is that if you are solely reliant on the emulator then you are living in a false economy. In the real world 3G and Wifi are going to be the most widely used connections. Slower connection speeds will effect the experience that users have when interacting with the app. Testing on the handset and the different connection types are essential for ensuring that the experience is maintained.
Therefore, to address this problem the App allows the user to change the default amount of data delivered to the handset in order to not degrade their experience. In some ways I feel that we could bake this into the app and simplify this experience. However, it’s also helpful for more advanced users. (So it would be great to hear your feedback in order to discuss whether you find these types of settings options useful for data heavy apps or if you feel that that the app should take care of such things.)
The Favourites page, as you may very well have guessed is a list of favourite properties; this view is consistent with the results list in order to provide a consistent look and feel. Selecting a favourite from the list navigates users into the details area of the App. Recently the favourites functionality was redesigned allowing users to view all of their favourite properties on a map.
Once the user has chosen the way in which they want to search for properties, selecting the rent or buy options performs a search and navigates the user to the search results page. The layout of the results was designed to take advantage of iconography in order to help simplify the visualisation of the data. The information displayed is just enough for the user to make an informed decision about selecting a property.
I would have to say that this area of the app took up the majority of time and it’s where app creators can really take advantage of the WP7Contrib. On first glance you look at the list and think well that’s not too tricky; an image some vector graphics and some text. What you then very quickly come to realise is that slamming your UI with data that’s coming from a 3rd party service turns out not to be such a great idea. In one way it’s arguable that the platform should provide better support for this type activity and in the Mango release some of these problems have been addressed.
I have attempted to sum up details of these learnings below, but will also go into more technical details in this series of posts. (If you would like more information I presented at Techdays UK where we talk about data driven Apps on WP7) Originally I started off with a list box and a rather complex data template, which caused a lot of problems. So I simplified the layout and what was being displayed. Converters are not great when it comes to performance; their usage was scaled back and these conversions done in the lower levels of the App. These small tweaks helped with performance but did not cure it. What resulted was an interesting journey of building some reusable components that can be found in the WP7Contrib and I would highly recommend using them if you are building a data intensive App or if you’re seeing performance issues with loading a list(s) of data. By using data virtualisation it provides a far more controlled mechanism that can be used to render data to the screen. These fixes solve the issue around getting data but we still need to improve how UI virtualisation is done and from a high level this comes in 2 forms. Firstly, loading the images is all done asynchronously to help improve load and rendering times and secondly this approach needs to be layered with prioritising which images are in the viewport in order to maintain a responsive experience. Therefore, the App monitors which images are currently being displayed and deals with these before the other images. Those images that are out of view are paused. Once the visible images are rendered, the App resumes downloading of the other images out of view.
The next change was swapping from a list box control to a long list selector control found in the toolkit designed which has been specifically to deal with larger amounts of data. The final, part of the puzzle was controlling when to add more data, the app only updates the UI with more items when the user is not scrolling. With all these elements in place the experience is a compelling one.
Now, why was this so much effort, well it’s all based around the type of experience that I wanted to create where by the user can infinitely scroll the list and does not have to manually say “get more”. I know that we can do better than a “get more” button appearing at bottom of a list, and yes it does result in more work. However, the resulting experience is more enjoyable and means that the user simply keeps scrolling down the list while the app responds by getting more properties.
There are lots of interesting technical details that I will go into in a separate post around what is happening behind the scenes here which should prove helpful to others.
On selecting a property the users are navigated to a details page, originally this was going to be a panorama control but as the majority of the apps that I have built or been involved in building you start out with good intentions. However, due to heaviness of the control this usually results in using a pivot control in place of the panorama.
The details page brings together some of the useful information that helps users gain a better understanding of what the area is like. This information is visualised by using charts. Visiblox chart controls are the ones that we use, they are very lightweight but pack a big punch which means that you can get these charts to render in a pivot control. Sweet!
The details page displays all of the information that we are given from Nestoria. One of the issues of working with 3rd party API’s is that you lose complete control over the data with regards to its integrity, yes we can paginate and create complex queries but we are not guaranteed complete data, and this is illustrated in the screen shot where Nestoria are unable to send details on the number of bedrooms or bathrooms. This is frustrating. However, the sooner we come to the realisation that this is a real world situation and design for it the better. The way it’s done here is to hide the artwork so that when the data is incomplete these are hidden from the user. Selecting the “view on” button navigates the user to the estate agent that has been aggregated by Nestoria. Unfortunately, the information shown on these web pages are not available via the Nestoria API. So in order to retain the user there is a specific page within the app that uses a browser control so that we don’t lose the user. This experience is far more fluid than navigating the user to the native browser where they leave the app and the experience feels disjointed and clunky.
The crime and house price pivot pages contain the visualisation of the information from the UK Police API for crimes in the surrounding area. The Nestoria API provides the data for average prices in the local area. Both charts look great and load in a reasonable time. The line chart is a tricky one. The key is fundamental to understanding the data being visualised in the chart, however in its expanded state and with the maximum number of average prices returned the layout is a little cluttered. I have been thinking about collapsing the key index and expanding when the user touches the index. (If you have thoughts on this we would love to hear them, all for more general thoughts on using charts or data visualisation in your app it would be great to discuss those as well.)
The app bar on this page provides some actions that navigate the user to the other screens; property map; route map; and actions for email; and adding a property to favourites. These options are there to help with the immersive experience that we are trying to create. The experience here is that once the user has found a property of interest there is a stepping off point into other interesting areas of the App.
The property map page visualises the data about the area surrounding the property, and provides the user with different options for viewing different facilities, these include, medical centres; pubs; restaurants; coffee shops; and shopping centres. The idea here is to visualise this data in the most useful way possible and when dealing with properties and facilities the map metaphor works best. There are a predefined set of options here. We are very interested in hearing from users with regards to how useful these options are and if you could customise these would you want the ability to do so.
The route map page is all about helping you get from where you are to the property that you have found. For me this is one of the killer aspects of the app and uses, sensors and services to create a great experience. There are options to change the mode of transport from walking to driving.
And that concludes the journey. As I mentioned at the start FindaPad is built on top of the WP7Contrib and hopefully illustrates the art of the possible when incorporating this into you WP7 app. So, I would strongly recommend that if you are thinking about creating a WP7 to check out the open source project and the supporting blog posts and samples.
Finally, none of this would have been possible without the human compiler Ollie Riches and great design eye of Nick Harewood. They, have some great posts coming up that talk in depth about particular areas of the app.