This page outlines recommendations for designing and building useful CommCare applications. These are compiled from collective experience in app construction and are only recommendations. Individual projects could vary substantially and the overall best practice is to go through extensive user testing and piloting to identify and correct language, media, or work flows that are confusing.This site is currently undergoing revision (9 JULY 2012)
APPLICATION PLANNING
We have created an excel template that we like to use as an application spec. It's proven useful for defining and sharing the proposed application before starting to build it. If you choose to build your application first in the form builder/HQ, you can now generate a document very similar to the application spec. This is found in the form builder under “advanced” -> “export form contents.” You can then select all and copy the contents into an Excel document. Exporting or working with the content in an Excel document makes it easy to show the overall structure of a form, which is useful for sharing and discussing.
...
- Involve representative from partner organization on site for recording session and/or a staff member who understands local dialect. Although scripts can be followed, presence of native speakers will ensure integrity of message content.
- See more detailed recommendations in our Audio Recording Guide.
Images:
If possible, consider using a local illustrator. Use the actual uniforms/dress of local health professionals.
- If there are multiple single select questions in a row, its important to change the image for each picture. If the image is the same, its easy for the user, especially illiterate users, to get confused or think the application is not working properly.
- User-test your images- sometimes what you may think is a clearly understandable symbol may not be understood by users or their clients. For example, in one case an artist drew a digital thermometer and only upon asking users did the designer discover that they all thought it was a pen, not a thermometer.
...
- Take advantage of calculations in forms to minimize errors. For example, if you are asking for a birth date, add a label afterwards that shows the calculated age. This may highlight an error in date entry if the age appears different than what was expected.
Use labels to force the user to stop and verify their information. You can add a label that shows the user data they entered and encourages them to verify if it is correct (see Common Logic and Calculations ).
- Use groups to prevent writing the same display logic (and having to update it) for related questions. Groups also make it easier to manage large forms in the designer.
- Consider including a success/you're done with the form label as your last question. This can be particularly useful on J2ME phones by giving the user an opportunity to correct any errors and make it clear to the user that the form is ending..
Don't try to do too much in one form. If you make a simple form that is easy to use it has a higher probabilty of success than a complex one that tries to tackle too much.
...
If you need to have a number of a specific length (i.e. for an ID number), put a string-length constraint on the question (see Common Logic and Calculations)
MULTI-SELECT
These users experienced challenges in understanding the concept of a multi-select option question. In this question, the user is able to select more than one option. The selected options are indicated by an 'x' in a box. The question asked the user to select all the immunizations that child had received to date, with an option at the end for 'none'. Many users selected all the options, including the 'none' option or skipped the entire question and selected no options.Multi-select questions allow the users to choose more than one answer from a list. While this may seem relativley straight forward we have found that the use of these question types can be extremely confusing and error prone:
- On J2ME phones the check box can be very difficult to see and the multi-select question difficult to use. The user hsa to select each answer individually and then navigate to the bottom of the list of choices to select “done.” This is very different from how the other question types work, so users sometimes end up selecting and then un-selecting the same choice in their attempt to complete the question.
- On smartphones (ODK), when swiping from one question to another some users accidentally select additional options from the list.
As such, we recommend that you minimize the use of multi-select questions. You can do that by:
- breaking multi-select questions into a series of single select questions. "Which pregnancy danger signs are you experiencing, if any?" can become four, quick, single-select questions asking yes/no if the user is experiencing each symptom. This is worth doing if there are up to 4-5 options and if it is useful for the client or user to be asked these questions directly.
If you do choose to use a multi-select question, we strongly recommend that you do the following:
- Keep the list short enough so that it all shows up on one screen. If you have to scroll to get to the bottom of the list, the user will often miss those options. If your list is too long consider breaking it into more than one question.
You could also consider breaking the list into multiple questions single-select questions or preceding it with a single-select question so that the multi-select question is only displayed if applicable.
SINGLE-SELECT
- Many applications have lots of yes/no questions. Keeping the order of these consistent makes it easier for the user to navigate through the forms more quickly. However, varying the position means that the user has to pay more attention to the actual answer.
- If a single select question dictates what the next question will be (if yes show question A, if no show question B) it is best to make the single select question required.
- On J2ME phones add the appropriate numeral before each display text (i.e. the first option should have "1." before it)
...