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.
| Table of Contents |
|---|
APPLICATION PLANNING
...
Download the Example Spec
APPLICATION DESIGN
Question ID and Case Property Naming
...
For multilingual applications make sure each of the following is translated:
Question labels/display text in a form
Names of forms and modules
Any information displayed in the case list and detail (including ID mapping)
User Interface translations (Translate the CommCare User Interface) for your language. Common language (ex. back, form is loading) should be updated.
Set the default language of your application before creating your released build. Drag and drop the languages and put the default language at the top.
FORM DESIGN
Overall Form Structure
General Advice:
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 the user 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 (see the Beginner's Guide)
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.
Question Types
While selecting a question type may seem very straight forward, there are some interesting usability issues associated with different questions that are important to consider.
Text Input
Text input is the most time-consuming and error-prone type of question. Wherever possible replace text questions with single select questions. If there are a lot of options for a response, consider breaking it down into several shorter lists (i.e. first ask which village, then depending upon that answer ask which part of the village). Text input questions are especially difficult for any illiterate user and can be intimidating for many users. Where possible these questions should not be required and there should be a workaround to gather the information.
Numeric Input (Integer, Decimal)
Make sure you choose carefully whether you want an integer or decimal number in you data and choose the question type accordingly.
Keep in mind that neither integer nor decimal questions keep leading zeros. If you need to maintain leading zeros choose Phone Number/Numeric ID Question Type
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)
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 so the user knows which button to push)
Multi-Select
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 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 by doing the following:
Break multi-select questions into a series of single select questions. A multi-select question with four options, "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.
Overall, it is best practice is to have 1 yes/no such as 'is patient experiencing symptoms' and then multiple single select yes/no questions for all the symptoms. This will make the form longer, however, is more user-friendly. Having single select yes/no questions for each symptom also forces the user to really acknowledge each symptom; sometimes if they are in a list, they will not carefully read all the choices.
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 preceding it with a single-select question so that the multi-select question is only displayed if applicable.
If "none" is one of your choices make a validation condition that prevents user from selecting "none" in addition to other options (see Common Logic and Calculations). And then make sure you add a descriptive validation message!
GPS
If you are going to add a GPS question make sure that GPS works well on your phone in the areas you will be working. Don't make GPS questions required unless you're sure you can get them every time.
Consider what the user should do if they can’t get a GPS reading while they are in the field. This could include a follow up question that is displayed if the GPS question is left blank, and asks the reason.
Logic Properties
Minimize repeating logic and question content. Instead, whenever possible, create a hidden property that performs the calculation once and refer to the output of this variable wherever is required.
Labels used for displaying the value of hidden properties: create a hidden property called debug and set its Calculate Condition to true() or false(). Set the Display Condition of the debug label to /data/debug
If the answer to a question needs to be stored in a different form field and case property based on a logic condition, only include the question in the form once, then create a hidden property for each form or case property that needs to get populated. Set its Calculate Condition to point to the actual question being displayed and set the Display Condition to point at the logic that decides if that particular form/case property needs to be populated. Do not repeat the same question multiple times. Using hidden properties ensures that the form is easier to maintain and simpler to translate because a change only needs to be made to one question rather than multiple questions.
Create hidden properties even for simple calculations, in particular all calculations that include "magical" constants. For example, if multiple questions need to know if a child's age is under 60 months, create a property named child_under_5_years and set its Calculate Condition to /data/child_age_in_months <= 60. This approach ensures that if this number changes, it's easy to update one hidden property. Furthermore, it makes obvious what that particular piece of logic does - it checks that the age is under 5 years based on the age on months. It's always easier to read a variable name rather than trying to understand a logical statement.
Validation
Creating a validation condition for input-type questions can be very useful as a way to minimize the risk of users entering erroneous data. However, you should keep the following in mind:
Validation conditions should always be accompanied by descriptive constraint messages that will clearly inform the user what they need to correct. You can also add audio to constraint messages. For example, you may want to put a limit on a birth date to make sure the user doesn't accidentally put a date in the future. But if you don't put a constraint message the user may not understand why their answer was not accepted. This can be very frustrating for the user.
You want to be careful about your validation - if a user enters data in the field that doesn't fit your validation rule, this could prevent your app from being used. Make sure that your conditions are realistic and consider allowing an extra margin on your allowed values to permit extreme cases.
Required Question
Required questions prevent the user from moving forward in the form without entering or selecting a value. Be careful when specifying a question is required - if the user of the application cannot determine the value for a particular question (ex. they are transcribing from a paper form and the particular value is not filled in), this can prevent them from submitting any data. If necessary, you can add a follow-up question that asks why a particular value was blank.
...