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.
...
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.
...
- 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:
...