Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 29 Next »

Here are some points to consider when designing your application

Getting Started

There are several stages to the development of a CommCare application, with important questions to consider at each stage.

Application Design

  1. Project Context: What data is being tracked? Who are the users? What are the data needs?

  2. Define Menu and Form Structure: What are the major events (i.e. registration, monthly visits, meetings, etc.)? What is the structure of the community or intervention How can the structure be optimized for usability/help the mobile user?

  3. Content Design

    1. What List of Question Types in CommCare should you include? Will they require Common Logic and Calculations ?

    2. What will the multimedia content be?

    3. What counseling messages need to be included?

    4. What questions or calculations should be in each form?

Application Purpose and Requirements

When developing an application, the first step is to "define" the application. Think about the major questions in structuring the app. It also helps to understand how complex the program will be, and what type of resources will be required (i.e. multimedia development, approval of health counseling messages, etc.). 

Defining Your Workflow

In the next stage, it is important to dive into more detail about how to structure your application. Here are some the steps the field team takes at this stage:

  • Draw a schematic that shows the workflow of the application. Specifically, show the structure of the Menus and Forms and how you think the content should be best organized. 

  • Describe the purpose of each form as it relates to case management concepts. For each form consider how it relates to the life cycle/care cycle of that case of interest. 

Some specific questions for consideration:

  • What is/are the criterion/criteria for closing a case? 

  • Is an edit form is necessary or required?

  • If case sharing is required in the application, are there multiple workflows to illustrate?

Workflow Mapping Guide

In this guide, we present examples and templates to create digital workflow documentation.

The DIIG Digital Workflow Template includes examples, key elements, and templates following the WHO’s Digital Implementation Investment Guide (DIIG). Copy and paste templates to create your own workflows using PowerPoint or Google Slides.

https://www.dimagi.com/toolkits/diig-digital-workflow-template/

Define the Application Content

After your overall concept and workflow have been defined, it's time to dive into the content. At this stage you can start to fill in the specific content of each form.

FAQs

How can your user edit data?

If, for example, your user enters the wrong village name or misspells a name, how will they correct that case data?

It is best to add an "edit details" form to your application. This can be a very simple process:

  1. Make a copy of a registration form (or whichever form has most of the details you want to be able to update)

  2. Change the name of the form, delete any questions you don't want to update, and add any additional questions

  3. In the case configuration, pre-load all of the questions with the values from the case, and make sure that everything updates the case. By doing this, when the user opens the form all of the fields will be pre-populated with the previous values. They just need to change whichever value they want to correct, and all of the case properties will be updated with the most recent value.

Things to note about this:

  • This process involves submitting a separate form to update the case data. So the original registration or other form will still be in the system, only the CASE DATA will be updated. As such, when analyzing data, if you only look at the registration forms but not the registration update forms, you will not be looking at an accurate data set

  • If you have several case types in your application you may want an edit form for each case type

How will a user close a case?

In a single application there may be many ways to close a case. For example, from the user's perspective a case may be closed automatically when an event occurs, such as giving birth or recovering from an illness. However, sometimes it is important to account for edge cases where a case may have been registered twice or by accident.

There are a couple of ways to deal with this:

  • You can add a "remove name" form to your application to deal with these situations- remember that using language like "close case" may not be clear to the user, as from their perspective you are enabling a way to remove the name from their list.

  • You can add an edit form that allows the user to remove the name (i.e. "do you want to remove this user from your phone? Yes/No -> if yes, close the case)

  • You can alter a case property which filters the case out of the user's case list. This can be a useful approach when you want someone other than the mobile user to have control over actually closing out a case. This solution is only recommended if you have case sharing enabled and therefore a way to actually close out the cases in a different application. Filtering the cases without a way to close them would lead to an build up of non-accessible cases on the phone over time. You could have a CloudCare app that can see all cases where a case property called case_to_close = "yes" and then the CloudCare user can deal with the case (i.e. determine if it is safe to close it, etc.)

  • No labels