If you weren't aware, new consumer trading laws concerning online and app-based games come into effect soon.
These changes are intended to protect consumers from potentially misleading, commercially aggressive or otherwise unfair practices.
You can read the practices you should be following at http://www.oft.gov.uk/shared_oft/consumer-enforcement/oft1519.pdf
You can also read the press release at http://www.oft.gov.uk/news-and-updates/press/2014/05-14#.Uuqzt86PM5s
These new laws come into effect on April 1st. That gives you 2 months to get your game in order if this affects you.
Thursday, January 30, 2014
Monday, January 20, 2014
How not to highlight alternate items in a virtualised list
It's a common requirement: highlighting alternate items in a list. There are various reasons for wanting to do this and almost infinite ways to visually represent the highlighted item.
As I've been asked to show an example of how to do this right, I present this simple example.
Grab the full source.
Here's all the CS.
And here's the corresponding XAML.
This code is for a page containing a pivot with 2 items. The first contains a ListBox using the "BadConverter" and the second contains a LongListSelector using the "GoodConverter". The same view model is bound to both lists.
The simple way to do the highlighting is with a converter. In the bad example the converter uses it's own reference to keep track of which items to highlight. (It just alternates the color that it applies to the items as they are realized.) The good example always applies the color based on a property of the item. This will always be the same for each item.
This means that if the lists are scrolled quickly the bad list may end up highlighting items in an order different to the one they are displayed in but the good list will always be highlighted based on the identifying property of the items, assuming that the items are in the correct order.
Obviously there are some assumptions in the above that it's probably good to make clear:
I hope this helps.
As I've been asked to show an example of how to do this right, I present this simple example.
Grab the full source.
Here's all the CS.
And here's the corresponding XAML.
This code is for a page containing a pivot with 2 items. The first contains a ListBox using the "BadConverter" and the second contains a LongListSelector using the "GoodConverter". The same view model is bound to both lists.
The simple way to do the highlighting is with a converter. In the bad example the converter uses it's own reference to keep track of which items to highlight. (It just alternates the color that it applies to the items as they are realized.) The good example always applies the color based on a property of the item. This will always be the same for each item.
This means that if the lists are scrolled quickly the bad list may end up highlighting items in an order different to the one they are displayed in but the good list will always be highlighted based on the identifying property of the items, assuming that the items are in the correct order.
Obviously there are some assumptions in the above that it's probably good to make clear:
- The use of a LongListSelector is only to help remind that the ListBox is deprecated in favor of the LongListSelector.
- The "Id" property is used exclusively for determining the highlighting color. It has no other value. If the underlying property has an "Id" property that represents something else and might not always be in a sequential order, with no gaps, then creating another property ("PositionInList"?) for this purpose would be appropriate.
- The values of the "Id" property could just be "1" and "2" repeatedly. For this example they don't need to increment.
- The "Entry" class could have a property that returns a color and this could be bound to the display. This probably couple the display logic to the underlying view model too strongly. MVVM purists will have very strong objections to this ;)
I hope this helps.
Tuesday, January 14, 2014
Analyzing the impact of when the user is prompted to leave a review
I recently released a new app and as is my way with the apps I release myself I've used it to do some experimentation.
It was a simple app originally created for one person but I've added some new features and released updates based on requests and feedback.
In addition to the requested updates, I've also done some experimentation with prompting the person using the app to leave a review.
Adding a prompt to ask the user to leave a review/rating is really easy and if you're registered with DVLUP then you could get 100XP for doing so.
The way that the "rate my app" code works is that a prompt like the above is shown on the 5th time that the app is opened. If the rate option is not selected then a similar prompt is shown again on the 10th time the app is launched.
I have a fundamental objection to this way of working.
When someone opens an app it's because they want to use it to achieve some task. That task is almost never to rate the app. Therefore, asking the user to do something unrelated to what they are actually trying to do is frustrated and just gets in their way. As a rule, making it harder for the user to do what they want and adding unnecessary steps is a bad thing.
It's much better to ask people to do something to help you if it isn't going to get in the way of, or distract from, what they are currently doing.
While I included the default (prompt on app launch) behaviour in the original version of my app, in version 2.0 I changed it to only show the prompt when the back button was used to close the app.
Now, with 3 weeks of data I can do some analysis of what effect this change had.
What this graph shows is that reviews seem to be more tied to downloads than anything else. This suggests to me that the people who are leaving reviews are doing so straight after downloading the app, rather than in response to the prompt displayed to the app. However, this app has seen a higher level of reviews than other similar apps so maybe the prompts are having an effect.
What this really shows me is that having the prompt shown when navigating away from the app, once the person has completed their task, rather than when the app is launched doesn't have a negative impact on the number of ratings/reviews that are actually given.
Admittedly this wasn't a very scientific study and I'm not tracking the interaction with the prompt in any detail so more could be done there.
Maybe it's too early to really tell the full impact of this difference. I'll keep an eye on it and if there's anything worth noting I'll share it here.
It was a simple app originally created for one person but I've added some new features and released updates based on requests and feedback.
In addition to the requested updates, I've also done some experimentation with prompting the person using the app to leave a review.
Adding a prompt to ask the user to leave a review/rating is really easy and if you're registered with DVLUP then you could get 100XP for doing so.
The way that the "rate my app" code works is that a prompt like the above is shown on the 5th time that the app is opened. If the rate option is not selected then a similar prompt is shown again on the 10th time the app is launched.
I have a fundamental objection to this way of working.
When someone opens an app it's because they want to use it to achieve some task. That task is almost never to rate the app. Therefore, asking the user to do something unrelated to what they are actually trying to do is frustrated and just gets in their way. As a rule, making it harder for the user to do what they want and adding unnecessary steps is a bad thing.
It's much better to ask people to do something to help you if it isn't going to get in the way of, or distract from, what they are currently doing.
While I included the default (prompt on app launch) behaviour in the original version of my app, in version 2.0 I changed it to only show the prompt when the back button was used to close the app.
Now, with 3 weeks of data I can do some analysis of what effect this change had.
What this really shows me is that having the prompt shown when navigating away from the app, once the person has completed their task, rather than when the app is launched doesn't have a negative impact on the number of ratings/reviews that are actually given.
Admittedly this wasn't a very scientific study and I'm not tracking the interaction with the prompt in any detail so more could be done there.
Maybe it's too early to really tell the full impact of this difference. I'll keep an eye on it and if there's anything worth noting I'll share it here.
When there are issues with apps in the store
For some reason, my post on How to respond to bad apps? has been very popular recently. This is quite timely as I thought it might be worth re-documenting how to deal with apps that probably shouldn't be in the store. This subject comes up regularly whenever a questionable (for whatever reason) app appears in the store.
If another app or game in the store infringes YOUR copyright, trademarks or other intellectual property you should report this to Microsoft using the details in MSDN.
If you notice an app "that seems suspicious" (probably shouldn't have got through certification) you can raise this by emailing reportapp@microsoft.com.
If another app or game in the store infringes YOUR copyright, trademarks or other intellectual property you should report this to Microsoft using the details in MSDN.
If you notice an app "that seems suspicious" (probably shouldn't have got through certification) you can raise this by emailing reportapp@microsoft.com.
Monday, January 13, 2014
High ratings - cause and effect
The Windows Phone Developer Communications email in December had a focus on design. The main resources it called out were this list of resources and this article but it also included the below graphic, which highlights an issue I've talked, but not written, about before.
Unfortunately, there are people who see the above statistics as a shortcut to improved ratings. Good/high ratings are a side effect of a high quality, useful app that provides value to the person using it. Simply adding features doesn't automatically equate to an app that will get or deserve higher ratings.
Let's look at each in turn.
Wide live tiles
If an app shows data that is remotely updated and the person will that app installed on their phone will benefit from being able to easily see that content when it is updated, without having to open the app, then having that feature could be very useful. Useful apps get high ratings.
Simply adding a wide tile to an app that will never have new content to show to the user is a waste and provides no use. Adding it will not provide benefit to the user. (Which is why Microsoft recommend only adding a wide tile if it would be updated with changing information.) Doing something that has no value to the user won't improve ratings.
Pinning features
In a large app with many areas to it, being able to create deep links to that functionality can save people time, effort and the need to avoid repetitive navigation to get to what they want is a good thing. Doing good things for users is more likely to encourage them to leave a higher rating.
Regular updates
Regularly releasing updates can be a good thing if it's to release bug fixes and add new features that the people using the app are asking for and will benefit from. Making the app more stable and capable of doing more will encourage a higher rating. It is also likely to appeal to more people.
However, regularly releasing updates that don't fix bugs, enhance existing features or add valuable new features is a waste of effort. In fact it will probably lead to worse reviews as you add more, unwanted features to a buggy app.
Don't just add features for no reason. Focus on creating a high quality, reliable app that provides real value to the people using it and the ratings and reviews will come.