Universal Mistakes cause users to be unhappy

Apps may survive having a few of these problems, but maybe they are getting 2 star reviews or poor user engagement.  Users don’t know why they are not happy in most cases, but the result is that they are leaving bad reviews and not engaging with the developer.

Passing certification is not enough

There are a number of small things that don’t cost much in terms of time or effort.  You will spend far less time than you did building your app, and will help get more people to be happy with your application.  Spending some time polishing your app goes a long way for customer satisfaction.

Windows 8 App Mistake #10

Default Splash screen and icon should never be left at the default.

Even most users know this is the default icon by now.  It will actually fail certification now, but it was allowed for a long time. 

Establish a brand through color and iconography. The start of the app, and the way it looks on the start screen, are important ways to establish a color theme and brand with the user.  They need to start to identify your brand when using your products.

Don’t include your app name in the icon, Windows already has a great display of the text name for the package.  It is ok to include your app name or company logo on the splash screen, but really try to showcase the app.

Windows 8 App Mistake #9

 DeveloperAppNameDoesntWork

End users don’t want to read camel cased naming, and it also makes it impossible for search engines to get the individual words out of that mess.  You want to make it easy for people to find your app, not hard.

Here are some quick tips for your app naming:

• Make sure the name fits under a small tile.
• Make sure you modify the app properties to include a nice name – takes a few minutes
• Abbreviations are ok, as long as the user learns them.  This is how they will search for the app from the start screen, so make it memorable.
• Don’t use another apps name in yours (Flappy Bird, Clash of Clans, etc).  Don’t get a takedown notice because of your name.

Windows 8 App Mistake #8

Keywords are precious.  Don’t use your app name as a keyword in the app store.  The name is already included in the text results, and has a heavier result weight than the keywords.

Additional hints for keywords:

• Use phrases if users are likely to search on them (Doesn’t have to be a single word)
• App marketing around chosen keywords
• Use those same keywords in tweets, blog posts, etc about the app
  • For the app shown I would put a tweet that says Disney Family Trivia app. People will search on different parts of phrases they might remember

Windows 8 App Mistake #7

First user experience is key.  You have 30 seconds to grab that user.  Adding an application walk through is a great way to get people over that initial 30 seconds.  Long boring tutorial is NOT the answer.  Allow users to drop out quickly, and then resume the tutorial when they hit a new area of the application.

Hidden features will never be found.  If you have an advanced feature that most users are not finding (see the mistake about analytics, you should know which features are being used!), add a guide to show it to users.  Don’t be afraid to ask the user if they would like to learn more about something in the app.  These type of just in time training within the application allows users to expand their knowledge of your application over time.

Seriously consider adding a what’s new guide for each new release.  Especially if you have added new features that may not be obvious to the user.  You need to guide them to find the features you work so hard on implementing.  Don’t assume users will read the update notes in the store description.  Most never go back to the store and view your app once they have it installed.

Additional tip for the first 30 second experience

Hand your app to someone who knows nothing about it.  Watch them for the first 30 seconds (no talking, no pointing, nothing!).  It will be painful to watch them explore the app and wander around, but you will learn a lot about how users experience your app for the first time.

Windows 8 App Mistake #6

In app advertising should appear to be a part of the application experience, not a banner ad!

Users do not like ads, especially banner ads.  Don’t put them in as banners or users will ignore them.  Remember that Bing Ads for Windows 8 do NOT pay per click, so just showing them on the screen is enough.

Look at the Bing Sports, and Bing Finance apps that ship with Windows 8 for good example of how to make the ad a part of the content without being obtrusive. 

Additional thoughts around advertising

• Never put an ad where users can accidentally click on it (makes them mad)
• Give a way for users to buy their way out of ads
  • $1.99 to remove ads will make more money than you would off showing them ads
• Consider using multiple ad networks to rotate through ads and avoid low fill rate issues
• Create ads for your other apps to show when offline or no ads returned from ad network
  • Always have something to show, and highlight your other apps!

Windows 8 App Mistake #5

Ship regular updates to your apps.  This is your chance to engage the users, provide feedback to them on progress, and just let them know the app is alive and well.

After shipping an update with lots of user downloads you may see yourself in the “New & Rising” category of the store.  It is not automatic, but based upon the number of users who download and run the update.

Users get bored with perfectly working apps that are never updated.  How else do you explain so many Twitter clients?  Users are always returning to the store looking for new clients to their favorite services.

Update your store screenshots

Would you use a sports app for your favorite team that shows a season two years old in the screen shot?  Update those screen shots if you have time sensitive content in them as well.

Windows 8 App Mistake #4

Capture user feedback. If you don’t give users a way to interact with you they will choose your marketplace reviews to do it.  That is not where you want to get negative suggestions or feedback.  Always give users a way to reach out and interact with you.  They will feel more empowered and a part of the community for the app.

I always create a twitter account for each of my apps (or group of apps in the case of sports apps).  That allows me to interact with users, and I put it the handle in the splash screen.  I get tweets from users, followers, and most important thing to me is the community it gives to the app.  I have tried using twitter as a way to broadcast to users (show them at app startup) with mixed success.  It really depends on the type of app you are building.  But always give a way to get feedback, even if it is just a launch to the mail client using a generic app email address.

Windows 8 App Mistake #3

Paid app, with a free trial that never expires.  This has to be one of the worst strategies to monetize your app.  You want to get free users, then put the app in the free section.  If you want people to pay only when they like it, add an in app purchase to “support the developer” or something like that.  You will get 10x or more downloads from the free section of the store, and that larger base of users will mean you make a lot more money.  Free apps with ads, and an in app purchase to remove them will make more money than a free trial of a paid app.

A paid app without a trial will never succeed.  But a trial should be just that, somehow limited or expiring at some point.  Free trial forever just makes no sense.  Trial apps are unique to the Windows platforms, and they do have their place, but not without limits.

Build a minimum viable product

Imagine instead you have a free app that includes basic functionality, this is your minimum viable product.  Maybe it doesn’t support live tiles, or notifications, social features, or online backup.  These are all things you can charge for outside the base functionality.

Then app four or five features that not everyone will use, but they have to pay for individually.  A few users will buy them all, but most will only buy what they want.  This gives you a huge base of free users, and you will make more from those who are willing to pay for features.  Three $1.99 purchases are worth more than a single app purchase as well.  You can then also engage the users and add features they request, for a fee of course.

I have much, much more to say about monetization, but I will save that for a future blog post.

Windows 8 App Mistake #2

Live tiles should be…  well, alive!

Never include a tile to the app that does nothing.   Make users want to launch the app!  Give them a call to action.  New news is available, your friend replied to you, come see the latest sales, etc.  All of these call to actions make a user want to launch the app

Notice the image here is all tiles for Bing Finance to different stocks.  Each has information that is valuable without launching the app, but clicking on it takes you directly to that stock, not the general finance start screen.  This is known as deep linking.

Deep linking

The stock tiles are a good example of this in action, but there are many others. If there is a feature that users use frequently and it is not on the launch page of the app you should include a way for users to launch directly to it.  Think about 4 square as an example.  Most frequently users are checking in places.  If you had to launch the app, navigate to check in, and then press the location that is too many steps.  Create a tile called check in and let the user get straight to that spot in the app.  These type of interactions are also unique to Windows devices, take advantage of them!

Tile Sizes

Never create a double wide tile without having some sort of dynamic content.  You are just wasting users screen space.  Leave a single width tile for static content.  Also don’t forget that the extra small tiles can only show little badges, no content.

Windows 8 App Mistake #1

In App Analytics are not optional.  There are truly free options available for any size developer up until you get millions of users.  So there is no excuse not to use one of these services.

Example of questions you should always be able to answer:

• How many users are still running version 1.0?
• Do users use feature X?
• How many users run the app in snapped mode?
• Does anyone create secondary live tiles?
• How long does the average user spend in your app?
• Do you have any unhandled exceptions in your app?
• How many users have actually run your app this month?

I have articles on the blog covering how to add these types of services to your apps with services like MarkedUp.  A basic version checker and number of users can be done in minutes.  Getting features and screens instrumented can take a little longer, but more less than it took to build those features.

Thank you

Thanks for reading this far down the list!  Hope this was super useful to you and you will take some of these suggestions to heart.  I have seen apps that implemented all of these go from being 1 and 2 stars apps to 4 stars.  The app was solid to begin with, it just needed some polish to make it more engaging to the users.

Proof of Concept Code

Several of our proof of concept (POC) projects have already been published to Codeplex Azure Business Scale POCs.

Enable NuGet to download missing packages

In order to build the packages from the proof of concept projects you will need to enable NuGet to get the missing packages for you automatically.

From the Visual Studio 2012 Tools | Options menu choose the Package Manager treeview item and then select the Package Restore.  When you build the project for the first time NuGet will get the packages automatically.

Where did this come from?

I spend a portion of my job working with large partners to help them architect their applications to run in Windows Azure.  Usually they are coming from an on premises application that was not built for scale out.  One of the most helpful patterns I use is the Queue Centric Workflow pattern.  I have collected email snippets that usually occur after the first design session.  I thought I would collect them in one place to share with partners, and to hopefully help others.

A key aspect of building scale systems is to ensure your application state is kept outside the individual application components.  Windows Azure provides a very robust, scalable queue system built on top of redundant Windows Azure Storage.  This becomes a key to almost every application design I work with today.  Taking advantage of storage services is not covered in this post, perhaps I will go into that in a later post.

What is this pattern?

The Queue Centric Workflow pattern is an essential pattern for loose coupling of cloud based applications. This pattern is a subset of the Command Query Responsibility Separation (CQRS). Reliable queues are built into Windows Azure.

To use this pattern an object should generate a queue entry for work to be completed asynchronously from the primary application. The following challenges are overcome by using this pattern:

· Application decoupling across tiers, but all tiers collaborate using external Azure Queue / Tables

· Application needs to guarantee at least once processing for messages

· Ability to scale processing nodes deterministically based upon amount of outstanding work

There are a lot of other patterns which can be used in conjunction with this one, but I am primarily focused on using queues in this paper.

Azure Storage Queues are Reliable

The Azure Storage Queue is a reliable queue due to the underlying Azure Storage service. The queue data is always persisted across three nodes, and allows for hundreds of calls per second.

The queue itself being reliable does not inherently make your application more durable, your application design still must take into account failures. These failures may come from dependent services, or your own software.

Receiver Asynchronous Processing

The Queue Centric Workflow pattern may be used in many situations where loosely coupled asynchronous processing is desirable. Commands are sent as messages via a queue, which are turn processed on receiver nodes. Receivers may be located on separate physical services, or may be running within the main application. A key tenant is that the queue messages are outside your application and will survive the failure of your app.

The queue has a few very simple operations, remember that the service is just a series of REST calls. The queue is then polled periodically by receiver which will then process the messages. The queue itself is a FIFO queue, but the messages are not processed in order. A message that was returned to the queue from a failed node may be processed out of order from other messages. Do not use the queue as an ordered communication device!

Key operations on messages include:

· Enqueue (put) – Add a message to the queue

· Dequeue (get) – Get the next message from the queue without deleting it

· Peek – Look at the next message without processing it

· Update – Messages may be updated to change their invisibility timeout, or the message

Invisibility Window

Each message, upon being pulled from the queue, is invisible to other receivers for a period of time. This is to ensure that the message is successfully processed. In the event a receiver fails/crashes while processing, the pulled message will become visible again after some time and can be picked up for processing again.

Your receiver application should follow a process similar to this while operating:

· Get next message from the queue

· Verify the message has not been dequeued too many times (see poison message handling)

· Periodically update the queue message during processing to extend the invisibility window

· Delete the message from the queue if it was successfully processed

At-least-once processing

By following the above pattern for processing messages you are ensured each message is processed at least one time. That may seem strange at first, how can messages be processed more than one time? If the machine processing the request is rebooted, crashes, or otherwise fails to complete the processing of the message it will be returned to the queue and another receiver will process it.

Idempotent Processing of Repeated Messages

Since a message may be processed more than once, your application will need to handle that scenario. Idempotence is a mathematical property that says an operation must have the same visible result despite having an operator applied to it twice.

For example if an operation must generate a thumbnail of an image it doesn’t matter if the operation is run twice as long as the same thumbnail is output. There are operational wastes in running the process twice, but the end user will never know it was run twice.

This is true of many messages in decoupled systems. If the message was processed, or partially processed, once it may still have been put back on the queue because the original receiver crashed after they completed the task (and had not yet deleted the message).

If an operation is critical to being processed exactly once additional business logic will need to be included in the application to handle this scenario. Most application logic assumes running for the first time, and additional code may be needed to handle validating stages of processing in a larger task. If this is required the original message may be updated at each stage with a checkpoint marker (“step3” for example) to let a subsequent caller know how far the original processor got with the message.

Poison Message Handling

In some cases the message may be causing the receiver application to crash either due to a code bug, or malicious intent. In either case the application must decide how many times to retry the processing before flagging the request as bad.

This topic ties in directly with Idempotence Processing. An application must ensure that processing of a message twice would leave the system in the same state as if it had only been run once. If this cannot be ensured than any message being dequeued twice would need to be flagged as bad.

A typical implementation would flow something like the following:

· The receiver application pulls a message from the queue and checks the dequeue count

· Check if the message has been attempted more than 3 times, or if the receiver finds a previous output with a crash dump. In either case the message is removed from the queue and placed into a bad message queue.

Poison messages are typically deleted from the primary queue and inserted into a bad message queue (this is sometimes called a dead letter queue because it can’t be delivered successfully).

Scaling Processing Nodes

The size of the queue, and the amount of time required to process each message are useful properties to use for scaling receiver nodes. The receiver application can calculate the time required to process a message and place the result in a shared table. Some application patterns do not lend themselves to a deterministic processing time and may not be able to use this as a metric. Many applications are able to use the queue size to estimate the processing required and determine when to scale up more receiver nodes.

Microsoft provides the Microsoft Enterprise Library Autoscaling Application Block (WASABi) to assist developers in scaling their applications. The application has the following key benefits:

· Allows the graphical Enterprise Library configuration tool to manage configuration settings

· Allows configuration of application blocks though storage locations and logging mechanisms

· Allows application block customization by adding custom autoscaling rules and actions

Use of the application block is not required, however. Developers are free to choose another solution for scaling their application. Some form of auto scale is desirable in many situations where the load can vary, simply to save the company money on consuming resources that are not needed.

Watch out for Money Leaks

Most cloud applications need to balance the need for quick processing (performance), with the real world demands of running resources (costs). Most applications will have to strike a balance between these two. Some ideas to look for are deterministic time periods of load (maybe first thing Monday morning), or periods of inactivity that are predictable and can be used to scale back an application.

As of this writing 1 million storage transactions cost $0.10 (see Azure calculator). Each transaction for a queue operation counts towards that storage transaction (remember that queues and tables are both part of Azure Storage).

Attempting to dequeue messages when there is no work to be completed will still cost you money. Consider adding some form of step off after an unsuccessful dequeue operation to ensure you are not leaking money within your application.

Exponential Backoff is a commonly used pattern to wait longer and longer after each unsuccessful attempt. Applications that do not implement some form of delayed retry handling will waste resources on Azure, and cost the user more money than is needed for operations.

Summary

I hope this paper has sparked some thoughts in your mind about your own applications. There are many papers and books on the topic of Cloud Architecture and scaling. I have a few broad recommendations for topics you may want to research further.

Decoupling of application tiers – This is very important for cloud applications to ensure a backlog or outage in one tier does not bring the entire application down. It also allows for bursting of the layers that need additional resources, rather than requiring all tiers be scaled.

Guaranteed Processing – All message based systems need a good way to ensure all messages are processed at least once. Windows Azure has really good reliable queues for this purpose. You may want to research how other distributed systems handle messages.

Example Application Design

The above diagram is an example of using an Azure Queue to control Worker Roles during processing of input.  A full write up of this architecture is provided in the blog post Proof of Concept to test scalability of stream data processing in Azure.