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.
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.
Great idea. Thank you!
ReplyDelete