Configuration phase 2 (Navigation drawer configuration implementation)

[dubdabasoduba]

What is the vision of the configuration?

• We would like to achieve a configurable register flow that starts from the Navigation drawer to the Client profile.
• This will enable us to configure the following
  • The menu item for a register and when it's displayed on the navigation drawer.
  • The register that opens after the menu above is clicked, the configuration of the data to be displayed on the register.
  • The profile that is opened after the register row is clicked, should also define what is displayed on the profile and the menu actions to be performed on the profile.

Navigation Drawer configuration

What we want to achieve

• To create a configuration file to define what menus are shown on the navigation drawer.
• We need to identify the following
  • The menus must always be shown.
  • Menus that can be turned off and on.
  • What registers can be shown on the navigation drawer. Here we need to identify the following
    • The main register. This will be the first register on the register list.
    • What other registers will be shown on the navigation drawer as menus.
    • What registers show on the "other client" registers menu item. Here we define the registers to be shown on the bottom sheets.

How to achieve the configuration

• This configuration is using the following mock up as the source of truth for the Navigation menu UI.

1. Menu identification
   • Static Menus/UI (Will always be shown and have the same functionality)
     • Top Bar (App Name & version)
     • Bottom Section (Sync & Sync timestamp)
     • Settings/Profile
   • Semi Static Menus (MIght be hidden and can be slightly configured)
     • Main registration button (Add Family button)
     • Reports
     • Device to Device data transfer
     • Other Patients/Clients' menu
       • This opens the bottom sheet shown here.
   • Dynamic Menus (Will always change)
     • Registers menus
2. Configuration of the different menu types.
   • Static menus/UI
     • These UI pieces will always be shown to the users. The data shown on them will either come from the app config or a calculation set on the app.
   • Semi Static Menus
     • Main Registration (Add family button)
       • This should be hidden or shown based on a configuration. If it is set to be shown then the last next 2 list items should always be available.
       • The naming should also be configurable
       • The Questionnaire it opens Should also be configurable.
     • Reports
       • This should be hidden or shown based on a configuration.
       • The naming should also be configurable
     • Device to Device data transfer
       • This should be hidden or shown based on a configuration.
       • The naming should also be configurable
     • Other Patients/Clients' menu
       • This should be hidden or shown based on a configuration
       • The naming should be configurable
       • The menus to be shown on the bottom sheet should be as configurable as the Dynamic menus below.
   • Dynamic Menus
     • These menus are used to define the different registers the users get access to. The following things have to be configurable.
       • Naming of each register menu.
       • Icons to the used.
       • Define whether we need to show or hide the counts against each of the menus.
       • Each menu should have a unique id assigned to it.
       • The menus will also have an onClick attribute.
         • This attribute will be used to identify the register config to load when the button is clicked. The config defines the register during runtime.

Configuration JSON proposal

{
  "appId": "ecbis-saa",
  "classification": "Navigation",
  "staticMenu": [
    {
      "id": "main_add_button",
      "visible": true,
      "display": "Add New Household",
      "actions": [
        {
          "type": "onClose",
          "workflow": "launch_profile",
          "id": "patient_profile"
        }
      ],
      "questionnaire": {
        "id": "82952",
        "title": "Add Family",
        "saveButtonText": "ADD FAMILY",
        "setPractitionerDetails": true,
        "setOrganizationDetails": true
      }
    },
    {
      "id": "reports",
      "visible": true,
      "display": "Reports"
    },
    {
      "id": "p2p_sync",
      "visible": true,
      "display": "Transfer Data"
    },
    {
      "id": "profile",
      "visible": true,
      "display": "Profile"
    }
  ],
  "clientRegister": [
    {
      "id": "all_households",
      "display": "All Households",
      "icon": "",
      "showCount": true,
      "actions": [
        {
          "type": "onClick",
          "workflow": "launch_register",
          "id": "all_household_register"
        },
        {
          "type": "count",
          "rules": [
            {
              "name": "householdCount",
              "condition": "",
              "action": [
                "householdCountValue = helper.count('all_household_register')"
              ]
            }
          ]
        }
      ]
    },
    {
      "id": "child",
      "display": "Child",
      "icon": "",
      "showCount": true,
      "onClick": {
        "register": "register_id"
      }
    },
    {
      "id": "sick",
      "display": "Sick",
      "icon": "",
      "showCount": true,
      "onClick": {
        "register": "register_id"
      }
    },
    {
      "id": "priority",
      "display": "Today's Priority",
      "icon": "",
      "showCount": true,
      "onClick": {
        "register": "register_id"
      }
    }
  ],
  "otherClients": {
    "visible": true,
    "display": "Other Patients",
    "bottomSheetRegister": [
      {
        "id": "bottom_all_households",
        "display": "All Households",
        "showCount": true,
        "onClick": {
          "register": "register_id"
        }
      },
      {
        "id": "bottom_child",
        "display": "Child",
        "showCount": true,
        "onClick": {
          "register": "register_id"
        }
      },
      {
        "id": "bottom_sick",
        "display": "Sick",
        "showCount": true,
        "onClick": {
          "register": "register_id"
        }
      },
      {
        "id": "bottom_priority",
        "display": "Today's Priority",
        "showCount": true,
        "onClick": {
          "register": "register_id"
        }
      }
    ]
  }
}

Next steps --> Configuration phase 2 (Registers configuration implementation)

[pld]

Looks great, for Register config do we have registers where the columns and the contents of the rows for each column vary? Then we'd want to add that too

[pld]

Yes correct

[FikriMilano]

We do have something called patient_register_row config for that.
It's just that I'm not sure if it's still compatible with the current Single APK Approach.

Anyway, we can note that down.

[dubdabasoduba]

@FikriMilano Do you have a link to this?

[pld]

OK cool, maybe we'd want to migrate that over

[FikriMilano]

@dubdabasoduba
patient_register_row
https://fhir.labs.smartregister.org/fhir/Binary/63002

[FikriMilano]

@dubdabasoduba
I have question, quoting this:

1. Menu identification
   • Static Menus/UI (Will always be shown and have the same functionality)
     • Top Bar (App Name & version)
     • Bottom Section (Sync & Sync timestamp)
     • Settings/Profile

At Settings/Profile
By Profile do you mean it will open the logged in user's profile page? that will contain settings e.g. logout button, etc

[dubdabasoduba]

@dubdabasoduba I have question, quoting this:

1. Menu identification

   • Static Menus/UI (Will always be shown and have the same functionality)

     • Top Bar (App Name & version)
     • Bottom Section (Sync & Sync timestamp)
     • Settings/Profile

At Settings/Profile By Profile do you mean it will open the logged in user's profile page? that will contain settings e.g. logout button, etc

@FikriMilano Yes.

[FikriMilano]

Got it

[FikriMilano]

@dubdabasoduba
I saw in the designs, there are some examples that have different menu item titles, but with the same functionality.

For comparison:

• https://www.figma.com/file/gDW2MxoHNI77hv1O49xgAk/FHIR-Apps-~-Design-System?node-id=10543%3A110303
• https://www.figma.com/file/gDW2MxoHNI77hv1O49xgAk/FHIR-Apps-~-Design-System?node-id=10543%3A110316

Can I assume that we want to make the menu item titles configurable?

[dubdabasoduba]

@FikriMilano Yes that's the aim fo the Navigation Drawer configurations settings.

[FikriMilano]

Got it

[ellykits]

Can we use camelCase for the JSON properties for the configs.

[ellykits]

This should be consistent with the naming convention used for FHIR resource JSON properties.

[FikriMilano]

Could we remove the priority attribute? since it's essentially the same as using the original ordering

[pld]

can you explain that a bit?

[dubdabasoduba]

Looking at the clientRegister attribute, we have JSON objects in the array. What @FikriMilano is suggesting is removing the priority atribute in each object and using the objects position in the array to define it's position on the register menu list on the navigation drawer.

[pld]

OK I see, I think it's ok to remove. If having it as a priority makes the code smaller or clearer, let's keep the attribute, but if it's neutral we can remove.

It's "hidden information" or a "convention" if we don't have it the JSON, so that's not great, but I don't think that's a strong enough argument to keep it in since we're still figuring out what the configuration is

[dubdabasoduba]

@pld I think it's a strong enough argument to have it clearly highlighted on the documentation.

[ellykits]

How will we configure this type of navigation (screen to screen)? example is in Quest/G6PD workflows where we use different Details screens.

[pld]

K, not sure I'm following, so in the menu you would like to be able to select either of those 2 reporting screens?

[pld]

OK thanks @ellykits I think I understand this better now. It sounds like what we need to solve for here is that menu content may be tied to the workflow, so you might need to specify that in order to be able to render the appropriate menu content.

If we have a defined set of workflow names, we could have another level like

profile
  eir
     [menu items...]
  anc
     [menu items...]

then when defining your profile menu you do it for a specific workflow

[ellykits]

@dubdabasoduba What are your thoughts?

[pld]

Also, I don't think we need to solve this now (or do we? is this something we have in the app right now?), and I do think the approach we're taking can be extended to handle this

[dubdabasoduba]

@ellykits @pld I am looking at the problem in from 2 catergories

1. What do you open on click
2. what do you navigate to on close.

The immediate problem we have to solve for is on the main registration button.

1. We need to solve for it closing to the patient profile or to the register page.
   • This close happens after the registration questionnaire is closed by saving the patient.
   • If the questionnaire is closed by any other occurance then we automatically move back to the register page.

• For this registration button situation I would propose having an onClose navigation workflow point in the app.

• This point would have an ID in order to indicate where it is triggered. This point and Id are then hardcode in the app. When closing a questionnaire we would first check whether the trigger menu item had an onClose config. If yes then check it the config Id matches the workflow point.

  • If it matches then we redirect to the configuration defination
  • If not then we use the code define default. In the registration case moving back the register is the default.

• The JSON on the button will be updated to look like the sample below.

{
  "id": "main_add_button",
  "visible": true,
  "name": "Add New Household",
  "onClose": {
    "id": "registration_redirect",
    "workflow": "redirect_to_profile"
  }
}

• As for the ones on the profile I think we need to identify the diferent flows we can have then try to solve for them using the 2 categories mentioned above (if possible)