# Add a pop-up message to prompt the CHV to ask further question or give more information or provide health education

**URL:** <https://forum.communityhealthtoolkit.org/t/add-a-pop-up-message-to-prompt-the-chv-to-ask-further-question-or-give-more-information-or-provide-health-education/2734>\
**Category:** Design\
**Tags:** ui-ux, workflow\
**Created:** [May 9, 2023, 4:23pm UTC](https://forum.communityhealthtoolkit.org/t/add-a-pop-up-message-to-prompt-the-chv-to-ask-further-question-or-give-more-information-or-provide-health-education/2734 "2023-05-09T16:23:33Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![sue](https://communityhealthtoolkit.b-cdn.net/user_avatar/forum.communityhealthtoolkit.org/sue/32/355_2.png) [@sue](https://forum.communityhealthtoolkit.org/u/sue)\
**Post date:** [May 9, 2023, 4:23pm UTC](https://forum.communityhealthtoolkit.org/t/add-a-pop-up-message-to-prompt-the-chv-to-ask-further-question-or-give-more-information-or-provide-health-education/2734/1 "2023-05-09T16:23:34Z")

</div>

Scenario 1: A CHV is asking sensitive questions to HH members on Hepatitis B. In the workflow, I want to alert the CHV to: **Be sensitive when asking the next Questions**

How we are designing for this: We put a note for the CHV saying, **Note: Be sensitive when asking the next Question**

New suggestion: Is it possible to pause the workflow at this point and include a message or notification that tells the user that they need to obtain additional information before continuing with the workflow. This could be in the form of a pop-up message or a prompt that appears on the screen. This pop-up message could be prompted by a response to a previous question.  
Once the CHV has taken note of the prompt, they can return to the workflow and answer the question about hepatitis B.

Scenario 2: CHVs complain that the MNCH workflow forms are long. Part of the reasons for the long forms is because we have included health education messages and instructions within the forms. We would like to keep the form short and precise.

New suggestion: Can we use the pop-up message containing the Health education messages or the instructions floating on the screen prompting the VHT to read and return back to the workflow questions? This approach allow CHVs to pause the workflow and read information without disrupting the user’s overall experience. It also helps shorten the forms as desired

cc. @Nicole_Orlowski @michael @Ziithe

---

<div class="post-metadata">

**Author:** ![jkuester](https://communityhealthtoolkit.b-cdn.net/user_avatar/forum.communityhealthtoolkit.org/jkuester/32/806_2.png) [@jkuester](https://forum.communityhealthtoolkit.org/u/jkuester)\
**Post date:** [June 14, 2023, 9:39pm UTC](https://forum.communityhealthtoolkit.org/t/add-a-pop-up-message-to-prompt-the-chv-to-ask-further-question-or-give-more-information-or-provide-health-education/2734/2 "2023-06-14T21:39:33Z")

</div>

So, I do not believe there is a built-in way to pop up a message/prompt when filling out a form. However, I have confirmed that it is possible to achieve behavior similar to what you are proposing with a custom [extension-lib](https://docs.communityhealthtoolkit.org/apps/reference/forms/app/#chtextension-lib). Basically the idea is to create a custom `extension-lib` function that allows for opening an alert from the browser/app.

Example:

Create a new [extension library](https://docs.communityhealthtoolkit.org/apps/reference/extension-libs/) with the following code:

```js
const getValue = function(obj) {
  let val;
  if (obj.t === 'arr') {
    val = obj.v && obj.v.length && obj.v[0];
  } else {
    
    val = obj.v;
  }
  if (!val) {
    return '';
  }
  return val.textContent;
};

module.exports = function(first) {
  const message = getValue(first);
  window.alert(message);
  return first;
};

```

Then you can use the extension-lib function in a form like this:

| type | name | label::en | relevant | appearance | calculation |
| --- | --- | --- | --- | --- | --- |
| begin group | page | NO\_LABEL | | field-list | |
| string | message | Enter alert message | | | |
| trigger | show | Show Alert? | | | |
| calculate | alert | | ${show} = “OK” | | cht:extension-lib(“alert.js”, …/message) |
| end group | page | | | | |

This will cause the alert to be opened whenever the `alert` field becomes relevant. (Also, you could use `window.confirm` in the extension function instead if you want to record a boolean value of the user’s response to the alert.)

This would work for brief notification messages, but is probably not ideal for long-form documentation. For that it would be nice to have a more sophisticated approach. Several issues have been logged recently that would provide interesting options here:

> <https://github.com/medic/cht-core/issues/8217>
>
> \[Guidance hints\](https://xlsform.org/en/#guidance-hints) are collapsible (and co…llapsed by default) hint texts that can be added to questions in a form. Normal hints are always displayed and so are always taking up screen space. This is not great for extensive information that might not always need to be referenced but still is important to have available to the user. Reference information could be embedded in a guidance hint that the user could reference when needed, but otherwise would not affect their workflow (they would not have to scroll past a bunch of text they are not going to read....).  
> 
> These guidance hints are already supported in enketo-core \`5.5.2\`+ so cht-core 4.x technically already has built-in support. However, our verison of \[pyxform\](https://github.com/medic/pyxform) does not support including these in the form xml when converting the xlsx. So, that would need to be upgraded to be able to use the functionality. Also, cht-core needs a new translation and probably some css tweaking to make stuff look nice.  
> 
> I kinda manually compiled an xml for a form with a guidance hint and loaded into the CHT and this is what it looks like currently:
> 
> !\[image\](https://user-images.githubusercontent.com/8441903/236497325-a0cc6aaf-2958-4ca5-8622-2712dc226804.png)
> !\[image\](https://user-images.githubusercontent.com/8441903/236497350-043d923c-6ac4-4c54-b0a8-927236ebdab2.png)
> 
> \`\`\`.xml
> \<?xml version="1.0"?\>
> \<h:html xmlns="http://www.w3.org/2002/xforms" xmlns:h="http://www.w3.org/1999/xhtml" xmlns:ev="http://www.w3.org/2001/xml-events" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:jr="http://openrosa.org/javarosa" xmlns:orx="http://openrosa.org/xforms"\>
> \<h:head\>
> \<h:title\>Enketo Widgets\</h:title\>
> \<model\>
> \<itext\>
> \<translation default="true()" lang="en"\>
> \<text id="/enketo\_widgets/my\_group/name:hint"\>
> \<value form="guidance"\>This is a guidance hint!\</value\>
> \</text\>
> \</translation\>
> \</itext\>
> \<instance\>
> \<enketo\_widgets id="enketo\_widgets" prefix="J1!enketo\_widgets!" delimiter="#" version="2023-05-05 00:00:00"\>
> \<my\_group\>
> \<age/\>
> \<name/\>
> \</my\_group\>
> \<meta tag="hidden"\>
> \<instanceID/\>
> \</meta\>
> \</enketo\_widgets\>
> \</instance\>
> \<instance id="contact-summary"/\>
> \<bind nodeset="/enketo\_widgets/my\_group/age" type="string"/\>
> \<bind nodeset="/enketo\_widgets/my\_group/name" type="string"/\>
> \<bind nodeset="/enketo\_widgets/meta/instanceID" type="string" readonly="true()" calculate="concat('uuid:', uuid())"/\>
> \</model\>
> \</h:head\>
> \<h:body class="pages"\>
> \<group appearance="field-list" ref="/enketo\_widgets/my\_group"\>
> \<input ref="/enketo\_widgets/my\_group/age"\>
> \<label\>Age?\</label\>
> \<hint\>this is a regular hint\</hint\>
> \</input\>
> \<input ref="/enketo\_widgets/my\_group/name"\>
> \<label\>Name?\</label\>
> \<hint ref="jr:itext('/enketo\_widgets/my\_group/name:hint')"/\>
> \</input\>
> \</group\>
> \</h:body\>
> \</h:html\>
> \`\`\`

> <https://github.com/medic/cht-core/issues/8218>
>
> Currently there is no way to show/hide sections of a form except via \`relevant\` …logic. This does not work for all use-cases since values in the non-relevant part of the form will not be saved at the end.
> 
> The default Enekto webapp supports being able to just collapse groups (that do not have the \`field-list\` appearance).  
> 
> !\[image\](https://user-images.githubusercontent.com/8441903/236499737-6fc095b4-d9c1-422f-9333-23528346360e.png)
> !\[image\](https://user-images.githubusercontent.com/8441903/236499821-dc413d6a-0a13-4dc4-be52-992158ab1640.png)
> 
> We could support similar functionality in the CHT, though we may want to make it opt-in. So if you added the \`collapsible\` appearance to a group it would make this happen. (Also would be good to consider some way of making the group collapsed by default, when desired, so the content is initially hidden until the user expands the group....)

---

<div class="post-metadata">

**Author:** ![michael](https://communityhealthtoolkit.b-cdn.net/user_avatar/forum.communityhealthtoolkit.org/michael/32/319_2.png) [@michael](https://forum.communityhealthtoolkit.org/u/michael)\
**Post date:** [June 15, 2023, 9:16pm UTC](https://forum.communityhealthtoolkit.org/t/add-a-pop-up-message-to-prompt-the-chv-to-ask-further-question-or-give-more-information-or-provide-health-education/2734/3 "2023-06-15T21:16:44Z")

</div>

This is awesome @jkuester … any chance you have a little video of what it looks like 🎥 ?

---

<div class="post-metadata">

**Author:** ![jkuester](https://communityhealthtoolkit.b-cdn.net/user_avatar/forum.communityhealthtoolkit.org/jkuester/32/806_2.png) [@jkuester](https://forum.communityhealthtoolkit.org/u/jkuester)\
**Post date:** [June 20, 2023, 2:40pm UTC](https://forum.communityhealthtoolkit.org/t/add-a-pop-up-message-to-prompt-the-chv-to-ask-further-question-or-give-more-information-or-provide-health-education/2734/4 "2023-06-20T14:40:06Z")

</div>

[https://communityhealthtoolkit.b-cdn.net/uploads/default/original/2X/5/563bce9282b2dca7fbae4392a0f20851e6fcb065.mp4](https://communityhealthtoolkit.b-cdn.net/uploads/default/original/2X/5/563bce9282b2dca7fbae4392a0f20851e6fcb065.mp4)

---

<div class="post-metadata">

**Author:** ![robinmurphy](https://communityhealthtoolkit.b-cdn.net/letter_avatar_proxy/v4/letter/r/e5b9ba/32.png) [@robinmurphy](https://forum.communityhealthtoolkit.org/u/robinmurphy)\
**Post date:** [June 22, 2023, 12:37pm UTC](https://forum.communityhealthtoolkit.org/t/add-a-pop-up-message-to-prompt-the-chv-to-ask-further-question-or-give-more-information-or-provide-health-education/2734/5 "2023-06-22T12:37:40Z")

</div>

Hi @jkuester,

On xlsx forms that has its `settings` `style` property set to `pages`, when implementing the `trigger` and `alert.js` via the `calculation` field, as suggested, it causes the alert dialog to be displayed unexpectedly in the following cases:  
On next/previous press.  
On clicking an option in a `multi_select` widget that has an `appearance` of `minimal`.

Is there a way to circumvent this?

---

<div class="post-metadata">

**Author:** ![jkuester](https://communityhealthtoolkit.b-cdn.net/user_avatar/forum.communityhealthtoolkit.org/jkuester/32/806_2.png) [@jkuester](https://forum.communityhealthtoolkit.org/u/jkuester)\
**Post date:** [June 22, 2023, 6:14pm UTC](https://forum.communityhealthtoolkit.org/t/add-a-pop-up-message-to-prompt-the-chv-to-ask-further-question-or-give-more-information-or-provide-health-education/2734/6 "2023-06-22T18:14:11Z")

</div>

_sigh_

I should have known this was too good to be true… Unfortunately you are correct. I neglected to test this against a multi-page form. 😞 Currently the CHT force-recalculates the expressions when changing pages which is why the alert is triggered by the next/previous buttons. Sadly the options for improving this behavior (without updating code in cht-core) are somewhat limited since Enketo does not support any kind of logic short-circuiting in its XPath evaluations.

- One option is to only trigger the alerts on the last page of the report (as long as they are not relevant until the last page, they should not be triggered when navigating between pages), However, after they are relevant, they would get triggered if the Previous button is used.
- Another option is to use some logic in your `extension-lib` function to control when the alert is displayed. There are probably a number of ways to do this, but one simple thing I tried was:
  - Update the extension-lib function to take a new param:

```auto
module.exports = function(startParam, messageParam){
  const message = getValue(messageParam);
  const start = getValue(startParam);
  if(!global.chtAlertStart || global.chtAlertStart !== start) {
    global.chtAlertStart = start;
    window.alert(message);
  }
  return messageParam;
};

```

  - Then in your form, include the `start` [metadata field](https://docs.getodk.org/form-question-types/#metadata)
  - Finally, pass the value for `start` when calling the function: `cht:extension-lib(“alert.js”, ${start}, ${message})`
  - `start` should be accurate to the millisecond, so it is unlikely to cause collisions even when quickly switching between forms, but should always remain the same value while the current form is being filled out.

Obviously these not not great workarounds, but they are the only ones that I have come up with so far. A proper solution (with broader performance benefits) might require refactoring [Openrosa XPath Evaluator](https://github.com/enketo/openrosa-xpath-evaluator) to support short-circuiting evaluations so that it does not always evaluate both sides of an expression if it can know that one value will be unnecessary (e.g. when computing a boolean `${A} or ${B}`, it would be better to compute `${A}` first. Then, if `${A}` is `true`, just skip evaluating `${B}` altogether (since its value does not matter)).

Also, the `multi_select` issue you noted poses a unique challenge to this kind of functionality. Each time you select a new item in a `multi_select`, it is recorded as a fresh “answer” to the question (and so any expressions that depend on that question value will be re-calculated. In that sense, if your alert is triggered by answering the `multi_select` then it is expected behavior that it would be triggered for each relevant selection. (That being said, my `start` workaround should also prevent re-alerts for this case too…)