Practical ways to make a basic app better3 December 2013
One of the things about Windows phone app development that appeals to lots of developers is how the tools and frameworks make it very easy to develop basic apps. In this article I'm going to look at one such app and then show how it can be extended and improved to create something better.
Let's consider a scenario that is popular with many app developers and then see how it can be enhanced to be something more than just a basic app. The scenario involves making a supporting app for a website, based on the RSS feed provided by that site. For our example we'll use ubelly.com (now microsoft.com/en-gb/developers). It's a poplar site without any current app presence and its subject matter is likely to be of interest to a number of Windows Phone users.
Building a basic app
Firing up Visual Studio we can create a new app based on the "Windows Phone Databound app" template. Then, with some very minor changes to the XAML and by adding a couple of dozen lines of code we can create something that will download the most recent articles from the RSS feed and display a summary list of them to the user that they can then tap on to view a whole article (I won't show the code as this article isn't about simple code to create a simple app it's about doing something more.)
It's then just a case of adding a suitable icon and a prompt to the user when there's no network connection and we're ready to submit to the store.
Here's how such an app looks: The main page, with list of articles; a details page showing an article; and a simple icon.
Yes, this really is all it takes to get an app in the store. You can see it at http://www.windowsphone.com/s?appid=2c9b6888-dc5a-45ed-b669-2ade25783a6d
Unfortunately, the number of apps that we can see in the store with this basic level of functionality and effort spent on them suggests that for many developers this is deemed to be adequate.
Equally unfortunate but, I suspect, strongly correlated is the number of developers who complain about lack of downloads and positive reviews. I don't consider this a coincidence.
While the above does show that it's possible to create a very basic app quickly, quickly built apps are very rarely what consumers want and if an app isn't what people want they won't download it or give it a positive rating.
By all means if you're brand new to windows phone development and you just want the satisfaction and reassurance of your ability that getting your first app in the store will provide than by all means build such an app. Just don't stop there.
At my most generous I'd describe an app like the one I've just outlined as "basic". It provides only trivial functionality and doesn't even do that in a particularly good way.
Let's stop and consider the user of such an app. Based on the functionality there's really only one use case it supports: looking at a list of the most recent articles and, optionally, reading them.
Unfortunately for the app developer there's already an application on every phone which can do this better - Internet Explorer. Yes, good old IE will let the user go to ubelly.com and view a list of the most recent articles on the homepage. They can then tap on one to read the whole thing.
The reason it does this better than a basic app is that, while the website hasn't been designed for reading on the small screen of a phone, the articles are better laid out than in the app. The app also doesn't include images or other content embedded in the article.
When we look at it like this we've created an app which we're going to have a hard job of persuading people to download. "Please download this app: it's like looking at the site in your browser, only not as good." That's a tough sell, especially for developers who aren't used to focusing on sales and marketing.
Before we dive back into our code and start looking to make improvements it's worth considering some other options that are available.
Creating an application with content that is based, either in whole or in part, on data from some form of syndication feed (RSS or atom) is a very common task and there are tools available that can create such applications for us.
ZipApp (http://zipapp.co.uk/) was created by Microsoft in the UK, with support from Nokia, and allows the generation of both Windows Phone and Windows 8 apps based on syndication feeds.
Windows Phone App Studio (http://apps.windowsstore.com/) was also created by Microsoft and is intended to make it easier to create a wide range of Windows Phone apps based on a wide variety of templates.
Both tools will allow you to quickly create a code base that you can build upon to create an app that is much better than the basic one described above - but be wary of just taking the generated code as is. While powerful, both tools are still in development and continue to be enhanced. As such it's unfair to focus too much on any present shortcomings but worth remembering that generated code should not be assumed to be perfect or the best provide possible app experience for your users.
I recommend investigating these tools further too fully understand all that they could provide for you, especially if you're new to development. App Studio in particular is currently receiving a lot of investment and has ambitious plans regarding the variety and number of features that can be used in the apps it produces.
What are the shortcomings of our basic app and what does a 'better' app look like?
It starts with principles
As we start to look at making a 'better' app it's worth looking at the design principles of Windows Phone and the apps that are built for it.
These principles are:
- Pride in craftsmanship
- More with less
- Fast and fluid
- Authentically digital
- Win as one
These principles aren't intended to just be applied to the visual design but to all parts of the applications design, especially the user's experience with the app.
Let's look at each principle in turn and how the basic app falls short.
Pride in craftsmanship
This principle is about quality and attention to detail. The basic app is far from something to be proud of. Its simplistic visuals don't inspire quality and there is no attention to the details of what the people who will use the app actually want.
More with Less
It's common to hear about a 'fierce reduction' of unnecessary UI elements when talking about designing Windows Phone apps. This is where the idea of 'less' comes from. The basic app definitely has less as there's very little to it. What it doesn't do is allow the person using it to do more because of it. Nor does it allow the app to do more with the content because of the lack of unnecessary items on the screen.
Fast and fluid
People using mobile devices don't like, and shouldn't have, to wait any longer than is absolutely necessary for the information they seek to be available to them. When that information is displayed the navigation between and through that data should be smooth and natural: fluid. Again the basic app falls short on both these counts. The app can be slow to display articles as it requests them from the server each time. It also must do this to allow the user to discover if there are new articles. When articles have been loaded the navigation to view them is abrupt and jarring, not smooth and fluid.
Being 'authentically digital' means being true to the fact that the app is being used on a digital device and not trying to force real world metaphors or interactions into the interface unnecessarily. This is the one principle that the basic app follows, but this is mainly as a side effect of its simplicity rather than a specific design choice.
Win as one
'Winning as one' is an extension of Microsoft's '3 screens and the cloud' strategy. The principle is that an app should be part of something larger than just a singular app on a single platform. This is often simply interpreted as meaning that every Windows Phone application should be accompanied by a Windows 8[.1] version too. This isn't always the case though. Putting that discussion aside, what is clearly a shortcoming of the basic app is that it doesn't maintain any of the brand identity or visual design language from the website. As such it doesn't support the idea of there being 'one ubelly'. Instead the basic app is something very separate.
Practical ways to make the basic app better.
With these principles in mind, let's look at some of the specific shortcomings of the "basic" app and how these could be addressed.
- The biggest limitation of the basic app is that it only works when there is a connection to the web server available. As a phone doesn't always have a connection available, it would be better if the app remembered the data it had previously retrieved so it could be viewed later, even if a connection wasn't available. Adding data caching can also reduce the time between a person starting the app and being able to view content.
- Rather than retrieve the data (articles) each time it connects to the server, it would be better if it only retrieved the data if there was something new to retrieve. Making this change will reduce the time it takes to retrieve data and the cost obtaining the data if it's being retrieved over a mobile network, where data limits and higher costs are likely to exist when compared with WiFi.
- As an extension of the last point, not only do we want to avoid retrieving data when there is nothing new, it would then be better still if it only retrieved the new articles, rather than all of them. If downloading the output of an RSS feed, all data is returned and again this has potential time and cost implications.
- As data may be being retrieved over an expensive, or limited, connection it would also be better if the data that was transmitted was a small as possible. Making sure that we're requesting GZipped data is the obvious way to do this.
- Once the app has retrieved the data it would be better if it presents it in a nicer way and kept, at least some of, the formatting, images and other embedded content of the articles as they are displayed on the website. As the original article has some formatting in its HTML form it is silly to ignore this. With only minor customization to the HTML it can be made to display well on the small screen of a phone.
- Still on the theme of how things look, the basic app has no branding within it and the strong visual identity seen on the website is completely ignored. It would be better to incorporate appropriate branding elements, such as fonts and colour schemes, within the app. Additionally, finding a way to incorporate the 'critter' character into the design can also provide a strong reinforcement of brand identity.
- Currently the content that is retrieved from the RSS feed must be parsed on the device. Because this logic is contained within the application, if it needs to be changed at any time (such as if a bug is found or new formatting is included in the original source that must now be accounted for) then it will be necessary to distribute a new version of the app to address this issue. As distributing an update can take up to 7 days to go through the certification process and there's nothing in the app to ensure that the person using the app has the latest version, it would be better to not have to rely on the app to reformat the content for display. We'll explore this more later.
There is other functionality we can also add to the app to improve the experience for the person using it and provide a richer experience than they could achieve with a web browser.
- As someone who installs the app is interested in reading the articles that are posted it's reasonable to assume that they would want to know when new articles are posted and be made aware of this without having to open the app to check.
- In addition to being made aware of when new articles are posted it would be good if they could be automatically downloaded so that when the user notices the new article (for instance by noticing an updated tile or seeing a toast notification) they did not have to wait for it to download before being able to read it. Of course, if the phone did not have a connection when an updated tile was reacted to then the experience of not being able to view the new article they've just been told about could be frustrating for the person interested in reading that content.
- It would also be better to add some refinement and polish to the user experience of the app, such as by adding appropriate animations to the page navigation and content interaction to provide a more fluid experience and support more of the conventions of the platform.
There are also some windows phone specific features we can make use of:
- Adding the ability to pin a specific article to the users start screen for quick access.
- Adding the ability to have the app read articles to the user with the inbuilt speech synthesizer. (Having the app/phone read aloud is a feature that is popular with people who drive a lot as it allows them to have access to content even when they cannot interact with the phone using their hands or whose concentration is otherwise engaged.)
In terms of what we've defined as better functionality much can be done within the application but there is a bigger change that is required to make a number of these features possible. This is the introduction of a separate web backend to act as a proxy to the RSS feed. It is this new endpoint that the app would connect to, rather than the RSS feed directly. Such a necessity is common for a site which does not already have an appropriate API but only exposes data via an RSS (or ATOM) feed.
This web proxy will do the following:
- Retrieve the raw data from the RSS feed.
- Parse and reformat the articles ready for display on the phone. This way the work need only be done once, on the server, rather than on each phone. (The server will also be able to do the processing faster than a phone could too.)
- Cache the, formatted, data to allow for a faster response to requests form the app.
- Return only new articles, based on the app specifying the most recent article it requested previously.
- Return compressed (Gzipped) responses to ensure the amount of data sent is as small as possible to help save time, money and bandwidth.
While the benefits of having a web proxy in place are fantastic they do come with some negatives that may be worth considering:
- There is a development cost to building, testing and maintaining it.
- There are probably ongoing hosting and data fees for running it.
Having built many such web proxies for data feeds and having seen the benefits that they can bring I can't advocate for them strongly enough. The satisfaction that comes from knowing that a formatting fix can quickly be made and pushed to the server and a bug is instantly fixed for all users, many before they've even noticed the problem, is great. It's also possible to put a potential cost saving against being able to make such a change so quickly when handling the support emails and the implications of negative reviews it may cause are factored into waiting for an update to make its way through the store certification process.
The next biggest change needed to make a "better" app is to add a periodic background agent. This will contact the server to check for new content and download it if any exists. It will then update the live tile and raise a toast notification, as appropriate, to let the user know that there is new content in the app. We'll also add a settings page to allow the user to enable or disable this functionality as appropriate.
Here's how a better version of the app looks. Including a tile showing a pinned article.
This version of the app, which incorporates all the above discussed features, is also in store and you can find it at http://www.windowsphone.com/s?appid=3a48e8fd-a272-4df3-81b0-0419e0caea46
If you try both apps I'm sure you'll agree which is 'better'.
In everything we've looked at so far we've been considering things from the perspective of a developer working with another party's data, as this is the scenario common to a lot of developers. But what if we consider things from the perspective of the party that is actually creating the data?
There are two benefits of having an app that presents content that is also on the website.
- It could help reach a broader audience through discovery in the Store.
- It could help create a deeper connection with readers and encourage more engagement with, and feedback from, them.
The first of these benefits is only likely to be small. Relying on the Store for discovery is very rarely successful but it may help attract a few more regular readers.
It's the second of these points where an app could really beneficial. If someone has taken the trouble of installing the app and is using it to be made aware of when there is new content available these are just the kind of readers that authors/publishers are keen to engage with. If these people are keen to know about content as soon as it is published then they probably have a keen interest in and knowledge about those subjects. Such people also probably have informed, relevant ideas and opinions about those subjects too. These are just the sort of people it would be good to get comments and feedback on articles from. By having a way to gather that feedback within the app there would be another way to help encourage people to provide it. By also having a way to easily submit feedback within the app, combined by the fact that most people keep their phones close to them most of the time it will be easier for them to provide feedback at the point of inspiration should they think of something while reflecting on an article at a later time.
Having a way for users of the app to comment on or in other ways provide feedback on articles would also be a great addition to the app. Just be sure to use the same comments and feedback system that are also used on the website so that user responses are available to all regardless of the way they are viewing the articles.
If the provider of the data is more involved in the app then there is also the greater possibility of them being able to provide more data for it than just a single RSS feed. This could allow the app to include:
- More content
- Older content
- Additional categorisation of content
- Searching for content
All of which could provide a richer experience within the app and more engaged users.
It's probably also worth noting that if a lot more content and information about it (meta-data) was made available then it may be worth reconsidering the information architecture (structural layout of data) in the app to best make use of the additional resources.
Having an app that provides an optimal experience for the user, the developer and the publisher of the content (that is all stakeholders) is what would be the 'best' app that could be created.
A third version of the app, which incorporates the features that would most benefit the content producer is not yet available but I hope you can imagine what the 'better' app would be like with appropriate features added.
I hope that through this article I've been able to show a practical example of how creating something that is much more than just a basic app can be more useful to and beneficial for the user. Additionally, by considering the content provider we can create an app that is best for everyone.
In turn I hope this will help you think more about how you can create better applications and I look forward to seeing them in the store.