How to respond to bad apps?

Update: In response to comments below and on Twitter, I've tried to clarify things better below.

What do you do when you find a bad app?

• Engage with the developer to report why?
• Leave a negative review?
• Leave a low rating?
• Uninstall it?
• Just never launch it again?

What do you do?


I've started leaving 1 star reviews to bad apps, rather than just ignoring them.
I figure this helps serve as a warning to others who may download it.

If I know hte develoepr I'll talk to them but I just don't have the time to talk to everyone :(

Do you consider reviews when downloading an app? Is lots of bad reviews worse than no reviews?

I'd love to know your thoughts...



I also uninstall it, but that's just because I've got hundreds (not exagerating) of apps installed and I don't want the clutter.


Of course, if I come across an app which shouldn't be in the, marketplace in the first place I report it.




If you are/were the developer you'll want direct feedback, not a negative review.
That's a given. 
But what if we're talking about another persons app?
Imagine the app has so much wrong with it you don't know where to begin and haven't got the time to get in to a long discussion about why that's the case and all the ways the app could and should be improved.
This leaves 2 options:
1) do nothing
2) leave a low rating

In this scenario, what do you do?
If you do nothing then my theory is that there's a greater likelihood that someone else will waste part of their life tryint to use that app.
If you give a low rating they may think twice.


Yes, in an ideal world there would be the time to help everyone make a great app and developers would avoid the situation in the first place by taking the time to understand what makes a good app and to test their designs, assumptions and quality prior to releasing it. Unfortunately a quick look at any marketplace reminds us that we're not in a perfect world though.

Yes, if you're the developer you'll want a detailed description of why you've got a bad review but reviews aren't written for the developer. They're written to help other people get a feel of what other users think of the app before they download it.
If you're a developer of an app and you're getting bad reviews and don't know why then it's your responsibility to go and find out why. It's not the responsibility of the person giving the review.




 , th

Your app sucks and now I know what to do about it

The Windows Phone marketplace is a semi curated environment. This is both a good and a bad thing.

It makes the app submission process fairly reliable and keeps the very buggy and inappropriate apps out.

It does, however, require a human element in the certification process that can be subject to inconsistency and error.

Sometimes apps pass certification which shouldn't have. This is separate from any quality judgement, I'm referring here to apps breaking the marketplace rules and certification requirements

Fortunately, there is a place to report such occurrence: Reporting a Concern about an App in the Marketplace

If you're interested in and concerned about the general quality of what's in the marketplace - presumably because you want to see high quality, predictable apps which bring value to the overall ecosystem then I'd like to encourage you to report any such apps that break the certification rules too.

!!! This is not a place for reporting "bad" apps, just ones that break certification rules !!!

This isn't a substitute for also reporting such issues to the creators/publishers of such apps and engaging with them also. So that they can address the issues and learn what they shouldn't be doing.

13 ways to improve the performance of your app

There are lots of ways you can improve the performance (and the perceived performance) of your app.
This is not a complete list, just what came to mind right now.

The important (though unfortunate) thing to take from this is that great performance doesn't come easily and there are lots of things you can (or have to) do to give your users an awesome experience.

Note that some MVVM purist may dispute some of these but they're based on real world experience.

1. Get off the UI thread - Don't use it when you don't have to. Keep the UI responsive.
2. Don't use value converters - They have a much greater performance impact than direct properties.
3. Don't use dependency properties when you don't need to - If regular properties will work for your needs then keep it simple as they're much faster to read
4. Have fewer external dependenices - Loading fewer third party libraries saves time
5. Split up your assemblies - Don't load all the pages (and code) in your app when you don't need to
6. Cache images (and data) - Downloading external resources takes time. Don't repeat it unnecessarily. The same goes for processing or reformatting data.
7. Use a "boot loader" - If you have a large app or a complicated start up process, only have the bare minimum in the app and push everything else to separate assemblies. This will help you get as animated loading page up as quickly as possible.
8. Preload/prefetch data - If you can, get the data before you need it so that when you do need it the user doesn't have to wait.
9. Lazy load data - If there is a large amount of data, only load it as you need it. Don't waste time forcing your user to wait while it's all loaded.
10. Reuse [data] templates (load less xaml) - Loading fewer templates is faster. Make sure you don't reload the same ones repeatedly
11. Have less XAML - Don't use any more XAML than you need to. I often see slow apps which have unnecessarily complicated, nested controls when the same thing coudl have been created with fewer controls.
12. Avoid nested margins - Reduce the amount of work the loyout engine has to do measuring the elements in creates.
13. Don't use XAML - Yes, it's extreme but you can get better performance from a UI created in code than in XAML (you save the parsing time) This can make supporting the code and making changes harder though.

The above has helped me in the past. Hopefully it may help you too.

In the interest of balance: 101 Reasons Not to Buy A Windows Phone 7.5

I've been alerted by Tomi Ahonen about a list of 101 reasons NOT to buy a Windows Phone 7.5.

My initial response was to roll my eyes but some of it is insightful about how some people are perceiving the platform.
There's a few points I'd disagree with and plenty that are purely criticisms because it's not the same as other devices or platforms.

It seems to have been written by a disappointed (frustrated?) Symbian user.

What I know though is that I like it ;) and only one person I know who's used a WP device didn't like it, compared with many who upgraded from or changed their plans to buy an iPhone after using mine for a short while.

Diversion over, normal developer related content will resume shortly.

BitsPerPixel and 256MB devices

At some point (I think it was with the mango tools release) we gained the ability to specify that an app should use 32 bits for each pixel when showing a color, compared with the default 16. This enabled the ability to show smooth gradients and avoided "banding".

It just takes a setting in the manifest file.

Based on my experiences with the new 256MB emulator (which is included with the 7.1.1 SDK update) the new, lower spec devices don't appear to support the 32bit option. This would make sense as it would mean the device would need to use less memory to load/display the image and could also mean a cheaper screen.

This is currently only tested in the emulator but as soon as I can get a real device I'll check there too.
Do you have a device you can check this on? If so, do you see this behaviour?

Need to do some dithering of images to wrok around this? Check out http://adtsai.blogspot.co.uk/2011/03/high-quality-dithering-for-windows.html