#WP7Dev app feedback #3

Following on from my offer to provide some detailed analysis/feedback/review of some apps. Here's some more feedback from another app. It's been anonymized and I've removed a few specific points but hopefully the following will still be of general use.

• Marketplace description: That’s a very long first paragraph. Try and break it into two or more or shorten it. A large block of text can be off-putting and make people unlikely to read it.
• Marketplace description: That's a long list of bullet points. Are the most important/compelling ones at the top of the list?
  
  • Phrase each point the same point. Don't jump back and forth between what the app does and what "You" can do.
  • Don't claim improved usability. Let the users decide if something is usable. If you have to tell them then something is wrong.
  • As an alternative set of bullet points I would suggest something like this.
    
    New in this version:
    - simpler indicating of XXXXX completion
    - easier to change XXXXXX order
    - improved performance
    - improved personalisation
    - simplified editing
    
    
• If the old version of the app won't update, what are you doing to help users migrate data or provide other support. - You want users talking about how you helped them, not that they lost data or had problems.
• When the upgrade nag screen is displayed the screen may looked more balanced if the buttons were of equal size (each half the screen width). I'd also recommend making this message larger and in the centre of the screen.
• You probably also want to avoid displaying the application bar when the upgrade nag screen is displayed. It can be selected at this time.
• The application is very empty on first use. Add something that makes it clear what the user should do.
• You could also consider automatically opening the "New XXXXXXX" screen if that's all the user can do with the application when started for the first time.
• If I select a XXXXXX then the application bar contains a "cancel" option. This appears to do exactly the same thing as the back button. If they do the same thing remove the cancel option as there's no reason to have 2 buttons which do the same thing.
• On the edit screen, there is no need to have colons after labels.
• On the edit screen, the label "XXXXX YYYYY" could just be "XXXXX". Having "YYYYY", in the past tense, implies this is something that has been done which isn't necessarily the case with new items. The shorter label removes the possibility of ambiguity.
• Internationalisation issues aside, I would make the "XXXXXX" box smaller and the "YYYYY" one bigger so they are the same size as the date and time boxes. This should make the screen seem more evenly balanced.
• On the edit screen, the label to indicate if the XXXX is active or complete could be closer to the toggle switch to better indicate that they are connected.
• This label is also quite difficult to see in the light theme.
• I would consider adding a label to the time field as it isn't necessarily clear what the field is for. Alternatively you could provide a default value of "00:00". This wouldn't affect anything in terms of order unless a different time and/or a date is selected.
• As selecting a time defaults to the current time, I would expect the date to be set to the current date if I select a time before setting a date.
• If I enter a description with characters containing descenders, these are not fully displayed on the main page. This particularly affects the "g"s.
• When I entered a phone number in a description it detected the number but didn’t include the last digit in the selected/highlighted number.
• On the preferences screen, the "XXXXX" essentially has 2 labels. You could probably drop the sentence starting "Change the ..." without compromising understandability of the preference.
• The "XXXXXXX" input box doesn't appear to adjust for theme settings and always looks like it as light theme colours applied and this stands out as odd/different when the dark theme is selected.
• The button to add a "New" XXXXXXXX would look more in keeping with the buttons used by the OS and default apps if it was the full width of the page.
• The "Create a new XXXXXX" input box doesn't behave as I would expect with regard to respecting the back button. If it is displayed and I press the back button I would expect the prompt to close, not the XXXXXX selector.
• In the email created from the about screen, you may want to include the version number of the application. This will likely be helpful to you when investigating any reported error or problem.
• When tombstoned from the XXXXXXX screen the selected pivot item isn't remembered. Just a minor point but surprising, and not in a good way.
• On the about screen (in trial mode) the "buy" button is cased differently to the other buttons and so stands out. (And not in a positive way.)

What the developer of the app thought of this feeedback:

I was impressed with both the breadth and depth of your comments. It was extremely valuable that in addition to your direct feeback you provided concrete examples of ways to improve upon it. This made it very easy to actually fix the problems you identified rather than having to wonder how I would go about resolving the issues. The attention to detail in your comments made it clear that you had combed over the entire application which made me much more confident that there weren’t any missed items. Based on your feedback, I will be able to provide a much more polished and meaningful experience for my users which is invaluable.

What do you think of the above? Is me posting these useful to you as well?

#WP7Dev: Application performance and tuning

When it comes to optimising the performance of your Windows Phone 7 application there are lots of things that can be done.

Firstly, ensure you understand best practices:

• Watch this video (form Channel 9) : Inside Windows Phone #03: Optimizing Windows Phone Silverlight Applications
• Read this White Paper: Performance Considerations in Applications for Windows Phone
• Read the performance tips on the Windows Phone 7 Development Best Practices Wiki

Secondly, use the available tools to analyse your apps before releasing them:

• Enable the peformance category CODE_ANALYSIS ruleset in Visual Studio (but only if you have Premium or Ultimate edition).
• Try the profiler in Silverlight Spy (4.0) (works with the emulator)
• Try the profiler from EQATEC

Thirdly, add analytics to your app to understand how it's used and any issues users are actually having:

• Try the one from EQATEC
• or the one from PreEmptive

Got any other tips?

Carphone Warehouse don't understand Windows Phone 7

Today, I received an email from someone asking clarification on the features available on the Windows Phone 7 device they were thinking of purchasing. The information on the Carphone Warehouse website didn't match with what they'd be told elsewhere.
With my FUD sense tingling, lets look at the feature comparison on their website. (Screenshot of comparison below - click for full size.)

THIS IS WRONG!!!!!!

So what is wrong?

• ALL models provide access to the Windows Phone Markeplace.
• ALL models come with at least 8GB of memory. Even if it's not built-in, it's provided via non-removable memory card.
• ALL models come with some apps and have the ability to install more (via the marketplace).
• ALL models support XBox Live gaming
• ALL models have an accelerometer.
• ALL models have the ability to record video.
• ALL models have integrated social networking.
• ALL models come with Microsoft Office Mobile.
• ALL models support Wi-Fi connectivity.

In fairness. The comparison chart was probably just compiled from a list of features specified separately for each individual phone.
In reality. This makes them look like they don't know about the products they are selling.

I hope this clarifies the situation.

My thoughts on the Microkia/Nokisoft announcement.

I've already been asked about this a few times, so here goes.

As someone with an investment of time and understanding in Windows Phone it's definitely a good thing. What it comes to mean in time as the finer details are announced and the implementations of those details are worked out we shall but see.

This is definitely an investment in the future and it will be a while before we see any actual devices because of todays announcement. But, by the end of 2012 there will be millions of people around the world with smartphones running a Windows Phone 7 (or maybe 8?) operating system.

The biggest change I can predict that will affect me in the short term is that Nokia will have a big influence on chassis specs and what was expected for chassis-2, later this year, won't happen and we'll ultimately end up with more than 2 chassis specs for WP7. Amd maybe even more for WP8?


I expect Symbian to still be around for a very long time.

I don't expect today's announcements to have any short term impact on tablet plans for either company. -  For the record I don't want to see WP7 running on a tablet/slate. I don't think it would work. I do think that something else based on the Metro theme could work really well though but it would need to be designed/targeted appropriately/specifically for such a device. (phone != tablet != pc)

3 big questions I have right now though:

1. Will Nokia give up on the Ovi store? or will it be merged with the marketplace-somehow?
2. What does this mean for the other WP7 device manufacturers? Will some of them leave the platform? What about the ones who have yet to release devices? (Micorosoft announced 10 OEM partners when they launched the platform at WMC last year.)
3. What do Blackberry (& WebOS - if there are any) developers think of this? and the seemingly widely held belief that there is now a three horse race?

And a bonus 4th - when can I have a device? ;)

Exciting times!...

For those that have missed them:
The Microsoft press release
The Nokia press release

Being "Authentically Digital" means not being a Skeuomorph!

[Yes, it was a new word to me too.]

Having spoken to a lot of developers about developing for Windows Phone 7, the "Metro" design language is something that is still quite mis-understood.

Today, I read this post about Skeuomorphs which I think is very good explanation of what it means to be "Authentically Digital" and provide "Content, Not Chrome" which are 2 of the principles of metro. Check out the article and see if it helps explain things a bit better?

More about "Metro" can be found in the UI Design and Interaction Guide for Windows Phone 7.

As a #WP7Dev - What I don't want to hear from Nokia!

In case you've been living under a rock this week, Nokia are making a big announcement this coming Friday.

Lots of people are suggesting it will involve Nokia using the Windows Phone 7 OS in some of their smartphones.

As someone who is developing applications for the WP7 platform I would see this as a really good thing. To potentially have many more potential users of the platform would be great.

I have one big concern though: that Nokia use a custom version or fork of WP7 and not the same one as everyone else. This could lead to all sorts of issues that would affect developers, users and the platform. As a developer it's amazingly reassuring to know that if an application runs on one device it will run on all of them. This leads (well it should do) to much higher quality apps, which in turn should lead to happier users. I really don't want to go back to a world of fragmentaion on what we've told should be a single platform.

To be clear, no-one has suggested this as a likely option (AFAIK), and the Nokia using WP7 is still just a rumour, it's just I thought of it-for some reason-and it scared me.

I REALLY hope this doesn't happen. :)

Suggestions to improve a #WP7 game

Suggestions to improve a WP7 game

On Twitter, @mechaghost asked for feedback on the beta version of a WP7 game they are creating.

An example of the game was posted on YouTube. Here it is:



I had a few thoughts, questions and suggestions, so continuing my current practice of providing feedback on Windows Phone 7 applications and games, here, in the hope that it will be useful/helpful to @mechaghost and others also, is my feedback:

• Although it's not shown I wonder about how the game is explained/taught/demonstrated to the user the first time they play it. Are there instructions, a demo, a walkthrough? Nothing is shown so I assume there isn't any. There should be something.
• The sound made by touching on a car doesn't seem appropriate to the action. (Someone also added this as a comment on YouTube.)
• Will you have multiple/different levels?
• If so, how will you differentiate different levels?
  
  • Will there be multiple different scenes/backgrounds?
  • Will there be a way to start with the vehicles already in greater frequency/speed? i.e. Do you always have to start over from the beginning? While the speed that game play increases seems appropriate to first time players I suspect it may get frustratingly slow after multiple plays.
  • Have you thought about ways to alter/enhance game play? Here are a few quick suggestions:
  • Vehicles whose speed can't be changed?
  • "Ghost vehicles" who can pass through others without crashing?
  • Other obstacles on the road? e.g. people crossing-who also must be avoided.
  • "Drive over bonuses" - items that appear on the road briefly and which if driven over award points bonuses or trigger brief periods of some other functionality. (Maybe from this list.)
  • The ability for vehicles to turn at a junction? Indicators on the vehicle could indicate this intent. This would require a greater level of player observation and planning where vehicles are headed and how to react accordingly.
  • Could you add traffic lights which, temporarily, stop traffic from a certain direction? Obviously these would only operate occasionaly or else would defeat the precept of the game. Maybe they could come on as a form of temporary bonus?
  • Add a night time mode - where you can just see vehicle headlights and a small area around street lamps? If a game goes on for a very long time this could be enabled automatically. Or this could be set based on the local time of the person playing the game. i.e. The game goes in to night time mode if it is night time where I (as player) actually am.
  • Could you add a help/basic mode which includes an indicator of where the next vehicle will enter the screen? This may help beginners.
  • This is purely speculative but when thinking about getting further in to the game, and there are more vehicles moving around, I would imagine there would be times when I'd also want to slow a vehicle down. Have you thought about this? I would expect such to require careful testing but could be worth considering/investigating. Obviously adding an appropriate gesture for this isn't immediately obvious. How about swiping backwards (against the direction of movement) of the vehicle in question. This could still leave a standard tap to speed a vehicle up. THIS WOULD REQUIRE CAREFUL USER TESTING!
    If this was successful you could also consider tap and hold to completely stop a vehicle. (Releasing the hold would start the vehicle again.) Stopped cars would need to be careful of being hit from behind!

Please note that the above is just based on watching the video (twice). I could/would provide a more detailed review/feedback if able to actually use the game and spend more time with it.

I hope this is useful. Let me know in the comments, or on twitter.

If you would like my feedback for a game or application that you have developed or are still developing, please get in touch.

Update: I've had a great response to my offer and so cannot accept any more apps to review just now. Sorry. Maybe I'll accept more in the future.

Let me help you improve your #WP7 app or game

For a limited time only, I'm offering you the chance to have a free review of your app. All I ask is that you let me share: an anonymized version of my feedback/comments/suggestions; and any quote from you on the value of the feedback, here on my blog.

Why am I doing this:
1. To help improve the general quality of applications.
2. To share my knowledge with those who have created the applications being reviewed.
3. To share my knowledge with the wider development community - hopefully, at least some of, my suggestions will be relevant to other apps too.
4. To prove to myself that I do know what I'm talking about and can provide useful feedback.

This is a limited time offer. - The length of the offer will likely depend on uptake. ;)

Update: uptake has been great. Offer closed. - for now at least.



As an example of what you might expect, here is an anonymized* extract from the feedback of a recent application I evaluated:
* Identifiable labels and text have been removed and replaced with XXXXXXXX.

- Don't use the default splash screen image. Use an image appropriate to your application. Not doing so shows a lack of professionalism and knowledge and appreciation of the platform. It's also a wasted branding opportunity.

- Have something useful in the application for first use. Your application currently shows an empty screen when started for the first time and no clear indication about what the user should do. Based on the default behaviour for a pivot layout the user will probably swipe to the right. If they do this then next 2 "screens" are also blank. This may lead the user, on first use of the app, to suspect a problem with the application or at least be unsure as to how the app should be used.

- In the application bar for every screen you have a help button. Clicking this take the user to a pivot screen containing information which would more usually be seen on an "about" screen.

- The help/about screen is very text heavy and is therefore unlikely to be read fully.

- The email button at the bottom of the help/about screen doesn't make clear the action that will be taken when it is tapped. Expect the user to scan the screen when it first loads. Their eyes are likely to be drawn to the button as it stands out on the screen but it's current label ("E-Mail") prompts no clear action.

- Yes, the second paragraph on the page explains what the "E-Mail" button is for but the potential confusion and 4 lines of text could be removed from the page if the button was relabelled "send feedback" or something similar.

- The repetition, on the help screen, of the application name and version number is unnecessary as this information is at the top of every page.

- In the email you generate for the user to provide feedback, I would recommend including the version number. This will help you confirm which version of the application the sender is referring to. This can help if the email is about an issue you have fixed in a newer version (or thought you'd fixed but may still be occurring).

- As accessing "about" information is a secondary function I would also recommend moving it to the application bar menu, rather than having a button/icon for it.

- The inclusion of about/help information on a pivot item breaks the standard navigation model. As a user, I would expect to be able to return from the display of such information by pressing the back button. In your case this closes the application. A surprising and potentially frustrating action. Especially if unsaved information has been entered.

- It is typical to display the help/about information in a separate page or as a popup on the existing page. This would avoid most of the issues identified when adding a specific pivot item for this.

- When navigated to the help pivot item you should also close the SIP if it was displayed prior to navigating to the help pivot.

- When navigated to the help pivot item you should also remove the save application bar button as pressing it when "help" is displayed can cause messages displayed which aren't relevant to the current (help) screen.

- The convention for pivot item header text (and recommended in the design guidelines) is for all text to be lower case. Your application stands out (& not in a positive way - it's just different) because of this. If you're going to be different you should have a good reason for this. To not do so shows a lack of understanding in the platform. This may raise concerns in terms of application reliability and quality in the mind of the user.

- There are 2 ways to get to the XXXXXXX screen. Depending on the method used, different application bar buttons are made available but there is no difference in the functionality available on the screen. Having some options missing could be confusing to the user and may cause problems if the user needs the missing option.

- Clicking the delete button when no details have been entered causes the application to crash!

- It's unnecessary to add colons next to the labels you have next to textboxes.

- You use the abbreviation "XX" on various screens but do not ever say/show what this is short for. Use the full name somewhere so that it is apparent to all users.

- The magnifying glass image is used on the XXXXX screen but not for the defacto standard of providing search.

- The XXXXXX screen includes an image which looks like it should be a button but tapping it does nothing. Why is it there if it does nothing? Not doing anything makes me (as a user) suspect that it's broken.

- The field XXXXXX suggests that it requires a number to be entered. If this is the case, use the appropriate input scope (probably "Phone Number") to help the user enter this.

- I assume that the label XXXXXX is an abbreviation for XXXXXX but there is space to enter the full name. Use the full name where possible to prevent possible confusion through ambiguity of the abbreviated version.

- It's not clear what the "XXXXXX" label refers to. My first thought was that it was misaligned but refers to the "XXXXXXX" options.

- If using images for buttons make them into actual buttons (with appropriate pressed and unpressed states) so the user can be certain they are pressing on the right thing.

- As "XXXXXX" & "XXXXXX" are mutually exclusive options. This could be more clearly indicated by using the traditional rounded radio button style, rather than the square checkbox style.

- The phone symbol (as used next to the "XXXXXXXX" and "XXXXXXXXX" fields) is used in other applications to call the entered number. Your use of this image to trigger a phone number chooser is unexpected and initially confusing. I would suggest using the magnifying glass image instead of the phone image for this purpose.

- Having a button to call the entered number may be a useful addition.

- It can be helpful to handle the "enter" key being pressed on the keyboard and using this to advance the focus of the selected textbox as it can make entering text easier.

- It would be helpful to indicate required fields.

- If I enter "XXXXX", "XXXXX", "XXXXXX", "XXXXX" and "XXXXX" and then tap the save button, I am prompted that "XXXXXXX: Must have a Valid Date Value - mm/dd/yyyy" but this field is on a different screen.

- Avoid using free text entry for date fields.

- If using free text entry for date fields, indicate the format the date must be provided in. (Especially if supporting multiple countries/regions where the order that days and months can be entered may vary as entries may be made which the system treats as valid but may not be what user intended.)

- Where possible, use a DatePicker for entering dates. It's typically enables quicker entry and removes the potential for ambiguity of day/month order. (There's one available in the toolkit if you weren't aware. see http://silverlight.codeplex.com/releases/view/55034)

- The "XXXXXXX" field requires a number to be entered but accepts values other than numbers and will perform calculations based on those values. This is very unlikely to generate the correct calculation result.

- Provide useful/likely defaults where appropriate. This can speed entry and make a large form appear less daunting to a user.

- The spacing between the label and the textbox that the label is for is inconsistent. Particularly on the "XXXXXX" screen.

- When entering multiple details it would be useful to not have to re-enter XXXXXXXX and XXXXXXX details which match those entered previously. An option to clone or create a copy of an existing entry may be a useful addition.


Here are some of the things that were said by the recipient of the above:

"I got a lot of value from your review."
"All of your suggestions are great. I will be going through this list with a fine tooth comb."
"This information will not only help my current app, but also hopefully my future apps!"

- Jeff (Developer of the app)

I hope this is useful. Let me know in the comments, or on twitter.

If you would like my feedback for a game or application that you have developed or are still developing, please get in touch.

Update: I've had a great response to my offer and so cannot accept any more apps to review just now. Sorry. Maybe I'll accept more in the future.

#DDDHack Update #wp7dev

If you're interested in taking part in the MSDN UK competition to build a Windows Phone 7 application but were caught out by the original starting code being built against the CTP version of the tools, there is now an alternative version of the code available at http://wp7rssreader.codeplex.com/.

If you were one of the people who told me the original code was "broken" please try this instead. ;)

WPUG goes to Cardiff

Calling anyone interested in #WP7Dev in Wales & the South West:

On March 2^nd WPUG is taking it's first steps outside London and has joined up with Mike Hole and the team at Sequence to have an event in Cardiff.

Check out the details at http://www.sequence.co.uk/sitecore/content/Blog/WPUG.aspx and be sure to tell anyone you know who may be interested.

#wp7dev #DDDHack competition

To tie in with last weekend's DDD9 event, MSDNUK are holding a Windows Phone 7 development competition.

There is a phone as a prize for the "best" XNA game and the "best" Silverlight application. The dealine for entries is Feb 12^th so get cracking if you want to enter.

More details at http://blogs.msdn.com/b/ukmsdn/archive/2011/01/29/dddhack-competition-at-ddd9.aspx