Error behavior on the table forms


(Nikodem Graczewski) #1

Hello everyone,

as a follow up to the last Technical Committee meeting I’m bringing this topic to the dev group so we can decide which approach we would like to take on this matter.

There are 4 possible approaches we could take on how we want to display errors on the table forms (sorted with level of effort required - easiest to hardest):

  1. Mimic what the other forms do.
  2. Make errors appear after the fields has been touched.
  3. Make errors appear after we leave (focus on something outside) the table row.
  4. Same as 3, but also highlight table header.
    To learn more about each of the approaches please visit the following link:
    https://openlmis.atlassian.net/wiki/spaces/OP/pages/378929173/OpenLMIS+UI±+Error+behavior+approaches

My two favorites are:

  • 1 - Mainly for consistency reasons. Implementing this approach would make all the forms (table or not) behave exactly the same across the whole system.
  • 2 - Early feedback for the user (errors are shown right after the input is dirty so the user can correct the errors early) as well as the fact we already have this approach implemented and it works fine with the pagination component.
    Please, share you opinions on the matter.

Best regards,
Nikodem


(Josh Zamor) #2

I expressed this during the call, but I feel like option #3 makes the most sense for line item type entry. Moreover though I wonder if we really are looking for one approach to all situations? e.g. I don’t feel like option #3 makes any sense for the Filter component or the general search component with My Facility / Supervised Facility and other options (btw did we ever settle on a simple name for that thing?). For filter or search it seems like option #1 seems to make the most sense.

My opinion here isn’t set in stone by any means but it does seem like having at-least two approaches makes sense: option #1 should be true for everything and the next option should make the most sense for line item type entry.

For clarity I think the wiki page presents the options in a slightly different order from top to bottom than what we are using here.

Best,

Josh

···

On Tuesday, May 29, 2018 at 10:25:00 AM UTC-7, Nikodem Graczewski wrote:

Hello everyone,

as a follow up to the last Technical Committee meeting I’m bringing this topic to the dev group so we can decide which approach we would like to take on this matter.

There are 4 possible approaches we could take on how we want to display errors on the table forms (sorted with level of effort required - easiest to hardest):

  1. Mimic what the other forms do.
  2. Make errors appear after the fields has been touched.
  3. Make errors appear after we leave (focus on something outside) the table row.
  4. Same as 3, but also highlight table header.
    To learn more about each of the approaches please visit the following link:
    https://openlmis.atlassian.net/wiki/spaces/OP/pages/378929173/OpenLMIS+UI±+Error+behavior+approaches

My two favorites are:

  • 1 - Mainly for consistency reasons. Implementing this approach would make all the forms (table or not) behave exactly the same across the whole system.
  • 2 - Early feedback for the user (errors are shown right after the input is dirty so the user can correct the errors early) as well as the fact we already have this approach implemented and it works fine with the pagination component.
    Please, share you opinions on the matter.

Best regards,
Nikodem


(Brandon Bowersox-Johnson) #3

I also feel that the line-item entry—especially the R&R Form—is a special case that justifies a special solution. OpenLMIS v3 has already chosen solution #3 for the R&R Form so far (from v3.0.0 to v3.3.0). I believe stakeholders and end-users are counting on that current behavior. The validation of those R&R Forms is a very detailed, important feature, and making any changes to it would require Product Committee involvement too.

As you evaluate how to handle errors consistently, I suggest looking at the other table forms separately from the R&R Form, and also look at non-form error handling (eg, filter, search, etc). That way if you are proposing changes, everyone can understand what parts of the system you would change.

I’m sorry I missed the Technical Committee (I have a conflicting commitment), but thanks for allowing me to share input.

-Brandon

···

From: openlmis-dev@googlegroups.com on behalf of "josh.zamor@openlmis.org" josh.zamor@openlmis.org

Date: Wednesday, May 30, 2018 at 10:01 PM

To: OpenLMIS Dev openlmis-dev@googlegroups.com

Subject: [openlmis-dev] Re: Error behavior on the table forms

I expressed this during the call, but I feel like option #3 makes the most sense for line item type entry. Moreover though I wonder if we really are looking for one approach to all situations? e.g. I don’t feel like option #3 makes any sense for the Filter component or the general search component with My Facility / Supervised Facility and other options (btw did we ever settle on a simple name for that thing?). For filter or search it seems like option #1 seems to make the most sense.

My opinion here isn’t set in stone by any means but it does seem like having at-least two approaches makes sense: option #1 should be true for everything and the next option should make the most sense for line item type entry.

For clarity I think the wiki page presents the options in a slightly different order from top to bottom than what we are using here.

Best,

Josh

On Tuesday, May 29, 2018 at 10:25:00 AM UTC-7, Nikodem Graczewski wrote:

Hello everyone,

as a follow up to the last Technical Committee meeting I’m bringing this topic to the dev group so we can decide which approach we would like to take on this matter.

There are 4 possible approaches we could take on how we want to display errors on the table forms (sorted with level of effort required - easiest to hardest):

  1. Mimic what the other forms do.
  1. Make errors appear after the fields has been touched.
  1. Make errors appear after we leave (focus on something outside) the table row.
  1. Same as 3, but also highlight table header.

To learn more about each of the approaches please visit the following link:

https://openlmis.atlassian.net/wiki/spaces/OP/pages/378929173/OpenLMIS+UI±+Error+behavior+approaches

My two favorites are:

  • 1 - Mainly for consistency reasons. Implementing this approach would make all the forms (table or not) behave exactly the same across the whole system.
  • 2 - Early feedback for the user (errors are shown right after the input is dirty so the user can correct the errors early) as well as the fact we already have this approach implemented and it works fine with the pagination component.

Please, share you opinions on the matter.

Best regards,

Nikodem

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to
openlmis-dev@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/8a4a37b3-9f3a-4237-bf71-fa17dc6c21d7%40googlegroups.com
.

For more options, visit https://groups.google.com/d/optout.


(Nikodem Graczewski) #4

I might have not expressed myself well enough if it comes to the distinction between table and regular forms, for which I’m sorry.

To clarify, by table form I mean any table that has any inputs inside (Requisition View, Proof of Delivery View, Shipment View and Stock Management Adjustment, Receive, Issue and Physical Inventory screens). Line item entry is the best phrase to describe it (thanks Josh!).

Everything that doesn’t reside directly inside a table (table filters, facility/program select, searches etc)

should be considered a standard form.

The main purpose of this thread is to choose the best approach for table forms as we’re using three different approaches to them across the system. The standard forms are already well documented and consistent (I couldn’t find a single form, which wouldn’t work the we expect it to). I agree with Josh on that we want to have two different approaches here.

I hope that clarifies any confusion I might have introduced.

Best regards,
Nikodem


SolDevelo
Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

···

On Thu, May 31, 2018 at 5:03 PM, Brandon Bowersox-Johnson brandon.bowersox-johnson@villagereach.org wrote:

I also feel that the line-item entry—especially the R&R Form—is a special case that justifies a special solution. OpenLMIS v3 has already chosen solution #3 for the R&R Form so far (from v3.0.0 to v3.3.0). I believe stakeholders and end-users are counting on that current behavior. The validation of those R&R Forms is a very detailed, important feature, and making any changes to it would require Product Committee involvement too.

As you evaluate how to handle errors consistently, I suggest looking at the other table forms separately from the R&R Form, and also look at non-form error handling (eg, filter, search, etc). That way if you are proposing changes, everyone can understand what parts of the system you would change.

I’m sorry I missed the Technical Committee (I have a conflicting commitment), but thanks for allowing me to share input.

-Brandon

From: openlmis-dev@googlegroups.com on behalf of "josh.zamor@openlmis.org" josh.zamor@openlmis.org

Date: Wednesday, May 30, 2018 at 10:01 PM

To: OpenLMIS Dev openlmis-dev@googlegroups.com

Subject: [openlmis-dev] Re: Error behavior on the table forms

I expressed this during the call, but I feel like option #3 makes the most sense for line item type entry. Moreover though I wonder if we really are looking for one approach to all situations? e.g. I don’t feel like option #3 makes any sense for the Filter component or the general search component with My Facility / Supervised Facility and other options (btw did we ever settle on a simple name for that thing?). For filter or search it seems like option #1 seems to make the most sense.

My opinion here isn’t set in stone by any means but it does seem like having at-least two approaches makes sense: option #1 should be true for everything and the next option should make the most sense for line item type entry.

For clarity I think the wiki page presents the options in a slightly different order from top to bottom than what we are using here.

Best,

Josh

On Tuesday, May 29, 2018 at 10:25:00 AM UTC-7, Nikodem Graczewski wrote:

Hello everyone,

as a follow up to the last Technical Committee meeting I’m bringing this topic to the dev group so we can decide which approach we would like to take on this matter.

There are 4 possible approaches we could take on how we want to display errors on the table forms (sorted with level of effort required - easiest to hardest):

  1. Mimic what the other forms do.
  2. Make errors appear after the fields has been touched.
  3. Make errors appear after we leave (focus on something outside) the table row.
  4. Same as 3, but also highlight table header.
    To learn more about each of the approaches please visit the following link:

https://openlmis.atlassian.net/wiki/spaces/OP/pages/378929173/OpenLMIS+UI±+Error+behavior+approaches

My two favorites are:

  • 1 - Mainly for consistency reasons. Implementing this approach would make all the forms (table or not) behave exactly the same across the whole system.
  • 2 - Early feedback for the user (errors are shown right after the input is dirty so the user can correct the errors early) as well as the fact we already have this approach implemented and it works fine with the pagination component.
    Please, share you opinions on the matter.

Best regards,

Nikodem

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to
openlmis-dev@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/8a4a37b3-9f3a-4237-bf71-fa17dc6c21d7%40googlegroups.com
.

For more options, visit https://groups.google.com/d/optout.

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/2F463C89-2265-4916-A42C-F6A0EA87D584%40villagereach.org.

For more options, visit https://groups.google.com/d/optout.

Nikodem Graczewski

Software Developer

ngraczewski@soldevelo.com


(Mary Jo Kochendorfer) #5

Nikodem,

Unfortunately I’m still a bit confused. I too share the concern that Brandon voiced regarding the R&R product grid table.

Could you clarify if you are proposing that the decision made on the pattern for “table forms” impacts the R&R product grid table attached? I was confused when you stated that the Requisition View is a table form since that does not have any inputs or error messages.

If there is any impact on the R&R product grid, we cannot move forward with choosing a table form error pattern without discussing with the Product Committee. We must propose all UI changes since it will impact current implementations of OpenLMIS v3 in Malawi. It would be great if you could pull together the options and clear examples and present at the next PC to ensure we have the whole communities input. I know it might feel arduous to also present to the PC but I do think this will impact the user experience enough that it is important to consider the PC’s perspective.

Thank you for pulling this proposal together and clarifying what the impact is. Let me know if you have any questions about what I’m asking for in terms of raising to the PC.

Thanks,

Mary Jo

···

From: OpenLMIS Dev openlmis-dev@googlegroups.com on behalf of Nikodem Graczewski ngraczewski@soldevelo.com

Date: Thursday, May 31, 2018 at 11:10 AM

To: Brandon Bowersox-Johnson brandon.bowersox-johnson@villagereach.org

Cc: OpenLMIS Dev openlmis-dev@googlegroups.com

Subject: Re: [openlmis-dev] Re: Error behavior on the table forms

I might have not expressed myself well enough if it comes to the distinction between table and regular forms, for which I’m sorry.

To clarify, by table form I mean any table that has any inputs inside (Requisition View, Proof of Delivery View, Shipment View and Stock Management Adjustment, Receive, Issue and Physical Inventory screens). Line item entry is the best phrase to describe it (thanks Josh!).

Everything that doesn’t reside directly inside a table (table filters, facility/program select, searches etc)
should be considered a standard form.

The main purpose of this thread is to choose the best approach for table forms as we’re using three different approaches to them across the system. The standard forms are already well documented and consistent (I couldn’t find a single form, which wouldn’t work the we expect it to). I agree with Josh on that we want to have two different approaches here.

I hope that clarifies any confusion I might have introduced.

Best regards,

Nikodem

Nikodem Graczewski

Software Developer

ngraczewski@soldevelo.com

On Thu, May 31, 2018 at 5:03 PM, Brandon Bowersox-Johnson <brandon.bowersox-johnson@villagereach.org > wrote:

I also feel that the line-item entry—especially the R&R Form—is a special case that justifies a special solution. OpenLMIS v3 has already chosen solution #3 for the R&R Form so far (from v3.0.0 to v3.3.0). I believe stakeholders and end-users are counting on that current behavior. The validation of those R&R Forms is a very detailed, important feature, and making any changes to it would require Product Committee involvement too.

As you evaluate how to handle errors consistently, I suggest looking at the other table forms separately from the R&R Form, and also look at non-form error handling (eg, filter, search, etc). That way if you are proposing changes, everyone can understand what parts of the system you would change.

I’m sorry I missed the Technical Committee (I have a conflicting commitment), but thanks for allowing me to share input.

-Brandon

From: <openlmis-dev@googlegroups.com > on behalf of "josh.zamor@openlmis.org " josh.zamor@openlmis.org

Date: Wednesday, May 30, 2018 at 10:01 PM

To: OpenLMIS Dev openlmis-dev@googlegroups.com

Subject: [openlmis-dev] Re: Error behavior on the table forms

I expressed this during the call, but I feel like option #3 makes the most sense for line item type entry. Moreover though I wonder if we really are looking for one approach to all situations? e.g. I don’t feel like option #3 makes any sense for the Filter component or the general search component with My Facility / Supervised Facility and other options (btw did we ever settle on a simple name for that thing?). For filter or search it seems like option #1 seems to make the most sense.

My opinion here isn’t set in stone by any means but it does seem like having at-least two approaches makes sense: option #1 should be true for everything and the next option should make the most sense for line item type entry.

For clarity I think the wiki page presents the options in a slightly different order from top to bottom than what we are using here.

Best,

Josh

On Tuesday, May 29, 2018 at 10:25:00 AM UTC-7, Nikodem Graczewski wrote:

Hello everyone,

as a follow up to the last Technical Committee meeting I’m bringing this topic to the dev group so we can decide which approach we would like to take on this matter.

There are 4 possible approaches we could take on how we want to display errors on the table forms (sorted with level of effort required - easiest to hardest):

  1. Mimic what the other forms do.
  1. Make errors appear after the fields has been touched.
  1. Make errors appear after we leave (focus on something outside) the table row.
  1. Same as 3, but also highlight table header.

To learn more about each of the approaches please visit the following link:

https://openlmis.atlassian.net/wiki/spaces/OP/pages/378929173/OpenLMIS+UI±+Error+behavior+approaches

My two favorites are:

  • 1 - Mainly for consistency reasons. Implementing this approach would make all the forms (table or not) behave exactly the same across the whole system.
  • 2 - Early feedback for the user (errors are shown right after the input is dirty so the user can correct the errors early) as well as the fact we already have this approach implemented and it works fine with the pagination component.

Please, share you opinions on the matter.

Best regards,

Nikodem

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/8a4a37b3-9f3a-4237-bf71-fa17dc6c21d7%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/2F463C89-2265-4916-A42C-F6A0EA87D584%40villagereach.org.

For more options, visit https://groups.google.com/d/optout.

**

SolDevelo** Sp. z o.o. [LLC] / www.soldevelo.com

Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland

Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/CAGOM9mW%2BjkRAG2UMQna3Qizqeip6oypjpzAyCi6qBRnF6KRj7A%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.


(Nikodem Graczewski) #6

Yes, if we decide to pick a different approach than the one we’re already using for product grid, this changes will also affect the requisition product grid. The list of screens that will be affected by this is as follows:

  • View Proof of Delivery (#!/pod/id)
  • View Requisition (#!/requisition/id)
  • View Shipment (#!/orders/id)
  • Issue (#!/stockmangement/issue/id)
  • Receive (#!/stockmangement/receive/id)
  • Physical Inventory (#!/physicalInventory/id)
  • Adjustments (#!/adjustment/id)
    Hopefully I didn’t miss any screen.

Best regards,

Nikodem


SolDevelo
Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

···

On Fri, Jun 1, 2018 at 8:39 PM, Mary Jo Kochendorfer maryjo.kochendorfer@villagereach.org wrote:

Nikodem,

Unfortunately I’m still a bit confused. I too share the concern that Brandon voiced regarding the R&R product grid table.

Could you clarify if you are proposing that the decision made on the pattern for “table forms” impacts the R&R product grid table attached? I was confused when you stated that the Requisition View is a table form since that does not have any inputs or error messages.

If there is any impact on the R&R product grid, we cannot move forward with choosing a table form error pattern without discussing with the Product Committee. We must propose all UI changes since it will impact current implementations of OpenLMIS v3 in Malawi. It would be great if you could pull together the options and clear examples and present at the next PC to ensure we have the whole communities input. I know it might feel arduous to also present to the PC but I do think this will impact the user experience enough that it is important to consider the PC’s perspective.

Thank you for pulling this proposal together and clarifying what the impact is. Let me know if you have any questions about what I’m asking for in terms of raising to the PC.

Thanks,

Mary Jo

From: OpenLMIS Dev openlmis-dev@googlegroups.com on behalf of Nikodem Graczewski ngraczewski@soldevelo.com

Date: Thursday, May 31, 2018 at 11:10 AM

To: Brandon Bowersox-Johnson brandon.bowersox-johnson@villagereach.org

Cc: OpenLMIS Dev openlmis-dev@googlegroups.com

Subject: Re: [openlmis-dev] Re: Error behavior on the table forms

I might have not expressed myself well enough if it comes to the distinction between table and regular forms, for which I’m sorry.

To clarify, by table form I mean any table that has any inputs inside (Requisition View, Proof of Delivery View, Shipment View and Stock Management Adjustment, Receive, Issue and Physical Inventory screens). Line item entry is the best phrase to describe it (thanks Josh!).

Everything that doesn’t reside directly inside a table (table filters, facility/program select, searches etc)
should be considered a standard form.

The main purpose of this thread is to choose the best approach for table forms as we’re using three different approaches to them across the system. The standard forms are already well documented and consistent (I couldn’t find a single form, which wouldn’t work the we expect it to). I agree with Josh on that we want to have two different approaches here.

I hope that clarifies any confusion I might have introduced.

Best regards,

Nikodem

Nikodem Graczewski

Software Developer

ngraczewski@soldevelo.com

On Thu, May 31, 2018 at 5:03 PM, Brandon Bowersox-Johnson <brandon.bowersox-johnson@villagereach.org > wrote:

I also feel that the line-item entry—especially the R&R Form—is a special case that justifies a special solution. OpenLMIS v3 has already chosen solution #3 for the R&R Form so far (from v3.0.0 to v3.3.0). I believe stakeholders and end-users are counting on that current behavior. The validation of those R&R Forms is a very detailed, important feature, and making any changes to it would require Product Committee involvement too.

As you evaluate how to handle errors consistently, I suggest looking at the other table forms separately from the R&R Form, and also look at non-form error handling (eg, filter, search, etc). That way if you are proposing changes, everyone can understand what parts of the system you would change.

I’m sorry I missed the Technical Committee (I have a conflicting commitment), but thanks for allowing me to share input.

-Brandon

From: <openlmis-dev@googlegroups.com > on behalf of "josh.zamor@openlmis.org " josh.zamor@openlmis.org

Date: Wednesday, May 30, 2018 at 10:01 PM

To: OpenLMIS Dev openlmis-dev@googlegroups.com

Subject: [openlmis-dev] Re: Error behavior on the table forms

I expressed this during the call, but I feel like option #3 makes the most sense for line item type entry. Moreover though I wonder if we really are looking for one approach to all situations? e.g. I don’t feel like option #3 makes any sense for the Filter component or the general search component with My Facility / Supervised Facility and other options (btw did we ever settle on a simple name for that thing?). For filter or search it seems like option #1 seems to make the most sense.

My opinion here isn’t set in stone by any means but it does seem like having at-least two approaches makes sense: option #1 should be true for everything and the next option should make the most sense for line item type entry.

For clarity I think the wiki page presents the options in a slightly different order from top to bottom than what we are using here.

Best,

Josh

On Tuesday, May 29, 2018 at 10:25:00 AM UTC-7, Nikodem Graczewski wrote:

Hello everyone,

as a follow up to the last Technical Committee meeting I’m bringing this topic to the dev group so we can decide which approach we would like to take on this matter.

There are 4 possible approaches we could take on how we want to display errors on the table forms (sorted with level of effort required - easiest to hardest):

  1. Mimic what the other forms do.
  2. Make errors appear after the fields has been touched.
  3. Make errors appear after we leave (focus on something outside) the table row.
  4. Same as 3, but also highlight table header.
    To learn more about each of the approaches please visit the following link:

https://openlmis.atlassian.net/wiki/spaces/OP/pages/378929173/OpenLMIS+UI±+Error+behavior+approaches

My two favorites are:

  • 1 - Mainly for consistency reasons. Implementing this approach would make all the forms (table or not) behave exactly the same across the whole system.
  • 2 - Early feedback for the user (errors are shown right after the input is dirty so the user can correct the errors early) as well as the fact we already have this approach implemented and it works fine with the pagination component.
    Please, share you opinions on the matter.

Best regards,

Nikodem

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/8a4a37b3-9f3a-4237-bf71-fa17dc6c21d7%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/2F463C89-2265-4916-A42C-F6A0EA87D584%40villagereach.org.

For more options, visit https://groups.google.com/d/optout.

**

SolDevelo** Sp. z o.o. [LLC] / www.soldevelo.com

Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland

Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/CAGOM9mW%2BjkRAG2UMQna3Qizqeip6oypjpzAyCi6qBRnF6KRj7A%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/02DA5B5A-716E-4D57-9FB9-6E2AB0C8898B%40villagereach.org.

For more options, visit https://groups.google.com/d/optout.

Nikodem Graczewski

Software Developer

ngraczewski@soldevelo.com


(Josh Zamor) #7

Thanks for the clarification Nikodem, now I understand better.

For line item entry only then:

I still think I favor option #3, identify errors in a line item only after some work has been done in the line item, and then you shift away from it. As well (as always) as identifying all errors when attempting to submit the entries. I recognize this is one of the hardest options and also that it’s likely personal preference - that is I prefer a UX that has fewer visual warnings as I’m working on an item, and instead prefer those visual warnings to be raised after I think I’m done: I shift to another line item or I click a button that is me indicating I’m done. I also recognize this isn’t what the Requisition screen does (option #2), as currently it raises those visual indicators within the line item I’m working on as soon as I start working on the line item and something isn’t right.

Between those two options my preference as I said is #3, however the UX between the two is so small that I can’t say I’d encourage investing significant effort in it. Using option #2 with a smaller LOE seems fine by me.

Do we have an approach to finding errors across line items? I can imagine as we get into budgets for Requisitions we’ll have the need. Would that change the LOE for anything here?

Best,

Josh

···

On Fri, Jun 1, 2018 at 8:39 PM, Mary Jo Kochendorfer
maryjo.kochendorfer@villagereach.org wrote:

Nikodem,

Unfortunately I’m still a bit confused. I too share the concern that Brandon voiced regarding the R&R product grid table.

Could you clarify if you are proposing that the decision made on the pattern for “table forms” impacts the R&R product grid table attached? I was confused when you stated that the Requisition View is a table form since that does not have any inputs or error messages.

If there is any impact on the R&R product grid, we cannot move forward with choosing a table form error pattern without discussing with the Product Committee. We must propose all UI changes since it will impact current implementations of OpenLMIS v3 in Malawi. It would be great if you could pull together the options and clear examples and present at the next PC to ensure we have the whole communities input. I know it might feel arduous to also present to the PC but I do think this will impact the user experience enough that it is important to consider the PC’s perspective.

Thank you for pulling this proposal together and clarifying what the impact is. Let me know if you have any questions about what I’m asking for in terms of raising to the PC.

Thanks,

Mary Jo

From: OpenLMIS Dev openlmis-dev@googlegroups.com on behalf of Nikodem Graczewski ngraczewski@soldevelo.com

Date: Thursday, May 31, 2018 at 11:10 AM

To: Brandon Bowersox-Johnson brandon.bowersox-johnson@villagereach.org

Cc: OpenLMIS Dev openlmis-dev@googlegroups.com

Subject: Re: [openlmis-dev] Re: Error behavior on the table forms

I might have not expressed myself well enough if it comes to the distinction between table and regular forms, for which I’m sorry.

To clarify, by table form I mean any table that has any inputs inside (Requisition View, Proof of Delivery View, Shipment View and Stock Management Adjustment, Receive, Issue and Physical Inventory screens). Line item entry is the best phrase to describe it (thanks Josh!).

Everything that doesn’t reside directly inside a table (table filters, facility/program select, searches etc)
should be considered a standard form.

The main purpose of this thread is to choose the best approach for table forms as we’re using three different approaches to them across the system. The standard forms are already well documented and consistent (I couldn’t find a single form, which wouldn’t work the we expect it to). I agree with Josh on that we want to have two different approaches here.

I hope that clarifies any confusion I might have introduced.

Best regards,

Nikodem

Nikodem Graczewski

Software Developer

ngraczewski@soldevelo.com

On Thu, May 31, 2018 at 5:03 PM, Brandon Bowersox-Johnson <brandon.bowersox-johnson@villagereach.org > wrote:

I also feel that the line-item entry—especially the R&R Form—is a special case that justifies a special solution. OpenLMIS v3 has already chosen solution #3 for the R&R Form so far (from v3.0.0 to v3.3.0). I believe stakeholders and end-users are counting on that current behavior. The validation of those R&R Forms is a very detailed, important feature, and making any changes to it would require Product Committee involvement too.

As you evaluate how to handle errors consistently, I suggest looking at the other table forms separately from the R&R Form, and also look at non-form error handling (eg, filter, search, etc). That way if you are proposing changes, everyone can understand what parts of the system you would change.

I’m sorry I missed the Technical Committee (I have a conflicting commitment), but thanks for allowing me to share input.

-Brandon

From: <openlmis-dev@googlegroups.com > on behalf of "josh.zamor@openlmis.org " josh.zamor@openlmis.org

Date: Wednesday, May 30, 2018 at 10:01 PM

To: OpenLMIS Dev openlmis-dev@googlegroups.com

Subject: [openlmis-dev] Re: Error behavior on the table forms

I expressed this during the call, but I feel like option #3 makes the most sense for line item type entry. Moreover though I wonder if we really are looking for one approach to all situations? e.g. I don’t feel like option #3 makes any sense for the Filter component or the general search component with My Facility / Supervised Facility and other options (btw did we ever settle on a simple name for that thing?). For filter or search it seems like option #1 seems to make the most sense.

My opinion here isn’t set in stone by any means but it does seem like having at-least two approaches makes sense: option #1 should be true for everything and the next option should make the most sense for line item type entry.

For clarity I think the wiki page presents the options in a slightly different order from top to bottom than what we are using here.

Best,

Josh

On Tuesday, May 29, 2018 at 10:25:00 AM UTC-7, Nikodem Graczewski wrote:

Hello everyone,

as a follow up to the last Technical Committee meeting I’m bringing this topic to the dev group so we can decide which approach we would like to take on this matter.

There are 4 possible approaches we could take on how we want to display errors on the table forms (sorted with level of effort required - easiest to hardest):

  1. Mimic what the other forms do.
  2. Make errors appear after the fields has been touched.
  3. Make errors appear after we leave (focus on something outside) the table row.
  4. Same as 3, but also highlight table header.
    To learn more about each of the approaches please visit the following link:

https://openlmis.atlassian.net/wiki/spaces/OP/pages/378929173/OpenLMIS+UI±+Error+behavior+approaches

My two favorites are:

  • 1 - Mainly for consistency reasons. Implementing this approach would make all the forms (table or not) behave exactly the same across the whole system.
  • 2 - Early feedback for the user (errors are shown right after the input is dirty so the user can correct the errors early) as well as the fact we already have this approach implemented and it works fine with the pagination component.
    Please, share you opinions on the matter.

Best regards,

Nikodem

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/8a4a37b3-9f3a-4237-bf71-fa17dc6c21d7%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/2F463C89-2265-4916-A42C-F6A0EA87D584%40villagereach.org.

For more options, visit https://groups.google.com/d/optout.

**

SolDevelo** Sp. z o.o. [LLC] / www.soldevelo.com

Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland

Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/CAGOM9mW%2BjkRAG2UMQna3Qizqeip6oypjpzAyCi6qBRnF6KRj7A%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to
openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to
openlmis-dev@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/02DA5B5A-716E-4D57-9FB9-6E2AB0C8898B%40villagereach.org
.

For more options, visit
https://groups.google.com/d/optout
.

**Nikodem Graczewski
**

Software Developer

ngraczewski@soldevelo.com


(Nikodem Graczewski) #8

Thanks for the feedback!

The reasoning behind option #3 totally makes sense to me.

About the questions I’m not sure I understand what you mean by “finding errors across line items”? Does it mean we want to bring user to the first error in the table after we attempt to submit it, or is it something else?

Best regards,
Nikodem


SolDevelo
Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

···

On Tue, Jun 5, 2018 at 12:59 AM, Josh Zamor josh.zamor@villagereach.org wrote:

Thanks for the clarification Nikodem, now I understand better.

For line item entry only then:

I still think I favor option #3, identify errors in a line item only after some work has been done in the line item, and then you shift away from it. As well (as always) as identifying all errors when attempting to submit the entries. I recognize this is one of the hardest options and also that it’s likely personal preference - that is I prefer a UX that has fewer visual warnings as I’m working on an item, and instead prefer those visual warnings to be raised after I think I’m done: I shift to another line item or I click a button that is me indicating I’m done. I also recognize this isn’t what the Requisition screen does (option #2), as currently it raises those visual indicators within the line item I’m working on as soon as I start working on the line item and something isn’t right.

Between those two options my preference as I said is #3, however the UX between the two is so small that I can’t say I’d encourage investing significant effort in it. Using option #2 with a smaller LOE seems fine by me.

Do we have an approach to finding errors across line items? I can imagine as we get into budgets for Requisitions we’ll have the need. Would that change the LOE for anything here?

Best,

Josh

On Jun 4, 2018, at 2:54 PM, Nikodem Graczewski ngraczewski@soldevelo.com wrote:

Yes, if we decide to pick a different approach than the one we’re already using for product grid, this changes will also affect the requisition product grid. The list of screens that will be affected by this is as follows:

  • View Proof of Delivery (#!/pod/id)
  • View Requisition (#!/requisition/id)
  • View Shipment (#!/orders/id)
  • Issue (#!/stockmangement/issue/id)
  • Receive (#!/stockmangement/receive/id)
  • Physical Inventory (#!/physicalInventory/id)
  • Adjustments (#!/adjustment/id)
    Hopefully I didn’t miss any screen.

Best regards,

Nikodem

**

SolDevelo** Sp. z o.o. [LLC] /
www.soldevelo.com

Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland

Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

You received this message because you are subscribed to a topic in the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this topic, visit
https://groups.google.com/d/topic/openlmis-dev/FTD6ta5PxWc/unsubscribe
.

To unsubscribe from this group and all its topics, send an email to
openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to
openlmis-dev@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/CAGOM9mVXaMAETbfw-CQUF2%3Dj%2B3EVBnxC%2B5qiuJ2h2jsAax%3Driw%40mail.gmail.com
.

For more options, visit https://groups.google.com/d/optout.

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/FAFB3858-7799-428A-AB0D-49DBBF3EB981%40villagereach.org.

For more options, visit https://groups.google.com/d/optout.

Nikodem Graczewski

Software Developer

ngraczewski@soldevelo.com

**Nikodem Graczewski
**

Software Developer

ngraczewski@soldevelo.com

On Fri, Jun 1, 2018 at 8:39 PM, Mary Jo Kochendorfer
maryjo.kochendorfer@villagereach.org wrote:

Nikodem,

Unfortunately I’m still a bit confused. I too share the concern that Brandon voiced regarding the R&R product grid table.

Could you clarify if you are proposing that the decision made on the pattern for “table forms” impacts the R&R product grid table attached? I was confused when you stated that the Requisition View is a table form since that does not have any inputs or error messages.

If there is any impact on the R&R product grid, we cannot move forward with choosing a table form error pattern without discussing with the Product Committee. We must propose all UI changes since it will impact current implementations of OpenLMIS v3 in Malawi. It would be great if you could pull together the options and clear examples and present at the next PC to ensure we have the whole communities input. I know it might feel arduous to also present to the PC but I do think this will impact the user experience enough that it is important to consider the PC’s perspective.

Thank you for pulling this proposal together and clarifying what the impact is. Let me know if you have any questions about what I’m asking for in terms of raising to the PC.

Thanks,

Mary Jo

From: OpenLMIS Dev openlmis-dev@googlegroups.com on behalf of Nikodem Graczewski ngraczewski@soldevelo.com

Date: Thursday, May 31, 2018 at 11:10 AM

To: Brandon Bowersox-Johnson brandon.bowersox-johnson@villagereach.org

Cc: OpenLMIS Dev openlmis-dev@googlegroups.com

Subject: Re: [openlmis-dev] Re: Error behavior on the table forms

I might have not expressed myself well enough if it comes to the distinction between table and regular forms, for which I’m sorry.

To clarify, by table form I mean any table that has any inputs inside (Requisition View, Proof of Delivery View, Shipment View and Stock Management Adjustment, Receive, Issue and Physical Inventory screens). Line item entry is the best phrase to describe it (thanks Josh!).

Everything that doesn’t reside directly inside a table (table filters, facility/program select, searches etc)
should be considered a standard form.

The main purpose of this thread is to choose the best approach for table forms as we’re using three different approaches to them across the system. The standard forms are already well documented and consistent (I couldn’t find a single form, which wouldn’t work the we expect it to). I agree with Josh on that we want to have two different approaches here.

I hope that clarifies any confusion I might have introduced.

Best regards,

Nikodem

Nikodem Graczewski

Software Developer

ngraczewski@soldevelo.com

On Thu, May 31, 2018 at 5:03 PM, Brandon Bowersox-Johnson <brandon.bowersox-johnson@villagereach.org > wrote:

I also feel that the line-item entry—especially the R&R Form—is a special case that justifies a special solution. OpenLMIS v3 has already chosen solution #3 for the R&R Form so far (from v3.0.0 to v3.3.0). I believe stakeholders and end-users are counting on that current behavior. The validation of those R&R Forms is a very detailed, important feature, and making any changes to it would require Product Committee involvement too.

As you evaluate how to handle errors consistently, I suggest looking at the other table forms separately from the R&R Form, and also look at non-form error handling (eg, filter, search, etc). That way if you are proposing changes, everyone can understand what parts of the system you would change.

I’m sorry I missed the Technical Committee (I have a conflicting commitment), but thanks for allowing me to share input.

-Brandon

From: <openlmis-dev@googlegroups.com > on behalf of "josh.zamor@openlmis.org " josh.zamor@openlmis.org

Date: Wednesday, May 30, 2018 at 10:01 PM

To: OpenLMIS Dev openlmis-dev@googlegroups.com

Subject: [openlmis-dev] Re: Error behavior on the table forms

I expressed this during the call, but I feel like option #3 makes the most sense for line item type entry. Moreover though I wonder if we really are looking for one approach to all situations? e.g. I don’t feel like option #3 makes any sense for the Filter component or the general search component with My Facility / Supervised Facility and other options (btw did we ever settle on a simple name for that thing?). For filter or search it seems like option #1 seems to make the most sense.

My opinion here isn’t set in stone by any means but it does seem like having at-least two approaches makes sense: option #1 should be true for everything and the next option should make the most sense for line item type entry.

For clarity I think the wiki page presents the options in a slightly different order from top to bottom than what we are using here.

Best,

Josh

On Tuesday, May 29, 2018 at 10:25:00 AM UTC-7, Nikodem Graczewski wrote:

Hello everyone,

as a follow up to the last Technical Committee meeting I’m bringing this topic to the dev group so we can decide which approach we would like to take on this matter.

There are 4 possible approaches we could take on how we want to display errors on the table forms (sorted with level of effort required - easiest to hardest):

  1. Mimic what the other forms do.
  2. Make errors appear after the fields has been touched.
  3. Make errors appear after we leave (focus on something outside) the table row.
  4. Same as 3, but also highlight table header.
    To learn more about each of the approaches please visit the following link:

https://openlmis.atlassian.net/wiki/spaces/OP/pages/378929173/OpenLMIS+UI±+Error+behavior+approaches

My two favorites are:

  • 1 - Mainly for consistency reasons. Implementing this approach would make all the forms (table or not) behave exactly the same across the whole system.
  • 2 - Early feedback for the user (errors are shown right after the input is dirty so the user can correct the errors early) as well as the fact we already have this approach implemented and it works fine with the pagination component.
    Please, share you opinions on the matter.

Best regards,

Nikodem

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/8a4a37b3-9f3a-4237-bf71-fa17dc6c21d7%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/2F463C89-2265-4916-A42C-F6A0EA87D584%40villagereach.org.

For more options, visit https://groups.google.com/d/optout.

**

SolDevelo** Sp. z o.o. [LLC] / www.soldevelo.com

Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland

Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/CAGOM9mW%2BjkRAG2UMQna3Qizqeip6oypjpzAyCi6qBRnF6KRj7A%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to
openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to
openlmis-dev@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/02DA5B5A-716E-4D57-9FB9-6E2AB0C8898B%40villagereach.org
.

For more options, visit
https://groups.google.com/d/optout
.


(Mary Jo Kochendorfer) #9

Josh,

To clarify, are you talking about within a lineItem having error messages between to cells/fields within a LineItem? If so, we currently have that behavior/need within the requisition product grid as cells within one lineItem calculate off each other.

Nikodem,

I must admit that I’m still a bit confused and I want to make sure I’m clear on what you are proposing and the impact on the current system behavior. After reading this thread and the
wiki
, I’m still confused. Would you be willing to review the following and make sure I didn’t misunderstand your proposal. If it is correct, we will need to bring this to the Product Committee. I suggest
updating your current wiki
to clearly state 1. The current state, 2. The proposed options and 3. The impact. You could use the table I created below.

Below I’ve started to lay out a summarized view, but I still have open questions to you in red.

Current behavior

Screens are inconsistent. The following proposal is specifically looking at “Table Forms”. A table form is any table that has any inputs inside of the table or ‘lineItem entries’. Nikodem, to clarify does this include tables which don’t have editable fields/cells but have a column with action buttons? That’s not clear to me.

Proposed Options

The following are the 4 options are for Table forms: Nikodem, it would be useful to see a table like this

···

#

Option

Level of Effort

User Benefit

Performance Impact

Will the option slow down the experience for the user on 2G?

Screens which would change if this option is selected.

1

Mimic what the other forms do.

Nikodem, could you clarify what this option is? Mimic which form?

Tiny?

2

Make errors appear after the fields has been touched.

3

Make errors appear after we leave (focus on something outside) the table row.

When fields within a lineItem are dependent on each other the error won’t show until they focus away from the LineItem (row)

4

Same as 3, but also highlight the table header.

Depending on the option, the following screens may be impacted. See the above table for details on which would change based on the option.

  • Requisition Product grid (I’m including this because it is my understanding it would be impacted if we chose an option which is different than the current behavior. Or perhaps you are including this later, my apologies.)

  • View Proof of Delivery (#!/pod/id) Question: why is this impacted if the table doesn’t have any inputs? I only see action buttons. Or are you referring to the editable proof of delivery screen?

  • View Requisition (#!/requisition/id) Question: why is this impacted if the table doesn’t have any inputs? I only see action buttons. Or are you referring to the editable requisition screen (aka requisition product grid)?

  • View Shipment (#!/orders/id) Question: do you mean View Orders? Why is this impacted if the table doesn’t have any inputs? I only see action buttons. Or are you referring to the editable shipment (aka the fulfill orders table)?

  • Issue (#!/stockmangement/issue/id)

  • Receive (#!/stockmangement/receive/id)

  • Physical Inventory (#!/physicalInventory/id)

  • Adjustments (#!/adjustment/id)

  • What about Fulfill Orders?

  • Should we be including the “batch approval” of requisitions?

Perhaps we can schedule a call if it would be easier to connect that way. I just want to make sure I’m understanding your proposal and which options will impact which screens. Thank you again for pulling this together and hopefully we can clarify this soon and I can send across to the PC.

Thanks,

Mary Jo

From: Nikodem Graczewski ngraczewski@soldevelo.com

Date: Tuesday, June 5, 2018 at 12:16 AM

To: Josh Zamor josh.zamor@villagereach.org

Cc: Mary Jo Kochendorfer maryjo.kochendorfer@villagereach.org, OpenLMIS Dev openlmis-dev@googlegroups.com

Subject: Re: [openlmis-dev] Re: Error behavior on the table forms

Thanks for the feedback!

The reasoning behind option #3 totally makes sense to me.

About the questions I’m not sure I understand what you mean by “finding errors across line items”? Does it mean we want to bring user to the first error in the table after we attempt to submit it, or is it something else?

Best regards,

Nikodem

Nikodem Graczewski

Software Developer

ngraczewski@soldevelo.com

On Tue, Jun 5, 2018 at 12:59 AM, Josh Zamor josh.zamor@villagereach.org wrote:

Thanks for the clarification Nikodem, now I understand better.

For line item entry only then:

I still think I favor option #3, identify errors in a line item only after some work has been done in the line item, and then you shift away from it. As well (as always) as identifying all errors when attempting to submit the entries. I recognize this is one of the hardest options and also that it’s likely personal preference - that is I prefer a UX that has fewer visual warnings as I’m working on an item, and instead prefer those visual warnings to be raised after I think I’m done: I shift to another line item or I click a button that is me indicating I’m done. I also recognize this isn’t what the Requisition screen does (option #2), as currently it raises those visual indicators within the line item I’m working on as soon as I start working on the line item and something isn’t right.

Between those two options my preference as I said is #3, however the UX between the two is so small that I can’t say I’d encourage investing significant effort in it. Using option #2 with a smaller LOE seems fine by me.

Do we have an approach to finding errors across line items? I can imagine as we get into budgets for Requisitions we’ll have the need. Would that change the LOE for anything here?

Best,

Josh

On Jun 4, 2018, at 2:54 PM, Nikodem Graczewski ngraczewski@soldevelo.com wrote:

Yes, if we decide to pick a different approach than the one we’re already using for product grid, this changes will also affect the requisition product grid. The list of screens that will be affected by this is as follows:

  • View Proof of Delivery (#!/pod/id)
  • View Requisition (#!/requisition/id)
  • View Shipment (#!/orders/id)
  • Issue (#!/stockmangement/issue/id)
  • Receive (#!/stockmangement/receive/id)
  • Physical Inventory (#!/physicalInventory/id)
  • Adjustments (#!/adjustment/id)

Hopefully I didn’t miss any screen.

Best regards,

Nikodem

Nikodem Graczewski

Software Developer

ngraczewski@soldevelo.com

On Fri, Jun 1, 2018 at 8:39 PM, Mary Jo Kochendorfer maryjo.kochendorfer@villagereach.org wrote:

Nikodem,

Unfortunately I’m still a bit confused. I too share the concern that Brandon voiced regarding the R&R product grid table.

Could you clarify if you are proposing that the decision made on the pattern for “table forms” impacts the R&R product grid table attached? I was confused when you stated that the Requisition View is a table form since that does not have any inputs or error messages.

If there is any impact on the R&R product grid, we cannot move forward with choosing a table form error pattern without discussing with the Product Committee. We must propose all UI changes since it will impact current implementations of OpenLMIS v3 in Malawi. It would be great if you could pull together the options and clear examples and present at the next PC to ensure we have the whole communities input. I know it might feel arduous to also present to the PC but I do think this will impact the user experience enough that it is important to consider the PC’s perspective.

Thank you for pulling this proposal together and clarifying what the impact is. Let me know if you have any questions about what I’m asking for in terms of raising to the PC.

Thanks,

Mary Jo

From: OpenLMIS Dev openlmis-dev@googlegroups.com on behalf of Nikodem Graczewski ngraczewski@soldevelo.com

Date: Thursday, May 31, 2018 at 11:10 AM

To: Brandon Bowersox-Johnson brandon.bowersox-johnson@villagereach.org

Cc: OpenLMIS Dev openlmis-dev@googlegroups.com

Subject: Re: [openlmis-dev] Re: Error behavior on the table forms

I might have not expressed myself well enough if it comes to the distinction between table and regular forms, for which I’m sorry.

To clarify, by table form I mean any table that has any inputs inside (Requisition View, Proof of Delivery View, Shipment View and Stock Management Adjustment, Receive, Issue and Physical Inventory screens). Line item entry is the best phrase to describe it (thanks Josh!).

Everything that doesn’t reside directly inside a table (table filters, facility/program select, searches etc) should be considered a standard form.

The main purpose of this thread is to choose the best approach for table forms as we’re using three different approaches to them across the system. The standard forms are already well documented and consistent (I couldn’t find a single form, which wouldn’t work the we expect it to). I agree with Josh on that we want to have two different approaches here.

I hope that clarifies any confusion I might have introduced.

Best regards,

Nikodem

Nikodem Graczewski

Software Developer

ngraczewski@soldevelo.com

On Thu, May 31, 2018 at 5:03 PM, Brandon Bowersox-Johnson <brandon.bowersox-johnson@villagereach.org > wrote:

I also feel that the line-item entry—especially the R&R Form—is a special case that justifies a special solution. OpenLMIS v3 has already chosen solution #3 for the R&R Form so far (from v3.0.0 to v3.3.0). I believe stakeholders and end-users are counting on that current behavior. The validation of those R&R Forms is a very detailed, important feature, and making any changes to it would require Product Committee involvement too.

As you evaluate how to handle errors consistently, I suggest looking at the other table forms separately from the R&R Form, and also look at non-form error handling (eg, filter, search, etc). That way if you are proposing changes, everyone can understand what parts of the system you would change.

I’m sorry I missed the Technical Committee (I have a conflicting commitment), but thanks for allowing me to share input.

-Brandon

From: openlmis-dev@googlegroups.com on behalf of "josh.zamor@openlmis.org " josh.zamor@openlmis.org

Date: Wednesday, May 30, 2018 at 10:01 PM

To: OpenLMIS Dev openlmis-dev@googlegroups.com

Subject: [openlmis-dev] Re: Error behavior on the table forms

I expressed this during the call, but I feel like option #3 makes the most sense for line item type entry. Moreover though I wonder if we really are looking for one approach to all situations? e.g. I don’t feel like option #3 makes any sense for the Filter component or the general search component with My Facility / Supervised Facility and other options (btw did we ever settle on a simple name for that thing?). For filter or search it seems like option #1 seems to make the most sense.

My opinion here isn’t set in stone by any means but it does seem like having at-least two approaches makes sense: option #1 should be true for everything and the next option should make the most sense for line item type entry.

For clarity I think the wiki page presents the options in a slightly different order from top to bottom than what we are using here.

Best,

Josh

On Tuesday, May 29, 2018 at 10:25:00 AM UTC-7, Nikodem Graczewski wrote:

Hello everyone,

as a follow up to the last Technical Committee meeting I’m bringing this topic to the dev group so we can decide which approach we would like to take on this matter.

There are 4 possible approaches we could take on how we want to display errors on the table forms (sorted with level of effort required - easiest to hardest):

  1. Mimic what the other forms do.
  1. Make errors appear after the fields has been touched.
  1. Make errors appear after we leave (focus on something outside) the table row.
  1. Same as 3, but also highlight table header.

To learn more about each of the approaches please visit the following link:

https://openlmis.atlassian.net/wiki/spaces/OP/pages/378929173/OpenLMIS+UI±+Error+behavior+approaches

My two favorites are:

  • 1 - Mainly for consistency reasons. Implementing this approach would make all the forms (table or not) behave exactly the same across the whole system.
  • 2 - Early feedback for the user (errors are shown right after the input is dirty so the user can correct the errors early) as well as the fact we already have this approach implemented and it works fine with the pagination component.

Please, share you opinions on the matter.

Best regards,

Nikodem

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to
openlmis-dev@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/8a4a37b3-9f3a-4237-bf71-fa17dc6c21d7%40googlegroups.com
.

For more options, visit
https://groups.google.com/d/optout
.

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to
openlmis-dev@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/2F463C89-2265-4916-A42C-F6A0EA87D584%40villagereach.org
.

For more options, visit
https://groups.google.com/d/optout
.

Error! Filename not specified.**

SolDevelo** Sp. z o.o. [LLC] / www.soldevelo.com

Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland

Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to
openlmis-dev@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/CAGOM9mW%2BjkRAG2UMQna3Qizqeip6oypjpzAyCi6qBRnF6KRj7A%40mail.gmail.com
.

For more options, visit
https://groups.google.com/d/optout
.

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to
openlmis-dev@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/02DA5B5A-716E-4D57-9FB9-6E2AB0C8898B%40villagereach.org
.

For more options, visit
https://groups.google.com/d/optout
.

**

SolDevelo** Sp. z o.o. [LLC] /
www.soldevelo.com

Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland

Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

You received this message because you are subscribed to a topic in the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this topic, visit
https://groups.google.com/d/topic/openlmis-dev/FTD6ta5PxWc/unsubscribe
.

To unsubscribe from this group and all its topics, send an email to
openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to
openlmis-dev@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/CAGOM9mVXaMAETbfw-CQUF2%3Dj%2B3EVBnxC%2B5qiuJ2h2jsAax%3Driw%40mail.gmail.com
.

For more options, visit
https://groups.google.com/d/optout
.

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to
openlmis-dev@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/FAFB3858-7799-428A-AB0D-49DBBF3EB981%40villagereach.org
.

For more options, visit
https://groups.google.com/d/optout
.

**

SolDevelo** Sp. z o.o. [LLC] /
www.soldevelo.com

Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland

Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41


(Josh Zamor) #10

Nikodem and Mary Jo,

No, by across I’m not referring to reading the line item from left to right or right to left. I mean across multiple line items and across a larger form. e.g. An error that displays when a Requisition exceeds it’s budget or a warning if during fulfillment a I fulfill more than one lot than was requested. I don’t think we do currently, I could easily be wrong, however I’m curious if that changes LOE for the different options.

Mary Jo,

Are you sure we need to run this by product committee? I could imagine that being more the case if we were proposing to change the Requisition behavior. Rather Nikodem is trying to reconcile the inconsistent UX error behavior we have in other parts, and I believe what we’re saying is that UX on the Requisition is good enough (and the lower LOE) to replicate elsewhere and achieve higher consistency.

Best,
Josh

···

On Jun 11, 2018, at 10:34 AM, Mary Jo Kochendorfer <maryjo.kochendorfer@villagereach.org<mailto:maryjo.kochendorfer@villagereach.org>> wrote:

Josh,
To clarify, are you talking about within a lineItem having error messages between to cells/fields within a LineItem? If so, we currently have that behavior/need within the requisition product grid as cells within one lineItem calculate off each other.

Nikodem,
I must admit that I’m still a bit confused and I want to make sure I’m clear on what you are proposing and the impact on the current system behavior. After reading this thread and the wiki<https://openlmis.atlassian.net/wiki/spaces/OP/pages/378929173/OpenLMIS+UI+-+Error+behavior+approaches>, I’m still confused. Would you be willing to review the following and make sure I didn’t misunderstand your proposal. If it is correct, we will need to bring this to the Product Committee. I suggest updating your current wiki<https://openlmis.atlassian.net/wiki/spaces/OP/pages/378929173/OpenLMIS+UI+-+Error+behavior+approaches> to clearly state 1. The current state, 2. The proposed options and 3. The impact. You could use the table I created below.

Below I’ve started to lay out a summarized view, but I still have open questions to you in red.

Current behavior
Screens are inconsistent. The following proposal is specifically looking at “Table Forms”. A table form is any table that has any inputs inside of the table or ‘lineItem entries’. Nikodem, to clarify does this include tables which don’t have editable fields/cells but have a column with action buttons? That’s not clear to me.

Proposed Options
The following are the 4 options are for Table forms: Nikodem, it would be useful to see a table like this

#

Option

Level of Effort

User Benefit

Performance Impact
Will the option slow down the experience for the user on 2G?

Screens which would change if this option is selected.

1

Mimic what the other forms do.
Nikodem, could you clarify what this option is? Mimic which form?

Tiny?

2

Make errors appear after the fields has been touched.

3

Make errors appear after we leave (focus on something outside) the table row.

When fields within a lineItem are dependent on each other the error won’t show until they focus away from the LineItem (row)

4

Same as 3, but also highlight the table header.

Depending on the option, the following screens may be impacted. See the above table for details on which would change based on the option.

  * Requisition Product grid (I’m including this because it is my understanding it would be impacted if we chose an option which is different than the current behavior. Or perhaps you are including this later, my apologies.)
  * View Proof of Delivery (#!/pod/id) Question: why is this impacted if the table doesn’t have any inputs? I only see action buttons. Or are you referring to the editable proof of delivery screen?
  * View Requisition (#!/requisition/id) Question: why is this impacted if the table doesn’t have any inputs? I only see action buttons. Or are you referring to the editable requisition screen (aka requisition product grid)?
  * View Shipment (#!/orders/id) Question: do you mean View Orders? Why is this impacted if the table doesn’t have any inputs? I only see action buttons. Or are you referring to the editable shipment (aka the fulfill orders table)?
  * Issue (#!/stockmangement/issue/id)
  * Receive (#!/stockmangement/receive/id)
  * Physical Inventory (#!/physicalInventory/id)
  * Adjustments (#!/adjustment/id)
  * What about Fulfill Orders?
  * Should we be including the “batch approval” of requisitions?

Perhaps we can schedule a call if it would be easier to connect that way. I just want to make sure I’m understanding your proposal and which options will impact which screens. Thank you again for pulling this together and hopefully we can clarify this soon and I can send across to the PC.

Thanks,
Mary Jo

From: Nikodem Graczewski <ngraczewski@soldevelo.com<mailto:ngraczewski@soldevelo.com>>
Date: Tuesday, June 5, 2018 at 12:16 AM
To: Josh Zamor <josh.zamor@villagereach.org<mailto:josh.zamor@villagereach.org>>
Cc: Mary Jo Kochendorfer <maryjo.kochendorfer@villagereach.org<mailto:maryjo.kochendorfer@villagereach.org>>, OpenLMIS Dev <openlmis-dev@googlegroups.com<mailto:openlmis-dev@googlegroups.com>>
Subject: Re: [openlmis-dev] Re: Error behavior on the table forms

Thanks for the feedback!

The reasoning behind option #3 totally makes sense to me.

About the questions I'm not sure I understand what you mean by "finding errors across line items"? Does it mean we want to bring user to the first error in the table after we attempt to submit it, or is it something else?

Best regards,
Nikodem

Nikodem Graczewski
Software Developer
ngraczewski@soldevelo.com<mailto:ngraczewski@soldevelo.com>

On Tue, Jun 5, 2018 at 12:59 AM, Josh Zamor <josh.zamor@villagereach.org<mailto:josh.zamor@villagereach.org>> wrote:
Thanks for the clarification Nikodem, now I understand better.

For line item entry only then:

I still think I favor option #3, identify errors in a line item only after some work has been done in the line item, and then you shift away from it. As well (as always) as identifying all errors when attempting to submit the entries. I recognize this is one of the hardest options and also that it’s likely personal preference - that is I prefer a UX that has fewer visual warnings as I’m working on an item, and instead prefer those visual warnings to be raised after I think I’m done: I shift to another line item or I click a button that is me indicating I’m done. I also recognize this isn’t what the Requisition screen does (option #2), as currently it raises those visual indicators within the line item I’m working on as soon as I start working on the line item and something isn’t right.

Between those two options my preference as I said is #3, however the UX between the two is so small that I can’t say I’d encourage investing significant effort in it. Using option #2 with a smaller LOE seems fine by me.

Do we have an approach to finding errors across line items? I can imagine as we get into budgets for Requisitions we’ll have the need. Would that change the LOE for anything here?

Best,
Josh

On Jun 4, 2018, at 2:54 PM, Nikodem Graczewski <ngraczewski@soldevelo.com<mailto:ngraczewski@soldevelo.com>> wrote:

Yes, if we decide to pick a different approach than the one we're already using for product grid, this changes will also affect the requisition product grid. The list of screens that will be affected by this is as follows:

  * View Proof of Delivery (#!/pod/id)
  * View Requisition (#!/requisition/id)
  * View Shipment (#!/orders/id)
  * Issue (#!/stockmangement/issue/id)
  * Receive (#!/stockmangement/receive/id)
  * Physical Inventory (#!/physicalInventory/id)
  * Adjustments (#!/adjustment/id)

Hopefully I didn't miss any screen.

Best regards,
Nikodem

Nikodem Graczewski
Software Developer
ngraczewski@soldevelo.com<mailto:ngraczewski@soldevelo.com>

On Fri, Jun 1, 2018 at 8:39 PM, Mary Jo Kochendorfer <maryjo.kochendorfer@villagereach.org<mailto:maryjo.kochendorfer@villagereach.org>> wrote:
Nikodem,
Unfortunately I’m still a bit confused. I too share the concern that Brandon voiced regarding the R&R product grid table.

Could you clarify if you are proposing that the decision made on the pattern for “table forms” impacts the R&R product grid table attached? I was confused when you stated that the Requisition View is a table form since that does not have any inputs or error messages.

If there is any impact on the R&R product grid, we cannot move forward with choosing a table form error pattern without discussing with the Product Committee. We must propose all UI changes since it will impact current implementations of OpenLMIS v3 in Malawi. It would be great if you could pull together the options and clear examples and present at the next PC to ensure we have the whole communities input. I know it might feel arduous to also present to the PC but I do think this will impact the user experience enough that it is important to consider the PC’s perspective.

Thank you for pulling this proposal together and clarifying what the impact is. Let me know if you have any questions about what I’m asking for in terms of raising to the PC.

Thanks,
Mary Jo

From: OpenLMIS Dev <openlmis-dev@googlegroups.com<mailto:openlmis-dev@googlegroups.com>> on behalf of Nikodem Graczewski <ngraczewski@soldevelo.com<mailto:ngraczewski@soldevelo.com>>
Date: Thursday, May 31, 2018 at 11:10 AM
To: Brandon Bowersox-Johnson <brandon.bowersox-johnson@villagereach.org<mailto:brandon.bowersox-johnson@villagereach.org>>
Cc: OpenLMIS Dev <openlmis-dev@googlegroups.com<mailto:openlmis-dev@googlegroups.com>>
Subject: Re: [openlmis-dev] Re: Error behavior on the table forms

I might have not expressed myself well enough if it comes to the distinction between table and regular forms, for which I'm sorry.

To clarify, by table form I mean any table that has any inputs inside (Requisition View, Proof of Delivery View, Shipment View and Stock Management Adjustment, Receive, Issue and Physical Inventory screens). Line item entry is the best phrase to describe it (thanks Josh!).

Everything that doesn't reside directly inside a table (table filters, facility/program select, searches etc) should be considered a standard form.

The main purpose of this thread is to choose the best approach for table forms as we're using three different approaches to them across the system. The standard forms are already well documented and consistent (I couldn't find a single form, which wouldn't work the we expect it to). I agree with Josh on that we want to have two different approaches here.

I hope that clarifies any confusion I might have introduced.

Best regards,
Nikodem

Nikodem Graczewski
Software Developer
ngraczewski@soldevelo.com<mailto:ngraczewski@soldevelo.com>

On Thu, May 31, 2018 at 5:03 PM, Brandon Bowersox-Johnson <brandon.bowersox-johnson@villagereach.org<mailto:brandon.bowersox-johnson@villagereach.org>> wrote:
I also feel that the line-item entry—especially the R&R Form—is a special case that justifies a special solution. OpenLMIS v3 has already chosen solution #3 for the R&R Form so far (from v3.0.0 to v3.3.0). I believe stakeholders and end-users are counting on that current behavior. The validation of those R&R Forms is a very detailed, important feature, and making any changes to it would require Product Committee involvement too.

As you evaluate how to handle errors consistently, I suggest looking at the other table forms separately from the R&R Form, and also look at non-form error handling (eg, filter, search, etc). That way if you are proposing changes, everyone can understand what parts of the system you would change.

I’m sorry I missed the Technical Committee (I have a conflicting commitment), but thanks for allowing me to share input.

-Brandon

From: <openlmis-dev@googlegroups.com<mailto:openlmis-dev@googlegroups.com>> on behalf of "josh.zamor@openlmis.org<mailto:josh.zamor@openlmis.org>" <josh.zamor@openlmis.org<mailto:josh.zamor@openlmis.org>>
Date: Wednesday, May 30, 2018 at 10:01 PM
To: OpenLMIS Dev <openlmis-dev@googlegroups.com<mailto:openlmis-dev@googlegroups.com>>
Subject: [openlmis-dev] Re: Error behavior on the table forms

I expressed this during the call, but I feel like option #3 makes the most sense for line item type entry. Moreover though I wonder if we really are looking for one approach to all situations? e.g. I don't feel like option #3 makes any sense for the Filter component or the general search component with My Facility / Supervised Facility and other options (btw did we ever settle on a simple name for that thing?). For filter or search it seems like option #1 seems to make the most sense.

My opinion here isn't set in stone by any means but it does seem like having at-least two approaches makes sense: option #1 should be true for everything and the next option should make the most sense for line item type entry.

For clarity I think the wiki page presents the options in a slightly different order from top to bottom than what we are using here.

Best,
Josh

On Tuesday, May 29, 2018 at 10:25:00 AM UTC-7, Nikodem Graczewski wrote:
Hello everyone,

as a follow up to the last Technical Committee meeting I'm bringing this topic to the dev group so we can decide which approach we would like to take on this matter.

There are 4 possible approaches we could take on how we want to display errors on the table forms (sorted with level of effort required - easiest to hardest):

  1. Mimic what the other forms do.
  2. Make errors appear after the fields has been touched.
  3. Make errors appear after we leave (focus on something outside) the table row.
  4. Same as 3, but also highlight table header.

To learn more about each of the approaches please visit the following link:
https://openlmis.atlassian.net/wiki/spaces/OP/pages/378929173/OpenLMIS+UI+-+Error+behavior+approaches<https://www.google.com/url?q=https%3A%2F%2Fopenlmis.atlassian.net%2Fwiki%2Fspaces%2FOP%2Fpages%2F378929173%2FOpenLMIS%2BUI%2B-%2BError%2Bbehavior%2Bapproaches&sa=D&sntz=1&usg=AFQjCNF2vDCG8MSDMA5qYJnSjvQCypInbA>

My two favorites are:

  * 1 - Mainly for consistency reasons. Implementing this approach would make all the forms (table or not) behave exactly the same across the whole system.
  * 2 - Early feedback for the user (errors are shown right after the input is dirty so the user can correct the errors early) as well as the fact we already have this approach implemented and it works fine with the pagination component.

Please, share you opinions on the matter.

Best regards,
Nikodem
--
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email toopenlmis-dev+unsubscribe@googlegroups.com<mailto:openlmis-dev+unsubscribe@googlegroups.com>.
To post to this group, send email to openlmis-dev@googlegroups.com<mailto:openlmis-dev@googlegroups.com>.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/8a4a37b3-9f3a-4237-bf71-fa17dc6c21d7%40googlegroups.com<https://groups.google.com/d/msgid/openlmis-dev/8a4a37b3-9f3a-4237-bf71-fa17dc6c21d7%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email toopenlmis-dev+unsubscribe@googlegroups.com<mailto:openlmis-dev+unsubscribe@googlegroups.com>.
To post to this group, send email to openlmis-dev@googlegroups.com<mailto:openlmis-dev@googlegroups.com>.
To view this discussion on the web visithttps://groups.google.com/d/msgid/openlmis-dev/2F463C89-2265-4916-A42C-F6A0EA87D584%40villagereach.org<https://groups.google.com/d/msgid/openlmis-dev/2F463C89-2265-4916-A42C-F6A0EA87D584%40villagereach.org?utm_medium=email&utm_source=footer>.

For more options, visit https://groups.google.com/d/optout.

Error! Filename not specified.
SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com<http://www.soldevelo.com/>
Al. Zwycięstwa 96/98<https://maps.google.com/?q=Al.+Zwycięstwa+96/98&entry=gmail&source=g>, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41
--
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email toopenlmis-dev+unsubscribe@googlegroups.com<mailto:openlmis-dev+unsubscribe@googlegroups.com>.
To post to this group, send email to openlmis-dev@googlegroups.com<mailto:openlmis-dev@googlegroups.com>.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/CAGOM9mW%2BjkRAG2UMQna3Qizqeip6oypjpzAyCi6qBRnF6KRj7A%40mail.gmail.com<https://groups.google.com/d/msgid/openlmis-dev/CAGOM9mW%2BjkRAG2UMQna3Qizqeip6oypjpzAyCi6qBRnF6KRj7A%40mail.gmail.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email toopenlmis-dev+unsubscribe@googlegroups.com<mailto:openlmis-dev+unsubscribe@googlegroups.com>.
To post to this group, send email to openlmis-dev@googlegroups.com<mailto:openlmis-dev@googlegroups.com>.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/02DA5B5A-716E-4D57-9FB9-6E2AB0C8898B%40villagereach.org<https://groups.google.com/d/msgid/openlmis-dev/02DA5B5A-716E-4D57-9FB9-6E2AB0C8898B%40villagereach.org?utm_medium=email&utm_source=footer>.

For more options, visit https://groups.google.com/d/optout.

SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com<http://www.soldevelo.com/>
Al. Zwycięstwa 96/98<https://maps.google.com/?q=Al.+Zwycięstwa+96/98&entry=gmail&source=g>, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

--
You received this message because you are subscribed to a topic in the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openlmis-dev/FTD6ta5PxWc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openlmis-dev+unsubscribe@googlegroups.com<mailto:openlmis-dev+unsubscribe@googlegroups.com>.
To post to this group, send email to openlmis-dev@googlegroups.com<mailto:openlmis-dev@googlegroups.com>.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/CAGOM9mVXaMAETbfw-CQUF2%3Dj%2B3EVBnxC%2B5qiuJ2h2jsAax%3Driw%40mail.gmail.com<https://groups.google.com/d/msgid/openlmis-dev/CAGOM9mVXaMAETbfw-CQUF2%3Dj%2B3EVBnxC%2B5qiuJ2h2jsAax%3Driw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com<mailto:openlmis-dev+unsubscribe@googlegroups.com>.
To post to this group, send email to openlmis-dev@googlegroups.com<mailto:openlmis-dev@googlegroups.com>.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/FAFB3858-7799-428A-AB0D-49DBBF3EB981%40villagereach.org<https://groups.google.com/d/msgid/openlmis-dev/FAFB3858-7799-428A-AB0D-49DBBF3EB981%40villagereach.org?utm_medium=email&utm_source=footer>.

For more options, visit https://groups.google.com/d/optout.

SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com<http://www.soldevelo.com/>
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41


(Mary Jo Kochendorfer) #11

Josh,

As I mentioned, I’m still confused on what is being proposed and the impact of the current requisition product grid error behavior. It is my understanding, after slacking with Nikodem, that based on the decision made there will be impacts on the requisition product grid (Nikodem refers to it as the View Requisition screen).

Given that, I stand by my request to have this proposal brought to the PC due to its impact on current implementations. If we were suggesting to use the View Requisition table form as the standard and make other screens align, then I don’t think it would be necessary.

Mary Jo

···

From: Josh Zamor josh.zamor@villagereach.org

Date: Monday, June 11, 2018 at 1:02 PM

To: Mary Jo Kochendorfer maryjo.kochendorfer@villagereach.org

Cc: Nikodem Graczewski ngraczewski@soldevelo.com, OpenLMIS Dev openlmis-dev@googlegroups.com

Subject: Re: [openlmis-dev] Error behavior on the table forms

Nikodem and Mary Jo,

No, by across I’m not referring to reading the line item from left to right or right to left. I mean across multiple line items and across a larger form. e.g. An error that displays when a Requisition exceeds it’s budget or a warning if during fulfillment a I fulfill more than one lot than was requested. I don’t think we do currently, I could easily be wrong, however I’m curious if that changes LOE for the different options.

Mary Jo,

Are you sure we need to run this by product committee? I could imagine that being more the case if we were proposing to change the Requisition behavior. Rather Nikodem is trying to reconcile the inconsistent UX error behavior we have in other parts, and I believe what we’re saying is that UX on the Requisition is good enough (and the lower LOE) to replicate elsewhere and achieve higher consistency.

Best,

Josh

On Jun 11, 2018, at 10:34 AM, Mary Jo Kochendorfer maryjo.kochendorfer@villagereach.org wrote:

Josh,

To clarify, are you talking about within a lineItem having error messages between to cells/fields within a LineItem? If so, we currently have that behavior/need within the requisition product grid as cells within one lineItem calculate off each other.

Nikodem,

I must admit that I’m still a bit confused and I want to make sure I’m clear on what you are proposing and the impact on the current system behavior. After reading this thread and the wiki , I’m still confused. Would you be willing to review the following and make sure I didn’t misunderstand your proposal. If it is correct, we will need to bring this to the Product Committee. I suggest updating your current wiki to clearly state 1. The current state, 2. The proposed options and 3. The impact. You could use the table I created below.

Below I’ve started to lay out a summarized view, but I still have open questions to you in red.

Current behavior

Screens are inconsistent. The following proposal is specifically looking at “Table Forms”. A table form is any table that has any inputs inside of the table or ‘lineItem entries’. Nikodem, to clarify does this include tables which don’t have editable fields/cells but have a column with action buttons? That’s not clear to me.


Proposed Options

The following are the 4 options are for Table forms: Nikodem, it would be useful to see a table like this

#

Option

Level of Effort

User Benefit

**Performance Impact **

Will the option slow down the experience for the user on 2G?

Screens which would change if this option is selected.

1

Mimic what the other forms do.

Nikodem, could you clarify what this option is? Mimic which form?

Tiny?

2

Make errors appear after the fields has been touched.

3

Make errors appear after we leave (focus on something outside) the table row.

When fields within a lineItem are dependent on each other the error won’t show until they focus away from the LineItem (row)

4

Same as 3, but also highlight the table header.

Depending on the option, the following screens may be impacted. See the above table for details on which would change based on the option.

  • Requisition Product grid (I’m including this because it is my understanding it would be impacted if we chose an option which is different than the current behavior. Or perhaps you are including this later, my apologies.)
  • View Proof of Delivery (#!/pod/id) Question: why is this impacted if the table doesn’t have any inputs? I only see action buttons. Or are you referring to the editable proof of delivery screen?
  • View Requisition (#!/requisition/id) Question: why is this impacted if the table doesn’t have any inputs? I only see action buttons. Or are you referring to the editable requisition screen (aka requisition product grid)?
  • View Shipment (#!/orders/id) Question: do you mean View Orders? Why is this impacted if the table doesn’t have any inputs? I only see action buttons. Or are you referring to the editable shipment (aka the fulfill orders table)?
  • Issue (#!/stockmangement/issue/id)
  • Receive (#!/stockmangement/receive/id)
  • Physical Inventory (#!/physicalInventory/id)
  • Adjustments (#!/adjustment/id)
  • What about Fulfill Orders?
  • Should we be including the “batch approval” of requisitions?

Perhaps we can schedule a call if it would be easier to connect that way. I just want to make sure I’m understanding your proposal and which options will impact which screens. Thank you again for pulling this together and hopefully we can clarify this soon and I can send across to the PC.

Thanks,

Mary Jo

**From: **Nikodem Graczewski ngraczewski@soldevelo.com

**Date: **Tuesday, June 5, 2018 at 12:16 AM

**To: **Josh Zamor josh.zamor@villagereach.org

**Cc: **Mary Jo Kochendorfer maryjo.kochendorfer@villagereach.org, OpenLMIS Dev openlmis-dev@googlegroups.com

**Subject: **Re: [openlmis-dev] Re: Error behavior on the table forms

Thanks for the feedback!

The reasoning behind option #3 totally makes sense to me.

About the questions I’m not sure I understand what you mean by “finding errors across line items”? Does it mean we want to bring user to the first error in the table after we attempt to submit it, or is it something else?

Best regards,

Nikodem

Nikodem Graczewski

Software Developer

ngraczewski@soldevelo.com

On Tue, Jun 5, 2018 at 12:59 AM, Josh Zamor josh.zamor@villagereach.org wrote:

Thanks for the clarification Nikodem, now I understand better.

For line item entry only then:

I still think I favor option #3, identify errors in a line item only after some work has been done in the line item, and then you shift away from it. As well (as always) as identifying all errors when attempting to submit the entries. I recognize this is one of the hardest options and also that it’s likely personal preference - that is I prefer a UX that has fewer visual warnings as I’m working on an item, and instead prefer those visual warnings to be raised after I think I’m done: I shift to another line item or I click a button that is me indicating I’m done. I also recognize this isn’t what the Requisition screen does (option #2), as currently it raises those visual indicators within the line item I’m working on as soon as I start working on the line item and something isn’t right.

Between those two options my preference as I said is #3, however the UX between the two is so small that I can’t say I’d encourage investing significant effort in it. Using option #2 with a smaller LOE seems fine by me.

Do we have an approach to finding errors across line items? I can imagine as we get into budgets for Requisitions we’ll have the need. Would that change the LOE for anything here?

Best,

Josh

On Jun 4, 2018, at 2:54 PM, Nikodem Graczewski ngraczewski@soldevelo.com wrote:

Yes, if we decide to pick a different approach than the one we’re already using for product grid, this changes will also affect the requisition product grid. The list of screens that will be affected by this is as follows:

  • View Proof of Delivery (#!/pod/id)
  • View Requisition (#!/requisition/id)
  • View Shipment (#!/orders/id)
  • Issue (#!/stockmangement/issue/id)
  • Receive (#!/stockmangement/receive/id)
  • Physical Inventory (#!/physicalInventory/id)
  • Adjustments (#!/adjustment/id)

Hopefully I didn’t miss any screen.

Best regards,

Nikodem

Nikodem Graczewski

Software Developer

ngraczewski@soldevelo.com

On Fri, Jun 1, 2018 at 8:39 PM, Mary Jo Kochendorfer maryjo.kochendorfer@villagereach.org wrote:

Nikodem,

Unfortunately I’m still a bit confused. I too share the concern that Brandon voiced regarding the R&R product grid table.

Could you clarify if you are proposing that the decision made on the pattern for “table forms” impacts the R&R product grid table attached? I was confused when you stated that the Requisition View is a table form since that does not have any inputs or error messages.

If there is any impact on the R&R product grid, we cannot move forward with choosing a table form error pattern without discussing with the Product Committee. We must propose all UI changes since it will impact current implementations of OpenLMIS v3 in Malawi. It would be great if you could pull together the options and clear examples and present at the next PC to ensure we have the whole communities input. I know it might feel arduous to also present to the PC but I do think this will impact the user experience enough that it is important to consider the PC’s perspective.

Thank you for pulling this proposal together and clarifying what the impact is. Let me know if you have any questions about what I’m asking for in terms of raising to the PC.

Thanks,

Mary Jo

**From: **OpenLMIS Dev <openlmis-dev@googlegroups.com > on behalf of Nikodem Graczewski ngraczewski@soldevelo.com

**Date: **Thursday, May 31, 2018 at 11:10 AM

**To: **Brandon Bowersox-Johnson brandon.bowersox-johnson@villagereach.org

**Cc: **OpenLMIS Dev openlmis-dev@googlegroups.com

**Subject: **Re: [openlmis-dev] Re: Error behavior on the table forms

I might have not expressed myself well enough if it comes to the distinction between table and regular forms, for which I’m sorry.

To clarify, by table form I mean any table that has any inputs inside (Requisition View, Proof of Delivery View, Shipment View and Stock Management Adjustment, Receive, Issue and Physical Inventory screens). Line item entry is the best phrase to describe it (thanks Josh!).

Everything that doesn’t reside directly inside a table (table filters, facility/program select, searches etc) should be considered a standard form.

The main purpose of this thread is to choose the best approach for table forms as we’re using three different approaches to them across the system. The standard forms are already well documented and consistent (I couldn’t find a single form, which wouldn’t work the we expect it to). I agree with Josh on that we want to have two different approaches here.

I hope that clarifies any confusion I might have introduced.

Best regards,

Nikodem

Nikodem Graczewski

Software Developer

ngraczewski@soldevelo.com

On Thu, May 31, 2018 at 5:03 PM, Brandon Bowersox-Johnson brandon.bowersox-johnson@villagereach.org wrote:

I also feel that the line-item entry—especially the R&R Form—is a special case that justifies a special solution. OpenLMIS v3 has already chosen solution #3 for the R&R Form so far (from v3.0.0 to v3.3.0). I believe stakeholders and end-users are counting on that current behavior. The validation of those R&R Forms is a very detailed, important feature, and making any changes to it would require Product Committee involvement too.

As you evaluate how to handle errors consistently, I suggest looking at the other table forms separately from the R&R Form, and also look at non-form error handling (eg, filter, search, etc). That way if you are proposing changes, everyone can understand what parts of the system you would change.

I’m sorry I missed the Technical Committee (I have a conflicting commitment), but thanks for allowing me to share input.

-Brandon

**From: **<openlmis-dev@googlegroups.com > on behalf of "josh.zamor@openlmis.org" josh.zamor@openlmis.org

**Date: **Wednesday, May 30, 2018 at 10:01 PM

**To: **OpenLMIS Dev openlmis-dev@googlegroups.com

**Subject: **[openlmis-dev] Re: Error behavior on the table forms

I expressed this during the call, but I feel like option #3 makes the most sense for line item type entry. Moreover though I wonder if we really are looking for one approach to all situations? e.g. I don’t feel like option #3 makes any sense for the Filter component or the general search component with My Facility / Supervised Facility and other options (btw did we ever settle on a simple name for that thing?). For filter or search it seems like option #1 seems to make the most sense.

My opinion here isn’t set in stone by any means but it does seem like having at-least two approaches makes sense: option #1 should be true for everything and the next option should make the most sense for line item type entry.

For clarity I think the wiki page presents the options in a slightly different order from top to bottom than what we are using here.

Best,

Josh

On Tuesday, May 29, 2018 at 10:25:00 AM UTC-7, Nikodem Graczewski wrote:

Hello everyone,

as a follow up to the last Technical Committee meeting I’m bringing this topic to the dev group so we can decide which approach we would like to take on this matter.

There are 4 possible approaches we could take on how we want to display errors on the table forms (sorted with level of effort required - easiest to hardest):

  1. Mimic what the other forms do.
  1. Make errors appear after the fields has been touched.
  1. Make errors appear after we leave (focus on something outside) the table row.
  1. Same as 3, but also highlight table header.

To learn more about each of the approaches please visit the following link:

https://openlmis.atlassian.net/wiki/spaces/OP/pages/378929173/OpenLMIS+UI±+Error+behavior+approaches

My two favorites are:

  • 1 - Mainly for consistency reasons. Implementing this approach would make all the forms (table or not) behave exactly the same across the whole system.
  • 2 - Early feedback for the user (errors are shown right after the input is dirty so the user can correct the errors early) as well as the fact we already have this approach implemented and it works fine with the pagination component.

Please, share you opinions on the matter.

Best regards,

Nikodem

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email toopenlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/8a4a37b3-9f3a-4237-bf71-fa17dc6c21d7%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email toopenlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visithttps://groups.google.com/d/msgid/openlmis-dev/2F463C89-2265-4916-A42C-F6A0EA87D584%40villagereach.org.

For more options, visit https://groups.google.com/d/optout.

Error! Filename not specified.**

SolDevelo** Sp. z o.o. [LLC] / www.soldevelo.com

Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland

Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email toopenlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/CAGOM9mW%2BjkRAG2UMQna3Qizqeip6oypjpzAyCi6qBRnF6KRj7A%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email toopenlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/02DA5B5A-716E-4D57-9FB9-6E2AB0C8898B%40villagereach.org.

For more options, visit https://groups.google.com/d/optout.

**

SolDevelo** Sp. z o.o. [LLC] / www.soldevelo.com

Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland

Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

You received this message because you are subscribed to a topic in the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this topic, visit https://groups.google.com/d/topic/openlmis-dev/FTD6ta5PxWc/unsubscribe.

To unsubscribe from this group and all its topics, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/CAGOM9mVXaMAETbfw-CQUF2%3Dj%2B3EVBnxC%2B5qiuJ2h2jsAax%3Driw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/FAFB3858-7799-428A-AB0D-49DBBF3EB981%40villagereach.org.

For more options, visit https://groups.google.com/d/optout.

**

SolDevelo** Sp. z o.o. [LLC] / www.soldevelo.com

Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland

Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41


(Nikodem Graczewski) #12

Hi Mary Jo,

I will try to answer your questions the best I can

Nikodem, to clarify does this include tables which don’t have editable fields/cells but have a column with action buttons? That’s not clear to me.

They wouldn’t be affected as they are not showing any errors.

Nikodem, could you clarify what this option is? Mimic which form?

Basically any form that isn’t a table form. It would behave similar to User creation for example. So we wouldn’t get any feedback unless we click the submit button (Initiate on Requisition View - aka Product Grid - for example).

Question: why is this impacted if the table doesn’t have any inputs? I only see action buttons. Or are you referring to the editable proof of delivery screen?
Question: why is this impacted if the table doesn’t have any inputs? I only see action buttons. Or are you referring to the editable requisition screen (aka requisition product grid)?
Question: do you mean View Orders? Why is this impacted if the table doesn’t have any inputs? I only see action buttons. Or are you referring to the editable shipment (aka the fulfill orders table)?
What about Fulfill Orders?
Should we be including the “batch approval” of requisitions?

When I was referring to those screens I was using their names in the system (used for headers and/or breadcrumbs), which caused a little bit of confusion. To clarify here are screenshots of every screen with a table form:

Should we be including the “batch approval” of requisitions?

I didn’t include this screen as it is not part of the official release and potentially a subject to change heavily because of the amount of data displayed on it. It also is considered a table form though.

I have also added the requested recap table to the wiki document

Best Regards,
Nikodem


SolDevelo
Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

···

On Mon, Jun 11, 2018 at 11:13 PM, Mary Jo Kochendorfer maryjo.kochendorfer@villagereach.org wrote:

Josh,

As I mentioned, I’m still confused on what is being proposed and the impact of the current requisition product grid error behavior. It is my understanding, after slacking with Nikodem, that based on the decision made there will be impacts on the requisition product grid (Nikodem refers to it as the View Requisition screen).

Given that, I stand by my request to have this proposal brought to the PC due to its impact on current implementations. If we were suggesting to use the View Requisition table form as the standard and make other screens align, then I don’t think it would be necessary.

Mary Jo

From: Josh Zamor josh.zamor@villagereach.org

Date: Monday, June 11, 2018 at 1:02 PM

To: Mary Jo Kochendorfer maryjo.kochendorfer@villagereach.org

Cc: Nikodem Graczewski ngraczewski@soldevelo.com, OpenLMIS Dev openlmis-dev@googlegroups.com

Subject: Re: [openlmis-dev] Error behavior on the table forms

Nikodem and Mary Jo,

No, by across I’m not referring to reading the line item from left to right or right to left. I mean across multiple line items and across a larger form. e.g. An error that displays when a Requisition exceeds it’s budget or a warning if during fulfillment a I fulfill more than one lot than was requested. I don’t think we do currently, I could easily be wrong, however I’m curious if that changes LOE for the different options.

Mary Jo,

Are you sure we need to run this by product committee? I could imagine that being more the case if we were proposing to change the Requisition behavior. Rather Nikodem is trying to reconcile the inconsistent UX error behavior we have in other parts, and I believe what we’re saying is that UX on the Requisition is good enough (and the lower LOE) to replicate elsewhere and achieve higher consistency.

Best,

Josh

On Jun 11, 2018, at 10:34 AM, Mary Jo Kochendorfer maryjo.kochendorfer@villagereach.org wrote:

Josh,

To clarify, are you talking about within a lineItem having error messages between to cells/fields within a LineItem? If so, we currently have that behavior/need within the requisition product grid as cells within one lineItem calculate off each other.

Nikodem,

I must admit that I’m still a bit confused and I want to make sure I’m clear on what you are proposing and the impact on the current system behavior. After reading this thread and the wiki , I’m still confused. Would you be willing to review the following and make sure I didn’t misunderstand your proposal. If it is correct, we will need to bring this to the Product Committee. I suggest updating your current wiki to clearly state 1. The current state, 2. The proposed options and 3. The impact. You could use the table I created below.

Below I’ve started to lay out a summarized view, but I still have open questions to you in red.

Current behavior

Screens are inconsistent. The following proposal is specifically looking at “Table Forms”. A table form is any table that has any inputs inside of the table or ‘lineItem entries’. Nikodem, to clarify does this include tables which don’t have editable fields/cells but have a column with action buttons? That’s not clear to me.


Proposed Options

The following are the 4 options are for Table forms: Nikodem, it would be useful to see a table like this

#

Option

Level of Effort

User Benefit

**Performance Impact **

Will the option slow down the experience for the user on 2G?

Screens which would change if this option is selected.

1

Mimic what the other forms do.

Nikodem, could you clarify what this option is? Mimic which form?

Tiny?

2

Make errors appear after the fields has been touched.

3

Make errors appear after we leave (focus on something outside) the table row.

When fields within a lineItem are dependent on each other the error won’t show until they focus away from the LineItem (row)

4

Same as 3, but also highlight the table header.

Depending on the option, the following screens may be impacted. See the above table for details on which would change based on the option.

  • Requisition Product grid (I’m including this because it is my understanding it would be impacted if we chose an option which is different than the current behavior. Or perhaps you are including this later, my apologies.)
  • View Proof of Delivery (#!/pod/id) Question: why is this impacted if the table doesn’t have any inputs? I only see action buttons. Or are you referring to the editable proof of delivery screen?
  • View Requisition (#!/requisition/id) Question: why is this impacted if the table doesn’t have any inputs? I only see action buttons. Or are you referring to the editable requisition screen (aka requisition product grid)?
  • View Shipment (#!/orders/id) Question: do you mean View Orders? Why is this impacted if the table doesn’t have any inputs? I only see action buttons. Or are you referring to the editable shipment (aka the fulfill orders table)?
  • Issue (#!/stockmangement/issue/id)
  • Receive (#!/stockmangement/receive/id)
  • Physical Inventory (#!/physicalInventory/id)
  • Adjustments (#!/adjustment/id)
  • What about Fulfill Orders?
  • Should we be including the “batch approval” of requisitions?
    Perhaps we can schedule a call if it would be easier to connect that way. I just want to make sure I’m understanding your proposal and which options will impact which screens. Thank you again for pulling this together and hopefully we can clarify this soon and I can send across to the PC.

Thanks,

Mary Jo

**From: **Nikodem Graczewski ngraczewski@soldevelo.com

**Date: **Tuesday, June 5, 2018 at 12:16 AM

**To: **Josh Zamor josh.zamor@villagereach.org

**Cc: **Mary Jo Kochendorfer maryjo.kochendorfer@villagereach.org, OpenLMIS Dev openlmis-dev@googlegroups.com

**Subject: **Re: [openlmis-dev] Re: Error behavior on the table forms

Thanks for the feedback!

The reasoning behind option #3 totally makes sense to me.

About the questions I’m not sure I understand what you mean by “finding errors across line items”? Does it mean we want to bring user to the first error in the table after we attempt to submit it, or is it something else?

Best regards,

Nikodem

Nikodem Graczewski

Software Developer

ngraczewski@soldevelo.com

On Tue, Jun 5, 2018 at 12:59 AM, Josh Zamor josh.zamor@villagereach.org wrote:

Thanks for the clarification Nikodem, now I understand better.

For line item entry only then:

I still think I favor option #3, identify errors in a line item only after some work has been done in the line item, and then you shift away from it. As well (as always) as identifying all errors when attempting to submit the entries. I recognize this is one of the hardest options and also that it’s likely personal preference - that is I prefer a UX that has fewer visual warnings as I’m working on an item, and instead prefer those visual warnings to be raised after I think I’m done: I shift to another line item or I click a button that is me indicating I’m done. I also recognize this isn’t what the Requisition screen does (option #2), as currently it raises those visual indicators within the line item I’m working on as soon as I start working on the line item and something isn’t right.

Between those two options my preference as I said is #3, however the UX between the two is so small that I can’t say I’d encourage investing significant effort in it. Using option #2 with a smaller LOE seems fine by me.

Do we have an approach to finding errors across line items? I can imagine as we get into budgets for Requisitions we’ll have the need. Would that change the LOE for anything here?

Best,

Josh

On Jun 4, 2018, at 2:54 PM, Nikodem Graczewski ngraczewski@soldevelo.com wrote:

Yes, if we decide to pick a different approach than the one we’re already using for product grid, this changes will also affect the requisition product grid. The list of screens that will be affected by this is as follows:

  • View Proof of Delivery (#!/pod/id)
  • View Requisition (#!/requisition/id)
  • View Shipment (#!/orders/id)
  • Issue (#!/stockmangement/issue/id)
  • Receive (#!/stockmangement/receive/id)
  • Physical Inventory (#!/physicalInventory/id)
  • Adjustments (#!/adjustment/id)
    Hopefully I didn’t miss any screen.

Best regards,

Nikodem

Nikodem Graczewski

Software Developer

ngraczewski@soldevelo.com

On Fri, Jun 1, 2018 at 8:39 PM, Mary Jo Kochendorfer maryjo.kochendorfer@villagereach.org wrote:

Nikodem,

Unfortunately I’m still a bit confused. I too share the concern that Brandon voiced regarding the R&R product grid table.

Could you clarify if you are proposing that the decision made on the pattern for “table forms” impacts the R&R product grid table attached? I was confused when you stated that the Requisition View is a table form since that does not have any inputs or error messages.

If there is any impact on the R&R product grid, we cannot move forward with choosing a table form error pattern without discussing with the Product Committee. We must propose all UI changes since it will impact current implementations of OpenLMIS v3 in Malawi. It would be great if you could pull together the options and clear examples and present at the next PC to ensure we have the whole communities input. I know it might feel arduous to also present to the PC but I do think this will impact the user experience enough that it is important to consider the PC’s perspective.

Thank you for pulling this proposal together and clarifying what the impact is. Let me know if you have any questions about what I’m asking for in terms of raising to the PC.

Thanks,

Mary Jo

**From: **OpenLMIS Dev <openlmis-dev@googlegroups.com > on behalf of Nikodem Graczewski ngraczewski@soldevelo.com

**Date: **Thursday, May 31, 2018 at 11:10 AM

**To: **Brandon Bowersox-Johnson brandon.bowersox-johnson@villagereach.org

**Cc: **OpenLMIS Dev openlmis-dev@googlegroups.com

**Subject: **Re: [openlmis-dev] Re: Error behavior on the table forms

I might have not expressed myself well enough if it comes to the distinction between table and regular forms, for which I’m sorry.

To clarify, by table form I mean any table that has any inputs inside (Requisition View, Proof of Delivery View, Shipment View and Stock Management Adjustment, Receive, Issue and Physical Inventory screens). Line item entry is the best phrase to describe it (thanks Josh!).

Everything that doesn’t reside directly inside a table (table filters, facility/program select, searches etc) should be considered a standard form.

The main purpose of this thread is to choose the best approach for table forms as we’re using three different approaches to them across the system. The standard forms are already well documented and consistent (I couldn’t find a single form, which wouldn’t work the we expect it to). I agree with Josh on that we want to have two different approaches here.

I hope that clarifies any confusion I might have introduced.

Best regards,

Nikodem

Nikodem Graczewski

Software Developer

ngraczewski@soldevelo.com

On Thu, May 31, 2018 at 5:03 PM, Brandon Bowersox-Johnson brandon.bowersox-johnson@villagereach.org wrote:

I also feel that the line-item entry—especially the R&R Form—is a special case that justifies a special solution. OpenLMIS v3 has already chosen solution #3 for the R&R Form so far (from v3.0.0 to v3.3.0). I believe stakeholders and end-users are counting on that current behavior. The validation of those R&R Forms is a very detailed, important feature, and making any changes to it would require Product Committee involvement too.

As you evaluate how to handle errors consistently, I suggest looking at the other table forms separately from the R&R Form, and also look at non-form error handling (eg, filter, search, etc). That way if you are proposing changes, everyone can understand what parts of the system you would change.

I’m sorry I missed the Technical Committee (I have a conflicting commitment), but thanks for allowing me to share input.

-Brandon

**From: **<openlmis-dev@googlegroups.com > on behalf of "josh.zamor@openlmis.org" josh.zamor@openlmis.org

**Date: **Wednesday, May 30, 2018 at 10:01 PM

**To: **OpenLMIS Dev openlmis-dev@googlegroups.com

**Subject: **[openlmis-dev] Re: Error behavior on the table forms

I expressed this during the call, but I feel like option #3 makes the most sense for line item type entry. Moreover though I wonder if we really are looking for one approach to all situations? e.g. I don’t feel like option #3 makes any sense for the Filter component or the general search component with My Facility / Supervised Facility and other options (btw did we ever settle on a simple name for that thing?). For filter or search it seems like option #1 seems to make the most sense.

My opinion here isn’t set in stone by any means but it does seem like having at-least two approaches makes sense: option #1 should be true for everything and the next option should make the most sense for line item type entry.

For clarity I think the wiki page presents the options in a slightly different order from top to bottom than what we are using here.

Best,

Josh

On Tuesday, May 29, 2018 at 10:25:00 AM UTC-7, Nikodem Graczewski wrote:

Hello everyone,

as a follow up to the last Technical Committee meeting I’m bringing this topic to the dev group so we can decide which approach we would like to take on this matter.

There are 4 possible approaches we could take on how we want to display errors on the table forms (sorted with level of effort required - easiest to hardest):

  1. Mimic what the other forms do.
  2. Make errors appear after the fields has been touched.
  3. Make errors appear after we leave (focus on something outside) the table row.
  4. Same as 3, but also highlight table header.
    To learn more about each of the approaches please visit the following link:

https://openlmis.atlassian.net/wiki/spaces/OP/pages/378929173/OpenLMIS+UI±+Error+behavior+approaches

My two favorites are:

  • 1 - Mainly for consistency reasons. Implementing this approach would make all the forms (table or not) behave exactly the same across the whole system.
  • 2 - Early feedback for the user (errors are shown right after the input is dirty so the user can correct the errors early) as well as the fact we already have this approach implemented and it works fine with the pagination component.
    Please, share you opinions on the matter.

Best regards,

Nikodem

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email toopenlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/8a4a37b3-9f3a-4237-bf71-fa17dc6c21d7%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email toopenlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visithttps://groups.google.com/d/msgid/openlmis-dev/2F463C89-2265-4916-A42C-F6A0EA87D584%40villagereach.org.

For more options, visit https://groups.google.com/d/optout.

Error! Filename not specified.**

SolDevelo** Sp. z o.o. [LLC] / www.soldevelo.com

Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland

Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email toopenlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/CAGOM9mW%2BjkRAG2UMQna3Qizqeip6oypjpzAyCi6qBRnF6KRj7A%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email toopenlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/02DA5B5A-716E-4D57-9FB9-6E2AB0C8898B%40villagereach.org.

For more options, visit https://groups.google.com/d/optout.

**

SolDevelo** Sp. z o.o. [LLC] / www.soldevelo.com

Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland

Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

You received this message because you are subscribed to a topic in the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this topic, visit https://groups.google.com/d/topic/openlmis-dev/FTD6ta5PxWc/unsubscribe.

To unsubscribe from this group and all its topics, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/CAGOM9mVXaMAETbfw-CQUF2%3Dj%2B3EVBnxC%2B5qiuJ2h2jsAax%3Driw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/FAFB3858-7799-428A-AB0D-49DBBF3EB981%40villagereach.org.

For more options, visit https://groups.google.com/d/optout.

**

SolDevelo** Sp. z o.o. [LLC] / www.soldevelo.com

Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland

Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/47E41DF4-7131-42F4-8630-35509898B372%40villagereach.org.

For more options, visit https://groups.google.com/d/optout.

Nikodem Graczewski

Software Developer

ngraczewski@soldevelo.com


(Nikodem Graczewski) #13

Hello everyone,

since there wasn’t any arguments against using the approach #3, I will start writing tickets for updating the screens with this approach.

Here’s a list of the affected screens:

  • View Requisition (Product Grid)
  • Issue
  • Receive
  • Physical Inventory
  • Adjustments
    If there are any questions or different preferences, please let me know.

Best regards,
Nikodem


SolDevelo
Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

···

On Tue, Jun 12, 2018 at 9:03 AM, Nikodem Graczewski ngraczewski@soldevelo.com wrote:

Hi Mary Jo,

I will try to answer your questions the best I can

Nikodem, to clarify does this include tables which don’t have editable fields/cells but have a column with action buttons? That’s not clear to me.

They wouldn’t be affected as they are not showing any errors.

Nikodem, could you clarify what this option is? Mimic which form?

Basically any form that isn’t a table form. It would behave similar to User creation for example. So we wouldn’t get any feedback unless we click the submit button (Initiate on Requisition View - aka Product Grid - for example).

Question: why is this impacted if the table doesn’t have any inputs? I only see action buttons. Or are you referring to the editable proof of delivery screen?
Question: why is this impacted if the table doesn’t have any inputs? I only see action buttons. Or are you referring to the editable requisition screen (aka requisition product grid)?
Question: do you mean View Orders? Why is this impacted if the table doesn’t have any inputs? I only see action buttons. Or are you referring to the editable shipment (aka the fulfill orders table)?
What about Fulfill Orders?
Should we be including the “batch approval” of requisitions?

When I was referring to those screens I was using their names in the system (used for headers and/or breadcrumbs), which caused a little bit of confusion. To clarify here are screenshots of every screen with a table form:

  • View Proof of Delivery

  • View Requisition

  • View Shipment

  • Issue, Receive, Physical Inventory, Adjustments

Should we be including the “batch approval” of requisitions?

I didn’t include this screen as it is not part of the official release and potentially a subject to change heavily because of the amount of data displayed on it. It also is considered a table form though.

I have also added the requested recap table to the wiki document

Best Regards,
Nikodem

Nikodem Graczewski

Software Developer

ngraczewski@soldevelo.com

Nikodem Graczewski

Software Developer

ngraczewski@soldevelo.com

On Mon, Jun 11, 2018 at 11:13 PM, Mary Jo Kochendorfer maryjo.kochendorfer@villagereach.org wrote:

Josh,

As I mentioned, I’m still confused on what is being proposed and the impact of the current requisition product grid error behavior. It is my understanding, after slacking with Nikodem, that based on the decision made there will be impacts on the requisition product grid (Nikodem refers to it as the View Requisition screen).

Given that, I stand by my request to have this proposal brought to the PC due to its impact on current implementations. If we were suggesting to use the View Requisition table form as the standard and make other screens align, then I don’t think it would be necessary.

Mary Jo

From: Josh Zamor josh.zamor@villagereach.org

Date: Monday, June 11, 2018 at 1:02 PM

To: Mary Jo Kochendorfer maryjo.kochendorfer@villagereach.org

Cc: Nikodem Graczewski ngraczewski@soldevelo.com, OpenLMIS Dev openlmis-dev@googlegroups.com

Subject: Re: [openlmis-dev] Error behavior on the table forms

Nikodem and Mary Jo,

No, by across I’m not referring to reading the line item from left to right or right to left. I mean across multiple line items and across a larger form. e.g. An error that displays when a Requisition exceeds it’s budget or a warning if during fulfillment a I fulfill more than one lot than was requested. I don’t think we do currently, I could easily be wrong, however I’m curious if that changes LOE for the different options.

Mary Jo,

Are you sure we need to run this by product committee? I could imagine that being more the case if we were proposing to change the Requisition behavior. Rather Nikodem is trying to reconcile the inconsistent UX error behavior we have in other parts, and I believe what we’re saying is that UX on the Requisition is good enough (and the lower LOE) to replicate elsewhere and achieve higher consistency.

Best,

Josh

On Jun 11, 2018, at 10:34 AM, Mary Jo Kochendorfer maryjo.kochendorfer@villagereach.org wrote:

Josh,

To clarify, are you talking about within a lineItem having error messages between to cells/fields within a LineItem? If so, we currently have that behavior/need within the requisition product grid as cells within one lineItem calculate off each other.

Nikodem,

I must admit that I’m still a bit confused and I want to make sure I’m clear on what you are proposing and the impact on the current system behavior. After reading this thread and the wiki , I’m still confused. Would you be willing to review the following and make sure I didn’t misunderstand your proposal. If it is correct, we will need to bring this to the Product Committee. I suggest updating your current wiki to clearly state 1. The current state, 2. The proposed options and 3. The impact. You could use the table I created below.

Below I’ve started to lay out a summarized view, but I still have open questions to you in red.

Current behavior

Screens are inconsistent. The following proposal is specifically looking at “Table Forms”. A table form is any table that has any inputs inside of the table or ‘lineItem entries’. Nikodem, to clarify does this include tables which don’t have editable fields/cells but have a column with action buttons? That’s not clear to me.


Proposed Options

The following are the 4 options are for Table forms: Nikodem, it would be useful to see a table like this

#

Option

Level of Effort

User Benefit

**Performance Impact **

Will the option slow down the experience for the user on 2G?

Screens which would change if this option is selected.

1

Mimic what the other forms do.

Nikodem, could you clarify what this option is? Mimic which form?

Tiny?

2

Make errors appear after the fields has been touched.

3

Make errors appear after we leave (focus on something outside) the table row.

When fields within a lineItem are dependent on each other the error won’t show until they focus away from the LineItem (row)

4

Same as 3, but also highlight the table header.

Depending on the option, the following screens may be impacted. See the above table for details on which would change based on the option.

  • Requisition Product grid (I’m including this because it is my understanding it would be impacted if we chose an option which is different than the current behavior. Or perhaps you are including this later, my apologies.)
  • View Proof of Delivery (#!/pod/id) Question: why is this impacted if the table doesn’t have any inputs? I only see action buttons. Or are you referring to the editable proof of delivery screen?
  • View Requisition (#!/requisition/id) Question: why is this impacted if the table doesn’t have any inputs? I only see action buttons. Or are you referring to the editable requisition screen (aka requisition product grid)?
  • View Shipment (#!/orders/id) Question: do you mean View Orders? Why is this impacted if the table doesn’t have any inputs? I only see action buttons. Or are you referring to the editable shipment (aka the fulfill orders table)?
  • Issue (#!/stockmangement/issue/id)
  • Receive (#!/stockmangement/receive/id)
  • Physical Inventory (#!/physicalInventory/id)
  • Adjustments (#!/adjustment/id)
  • What about Fulfill Orders?
  • Should we be including the “batch approval” of requisitions?
    Perhaps we can schedule a call if it would be easier to connect that way. I just want to make sure I’m understanding your proposal and which options will impact which screens. Thank you again for pulling this together and hopefully we can clarify this soon and I can send across to the PC.

Thanks,

Mary Jo

**From: **Nikodem Graczewski ngraczewski@soldevelo.com

**Date: **Tuesday, June 5, 2018 at 12:16 AM

**To: **Josh Zamor josh.zamor@villagereach.org

**Cc: **Mary Jo Kochendorfer maryjo.kochendorfer@villagereach.org, OpenLMIS Dev openlmis-dev@googlegroups.com

**Subject: **Re: [openlmis-dev] Re: Error behavior on the table forms

Thanks for the feedback!

The reasoning behind option #3 totally makes sense to me.

About the questions I’m not sure I understand what you mean by “finding errors across line items”? Does it mean we want to bring user to the first error in the table after we attempt to submit it, or is it something else?

Best regards,

Nikodem

Nikodem Graczewski

Software Developer

ngraczewski@soldevelo.com

On Tue, Jun 5, 2018 at 12:59 AM, Josh Zamor josh.zamor@villagereach.org wrote:

Thanks for the clarification Nikodem, now I understand better.

For line item entry only then:

I still think I favor option #3, identify errors in a line item only after some work has been done in the line item, and then you shift away from it. As well (as always) as identifying all errors when attempting to submit the entries. I recognize this is one of the hardest options and also that it’s likely personal preference - that is I prefer a UX that has fewer visual warnings as I’m working on an item, and instead prefer those visual warnings to be raised after I think I’m done: I shift to another line item or I click a button that is me indicating I’m done. I also recognize this isn’t what the Requisition screen does (option #2), as currently it raises those visual indicators within the line item I’m working on as soon as I start working on the line item and something isn’t right.

Between those two options my preference as I said is #3, however the UX between the two is so small that I can’t say I’d encourage investing significant effort in it. Using option #2 with a smaller LOE seems fine by me.

Do we have an approach to finding errors across line items? I can imagine as we get into budgets for Requisitions we’ll have the need. Would that change the LOE for anything here?

Best,

Josh

On Jun 4, 2018, at 2:54 PM, Nikodem Graczewski ngraczewski@soldevelo.com wrote:

Yes, if we decide to pick a different approach than the one we’re already using for product grid, this changes will also affect the requisition product grid. The list of screens that will be affected by this is as follows:

  • View Proof of Delivery (#!/pod/id)
  • View Requisition (#!/requisition/id)
  • View Shipment (#!/orders/id)
  • Issue (#!/stockmangement/issue/id)
  • Receive (#!/stockmangement/receive/id)
  • Physical Inventory (#!/physicalInventory/id)
  • Adjustments (#!/adjustment/id)
    Hopefully I didn’t miss any screen.

Best regards,

Nikodem

Nikodem Graczewski

Software Developer

ngraczewski@soldevelo.com

On Fri, Jun 1, 2018 at 8:39 PM, Mary Jo Kochendorfer maryjo.kochendorfer@villagereach.org wrote:

Nikodem,

Unfortunately I’m still a bit confused. I too share the concern that Brandon voiced regarding the R&R product grid table.

Could you clarify if you are proposing that the decision made on the pattern for “table forms” impacts the R&R product grid table attached? I was confused when you stated that the Requisition View is a table form since that does not have any inputs or error messages.

If there is any impact on the R&R product grid, we cannot move forward with choosing a table form error pattern without discussing with the Product Committee. We must propose all UI changes since it will impact current implementations of OpenLMIS v3 in Malawi. It would be great if you could pull together the options and clear examples and present at the next PC to ensure we have the whole communities input. I know it might feel arduous to also present to the PC but I do think this will impact the user experience enough that it is important to consider the PC’s perspective.

Thank you for pulling this proposal together and clarifying what the impact is. Let me know if you have any questions about what I’m asking for in terms of raising to the PC.

Thanks,

Mary Jo

**From: **OpenLMIS Dev <openlmis-dev@googlegroups.com > on behalf of Nikodem Graczewski ngraczewski@soldevelo.com

**Date: **Thursday, May 31, 2018 at 11:10 AM

**To: **Brandon Bowersox-Johnson brandon.bowersox-johnson@villagereach.org

**Cc: **OpenLMIS Dev openlmis-dev@googlegroups.com

**Subject: **Re: [openlmis-dev] Re: Error behavior on the table forms

I might have not expressed myself well enough if it comes to the distinction between table and regular forms, for which I’m sorry.

To clarify, by table form I mean any table that has any inputs inside (Requisition View, Proof of Delivery View, Shipment View and Stock Management Adjustment, Receive, Issue and Physical Inventory screens). Line item entry is the best phrase to describe it (thanks Josh!).

Everything that doesn’t reside directly inside a table (table filters, facility/program select, searches etc) should be considered a standard form.

The main purpose of this thread is to choose the best approach for table forms as we’re using three different approaches to them across the system. The standard forms are already well documented and consistent (I couldn’t find a single form, which wouldn’t work the we expect it to). I agree with Josh on that we want to have two different approaches here.

I hope that clarifies any confusion I might have introduced.

Best regards,

Nikodem

Nikodem Graczewski

Software Developer

ngraczewski@soldevelo.com

On Thu, May 31, 2018 at 5:03 PM, Brandon Bowersox-Johnson brandon.bowersox-johnson@villagereach.org wrote:

I also feel that the line-item entry—especially the R&R Form—is a special case that justifies a special solution. OpenLMIS v3 has already chosen solution #3 for the R&R Form so far (from v3.0.0 to v3.3.0). I believe stakeholders and end-users are counting on that current behavior. The validation of those R&R Forms is a very detailed, important feature, and making any changes to it would require Product Committee involvement too.

As you evaluate how to handle errors consistently, I suggest looking at the other table forms separately from the R&R Form, and also look at non-form error handling (eg, filter, search, etc). That way if you are proposing changes, everyone can understand what parts of the system you would change.

I’m sorry I missed the Technical Committee (I have a conflicting commitment), but thanks for allowing me to share input.

-Brandon

**From: **<openlmis-dev@googlegroups.com > on behalf of "josh.zamor@openlmis.org" josh.zamor@openlmis.org

**Date: **Wednesday, May 30, 2018 at 10:01 PM

**To: **OpenLMIS Dev openlmis-dev@googlegroups.com

**Subject: **[openlmis-dev] Re: Error behavior on the table forms

I expressed this during the call, but I feel like option #3 makes the most sense for line item type entry. Moreover though I wonder if we really are looking for one approach to all situations? e.g. I don’t feel like option #3 makes any sense for the Filter component or the general search component with My Facility / Supervised Facility and other options (btw did we ever settle on a simple name for that thing?). For filter or search it seems like option #1 seems to make the most sense.

My opinion here isn’t set in stone by any means but it does seem like having at-least two approaches makes sense: option #1 should be true for everything and the next option should make the most sense for line item type entry.

For clarity I think the wiki page presents the options in a slightly different order from top to bottom than what we are using here.

Best,

Josh

On Tuesday, May 29, 2018 at 10:25:00 AM UTC-7, Nikodem Graczewski wrote:

Hello everyone,

as a follow up to the last Technical Committee meeting I’m bringing this topic to the dev group so we can decide which approach we would like to take on this matter.

There are 4 possible approaches we could take on how we want to display errors on the table forms (sorted with level of effort required - easiest to hardest):

  1. Mimic what the other forms do.
  2. Make errors appear after the fields has been touched.
  3. Make errors appear after we leave (focus on something outside) the table row.
  4. Same as 3, but also highlight table header.
    To learn more about each of the approaches please visit the following link:

https://openlmis.atlassian.net/wiki/spaces/OP/pages/378929173/OpenLMIS+UI±+Error+behavior+approaches

My two favorites are:

  • 1 - Mainly for consistency reasons. Implementing this approach would make all the forms (table or not) behave exactly the same across the whole system.
  • 2 - Early feedback for the user (errors are shown right after the input is dirty so the user can correct the errors early) as well as the fact we already have this approach implemented and it works fine with the pagination component.
    Please, share you opinions on the matter.

Best regards,

Nikodem

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email toopenlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/8a4a37b3-9f3a-4237-bf71-fa17dc6c21d7%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email toopenlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visithttps://groups.google.com/d/msgid/openlmis-dev/2F463C89-2265-4916-A42C-F6A0EA87D584%40villagereach.org.

For more options, visit https://groups.google.com/d/optout.

Error! Filename not specified.**

SolDevelo** Sp. z o.o. [LLC] / www.soldevelo.com

Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland

Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email toopenlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/CAGOM9mW%2BjkRAG2UMQna3Qizqeip6oypjpzAyCi6qBRnF6KRj7A%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email toopenlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/02DA5B5A-716E-4D57-9FB9-6E2AB0C8898B%40villagereach.org.

For more options, visit https://groups.google.com/d/optout.

**

SolDevelo** Sp. z o.o. [LLC] / www.soldevelo.com

Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland

Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

You received this message because you are subscribed to a topic in the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this topic, visit https://groups.google.com/d/topic/openlmis-dev/FTD6ta5PxWc/unsubscribe.

To unsubscribe from this group and all its topics, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/CAGOM9mVXaMAETbfw-CQUF2%3Dj%2B3EVBnxC%2B5qiuJ2h2jsAax%3Driw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/FAFB3858-7799-428A-AB0D-49DBBF3EB981%40villagereach.org.

For more options, visit https://groups.google.com/d/optout.

**

SolDevelo** Sp. z o.o. [LLC] / www.soldevelo.com

Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland

Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/47E41DF4-7131-42F4-8630-35509898B372%40villagereach.org.

For more options, visit https://groups.google.com/d/optout.


(Mary Jo Kochendorfer) #14

Nikodem,

I appreciate your initiative to move things forward. My apologies of the delay on getting this out to the PC. Our last meeting was filled up with an update from TZ and we didn’t have time. We can plan to bring it up on the upcoming meeting of July 3rd. Would you be available to join the call to provide an overview of the options? I want to ensure option 3 works for everyone since it will be a change to the current behavior on the View Requisition (product grid) which is currently in production in Malawi. I think it would be a welcomed change since right now errors show up instantly.

Thanks,

Mary Jo

···

From: Nikodem Graczewski ngraczewski@soldevelo.com

Date: Monday, June 25, 2018 at 2:55 AM

To: Mary Jo Kochendorfer maryjo.kochendorfer@villagereach.org

Cc: Josh Zamor josh.zamor@villagereach.org, OpenLMIS Dev openlmis-dev@googlegroups.com

Subject: Re: [openlmis-dev] Error behavior on the table forms

Hello everyone,

since there wasn’t any arguments against using the approach #3, I will start writing tickets for updating the screens with this approach.

Here’s a list of the affected screens:

  • View Requisition (Product Grid)

  • Issue

  • Receive

  • Physical Inventory

  • Adjustments

If there are any questions or different preferences, please let me know.

Best regards,

Nikodem

Nikodem Graczewski

Software Developer

ngraczewski@soldevelo.com

On Tue, Jun 12, 2018 at 9:03 AM, Nikodem Graczewski ngraczewski@soldevelo.com wrote:

Hi Mary Jo,

I will try to answer your questions the best I can

Nikodem, to clarify does this include tables which don’t have editable fields/cells but have a column with action buttons? That’s not clear to me.

They wouldn’t be affected as they are not showing any errors.

Nikodem, could you clarify what this option is? Mimic which form?

Basically any form that isn’t a table form. It would behave similar to User creation for example. So we wouldn’t get any feedback unless we click the submit button (Initiate on Requisition View - aka Product Grid - for example).

Question: why is this impacted if the table doesn’t have any inputs? I only see action buttons. Or are you referring to the editable proof of delivery screen?

Question: why is this impacted if the table doesn’t have any inputs? I only see action buttons. Or are you referring to the editable requisition screen (aka requisition product grid)?

Question: do you mean View Orders? Why is this impacted if the table doesn’t have any inputs? I only see action buttons. Or are you referring to the editable shipment (aka the fulfill orders table)?

What about Fulfill Orders?

Should we be including the “batch approval” of requisitions?

When I was referring to those screens I was using their names in the system (used for headers and/or breadcrumbs), which caused a little bit of confusion. To clarify here are screenshots of every screen with a table form:

  • View Proof of Delivery
  • View Requisition
  • View Shipment
  • Issue, Receive, Physical Inventory, Adjustments

Should we be including the “batch approval” of requisitions?

I didn’t include this screen as it is not part of the official release and potentially a subject to change heavily because of the amount of data displayed on it. It also is considered a table form though.

I have also added the requested recap table to the wiki document

Best Regards,

Nikodem

Nikodem Graczewski

Software Developer

ngraczewski@soldevelo.com

On Mon, Jun 11, 2018 at 11:13 PM, Mary Jo Kochendorfer maryjo.kochendorfer@villagereach.org wrote:

Josh,

As I mentioned, I’m still confused on what is being proposed and the impact of the current requisition product grid error behavior. It is my understanding, after slacking with Nikodem, that based on the decision made there will be impacts on the requisition product grid (Nikodem refers to it as the View Requisition screen).

Given that, I stand by my request to have this proposal brought to the PC due to its impact on current implementations. If we were suggesting to use the View Requisition table form as the standard and make other screens align, then I don’t think it would be necessary.

Mary Jo

From: Josh Zamor josh.zamor@villagereach.org

Date: Monday, June 11, 2018 at 1:02 PM

To: Mary Jo Kochendorfer maryjo.kochendorfer@villagereach.org

Cc: Nikodem Graczewski ngraczewski@soldevelo.com, OpenLMIS Dev openlmis-dev@googlegroups.com

Subject: Re: [openlmis-dev] Error behavior on the table forms

Nikodem and Mary Jo,

No, by across I’m not referring to reading the line item from left to right or right to left. I mean across multiple line items and across a larger form. e.g. An error that displays when a Requisition exceeds it’s budget or a warning if during fulfillment a I fulfill more than one lot than was requested. I don’t think we do currently, I could easily be wrong, however I’m curious if that changes LOE for the different options.

Mary Jo,

Are you sure we need to run this by product committee? I could imagine that being more the case if we were proposing to change the Requisition behavior. Rather Nikodem is trying to reconcile the inconsistent UX error behavior we have in other parts, and I believe what we’re saying is that UX on the Requisition is good enough (and the lower LOE) to replicate elsewhere and achieve higher consistency.

Best,

Josh

On Jun 11, 2018, at 10:34 AM, Mary Jo Kochendorfer maryjo.kochendorfer@villagereach.org wrote:

Josh,

To clarify, are you talking about within a lineItem having error messages between to cells/fields within a LineItem? If so, we currently have that behavior/need within the requisition product grid as cells within one lineItem calculate off each other.

Nikodem,

I must admit that I’m still a bit confused and I want to make sure I’m clear on what you are proposing and the impact on the current system behavior. After reading this thread and the wiki , I’m still confused. Would you be willing to review the following and make sure I didn’t misunderstand your proposal. If it is correct, we will need to bring this to the Product Committee. I suggest updating your current wiki to clearly state 1. The current state, 2. The proposed options and 3. The impact. You could use the table I created below.

Below I’ve started to lay out a summarized view, but I still have open questions to you in red.

Current behavior

Screens are inconsistent. The following proposal is specifically looking at “Table Forms”. A * table form* is any table that has any inputs inside of the table or ‘lineItem entries’. Nikodem, to clarify does this include tables which don’t have editable fields/cells but have a column with action buttons? That’s not clear to me.


Proposed Options

The following are the 4 options are for Table forms : Nikodem, it would be useful to see a table like this

#

Option

Level of Effort

User Benefit

**Performance Impact **

Will the option slow down the experience for the user on 2G?

Screens which would change if this option is selected.

1

Mimic what the other forms do.

Nikodem, could you clarify what this option is? Mimic which form?

Tiny?

2

Make errors appear after the fields has been touched.

3

Make errors appear after we leave (focus on something outside) the table row.

When fields within a lineItem are dependent on each other the error won’t show until they focus away from the LineItem (row)

4

Same as 3, but also highlight the table header.

Depending on the option, the following screens may be impacted. See the above table for details on which would change based on the option.

  • Requisition Product grid (I’m including this because it is my understanding it would be impacted if we chose an option which is different than the current behavior. Or perhaps you are including this later, my apologies.)
  • View Proof of Delivery (#!/pod/id) Question: why is this impacted if the table doesn’t have any inputs? I only see action buttons. Or are you referring to the editable proof of delivery screen?
  • View Requisition (#!/requisition/id) Question: why is this impacted if the table doesn’t have any inputs? I only see action buttons. Or are you referring to the editable requisition screen (aka requisition product grid)?
  • View Shipment (#!/orders/id) Question: do you mean View Orders? Why is this impacted if the table doesn’t have any inputs? I only see action buttons. Or are you referring to the editable shipment (aka the fulfill orders table)?
  • Issue (#!/stockmangement/issue/id)
  • Receive (#!/stockmangement/receive/id)
  • Physical Inventory (#!/physicalInventory/id)
  • Adjustments (#!/adjustment/id)
  • What about Fulfill Orders?
  • Should we be including the “batch approval” of requisitions?

Perhaps we can schedule a call if it would be easier to connect that way. I just want to make sure I’m understanding your proposal and which options will impact which screens. Thank you again for pulling this together and hopefully we can clarify this soon and I can send across to the PC.

Thanks,

Mary Jo

**From: ** Nikodem Graczewski ngraczewski@soldevelo.com

**Date: **Tuesday, June 5, 2018 at 12:16 AM

**To: **Josh Zamor josh.zamor@villagereach.org

**Cc: **Mary Jo Kochendorfer <maryjo.kochendorfer@villagereach.org >, OpenLMIS Dev openlmis-dev@googlegroups.com

**Subject: **Re: [openlmis-dev] Re: Error behavior on the table forms

Thanks for the feedback!

The reasoning behind option #3 totally makes sense to me.

About the questions I’m not sure I understand what you mean by “finding errors across line items”? Does it mean we want to bring user to the first error in the table after we attempt to submit it, or is it something else?

Best regards,

Nikodem

Nikodem Graczewski

Software Developer

ngraczewski@soldevelo.com

On Tue, Jun 5, 2018 at 12:59 AM, Josh Zamor josh.zamor@villagereach.org wrote:

Thanks for the clarification Nikodem, now I understand better.

For line item entry only then:

I still think I favor option #3, identify errors in a line item only after some work has been done in the line item, and then you shift away from it. As well (as always) as identifying all errors when attempting to submit the entries. I recognize this is one of the hardest options and also that it’s likely personal preference - that is I prefer a UX that has fewer visual warnings as I’m working on an item, and instead prefer those visual warnings to be raised after I think I’m done: I shift to another line item or I click a button that is me indicating I’m done. I also recognize this isn’t what the Requisition screen does (option #2), as currently it raises those visual indicators within the line item I’m working on as soon as I start working on the line item and something isn’t right.

Between those two options my preference as I said is #3, however the UX between the two is so small that I can’t say I’d encourage investing significant effort in it. Using option #2 with a smaller LOE seems fine by me.

Do we have an approach to finding errors across line items? I can imagine as we get into budgets for Requisitions we’ll have the need. Would that change the LOE for anything here?

Best,

Josh

On Jun 4, 2018, at 2:54 PM, Nikodem Graczewski ngraczewski@soldevelo.com wrote:

Yes, if we decide to pick a different approach than the one we’re already using for product grid, this changes will also affect the requisition product grid. The list of screens that will be affected by this is as follows:

  • View Proof of Delivery (#!/pod/id)
  • View Requisition (#!/requisition/id)
  • View Shipment (#!/orders/id)
  • Issue (#!/stockmangement/issue/id)
  • Receive (#!/stockmangement/receive/id)
  • Physical Inventory (#!/physicalInventory/id)
  • Adjustments (#!/adjustment/id)

Hopefully I didn’t miss any screen.

Best regards,

Nikodem

Nikodem Graczewski

Software Developer

ngraczewski@soldevelo.com

On Fri, Jun 1, 2018 at 8:39 PM, Mary Jo Kochendorfer <maryjo.kochendorfer@villagereach.org > wrote:

Nikodem,

Unfortunately I’m still a bit confused. I too share the concern that Brandon voiced regarding the R&R product grid table.

Could you clarify if you are proposing that the decision made on the pattern for “table forms” impacts the R&R product grid table attached? I was confused when you stated that the Requisition View is a table form since that does not have any inputs or error messages.

If there is any impact on the R&R product grid, we cannot move forward with choosing a table form error pattern without discussing with the Product Committee. We must propose all UI changes since it will impact current implementations of OpenLMIS v3 in Malawi. It would be great if you could pull together the options and clear examples and present at the next PC to ensure we have the whole communities input. I know it might feel arduous to also present to the PC but I do think this will impact the user experience enough that it is important to consider the PC’s perspective.

Thank you for pulling this proposal together and clarifying what the impact is. Let me know if you have any questions about what I’m asking for in terms of raising to the PC.

Thanks,

Mary Jo

**From: ** OpenLMIS Dev openlmis-dev@googlegroups.com on behalf of Nikodem Graczewski ngraczewski@soldevelo.com

**Date: **Thursday, May 31, 2018 at 11:10 AM

**To: **Brandon Bowersox-Johnson brandon.bowersox-johnson@villagereach.org

**Cc: **OpenLMIS Dev openlmis-dev@googlegroups.com

**Subject: **Re: [openlmis-dev] Re: Error behavior on the table forms

I might have not expressed myself well enough if it comes to the distinction between table and regular forms, for which I’m sorry.

To clarify, by table form I mean any table that has any inputs inside (Requisition View, Proof of Delivery View, Shipment View and Stock Management Adjustment, Receive, Issue and Physical Inventory screens). Line item entry is the best phrase to describe it (thanks Josh!).

Everything that doesn’t reside directly inside a table (table filters, facility/program select, searches etc) should be considered a standard form.

The main purpose of this thread is to choose the best approach for table forms as we’re using three different approaches to them across the system. The standard forms are already well documented and consistent (I couldn’t find a single form, which wouldn’t work the we expect it to). I agree with Josh on that we want to have two different approaches here.

I hope that clarifies any confusion I might have introduced.

Best regards,

Nikodem

Nikodem Graczewski

Software Developer

ngraczewski@soldevelo.com

On Thu, May 31, 2018 at 5:03 PM, Brandon Bowersox-Johnson <brandon.bowersox-johnson@villagereach.org > wrote:

I also feel that the line-item entry—especially the R&R Form—is a special case that justifies a special solution. OpenLMIS v3 has already chosen solution #3 for the R&R Form so far (from v3.0.0 to v3.3.0). I believe stakeholders and end-users are counting on that current behavior. The validation of those R&R Forms is a very detailed, important feature, and making any changes to it would require Product Committee involvement too.

As you evaluate how to handle errors consistently, I suggest looking at the other table forms separately from the R&R Form, and also look at non-form error handling (eg, filter, search, etc). That way if you are proposing changes, everyone can understand what parts of the system you would change.

I’m sorry I missed the Technical Committee (I have a conflicting commitment), but thanks for allowing me to share input.

-Brandon

**From: **<openlmis-dev@googlegroups.com > on behalf of "josh.zamor@openlmis.org" josh.zamor@openlmis.org

**Date: **Wednesday, May 30, 2018 at 10:01 PM

**To: **OpenLMIS Dev openlmis-dev@googlegroups.com

**Subject: **[openlmis-dev] Re: Error behavior on the table forms

I expressed this during the call, but I feel like option #3 makes the most sense for line item type entry. Moreover though I wonder if we really are looking for one approach to all situations? e.g. I don’t feel like option #3 makes any sense for the Filter component or the general search component with My Facility / Supervised Facility and other options (btw did we ever settle on a simple name for that thing?). For filter or search it seems like option #1 seems to make the most sense.

My opinion here isn’t set in stone by any means but it does seem like having at-least two approaches makes sense: option #1 should be true for everything and the next option should make the most sense for line item type entry.

For clarity I think the wiki page presents the options in a slightly different order from top to bottom than what we are using here.

Best,

Josh

On Tuesday, May 29, 2018 at 10:25:00 AM UTC-7, Nikodem Graczewski wrote:

Hello everyone,

as a follow up to the last Technical Committee meeting I’m bringing this topic to the dev group so we can decide which approach we would like to take on this matter.

There are 4 possible approaches we could take on how we want to display errors on the table forms (sorted with level of effort required - easiest to hardest):

  1. Mimic what the other forms do.
  1. Make errors appear after the fields has been touched.
  1. Make errors appear after we leave (focus on something outside) the table row.
  1. Same as 3, but also highlight table header.

To learn more about each of the approaches please visit the following link:

https://openlmis.atlassian.net/wiki/spaces/OP/pages/378929173/OpenLMIS+UI±+Error+behavior+approaches

My two favorites are:

  • 1 - Mainly for consistency reasons. Implementing this approach would make all the forms (table or not) behave exactly the same across the whole system.
  • 2 - Early feedback for the user (errors are shown right after the input is dirty so the user can correct the errors early) as well as the fact we already have this approach implemented and it works fine with the pagination component.

Please, share you opinions on the matter.

Best regards,

Nikodem

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email toopenlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/8a4a37b3-9f3a-4237-bf71-fa17dc6c21d7%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email toopenlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visithttps://groups.google.com/d/msgid/openlmis-dev/2F463C89-2265-4916-A42C-F6A0EA87D584%40villagereach.org.

For more options, visit https://groups.google.com/d/optout.

Error! Filename not specified.**

SolDevelo** Sp. z o.o. [LLC] / www.soldevelo.com

Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland

Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email toopenlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/CAGOM9mW%2BjkRAG2UMQna3Qizqeip6oypjpzAyCi6qBRnF6KRj7A%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email toopenlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/02DA5B5A-716E-4D57-9FB9-6E2AB0C8898B%40villagereach.org.

For more options, visit https://groups.google.com/d/optout.

**

SolDevelo** Sp. z o.o. [LLC] / www.soldevelo.com

Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland

Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

You received this message because you are subscribed to a topic in the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this topic, visit https://groups.google.com/d/topic/openlmis-dev/FTD6ta5PxWc/unsubscribe.

To unsubscribe from this group and all its topics, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/CAGOM9mVXaMAETbfw-CQUF2%3Dj%2B3EVBnxC%2B5qiuJ2h2jsAax%3Driw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/FAFB3858-7799-428A-AB0D-49DBBF3EB981%40villagereach.org.

For more options, visit https://groups.google.com/d/optout.

**

SolDevelo** Sp. z o.o. [LLC] / www.soldevelo.com

Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland

Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to
openlmis-dev@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/47E41DF4-7131-42F4-8630-35509898B372%40villagereach.org
.

For more options, visit
https://groups.google.com/d/optout
.

**

SolDevelo** Sp. z o.o. [LLC] /
www.soldevelo.com

Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland

Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41


(Nikodem Graczewski) #15

Hi Mary Jo,

unfortunately, I’m out of the office from 27th July to 8th August due to my wedding. Are we OK with postponing the presentation or should I find someone to present in my stead?

Best regards,
Nikodem


SolDevelo
Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

···

On Mon, Jun 25, 2018 at 7:38 PM, Mary Jo Kochendorfer maryjo.kochendorfer@villagereach.org wrote:

Nikodem,

I appreciate your initiative to move things forward. My apologies of the delay on getting this out to the PC. Our last meeting was filled up with an update from TZ and we didn’t have time. We can plan to bring it up on the upcoming meeting of July 3rd. Would you be available to join the call to provide an overview of the options? I want to ensure option 3 works for everyone since it will be a change to the current behavior on the View Requisition (product grid) which is currently in production in Malawi. I think it would be a welcomed change since right now errors show up instantly.

Thanks,

Mary Jo

From: Nikodem Graczewski ngraczewski@soldevelo.com

Date: Monday, June 25, 2018 at 2:55 AM

To: Mary Jo Kochendorfer maryjo.kochendorfer@villagereach.org

Cc: Josh Zamor josh.zamor@villagereach.org, OpenLMIS Dev openlmis-dev@googlegroups.com

Subject: Re: [openlmis-dev] Error behavior on the table forms

Hello everyone,

since there wasn’t any arguments against using the approach #3, I will start writing tickets for updating the screens with this approach.

Here’s a list of the affected screens:

  • View Requisition (Product Grid)
  • Issue
  • Receive
  • Physical Inventory
  • Adjustments
    If there are any questions or different preferences, please let me know.

Best regards,

Nikodem

Nikodem Graczewski

Software Developer

ngraczewski@soldevelo.com

On Tue, Jun 12, 2018 at 9:03 AM, Nikodem Graczewski ngraczewski@soldevelo.com wrote:

Hi Mary Jo,

I will try to answer your questions the best I can

Nikodem, to clarify does this include tables which don’t have editable fields/cells but have a column with action buttons? That’s not clear to me.

They wouldn’t be affected as they are not showing any errors.

Nikodem, could you clarify what this option is? Mimic which form?

Basically any form that isn’t a table form. It would behave similar to User creation for example. So we wouldn’t get any feedback unless we click the submit button (Initiate on Requisition View - aka Product Grid - for example).

Question: why is this impacted if the table doesn’t have any inputs? I only see action buttons. Or are you referring to the editable proof of delivery screen?

Question: why is this impacted if the table doesn’t have any inputs? I only see action buttons. Or are you referring to the editable requisition screen (aka requisition product grid)?

Question: do you mean View Orders? Why is this impacted if the table doesn’t have any inputs? I only see action buttons. Or are you referring to the editable shipment (aka the fulfill orders table)?

What about Fulfill Orders?

Should we be including the “batch approval” of requisitions?

When I was referring to those screens I was using their names in the system (used for headers and/or breadcrumbs), which caused a little bit of confusion. To clarify here are screenshots of every screen with a table form:

  • View Proof of Delivery

  • View Requisition

  • View Shipment

  • Issue, Receive, Physical Inventory, Adjustments

Should we be including the “batch approval” of requisitions?

I didn’t include this screen as it is not part of the official release and potentially a subject to change heavily because of the amount of data displayed on it. It also is considered a table form though.

I have also added the requested recap table to the wiki document

Best Regards,

Nikodem

Nikodem Graczewski

Software Developer

ngraczewski@soldevelo.com

On Mon, Jun 11, 2018 at 11:13 PM, Mary Jo Kochendorfer maryjo.kochendorfer@villagereach.org wrote:

Josh,

As I mentioned, I’m still confused on what is being proposed and the impact of the current requisition product grid error behavior. It is my understanding, after slacking with Nikodem, that based on the decision made there will be impacts on the requisition product grid (Nikodem refers to it as the View Requisition screen).

Given that, I stand by my request to have this proposal brought to the PC due to its impact on current implementations. If we were suggesting to use the View Requisition table form as the standard and make other screens align, then I don’t think it would be necessary.

Mary Jo

From: Josh Zamor josh.zamor@villagereach.org

Date: Monday, June 11, 2018 at 1:02 PM

To: Mary Jo Kochendorfer maryjo.kochendorfer@villagereach.org

Cc: Nikodem Graczewski ngraczewski@soldevelo.com, OpenLMIS Dev openlmis-dev@googlegroups.com

Subject: Re: [openlmis-dev] Error behavior on the table forms

Nikodem and Mary Jo,

No, by across I’m not referring to reading the line item from left to right or right to left. I mean across multiple line items and across a larger form. e.g. An error that displays when a Requisition exceeds it’s budget or a warning if during fulfillment a I fulfill more than one lot than was requested. I don’t think we do currently, I could easily be wrong, however I’m curious if that changes LOE for the different options.

Mary Jo,

Are you sure we need to run this by product committee? I could imagine that being more the case if we were proposing to change the Requisition behavior. Rather Nikodem is trying to reconcile the inconsistent UX error behavior we have in other parts, and I believe what we’re saying is that UX on the Requisition is good enough (and the lower LOE) to replicate elsewhere and achieve higher consistency.

Best,

Josh

On Jun 11, 2018, at 10:34 AM, Mary Jo Kochendorfer maryjo.kochendorfer@villagereach.org wrote:

Josh,

To clarify, are you talking about within a lineItem having error messages between to cells/fields within a LineItem? If so, we currently have that behavior/need within the requisition product grid as cells within one lineItem calculate off each other.

Nikodem,

I must admit that I’m still a bit confused and I want to make sure I’m clear on what you are proposing and the impact on the current system behavior. After reading this thread and the wiki , I’m still confused. Would you be willing to review the following and make sure I didn’t misunderstand your proposal. If it is correct, we will need to bring this to the Product Committee. I suggest updating your current wiki to clearly state 1. The current state, 2. The proposed options and 3. The impact. You could use the table I created below.

Below I’ve started to lay out a summarized view, but I still have open questions to you in red.

Current behavior

Screens are inconsistent. The following proposal is specifically looking at “Table Forms”. A * table form* is any table that has any inputs inside of the table or ‘lineItem entries’. Nikodem, to clarify does this include tables which don’t have editable fields/cells but have a column with action buttons? That’s not clear to me.


Proposed Options

The following are the 4 options are for Table forms : Nikodem, it would be useful to see a table like this

#

Option

Level of Effort

User Benefit

**Performance Impact **

Will the option slow down the experience for the user on 2G?

Screens which would change if this option is selected.

1

Mimic what the other forms do.

Nikodem, could you clarify what this option is? Mimic which form?

Tiny?

2

Make errors appear after the fields has been touched.

3

Make errors appear after we leave (focus on something outside) the table row.

When fields within a lineItem are dependent on each other the error won’t show until they focus away from the LineItem (row)

4

Same as 3, but also highlight the table header.

Depending on the option, the following screens may be impacted. See the above table for details on which would change based on the option.

  • Requisition Product grid (I’m including this because it is my understanding it would be impacted if we chose an option which is different than the current behavior. Or perhaps you are including this later, my apologies.)
  • View Proof of Delivery (#!/pod/id) Question: why is this impacted if the table doesn’t have any inputs? I only see action buttons. Or are you referring to the editable proof of delivery screen?
  • View Requisition (#!/requisition/id) Question: why is this impacted if the table doesn’t have any inputs? I only see action buttons. Or are you referring to the editable requisition screen (aka requisition product grid)?
  • View Shipment (#!/orders/id) Question: do you mean View Orders? Why is this impacted if the table doesn’t have any inputs? I only see action buttons. Or are you referring to the editable shipment (aka the fulfill orders table)?
  • Issue (#!/stockmangement/issue/id)
  • Receive (#!/stockmangement/receive/id)
  • Physical Inventory (#!/physicalInventory/id)
  • Adjustments (#!/adjustment/id)
  • What about Fulfill Orders?
  • Should we be including the “batch approval” of requisitions?
    Perhaps we can schedule a call if it would be easier to connect that way. I just want to make sure I’m understanding your proposal and which options will impact which screens. Thank you again for pulling this together and hopefully we can clarify this soon and I can send across to the PC.

Thanks,

Mary Jo

**From: ** Nikodem Graczewski ngraczewski@soldevelo.com

**Date: **Tuesday, June 5, 2018 at 12:16 AM

**To: **Josh Zamor josh.zamor@villagereach.org

**Cc: **Mary Jo Kochendorfer <maryjo.kochendorfer@villagereach.org >, OpenLMIS Dev openlmis-dev@googlegroups.com

**Subject: **Re: [openlmis-dev] Re: Error behavior on the table forms

Thanks for the feedback!

The reasoning behind option #3 totally makes sense to me.

About the questions I’m not sure I understand what you mean by “finding errors across line items”? Does it mean we want to bring user to the first error in the table after we attempt to submit it, or is it something else?

Best regards,

Nikodem

Nikodem Graczewski

Software Developer

ngraczewski@soldevelo.com

On Tue, Jun 5, 2018 at 12:59 AM, Josh Zamor josh.zamor@villagereach.org wrote:

Thanks for the clarification Nikodem, now I understand better.

For line item entry only then:

I still think I favor option #3, identify errors in a line item only after some work has been done in the line item, and then you shift away from it. As well (as always) as identifying all errors when attempting to submit the entries. I recognize this is one of the hardest options and also that it’s likely personal preference - that is I prefer a UX that has fewer visual warnings as I’m working on an item, and instead prefer those visual warnings to be raised after I think I’m done: I shift to another line item or I click a button that is me indicating I’m done. I also recognize this isn’t what the Requisition screen does (option #2), as currently it raises those visual indicators within the line item I’m working on as soon as I start working on the line item and something isn’t right.

Between those two options my preference as I said is #3, however the UX between the two is so small that I can’t say I’d encourage investing significant effort in it. Using option #2 with a smaller LOE seems fine by me.

Do we have an approach to finding errors across line items? I can imagine as we get into budgets for Requisitions we’ll have the need. Would that change the LOE for anything here?

Best,

Josh

On Jun 4, 2018, at 2:54 PM, Nikodem Graczewski ngraczewski@soldevelo.com wrote:

Yes, if we decide to pick a different approach than the one we’re already using for product grid, this changes will also affect the requisition product grid. The list of screens that will be affected by this is as follows:

  • View Proof of Delivery (#!/pod/id)
  • View Requisition (#!/requisition/id)
  • View Shipment (#!/orders/id)
  • Issue (#!/stockmangement/issue/id)
  • Receive (#!/stockmangement/receive/id)
  • Physical Inventory (#!/physicalInventory/id)
  • Adjustments (#!/adjustment/id)
    Hopefully I didn’t miss any screen.

Best regards,

Nikodem

Nikodem Graczewski

Software Developer

ngraczewski@soldevelo.com

On Fri, Jun 1, 2018 at 8:39 PM, Mary Jo Kochendorfer <maryjo.kochendorfer@villagereach.org > wrote:

Nikodem,

Unfortunately I’m still a bit confused. I too share the concern that Brandon voiced regarding the R&R product grid table.

Could you clarify if you are proposing that the decision made on the pattern for “table forms” impacts the R&R product grid table attached? I was confused when you stated that the Requisition View is a table form since that does not have any inputs or error messages.

If there is any impact on the R&R product grid, we cannot move forward with choosing a table form error pattern without discussing with the Product Committee. We must propose all UI changes since it will impact current implementations of OpenLMIS v3 in Malawi. It would be great if you could pull together the options and clear examples and present at the next PC to ensure we have the whole communities input. I know it might feel arduous to also present to the PC but I do think this will impact the user experience enough that it is important to consider the PC’s perspective.

Thank you for pulling this proposal together and clarifying what the impact is. Let me know if you have any questions about what I’m asking for in terms of raising to the PC.

Thanks,

Mary Jo

**From: ** OpenLMIS Dev openlmis-dev@googlegroups.com on behalf of Nikodem Graczewski ngraczewski@soldevelo.com

**Date: **Thursday, May 31, 2018 at 11:10 AM

**To: **Brandon Bowersox-Johnson brandon.bowersox-johnson@villagereach.org

**Cc: **OpenLMIS Dev openlmis-dev@googlegroups.com

**Subject: **Re: [openlmis-dev] Re: Error behavior on the table forms

I might have not expressed myself well enough if it comes to the distinction between table and regular forms, for which I’m sorry.

To clarify, by table form I mean any table that has any inputs inside (Requisition View, Proof of Delivery View, Shipment View and Stock Management Adjustment, Receive, Issue and Physical Inventory screens). Line item entry is the best phrase to describe it (thanks Josh!).

Everything that doesn’t reside directly inside a table (table filters, facility/program select, searches etc) should be considered a standard form.

The main purpose of this thread is to choose the best approach for table forms as we’re using three different approaches to them across the system. The standard forms are already well documented and consistent (I couldn’t find a single form, which wouldn’t work the we expect it to). I agree with Josh on that we want to have two different approaches here.

I hope that clarifies any confusion I might have introduced.

Best regards,

Nikodem

Nikodem Graczewski

Software Developer

ngraczewski@soldevelo.com

On Thu, May 31, 2018 at 5:03 PM, Brandon Bowersox-Johnson <brandon.bowersox-johnson@villagereach.org > wrote:

I also feel that the line-item entry—especially the R&R Form—is a special case that justifies a special solution. OpenLMIS v3 has already chosen solution #3 for the R&R Form so far (from v3.0.0 to v3.3.0). I believe stakeholders and end-users are counting on that current behavior. The validation of those R&R Forms is a very detailed, important feature, and making any changes to it would require Product Committee involvement too.

As you evaluate how to handle errors consistently, I suggest looking at the other table forms separately from the R&R Form, and also look at non-form error handling (eg, filter, search, etc). That way if you are proposing changes, everyone can understand what parts of the system you would change.

I’m sorry I missed the Technical Committee (I have a conflicting commitment), but thanks for allowing me to share input.

-Brandon

**From: **<openlmis-dev@googlegroups.com > on behalf of "josh.zamor@openlmis.org" josh.zamor@openlmis.org

**Date: **Wednesday, May 30, 2018 at 10:01 PM

**To: **OpenLMIS Dev openlmis-dev@googlegroups.com

**Subject: **[openlmis-dev] Re: Error behavior on the table forms

I expressed this during the call, but I feel like option #3 makes the most sense for line item type entry. Moreover though I wonder if we really are looking for one approach to all situations? e.g. I don’t feel like option #3 makes any sense for the Filter component or the general search component with My Facility / Supervised Facility and other options (btw did we ever settle on a simple name for that thing?). For filter or search it seems like option #1 seems to make the most sense.

My opinion here isn’t set in stone by any means but it does seem like having at-least two approaches makes sense: option #1 should be true for everything and the next option should make the most sense for line item type entry.

For clarity I think the wiki page presents the options in a slightly different order from top to bottom than what we are using here.

Best,

Josh

On Tuesday, May 29, 2018 at 10:25:00 AM UTC-7, Nikodem Graczewski wrote:

Hello everyone,

as a follow up to the last Technical Committee meeting I’m bringing this topic to the dev group so we can decide which approach we would like to take on this matter.

There are 4 possible approaches we could take on how we want to display errors on the table forms (sorted with level of effort required - easiest to hardest):

  1. Mimic what the other forms do.
  2. Make errors appear after the fields has been touched.
  3. Make errors appear after we leave (focus on something outside) the table row.
  4. Same as 3, but also highlight table header.
    To learn more about each of the approaches please visit the following link:

https://openlmis.atlassian.net/wiki/spaces/OP/pages/378929173/OpenLMIS+UI±+Error+behavior+approaches

My two favorites are:

  • 1 - Mainly for consistency reasons. Implementing this approach would make all the forms (table or not) behave exactly the same across the whole system.
  • 2 - Early feedback for the user (errors are shown right after the input is dirty so the user can correct the errors early) as well as the fact we already have this approach implemented and it works fine with the pagination component.
    Please, share you opinions on the matter.

Best regards,

Nikodem

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email toopenlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/8a4a37b3-9f3a-4237-bf71-fa17dc6c21d7%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email toopenlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visithttps://groups.google.com/d/msgid/openlmis-dev/2F463C89-2265-4916-A42C-F6A0EA87D584%40villagereach.org.

For more options, visit https://groups.google.com/d/optout.

Error! Filename not specified.**

SolDevelo** Sp. z o.o. [LLC] / www.soldevelo.com

Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland

Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email toopenlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/CAGOM9mW%2BjkRAG2UMQna3Qizqeip6oypjpzAyCi6qBRnF6KRj7A%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email toopenlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/02DA5B5A-716E-4D57-9FB9-6E2AB0C8898B%40villagereach.org.

For more options, visit https://groups.google.com/d/optout.

**

SolDevelo** Sp. z o.o. [LLC] / www.soldevelo.com

Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland

Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

You received this message because you are subscribed to a topic in the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this topic, visit https://groups.google.com/d/topic/openlmis-dev/FTD6ta5PxWc/unsubscribe.

To unsubscribe from this group and all its topics, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/CAGOM9mVXaMAETbfw-CQUF2%3Dj%2B3EVBnxC%2B5qiuJ2h2jsAax%3Driw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/FAFB3858-7799-428A-AB0D-49DBBF3EB981%40villagereach.org.

For more options, visit https://groups.google.com/d/optout.

**

SolDevelo** Sp. z o.o. [LLC] / www.soldevelo.com

Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland

Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to
openlmis-dev@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/47E41DF4-7131-42F4-8630-35509898B372%40villagereach.org
.

For more options, visit
https://groups.google.com/d/optout
.

**

SolDevelo** Sp. z o.o. [LLC] /
www.soldevelo.com

Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland

Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

Nikodem Graczewski

Software Developer

ngraczewski@soldevelo.com


(Josh Zamor) #16

How dare you! Keep such good news from us. Just kidding, congrats on the upcoming date!

A clerical note: when did we decide on option 3? I stated a preference for it, and I still have it, however I noted that the increased LOE probably wouldn't make it worth it over option 2. If in addition choosing option 3 means a rubber stamp from the product committee is needed to change the UX, then perhaps we really should just move forward with option 2 to get consistency. I'm okay if option 3 isn't taken up - the UX of option 2 is already accepted afaik.

Congrats Nikodem!

Best,
Josh

···

On Jun 25, 2018, at 10:34 PM, Nikodem Graczewski <ngraczewski@soldevelo.com> wrote:

Hi Mary Jo,

unfortunately, I'm out of the office from 27th July to 8th August due to my wedding. Are we OK with postponing the presentation or should I find someone to present in my stead?

Best regards,
Nikodem

Nikodem Graczewski
Software Developer
ngraczewski@soldevelo.com<mailto:ngraczewski@soldevelo.com>

On Mon, Jun 25, 2018 at 7:38 PM, Mary Jo Kochendorfer <maryjo.kochendorfer@villagereach.org<mailto:maryjo.kochendorfer@villagereach.org>> wrote:
Nikodem,

I appreciate your initiative to move things forward. My apologies of the delay on getting this out to the PC. Our last meeting was filled up with an update from TZ and we didn’t have time. We can plan to bring it up on the upcoming meeting of July 3rd. Would you be available to join the call to provide an overview of the options? I want to ensure option 3 works for everyone since it will be a change to the current behavior on the View Requisition (product grid) which is currently in production in Malawi. I think it would be a welcomed change since right now errors show up instantly.

Thanks,
Mary Jo

From: Nikodem Graczewski <ngraczewski@soldevelo.com<mailto:ngraczewski@soldevelo.com>>
Date: Monday, June 25, 2018 at 2:55 AM
To: Mary Jo Kochendorfer <maryjo.kochendorfer@villagereach.org<mailto:maryjo.kochendorfer@villagereach.org>>
Cc: Josh Zamor <josh.zamor@villagereach.org<mailto:josh.zamor@villagereach.org>>, OpenLMIS Dev <openlmis-dev@googlegroups.com<mailto:openlmis-dev@googlegroups.com>>
Subject: Re: [openlmis-dev] Error behavior on the table forms

Hello everyone,

since there wasn't any arguments against using the approach #3, I will start writing tickets for updating the screens with this approach.

Here's a list of the affected screens:

* View Requisition (Product Grid)
* Issue
* Receive
* Physical Inventory
* Adjustments
If there are any questions or different preferences, please let me know.

Best regards,
Nikodem

Nikodem Graczewski
Software Developer
ngraczewski@soldevelo.com<mailto:ngraczewski@soldevelo.com>

On Tue, Jun 12, 2018 at 9:03 AM, Nikodem Graczewski <ngraczewski@soldevelo.com<mailto:ngraczewski@soldevelo.com>> wrote:
Hi Mary Jo,

I will try to answer your questions the best I can
Nikodem, to clarify does this include tables which don’t have editable fields/cells but have a column with action buttons? That’s not clear to me.

They wouldn't be affected as they are not showing any errors.

Nikodem, could you clarify what this option is? Mimic which form?

Basically any form that isn't a table form. It would behave similar to User creation for example. So we wouldn't get any feedback unless we click the submit button (Initiate on Requisition View - aka Product Grid - for example).

Question: why is this impacted if the table doesn’t have any inputs? I only see action buttons. Or are you referring to the editable proof of delivery screen?
Question: why is this impacted if the table doesn’t have any inputs? I only see action buttons. Or are you referring to the editable requisition screen (aka requisition product grid)?
Question: do you mean View Orders? Why is this impacted if the table doesn’t have any inputs? I only see action buttons. Or are you referring to the editable shipment (aka the fulfill orders table)?
What about Fulfill Orders?
Should we be including the “batch approval” of requisitions?

When I was referring to those screens I was using their names in the system (used for headers and/or breadcrumbs), which caused a little bit of confusion. To clarify here are screenshots of every screen with a table form:

* View Proof of Delivery
[cid:ii_jibb9j0b1_163f2b3a71d450e2]
* View Requisition
[cid:ii_jibb8olt0_163f2b30dd813779]
* View Shipment
[cid:ii_jibbc4si2_163f2b583a8cce74]
* Issue, Receive, Physical Inventory, Adjustments
[cid:ii_jibbgzh13_163f2b8f6e205c1f]
Should we be including the “batch approval” of requisitions?

I didn't include this screen as it is not part of the official release and potentially a subject to change heavily because of the amount of data displayed on it. It also is considered a table form though.

I have also added the requested recap table to the wiki document

Best Regards,
Nikodem

Nikodem Graczewski
Software Developer
ngraczewski@soldevelo.com<mailto:ngraczewski@soldevelo.com>

On Mon, Jun 11, 2018 at 11:13 PM, Mary Jo Kochendorfer <maryjo.kochendorfer@villagereach.org<mailto:maryjo.kochendorfer@villagereach.org>> wrote:
Josh,

As I mentioned, I’m still confused on what is being proposed and the impact of the current requisition product grid error behavior. It is my understanding, after slacking with Nikodem, that based on the decision made there will be impacts on the requisition product grid (Nikodem refers to it as the View Requisition screen).

Given that, I stand by my request to have this proposal brought to the PC due to its impact on current implementations. If we were suggesting to use the View Requisition table form as the standard and make other screens align, then I don’t think it would be necessary.

Mary Jo

From: Josh Zamor <josh.zamor@villagereach.org<mailto:josh.zamor@villagereach.org>>
Date: Monday, June 11, 2018 at 1:02 PM
To: Mary Jo Kochendorfer <maryjo.kochendorfer@villagereach.org<mailto:maryjo.kochendorfer@villagereach.org>>
Cc: Nikodem Graczewski <ngraczewski@soldevelo.com<mailto:ngraczewski@soldevelo.com>>, OpenLMIS Dev <openlmis-dev@googlegroups.com<mailto:openlmis-dev@googlegroups.com>>
Subject: Re: [openlmis-dev] Error behavior on the table forms

Nikodem and Mary Jo,

No, by across I’m not referring to reading the line item from left to right or right to left. I mean across multiple line items and across a larger form. e.g. An error that displays when a Requisition exceeds it’s budget or a warning if during fulfillment a I fulfill more than one lot than was requested. I don’t think we do currently, I could easily be wrong, however I’m curious if that changes LOE for the different options.

Mary Jo,

Are you sure we need to run this by product committee? I could imagine that being more the case if we were proposing to change the Requisition behavior. Rather Nikodem is trying to reconcile the inconsistent UX error behavior we have in other parts, and I believe what we’re saying is that UX on the Requisition is good enough (and the lower LOE) to replicate elsewhere and achieve higher consistency.

Best,
Josh

On Jun 11, 2018, at 10:34 AM, Mary Jo Kochendorfer <maryjo.kochendorfer@villagereach.org<mailto:maryjo.kochendorfer@villagereach.org>> wrote:

Josh,
To clarify, are you talking about within a lineItem having error messages between to cells/fields within a LineItem? If so, we currently have that behavior/need within the requisition product grid as cells within one lineItem calculate off each other.

Nikodem,
I must admit that I’m still a bit confused and I want to make sure I’m clear on what you are proposing and the impact on the current system behavior. After reading this thread and the wiki<https://openlmis.atlassian.net/wiki/spaces/OP/pages/378929173/OpenLMIS+UI+-+Error+behavior+approaches>, I’m still confused. Would you be willing to review the following and make sure I didn’t misunderstand your proposal. If it is correct, we will need to bring this to the Product Committee. I suggest updating your current wiki<https://openlmis.atlassian.net/wiki/spaces/OP/pages/378929173/OpenLMIS+UI+-+Error+behavior+approaches> to clearly state 1. The current state, 2. The proposed options and 3. The impact. You could use the table I created below.

Below I’ve started to lay out a summarized view, but I still have open questions to you in red.

Current behavior
Screens are inconsistent. The following proposal is specifically looking at “Table Forms”. A table form is any table that has any inputs inside of the table or ‘lineItem entries’. Nikodem, to clarify does this include tables which don’t have editable fields/cells but have a column with action buttons? That’s not clear to me.

Proposed Options
The following are the 4 options are for Table forms: Nikodem, it would be useful to see a table like this

#

Option

Level of Effort

User Benefit

Performance Impact
Will the option slow down the experience for the user on 2G?

Screens which would change if this option is selected.

1

Mimic what the other forms do.
Nikodem, could you clarify what this option is? Mimic which form?

Tiny?

2

Make errors appear after the fields has been touched.

3

Make errors appear after we leave (focus on something outside) the table row.

When fields within a lineItem are dependent on each other the error won’t show until they focus away from the LineItem (row)

4

Same as 3, but also highlight the table header.

Depending on the option, the following screens may be impacted. See the above table for details on which would change based on the option.

* Requisition Product grid (I’m including this because it is my understanding it would be impacted if we chose an option which is different than the current behavior. Or perhaps you are including this later, my apologies.)
* View Proof of Delivery (#!/pod/id) Question: why is this impacted if the table doesn’t have any inputs? I only see action buttons. Or are you referring to the editable proof of delivery screen?
* View Requisition (#!/requisition/id) Question: why is this impacted if the table doesn’t have any inputs? I only see action buttons. Or are you referring to the editable requisition screen (aka requisition product grid)?
* View Shipment (#!/orders/id) Question: do you mean View Orders? Why is this impacted if the table doesn’t have any inputs? I only see action buttons. Or are you referring to the editable shipment (aka the fulfill orders table)?
* Issue (#!/stockmangement/issue/id)
* Receive (#!/stockmangement/receive/id)
* Physical Inventory (#!/physicalInventory/id)
* Adjustments (#!/adjustment/id)
* What about Fulfill Orders?
* Should we be including the “batch approval” of requisitions?
Perhaps we can schedule a call if it would be easier to connect that way. I just want to make sure I’m understanding your proposal and which options will impact which screens. Thank you again for pulling this together and hopefully we can clarify this soon and I can send across to the PC.

Thanks,
Mary Jo

From: Nikodem Graczewski <ngraczewski@soldevelo.com<mailto:ngraczewski@soldevelo.com>>
Date: Tuesday, June 5, 2018 at 12:16 AM
To: Josh Zamor <josh.zamor@villagereach.org<mailto:josh.zamor@villagereach.org>>
Cc: Mary Jo Kochendorfer <maryjo.kochendorfer@villagereach.org<mailto:maryjo.kochendorfer@villagereach.org>>, OpenLMIS Dev <openlmis-dev@googlegroups.com<mailto:openlmis-dev@googlegroups.com>>
Subject: Re: [openlmis-dev] Re: Error behavior on the table forms

Thanks for the feedback!

The reasoning behind option #3 totally makes sense to me.

About the questions I'm not sure I understand what you mean by "finding errors across line items"? Does it mean we want to bring user to the first error in the table after we attempt to submit it, or is it something else?

Best regards,
Nikodem

Nikodem Graczewski
Software Developer
ngraczewski@soldevelo.com<mailto:ngraczewski@soldevelo.com>

On Tue, Jun 5, 2018 at 12:59 AM, Josh Zamor <josh.zamor@villagereach.org<mailto:josh.zamor@villagereach.org>> wrote:
Thanks for the clarification Nikodem, now I understand better.

For line item entry only then:

I still think I favor option #3, identify errors in a line item only after some work has been done in the line item, and then you shift away from it. As well (as always) as identifying all errors when attempting to submit the entries. I recognize this is one of the hardest options and also that it’s likely personal preference - that is I prefer a UX that has fewer visual warnings as I’m working on an item, and instead prefer those visual warnings to be raised after I think I’m done: I shift to another line item or I click a button that is me indicating I’m done. I also recognize this isn’t what the Requisition screen does (option #2), as currently it raises those visual indicators within the line item I’m working on as soon as I start working on the line item and something isn’t right.

Between those two options my preference as I said is #3, however the UX between the two is so small that I can’t say I’d encourage investing significant effort in it. Using option #2 with a smaller LOE seems fine by me.

Do we have an approach to finding errors across line items? I can imagine as we get into budgets for Requisitions we’ll have the need. Would that change the LOE for anything here?

Best,
Josh

On Jun 4, 2018, at 2:54 PM, Nikodem Graczewski <ngraczewski@soldevelo.com<mailto:ngraczewski@soldevelo.com>> wrote:

Yes, if we decide to pick a different approach than the one we're already using for product grid, this changes will also affect the requisition product grid. The list of screens that will be affected by this is as follows:

* View Proof of Delivery (#!/pod/id)
* View Requisition (#!/requisition/id)
* View Shipment (#!/orders/id)
* Issue (#!/stockmangement/issue/id)
* Receive (#!/stockmangement/receive/id)
* Physical Inventory (#!/physicalInventory/id)
* Adjustments (#!/adjustment/id)
Hopefully I didn't miss any screen.

Best regards,
Nikodem

Nikodem Graczewski
Software Developer
ngraczewski@soldevelo.com<mailto:ngraczewski@soldevelo.com>

On Fri, Jun 1, 2018 at 8:39 PM, Mary Jo Kochendorfer <maryjo.kochendorfer@villagereach.org<mailto:maryjo.kochendorfer@villagereach.org>> wrote:
Nikodem,
Unfortunately I’m still a bit confused. I too share the concern that Brandon voiced regarding the R&R product grid table.

Could you clarify if you are proposing that the decision made on the pattern for “table forms” impacts the R&R product grid table attached? I was confused when you stated that the Requisition View is a table form since that does not have any inputs or error messages.

If there is any impact on the R&R product grid, we cannot move forward with choosing a table form error pattern without discussing with the Product Committee. We must propose all UI changes since it will impact current implementations of OpenLMIS v3 in Malawi. It would be great if you could pull together the options and clear examples and present at the next PC to ensure we have the whole communities input. I know it might feel arduous to also present to the PC but I do think this will impact the user experience enough that it is important to consider the PC’s perspective.

Thank you for pulling this proposal together and clarifying what the impact is. Let me know if you have any questions about what I’m asking for in terms of raising to the PC.

Thanks,
Mary Jo

From: OpenLMIS Dev <openlmis-dev@googlegroups.com<mailto:openlmis-dev@googlegroups.com>> on behalf of Nikodem Graczewski <ngraczewski@soldevelo.com<mailto:ngraczewski@soldevelo.com>>
Date: Thursday, May 31, 2018 at 11:10 AM
To: Brandon Bowersox-Johnson <brandon.bowersox-johnson@villagereach.org<mailto:brandon.bowersox-johnson@villagereach.org>>
Cc: OpenLMIS Dev <openlmis-dev@googlegroups.com<mailto:openlmis-dev@googlegroups.com>>
Subject: Re: [openlmis-dev] Re: Error behavior on the table forms

I might have not expressed myself well enough if it comes to the distinction between table and regular forms, for which I'm sorry.

To clarify, by table form I mean any table that has any inputs inside (Requisition View, Proof of Delivery View, Shipment View and Stock Management Adjustment, Receive, Issue and Physical Inventory screens). Line item entry is the best phrase to describe it (thanks Josh!).

Everything that doesn't reside directly inside a table (table filters, facility/program select, searches etc) should be considered a standard form.

The main purpose of this thread is to choose the best approach for table forms as we're using three different approaches to them across the system. The standard forms are already well documented and consistent (I couldn't find a single form, which wouldn't work the we expect it to). I agree with Josh on that we want to have two different approaches here.

I hope that clarifies any confusion I might have introduced.

Best regards,
Nikodem

Nikodem Graczewski
Software Developer
ngraczewski@soldevelo.com<mailto:ngraczewski@soldevelo.com>

On Thu, May 31, 2018 at 5:03 PM, Brandon Bowersox-Johnson <brandon.bowersox-johnson@villagereach.org<mailto:brandon.bowersox-johnson@villagereach.org>> wrote:
I also feel that the line-item entry—especially the R&R Form—is a special case that justifies a special solution. OpenLMIS v3 has already chosen solution #3 for the R&R Form so far (from v3.0.0 to v3.3.0). I believe stakeholders and end-users are counting on that current behavior. The validation of those R&R Forms is a very detailed, important feature, and making any changes to it would require Product Committee involvement too.

As you evaluate how to handle errors consistently, I suggest looking at the other table forms separately from the R&R Form, and also look at non-form error handling (eg, filter, search, etc). That way if you are proposing changes, everyone can understand what parts of the system you would change.

I’m sorry I missed the Technical Committee (I have a conflicting commitment), but thanks for allowing me to share input.

-Brandon

From: <openlmis-dev@googlegroups.com<mailto:openlmis-dev@googlegroups.com>> on behalf of "josh.zamor@openlmis.org<mailto:josh.zamor@openlmis.org>" <josh.zamor@openlmis.org<mailto:josh.zamor@openlmis.org>>
Date: Wednesday, May 30, 2018 at 10:01 PM
To: OpenLMIS Dev <openlmis-dev@googlegroups.com<mailto:openlmis-dev@googlegroups.com>>
Subject: [openlmis-dev] Re: Error behavior on the table forms

I expressed this during the call, but I feel like option #3 makes the most sense for line item type entry. Moreover though I wonder if we really are looking for one approach to all situations? e.g. I don't feel like option #3 makes any sense for the Filter component or the general search component with My Facility / Supervised Facility and other options (btw did we ever settle on a simple name for that thing?). For filter or search it seems like option #1 seems to make the most sense.

My opinion here isn't set in stone by any means but it does seem like having at-least two approaches makes sense: option #1 should be true for everything and the next option should make the most sense for line item type entry.

For clarity I think the wiki page presents the options in a slightly different order from top to bottom than what we are using here.

Best,
Josh

On Tuesday, May 29, 2018 at 10:25:00 AM UTC-7, Nikodem Graczewski wrote:
Hello everyone,

as a follow up to the last Technical Committee meeting I'm bringing this topic to the dev group so we can decide which approach we would like to take on this matter.

There are 4 possible approaches we could take on how we want to display errors on the table forms (sorted with level of effort required - easiest to hardest):

1. Mimic what the other forms do.
2. Make errors appear after the fields has been touched.
3. Make errors appear after we leave (focus on something outside) the table row.
4. Same as 3, but also highlight table header.
To learn more about each of the approaches please visit the following link:
https://openlmis.atlassian.net/wiki/spaces/OP/pages/378929173/OpenLMIS+UI+-+Error+behavior+approaches<https://www.google.com/url?q=https%3A%2F%2Fopenlmis.atlassian.net%2Fwiki%2Fspaces%2FOP%2Fpages%2F378929173%2FOpenLMIS%2BUI%2B-%2BError%2Bbehavior%2Bapproaches&sa=D&sntz=1&usg=AFQjCNF2vDCG8MSDMA5qYJnSjvQCypInbA>

My two favorites are:

* 1 - Mainly for consistency reasons. Implementing this approach would make all the forms (table or not) behave exactly the same across the whole system.
* 2 - Early feedback for the user (errors are shown right after the input is dirty so the user can correct the errors early) as well as the fact we already have this approach implemented and it works fine with the pagination component.
Please, share you opinions on the matter.

Best regards,
Nikodem
--
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email toopenlmis-dev+unsubscribe@googlegroups.com<mailto:openlmis-dev+unsubscribe@googlegroups.com>.
To post to this group, send email to openlmis-dev@googlegroups.com<mailto:openlmis-dev@googlegroups.com>.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/8a4a37b3-9f3a-4237-bf71-fa17dc6c21d7%40googlegroups.com<https://groups.google.com/d/msgid/openlmis-dev/8a4a37b3-9f3a-4237-bf71-fa17dc6c21d7%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email toopenlmis-dev+unsubscribe@googlegroups.com<mailto:openlmis-dev+unsubscribe@googlegroups.com>.
To post to this group, send email to openlmis-dev@googlegroups.com<mailto:openlmis-dev@googlegroups.com>.
To view this discussion on the web visithttps://groups.google.com/d/msgid/openlmis-dev/2F463C89-2265-4916-A42C-F6A0EA87D584%40villagereach.org<https://groups.google.com/d/msgid/openlmis-dev/2F463C89-2265-4916-A42C-F6A0EA87D584%40villagereach.org?utm_medium=email&utm_source=footer>.

For more options, visit https://groups.google.com/d/optout.

Error! Filename not specified.
SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com<http://www.soldevelo.com/>
Al. Zwycięstwa 96/98<https://maps.google.com/?q=Al.+Zwycięstwa+96/98&entry=gmail&source=g>, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41
--
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email toopenlmis-dev+unsubscribe@googlegroups.com<mailto:openlmis-dev+unsubscribe@googlegroups.com>.
To post to this group, send email to openlmis-dev@googlegroups.com<mailto:openlmis-dev@googlegroups.com>.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/CAGOM9mW%2BjkRAG2UMQna3Qizqeip6oypjpzAyCi6qBRnF6KRj7A%40mail.gmail.com<https://groups.google.com/d/msgid/openlmis-dev/CAGOM9mW%2BjkRAG2UMQna3Qizqeip6oypjpzAyCi6qBRnF6KRj7A%40mail.gmail.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email toopenlmis-dev+unsubscribe@googlegroups.com<mailto:openlmis-dev+unsubscribe@googlegroups.com>.
To post to this group, send email to openlmis-dev@googlegroups.com<mailto:openlmis-dev@googlegroups.com>.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/02DA5B5A-716E-4D57-9FB9-6E2AB0C8898B%40villagereach.org<https://groups.google.com/d/msgid/openlmis-dev/02DA5B5A-716E-4D57-9FB9-6E2AB0C8898B%40villagereach.org?utm_medium=email&utm_source=footer>.

For more options, visit https://groups.google.com/d/optout.

SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com<http://www.soldevelo.com/>
Al. Zwycięstwa 96/98<https://maps.google.com/?q=Al.+Zwycięstwa+96/98&entry=gmail&source=g>, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

--
You received this message because you are subscribed to a topic in the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openlmis-dev/FTD6ta5PxWc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openlmis-dev+unsubscribe@googlegroups.com<mailto:openlmis-dev+unsubscribe@googlegroups.com>.
To post to this group, send email to openlmis-dev@googlegroups.com<mailto:openlmis-dev@googlegroups.com>.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/CAGOM9mVXaMAETbfw-CQUF2%3Dj%2B3EVBnxC%2B5qiuJ2h2jsAax%3Driw%40mail.gmail.com<https://groups.google.com/d/msgid/openlmis-dev/CAGOM9mVXaMAETbfw-CQUF2%3Dj%2B3EVBnxC%2B5qiuJ2h2jsAax%3Driw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com<mailto:openlmis-dev+unsubscribe@googlegroups.com>.
To post to this group, send email to openlmis-dev@googlegroups.com<mailto:openlmis-dev@googlegroups.com>.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/FAFB3858-7799-428A-AB0D-49DBBF3EB981%40villagereach.org<https://groups.google.com/d/msgid/openlmis-dev/FAFB3858-7799-428A-AB0D-49DBBF3EB981%40villagereach.org?utm_medium=email&utm_source=footer>.

For more options, visit https://groups.google.com/d/optout.

SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com<http://www.soldevelo.com/>
Al. Zwycięstwa 96/98<https://maps.google.com/?q=Al.+Zwycięstwa+96/98&entry=gmail&source=g>, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

--
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com<mailto:openlmis-dev+unsubscribe@googlegroups.com>.
To post to this group, send email to openlmis-dev@googlegroups.com<mailto:openlmis-dev@googlegroups.com>.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/47E41DF4-7131-42F4-8630-35509898B372%40villagereach.org<https://groups.google.com/d/msgid/openlmis-dev/47E41DF4-7131-42F4-8630-35509898B372%40villagereach.org?utm_medium=email&utm_source=footer>.

For more options, visit https://groups.google.com/d/optout.

[Image removed by sender.]
SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com<http://www.soldevelo.com>
Al. Zwycięstwa 96/98<https://maps.google.com/?q=Al.+Zwycięstwa+96/98&entry=gmail&source=g>, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

[http://www.soldevelo.com/sites/default/files/Soldevelo_logo_EPS_CMYK.png]
SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com<http://www.soldevelo.com>
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41
<image002.png>
<image001.png>
<image004.png>
<image003.png>


(Nikodem Graczewski) #17

Hi Josh,

thank you! I obviously meant 27th June to 8th July, sorry for my mistake.

I felt like we were leaning forward option #3. The main effort with this ticket will most likely be updating the pagination component to work with it, updating the screen should be straight-forward.

Best regards,
Nikodem


SolDevelo
Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

···

On Mon, Jun 25, 2018 at 10:10 PM, Josh Zamor josh.zamor@villagereach.org wrote:

How dare you! Keep such good news from us. Just kidding, congrats on the upcoming date!

A clerical note: when did we decide on option 3? I stated a preference for it, and I still have it, however I noted that the increased LOE probably wouldn’t make it worth it over option 2. If in addition choosing option 3 means a rubber stamp from the product committee is needed to change the UX, then perhaps we really should just move forward with option 2 to get consistency. I’m okay if option 3 isn’t taken up - the UX of option 2 is already accepted afaik.

Congrats Nikodem!

Best,

Josh

On Jun 25, 2018, at 10:34 PM, Nikodem Graczewski ngraczewski@soldevelo.com wrote:

Hi Mary Jo,

unfortunately, I’m out of the office from 27th July to 8th August due to my wedding. Are we OK with postponing the presentation or should I find someone to present in my stead?

Best regards,

Nikodem

Nikodem Graczewski

Software Developer

ngraczewski@soldevelo.commailto:ngraczewski@soldevelo.com

On Mon, Jun 25, 2018 at 7:38 PM, Mary Jo Kochendorfer <maryjo.kochendorfer@villagereach.orgmailto:maryjo.kochendorfer@villagereach.org> wrote:

Nikodem,

I appreciate your initiative to move things forward. My apologies of the delay on getting this out to the PC. Our last meeting was filled up with an update from TZ and we didn’t have time. We can plan to bring it up on the upcoming meeting of July 3rd. Would you be available to join the call to provide an overview of the options? I want to ensure option 3 works for everyone since it will be a change to the current behavior on the View Requisition (product grid) which is currently in production in Malawi. I think it would be a welcomed change since right now errors show up instantly.

Thanks,

Mary Jo

From: Nikodem Graczewski <ngraczewski@soldevelo.commailto:ngraczewski@soldevelo.com>

Date: Monday, June 25, 2018 at 2:55 AM

To: Mary Jo Kochendorfer <maryjo.kochendorfer@villagereach.orgmailto:maryjo.kochendorfer@villagereach.org>

Cc: Josh Zamor <josh.zamor@villagereach.orgmailto:josh.zamor@villagereach.org>, OpenLMIS Dev <openlmis-dev@googlegroups.commailto:openlmis-dev@googlegroups.com>

Subject: Re: [openlmis-dev] Error behavior on the table forms

Hello everyone,

since there wasn’t any arguments against using the approach #3, I will start writing tickets for updating the screens with this approach.

Here’s a list of the affected screens:

  • View Requisition (Product Grid)
  • Issue
  • Receive
  • Physical Inventory
  • Adjustments

If there are any questions or different preferences, please let me know.

Best regards,

Nikodem

Nikodem Graczewski

Software Developer

ngraczewski@soldevelo.commailto:ngraczewski@soldevelo.com

On Tue, Jun 12, 2018 at 9:03 AM, Nikodem Graczewski <ngraczewski@soldevelo.commailto:ngraczewski@soldevelo.com> wrote:

Hi Mary Jo,

I will try to answer your questions the best I can

Nikodem, to clarify does this include tables which don’t have editable fields/cells but have a column with action buttons? That’s not clear to me.

They wouldn’t be affected as they are not showing any errors.

Nikodem, could you clarify what this option is? Mimic which form?

Basically any form that isn’t a table form. It would behave similar to User creation for example. So we wouldn’t get any feedback unless we click the submit button (Initiate on Requisition View - aka Product Grid - for example).

Question: why is this impacted if the table doesn’t have any inputs? I only see action buttons. Or are you referring to the editable proof of delivery screen?

Question: why is this impacted if the table doesn’t have any inputs? I only see action buttons. Or are you referring to the editable requisition screen (aka requisition product grid)?

Question: do you mean View Orders? Why is this impacted if the table doesn’t have any inputs? I only see action buttons. Or are you referring to the editable shipment (aka the fulfill orders table)?

What about Fulfill Orders?

Should we be including the “batch approval” of requisitions?

When I was referring to those screens I was using their names in the system (used for headers and/or breadcrumbs), which caused a little bit of confusion. To clarify here are screenshots of every screen with a table form:

  • View Proof of Delivery

[cid:ii_jibb9j0b1_163f2b3a71d450e2]

  • View Requisition

[cid:ii_jibb8olt0_163f2b30dd813779]

  • View Shipment

[cid:ii_jibbc4si2_163f2b583a8cce74]

  • Issue, Receive, Physical Inventory, Adjustments

[cid:ii_jibbgzh13_163f2b8f6e205c1f]

Should we be including the “batch approval” of requisitions?

I didn’t include this screen as it is not part of the official release and potentially a subject to change heavily because of the amount of data displayed on it. It also is considered a table form though.

I have also added the requested recap table to the wiki document

Best Regards,

Nikodem

Nikodem Graczewski

Software Developer

ngraczewski@soldevelo.commailto:ngraczewski@soldevelo.com

On Mon, Jun 11, 2018 at 11:13 PM, Mary Jo Kochendorfer <maryjo.kochendorfer@villagereach.orgmailto:maryjo.kochendorfer@villagereach.org> wrote:

Josh,

As I mentioned, I’m still confused on what is being proposed and the impact of the current requisition product grid error behavior. It is my understanding, after slacking with Nikodem, that based on the decision made there will be impacts on the requisition product grid (Nikodem refers to it as the View Requisition screen).

Given that, I stand by my request to have this proposal brought to the PC due to its impact on current implementations. If we were suggesting to use the View Requisition table form as the standard and make other screens align, then I don’t think it would be necessary.

Mary Jo

From: Josh Zamor <josh.zamor@villagereach.orgmailto:josh.zamor@villagereach.org>

Date: Monday, June 11, 2018 at 1:02 PM

To: Mary Jo Kochendorfer <maryjo.kochendorfer@villagereach.orgmailto:maryjo.kochendorfer@villagereach.org>

Cc: Nikodem Graczewski <ngraczewski@soldevelo.commailto:ngraczewski@soldevelo.com>, OpenLMIS Dev <openlmis-dev@googlegroups.commailto:openlmis-dev@googlegroups.com>

Subject: Re: [openlmis-dev] Error behavior on the table forms

Nikodem and Mary Jo,

No, by across I’m not referring to reading the line item from left to right or right to left. I mean across multiple line items and across a larger form. e.g. An error that displays when a Requisition exceeds it’s budget or a warning if during fulfillment a I fulfill more than one lot than was requested. I don’t think we do currently, I could easily be wrong, however I’m curious if that changes LOE for the different options.

Mary Jo,

Are you sure we need to run this by product committee? I could imagine that being more the case if we were proposing to change the Requisition behavior. Rather Nikodem is trying to reconcile the inconsistent UX error behavior we have in other parts, and I believe what we’re saying is that UX on the Requisition is good enough (and the lower LOE) to replicate elsewhere and achieve higher consistency.

Best,

Josh

On Jun 11, 2018, at 10:34 AM, Mary Jo Kochendorfer <maryjo.kochendorfer@villagereach.orgmailto:maryjo.kochendorfer@villagereach.org> wrote:

Josh,

To clarify, are you talking about within a lineItem having error messages between to cells/fields within a LineItem? If so, we currently have that behavior/need within the requisition product grid as cells within one lineItem calculate off each other.

Nikodem,

I must admit that I’m still a bit confused and I want to make sure I’m clear on what you are proposing and the impact on the current system behavior. After reading this thread and the wiki<https://openlmis.atlassian.net/wiki/spaces/OP/pages/378929173/OpenLMIS+UI±+Error+behavior+approaches>, I’m still confused. Would you be willing to review the following and make sure I didn’t misunderstand your proposal. If it is correct, we will need to bring this to the Product Committee. I suggest updating your current wiki<https://openlmis.atlassian.net/wiki/spaces/OP/pages/378929173/OpenLMIS+UI±+Error+behavior+approaches> to clearly state 1. The current state, 2. The proposed options and 3. The impact. You could use the table I created below.

Below I’ve started to lay out a summarized view, but I still have open questions to you in red.

Current behavior

Screens are inconsistent. The following proposal is specifically looking at “Table Forms”. A table form is any table that has any inputs inside of the table or ‘lineItem entries’. Nikodem, to clarify does this include tables which don’t have editable fields/cells but have a column with action buttons? That’s not clear to me.

Proposed Options

The following are the 4 options are for Table forms: Nikodem, it would be useful to see a table like this

Option

Level of Effort

User Benefit

Performance Impact

Will the option slow down the experience for the user on 2G?

Screens which would change if this option is selected.

1

Mimic what the other forms do.

Nikodem, could you clarify what this option is? Mimic which form?

Tiny?

2

Make errors appear after the fields has been touched.

3

Make errors appear after we leave (focus on something outside) the table row.

When fields within a lineItem are dependent on each other the error won’t show until they focus away from the LineItem (row)

4

Same as 3, but also highlight the table header.

Depending on the option, the following screens may be impacted. See the above table for details on which would change based on the option.

  • Requisition Product grid (I’m including this because it is my understanding it would be impacted if we chose an option which is different than the current behavior. Or perhaps you are including this later, my apologies.)
  • View Proof of Delivery (#!/pod/id) Question: why is this impacted if the table doesn’t have any inputs? I only see action buttons. Or are you referring to the editable proof of delivery screen?
  • View Requisition (#!/requisition/id) Question: why is this impacted if the table doesn’t have any inputs? I only see action buttons. Or are you referring to the editable requisition screen (aka requisition product grid)?
  • View Shipment (#!/orders/id) Question: do you mean View Orders? Why is this impacted if the table doesn’t have any inputs? I only see action buttons. Or are you referring to the editable shipment (aka the fulfill orders table)?
  • Issue (#!/stockmangement/issue/id)
  • Receive (#!/stockmangement/receive/id)
  • Physical Inventory (#!/physicalInventory/id)
  • Adjustments (#!/adjustment/id)
  • What about Fulfill Orders?
  • Should we be including the “batch approval” of requisitions?

Perhaps we can schedule a call if it would be easier to connect that way. I just want to make sure I’m understanding your proposal and which options will impact which screens. Thank you again for pulling this together and hopefully we can clarify this soon and I can send across to the PC.

Thanks,

Mary Jo

From: Nikodem Graczewski <ngraczewski@soldevelo.commailto:ngraczewski@soldevelo.com>

Date: Tuesday, June 5, 2018 at 12:16 AM

To: Josh Zamor <josh.zamor@villagereach.orgmailto:josh.zamor@villagereach.org>

Cc: Mary Jo Kochendorfer <maryjo.kochendorfer@villagereach.orgmailto:maryjo.kochendorfer@villagereach.org>, OpenLMIS Dev <openlmis-dev@googlegroups.commailto:openlmis-dev@googlegroups.com>

Subject: Re: [openlmis-dev] Re: Error behavior on the table forms

Thanks for the feedback!

The reasoning behind option #3 totally makes sense to me.

About the questions I’m not sure I understand what you mean by “finding errors across line items”? Does it mean we want to bring user to the first error in the table after we attempt to submit it, or is it something else?

Best regards,

Nikodem

Nikodem Graczewski

Software Developer

ngraczewski@soldevelo.commailto:ngraczewski@soldevelo.com

On Tue, Jun 5, 2018 at 12:59 AM, Josh Zamor <josh.zamor@villagereach.orgmailto:josh.zamor@villagereach.org> wrote:

Thanks for the clarification Nikodem, now I understand better.

For line item entry only then:

I still think I favor option #3, identify errors in a line item only after some work has been done in the line item, and then you shift away from it. As well (as always) as identifying all errors when attempting to submit the entries. I recognize this is one of the hardest options and also that it’s likely personal preference - that is I prefer a UX that has fewer visual warnings as I’m working on an item, and instead prefer those visual warnings to be raised after I think I’m done: I shift to another line item or I click a button that is me indicating I’m done. I also recognize this isn’t what the Requisition screen does (option #2), as currently it raises those visual indicators within the line item I’m working on as soon as I start working on the line item and something isn’t right.

Between those two options my preference as I said is #3, however the UX between the two is so small that I can’t say I’d encourage investing significant effort in it. Using option #2 with a smaller LOE seems fine by me.

Do we have an approach to finding errors across line items? I can imagine as we get into budgets for Requisitions we’ll have the need. Would that change the LOE for anything here?

Best,

Josh

On Jun 4, 2018, at 2:54 PM, Nikodem Graczewski <ngraczewski@soldevelo.commailto:ngraczewski@soldevelo.com> wrote:

Yes, if we decide to pick a different approach than the one we’re already using for product grid, this changes will also affect the requisition product grid. The list of screens that will be affected by this is as follows:

  • View Proof of Delivery (#!/pod/id)
  • View Requisition (#!/requisition/id)
  • View Shipment (#!/orders/id)
  • Issue (#!/stockmangement/issue/id)
  • Receive (#!/stockmangement/receive/id)
  • Physical Inventory (#!/physicalInventory/id)
  • Adjustments (#!/adjustment/id)

Hopefully I didn’t miss any screen.

Best regards,

Nikodem

Nikodem Graczewski

Software Developer

ngraczewski@soldevelo.commailto:ngraczewski@soldevelo.com

On Fri, Jun 1, 2018 at 8:39 PM, Mary Jo Kochendorfer <maryjo.kochendorfer@villagereach.orgmailto:maryjo.kochendorfer@villagereach.org> wrote:

Nikodem,

Unfortunately I’m still a bit confused. I too share the concern that Brandon voiced regarding the R&R product grid table.

Could you clarify if you are proposing that the decision made on the pattern for “table forms” impacts the R&R product grid table attached? I was confused when you stated that the Requisition View is a table form since that does not have any inputs or error messages.

If there is any impact on the R&R product grid, we cannot move forward with choosing a table form error pattern without discussing with the Product Committee. We must propose all UI changes since it will impact current implementations of OpenLMIS v3 in Malawi. It would be great if you could pull together the options and clear examples and present at the next PC to ensure we have the whole communities input. I know it might feel arduous to also present to the PC but I do think this will impact the user experience enough that it is important to consider the PC’s perspective.

Thank you for pulling this proposal together and clarifying what the impact is. Let me know if you have any questions about what I’m asking for in terms of raising to the PC.

Thanks,

Mary Jo

From: OpenLMIS Dev <openlmis-dev@googlegroups.commailto:openlmis-dev@googlegroups.com> on behalf of Nikodem Graczewski <ngraczewski@soldevelo.commailto:ngraczewski@soldevelo.com>

Date: Thursday, May 31, 2018 at 11:10 AM

To: Brandon Bowersox-Johnson <brandon.bowersox-johnson@villagereach.orgmailto:brandon.bowersox-johnson@villagereach.org>

Cc: OpenLMIS Dev <openlmis-dev@googlegroups.commailto:openlmis-dev@googlegroups.com>

Subject: Re: [openlmis-dev] Re: Error behavior on the table forms

I might have not expressed myself well enough if it comes to the distinction between table and regular forms, for which I’m sorry.

To clarify, by table form I mean any table that has any inputs inside (Requisition View, Proof of Delivery View, Shipment View and Stock Management Adjustment, Receive, Issue and Physical Inventory screens). Line item entry is the best phrase to describe it (thanks Josh!).

Everything that doesn’t reside directly inside a table (table filters, facility/program select, searches etc) should be considered a standard form.

The main purpose of this thread is to choose the best approach for table forms as we’re using three different approaches to them across the system. The standard forms are already well documented and consistent (I couldn’t find a single form, which wouldn’t work the we expect it to). I agree with Josh on that we want to have two different approaches here.

I hope that clarifies any confusion I might have introduced.

Best regards,

Nikodem

Nikodem Graczewski

Software Developer

ngraczewski@soldevelo.commailto:ngraczewski@soldevelo.com

On Thu, May 31, 2018 at 5:03 PM, Brandon Bowersox-Johnson <brandon.bowersox-johnson@villagereach.orgmailto:brandon.bowersox-johnson@villagereach.org> wrote:

I also feel that the line-item entry—especially the R&R Form—is a special case that justifies a special solution. OpenLMIS v3 has already chosen solution #3 for the R&R Form so far (from v3.0.0 to v3.3.0). I believe stakeholders and end-users are counting on that current behavior. The validation of those R&R Forms is a very detailed, important feature, and making any changes to it would require Product Committee involvement too.

As you evaluate how to handle errors consistently, I suggest looking at the other table forms separately from the R&R Form, and also look at non-form error handling (eg, filter, search, etc). That way if you are proposing changes, everyone can understand what parts of the system you would change.

I’m sorry I missed the Technical Committee (I have a conflicting commitment), but thanks for allowing me to share input.

-Brandon

From: <openlmis-dev@googlegroups.commailto:openlmis-dev@googlegroups.com> on behalf of "josh.zamor@openlmis.orgmailto:josh.zamor@openlmis.org" <josh.zamor@openlmis.orgmailto:josh.zamor@openlmis.org>

Date: Wednesday, May 30, 2018 at 10:01 PM

To: OpenLMIS Dev <openlmis-dev@googlegroups.commailto:openlmis-dev@googlegroups.com>

Subject: [openlmis-dev] Re: Error behavior on the table forms

I expressed this during the call, but I feel like option #3 makes the most sense for line item type entry. Moreover though I wonder if we really are looking for one approach to all situations? e.g. I don’t feel like option #3 makes any sense for the Filter component or the general search component with My Facility / Supervised Facility and other options (btw did we ever settle on a simple name for that thing?). For filter or search it seems like option #1 seems to make the most sense.

My opinion here isn’t set in stone by any means but it does seem like having at-least two approaches makes sense: option #1 should be true for everything and the next option should make the most sense for line item type entry.

For clarity I think the wiki page presents the options in a slightly different order from top to bottom than what we are using here.

Best,

Josh

On Tuesday, May 29, 2018 at 10:25:00 AM UTC-7, Nikodem Graczewski wrote:

Hello everyone,

as a follow up to the last Technical Committee meeting I’m bringing this topic to the dev group so we can decide which approach we would like to take on this matter.

There are 4 possible approaches we could take on how we want to display errors on the table forms (sorted with level of effort required - easiest to hardest):

  1. Mimic what the other forms do.
  1. Make errors appear after the fields has been touched.
  1. Make errors appear after we leave (focus on something outside) the table row.
  1. Same as 3, but also highlight table header.

To learn more about each of the approaches please visit the following link:

https://openlmis.atlassian.net/wiki/spaces/OP/pages/378929173/OpenLMIS+UI±+Error+behavior+approaches<https://www.google.com/url?q=https%3A%2F%2Fopenlmis.atlassian.net%2Fwiki%2Fspaces%2FOP%2Fpages%2F378929173%2FOpenLMIS%2BUI%2B-%2BError%2Bbehavior%2Bapproaches&sa=D&sntz=1&usg=AFQjCNF2vDCG8MSDMA5qYJnSjvQCypInbA>

My two favorites are:

  • 1 - Mainly for consistency reasons. Implementing this approach would make all the forms (table or not) behave exactly the same across the whole system.
  • 2 - Early feedback for the user (errors are shown right after the input is dirty so the user can correct the errors early) as well as the fact we already have this approach implemented and it works fine with the pagination component.

Please, share you opinions on the matter.

Best regards,

Nikodem

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email toopenlmis-dev+unsubscribe@googlegroups.commailto:openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.commailto:openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/8a4a37b3-9f3a-4237-bf71-fa17dc6c21d7%40googlegroups.com<https://groups.google.com/d/msgid/openlmis-dev/8a4a37b3-9f3a-4237-bf71-fa17dc6c21d7%40googlegroups.com?utm_medium=email&utm_source=footer>.

For more options, visit https://groups.google.com/d/optout.

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email toopenlmis-dev+unsubscribe@googlegroups.commailto:openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.commailto:openlmis-dev@googlegroups.com.

To view this discussion on the web visithttps://groups.google.com/d/msgid/openlmis-dev/2F463C89-2265-4916-A42C-F6A0EA87D584%40villagereach.org<https://groups.google.com/d/msgid/openlmis-dev/2F463C89-2265-4916-A42C-F6A0EA87D584%40villagereach.org?utm_medium=email&utm_source=footer>.

For more options, visit https://groups.google.com/d/optout.

Error! Filename not specified.

SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com<http://www.soldevelo.com/>

Al. Zwycięstwa 96/98<https://maps.google.com/?q=Al.+Zwyci%C4%99stwa+96/98&entry=gmail&source=g>, 81-451, Gdynia, Poland

Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email toopenlmis-dev+unsubscribe@googlegroups.commailto:openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.commailto:openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/CAGOM9mW%2BjkRAG2UMQna3Qizqeip6oypjpzAyCi6qBRnF6KRj7A%40mail.gmail.com<https://groups.google.com/d/msgid/openlmis-dev/CAGOM9mW%2BjkRAG2UMQna3Qizqeip6oypjpzAyCi6qBRnF6KRj7A%40mail.gmail.com?utm_medium=email&utm_source=footer>.

For more options, visit https://groups.google.com/d/optout.

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email toopenlmis-dev+unsubscribe@googlegroups.commailto:openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.commailto:openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/02DA5B5A-716E-4D57-9FB9-6E2AB0C8898B%40villagereach.org<https://groups.google.com/d/msgid/openlmis-dev/02DA5B5A-716E-4D57-9FB9-6E2AB0C8898B%40villagereach.org?utm_medium=email&utm_source=footer>.

For more options, visit https://groups.google.com/d/optout.

SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com<http://www.soldevelo.com/>

Al. Zwycięstwa 96/98<https://maps.google.com/?q=Al.+Zwyci%C4%99stwa+96/98&entry=gmail&source=g>, 81-451, Gdynia, Poland

Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

You received this message because you are subscribed to a topic in the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this topic, visit https://groups.google.com/d/topic/openlmis-dev/FTD6ta5PxWc/unsubscribe.

To unsubscribe from this group and all its topics, send an email to openlmis-dev+unsubscribe@googlegroups.commailto:openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.commailto:openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/CAGOM9mVXaMAETbfw-CQUF2%3Dj%2B3EVBnxC%2B5qiuJ2h2jsAax%3Driw%40mail.gmail.com<https://groups.google.com/d/msgid/openlmis-dev/CAGOM9mVXaMAETbfw-CQUF2%3Dj%2B3EVBnxC%2B5qiuJ2h2jsAax%3Driw%40mail.gmail.com?utm_medium=email&utm_source=footer>.

For more options, visit https://groups.google.com/d/optout.

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.commailto:openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.commailto:openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/FAFB3858-7799-428A-AB0D-49DBBF3EB981%40villagereach.org<https://groups.google.com/d/msgid/openlmis-dev/FAFB3858-7799-428A-AB0D-49DBBF3EB981%40villagereach.org?utm_medium=email&utm_source=footer>.

For more options, visit https://groups.google.com/d/optout.

SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com<http://www.soldevelo.com/>

Al. Zwycięstwa 96/98<https://maps.google.com/?q=Al.+Zwyci%C4%99stwa+96/98&entry=gmail&source=g>, 81-451, Gdynia, Poland

Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.commailto:openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.commailto:openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/47E41DF4-7131-42F4-8630-35509898B372%40villagereach.org<https://groups.google.com/d/msgid/openlmis-dev/47E41DF4-7131-42F4-8630-35509898B372%40villagereach.org?utm_medium=email&utm_source=footer>.

For more options, visit https://groups.google.com/d/optout.

[Image removed by sender.]

SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com<http://www.soldevelo.com>

Al. Zwycięstwa 96/98<https://maps.google.com/?q=Al.+Zwyci%C4%99stwa+96/98&entry=gmail&source=g>, 81-451, Gdynia, Poland

Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

[http://www.soldevelo.com/sites/default/files/Soldevelo_logo_EPS_CMYK.png]

SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com<http://www.soldevelo.com>

Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland

Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

<image002.png>

<image001.png>

<image004.png>

<image003.png>

Nikodem Graczewski

Software Developer

ngraczewski@soldevelo.com


(Josh Zamor) #18

Hi Nikodem,

I think we missed one another here. I said I preferred the UX of option 3, but given the higher LOE (and need to get sign-off from PC) I thought option 2 was fine:

So I’m okay with option #2 - it accomplishes the consistency goal with a lower cost and the same UX we use for the Requisition’s line item entry. Also explains why I was confused that you and Mary Jo felt the need to get approval from the PC.

At this point it may be worth informing the PC of a different UX (option 3) and gathering additional feedback, but again option 2 seems the right approach for the UX we have today.

Glad this clears things up.

Best,

Josh

···

Between those two options my preference as I said is #3, however the UX between the two is so small that I can’t say I’d encourage investing significant effort in it. Using option #2 with a smaller LOE seems fine by me.

On Mon, Jun 25, 2018 at 10:10 PM, Josh Zamor
josh.zamor@villagereach.org wrote:

How dare you! Keep such good news from us. Just kidding, congrats on the upcoming date!

A clerical note: when did we decide on option 3? I stated a preference for it, and I still have it, however I noted that the increased LOE probably wouldn’t make it worth it over option 2. If in addition choosing option 3 means a rubber stamp from the product committee is needed to change the UX, then perhaps we really should just move forward with option 2 to get consistency. I’m okay if option 3 isn’t taken up - the UX of option 2 is already accepted afaik.

Congrats Nikodem!

Best,

Josh

On Jun 25, 2018, at 10:34 PM, Nikodem Graczewski ngraczewski@soldevelo.com wrote:

Hi Mary Jo,

unfortunately, I’m out of the office from 27th July to 8th August due to my wedding. Are we OK with postponing the presentation or should I find someone to present in my stead?

Best regards,

Nikodem

Nikodem Graczewski

Software Developer

ngraczewski@soldevelo.commailto:ngraczewski@soldevelo.com

On Mon, Jun 25, 2018 at 7:38 PM, Mary Jo Kochendorfer <maryjo.kochendorfer@villagereach.org<mailto:maryjo.kochendorfer@villagereach.org >> wrote:

Nikodem,

I appreciate your initiative to move things forward. My apologies of the delay on getting this out to the PC. Our last meeting was filled up with an update from TZ and we didn’t have time. We can plan to bring it up on the upcoming meeting of July 3rd. Would you be available to join the call to provide an overview of the options? I want to ensure option 3 works for everyone since it will be a change to the current behavior on the View Requisition (product grid) which is currently in production in Malawi. I think it would be a welcomed change since right now errors show up instantly.

Thanks,

Mary Jo

From: Nikodem Graczewski <ngraczewski@soldevelo.commailto:ngraczewski@soldevelo.com>

Date: Monday, June 25, 2018 at 2:55 AM

To: Mary Jo Kochendorfer <maryjo.kochendorfer@villagereach.orgmailto:maryjo.kochendorfer@villagereach.org>

Cc: Josh Zamor <josh.zamor@villagereach.orgmailto:josh.zamor@villagereach.org>, OpenLMIS Dev <openlmis-dev@googlegroups.commailto:openlmis-dev@googlegroups.com>

Subject: Re: [openlmis-dev] Error behavior on the table forms

Hello everyone,

since there wasn’t any arguments against using the approach #3, I will start writing tickets for updating the screens with this approach.

Here’s a list of the affected screens:

  • View Requisition (Product Grid)
  • Issue
  • Receive
  • Physical Inventory
  • Adjustments

If there are any questions or different preferences, please let me know.

Best regards,

Nikodem

Nikodem Graczewski

Software Developer

ngraczewski@soldevelo.commailto:ngraczewski@soldevelo.com

On Tue, Jun 12, 2018 at 9:03 AM, Nikodem Graczewski <ngraczewski@soldevelo.commailto:ngraczewski@soldevelo.com> wrote:

Hi Mary Jo,

I will try to answer your questions the best I can

Nikodem, to clarify does this include tables which don’t have editable fields/cells but have a column with action buttons? That’s not clear to me.

They wouldn’t be affected as they are not showing any errors.

Nikodem, could you clarify what this option is? Mimic which form?

Basically any form that isn’t a table form. It would behave similar to User creation for example. So we wouldn’t get any feedback unless we click the submit button (Initiate on Requisition View - aka Product Grid - for example).

Question: why is this impacted if the table doesn’t have any inputs? I only see action buttons. Or are you referring to the editable proof of delivery screen?

Question: why is this impacted if the table doesn’t have any inputs? I only see action buttons. Or are you referring to the editable requisition screen (aka requisition product grid)?

Question: do you mean View Orders? Why is this impacted if the table doesn’t have any inputs? I only see action buttons. Or are you referring to the editable shipment (aka the fulfill orders table)?

What about Fulfill Orders?

Should we be including the “batch approval” of requisitions?

When I was referring to those screens I was using their names in the system (used for headers and/or breadcrumbs), which caused a little bit of confusion. To clarify here are screenshots of every screen with a table form:

  • View Proof of Delivery

[cid:ii_jibb9j0b1_163f2b3a71d450e2]

  • View Requisition

[cid:ii_jibb8olt0_163f2b30dd813779]

  • View Shipment

[cid:ii_jibbc4si2_163f2b583a8cce74]

  • Issue, Receive, Physical Inventory, Adjustments

[cid:ii_jibbgzh13_163f2b8f6e205c1f]

Should we be including the “batch approval” of requisitions?

I didn’t include this screen as it is not part of the official release and potentially a subject to change heavily because of the amount of data displayed on it. It also is considered a table form though.

I have also added the requested recap table to the wiki document

Best Regards,

Nikodem

Nikodem Graczewski

Software Developer

ngraczewski@soldevelo.commailto:ngraczewski@soldevelo.com

On Mon, Jun 11, 2018 at 11:13 PM, Mary Jo Kochendorfer <maryjo.kochendorfer@villagereach.org<mailto:maryjo.kochendorfer@villagereach.org >> wrote:

Josh,

As I mentioned, I’m still confused on what is being proposed and the impact of the current requisition product grid error behavior. It is my understanding, after slacking with Nikodem, that based on the decision made there will be impacts on the requisition product grid (Nikodem refers to it as the View Requisition screen).

Given that, I stand by my request to have this proposal brought to the PC due to its impact on current implementations. If we were suggesting to use the View Requisition table form as the standard and make other screens align, then I don’t think it would be necessary.

Mary Jo

From: Josh Zamor <josh.zamor@villagereach.orgmailto:josh.zamor@villagereach.org>

Date: Monday, June 11, 2018 at 1:02 PM

To: Mary Jo Kochendorfer <maryjo.kochendorfer@villagereach.orgmailto:maryjo.kochendorfer@villagereach.org>

Cc: Nikodem Graczewski <ngraczewski@soldevelo.commailto:ngraczewski@soldevelo.com>, OpenLMIS Dev <openlmis-dev@googlegroups.commailto:openlmis-dev@googlegroups.com>

Subject: Re: [openlmis-dev] Error behavior on the table forms

Nikodem and Mary Jo,

No, by across I’m not referring to reading the line item from left to right or right to left. I mean across multiple line items and across a larger form. e.g. An error that displays when a Requisition exceeds it’s budget or a warning if during fulfillment a I fulfill more than one lot than was requested. I don’t think we do currently, I could easily be wrong, however I’m curious if that changes LOE for the different options.

Mary Jo,

Are you sure we need to run this by product committee? I could imagine that being more the case if we were proposing to change the Requisition behavior. Rather Nikodem is trying to reconcile the inconsistent UX error behavior we have in other parts, and I believe what we’re saying is that UX on the Requisition is good enough (and the lower LOE) to replicate elsewhere and achieve higher consistency.

Best,

Josh

On Jun 11, 2018, at 10:34 AM, Mary Jo Kochendorfer <maryjo.kochendorfer@villagereach.org<mailto:maryjo.kochendorfer@villagereach.org >> wrote:

Josh,

To clarify, are you talking about within a lineItem having error messages between to cells/fields within a LineItem? If so, we currently have that behavior/need within the requisition product grid as cells within one lineItem calculate off each other.

Nikodem,

I must admit that I’m still a bit confused and I want to make sure I’m clear on what you are proposing and the impact on the current system behavior. After reading this thread and the wiki<https://openlmis.atlassian.net/wiki/spaces/OP/pages/378929173/OpenLMIS+UI±+Error+behavior+approaches >, I’m still confused. Would you be willing to review the following and make sure I didn’t misunderstand your proposal. If it is correct, we will need to bring this to the Product Committee. I suggest updating your current wiki<https://openlmis.atlassian.net/wiki/spaces/OP/pages/378929173/OpenLMIS+UI±+Error+behavior+approaches > to clearly state 1. The current state, 2. The proposed options and 3. The impact. You could use the table I created below.

Below I’ve started to lay out a summarized view, but I still have open questions to you in red.

Current behavior

Screens are inconsistent. The following proposal is specifically looking at “Table Forms”. A table form is any table that has any inputs inside of the table or ‘lineItem entries’. Nikodem, to clarify does this include tables which don’t have editable fields/cells but have a column with action buttons? That’s not clear to me.

Proposed Options

The following are the 4 options are for Table forms: Nikodem, it would be useful to see a table like this

Option

Level of Effort

User Benefit

Performance Impact

Will the option slow down the experience for the user on 2G?

Screens which would change if this option is selected.

1

Mimic what the other forms do.

Nikodem, could you clarify what this option is? Mimic which form?

Tiny?

2

Make errors appear after the fields has been touched.

3

Make errors appear after we leave (focus on something outside) the table row.

When fields within a lineItem are dependent on each other the error won’t show until they focus away from the LineItem (row)

4

Same as 3, but also highlight the table header.

Depending on the option, the following screens may be impacted. See the above table for details on which would change based on the option.

  • Requisition Product grid (I’m including this because it is my understanding it would be impacted if we chose an option which is different than the current behavior. Or perhaps you are including this later, my apologies.)
  • View Proof of Delivery (#!/pod/id) Question: why is this impacted if the table doesn’t have any inputs? I only see action buttons. Or are you referring to the editable proof of delivery screen?
  • View Requisition (#!/requisition/id) Question: why is this impacted if the table doesn’t have any inputs? I only see action buttons. Or are you referring to the editable requisition screen (aka requisition product grid)?
  • View Shipment (#!/orders/id) Question: do you mean View Orders? Why is this impacted if the table doesn’t have any inputs? I only see action buttons. Or are you referring to the editable shipment (aka the fulfill orders table)?
  • Issue (#!/stockmangement/issue/id)
  • Receive (#!/stockmangement/receive/id)
  • Physical Inventory (#!/physicalInventory/id)
  • Adjustments (#!/adjustment/id)
  • What about Fulfill Orders?
  • Should we be including the “batch approval” of requisitions?

Perhaps we can schedule a call if it would be easier to connect that way. I just want to make sure I’m understanding your proposal and which options will impact which screens. Thank you again for pulling this together and hopefully we can clarify this soon and I can send across to the PC.

Thanks,

Mary Jo

From: Nikodem Graczewski <ngraczewski@soldevelo.commailto:ngraczewski@soldevelo.com>

Date: Tuesday, June 5, 2018 at 12:16 AM

To: Josh Zamor <josh.zamor@villagereach.orgmailto:josh.zamor@villagereach.org>

Cc: Mary Jo Kochendorfer <maryjo.kochendorfer@villagereach.org<mailto:maryjo.kochendorfer@villagereach.org >>, OpenLMIS Dev <openlmis-dev@googlegroups.commailto:openlmis-dev@googlegroups.com>

Subject: Re: [openlmis-dev] Re: Error behavior on the table forms

Thanks for the feedback!

The reasoning behind option #3 totally makes sense to me.

About the questions I’m not sure I understand what you mean by “finding errors across line items”? Does it mean we want to bring user to the first error in the table after we attempt to submit it, or is it something else?

Best regards,

Nikodem

Nikodem Graczewski

Software Developer

ngraczewski@soldevelo.commailto:ngraczewski@soldevelo.com

On Tue, Jun 5, 2018 at 12:59 AM, Josh Zamor <josh.zamor@villagereach.orgmailto:josh.zamor@villagereach.org> wrote:

Thanks for the clarification Nikodem, now I understand better.

For line item entry only then:

I still think I favor option #3, identify errors in a line item only after some work has been done in the line item, and then you shift away from it. As well (as always) as identifying all errors when attempting to submit the entries. I recognize this is one of the hardest options and also that it’s likely personal preference - that is I prefer a UX that has fewer visual warnings as I’m working on an item, and instead prefer those visual warnings to be raised after I think I’m done: I shift to another line item or I click a button that is me indicating I’m done. I also recognize this isn’t what the Requisition screen does (option #2), as currently it raises those visual indicators within the line item I’m working on as soon as I start working on the line item and something isn’t right.

Between those two options my preference as I said is #3, however the UX between the two is so small that I can’t say I’d encourage investing significant effort in it. Using option #2 with a smaller LOE seems fine by me.

Do we have an approach to finding errors across line items? I can imagine as we get into budgets for Requisitions we’ll have the need. Would that change the LOE for anything here?

Best,

Josh

On Jun 4, 2018, at 2:54 PM, Nikodem Graczewski <ngraczewski@soldevelo.com<mailto:ngraczewski@soldevelo.com >> wrote:

Yes, if we decide to pick a different approach than the one we’re already using for product grid, this changes will also affect the requisition product grid. The list of screens that will be affected by this is as follows:

  • View Proof of Delivery (#!/pod/id)
  • View Requisition (#!/requisition/id)
  • View Shipment (#!/orders/id)
  • Issue (#!/stockmangement/issue/id)
  • Receive (#!/stockmangement/receive/id)
  • Physical Inventory (#!/physicalInventory/id)
  • Adjustments (#!/adjustment/id)

Hopefully I didn’t miss any screen.

Best regards,

Nikodem

Nikodem Graczewski

Software Developer

ngraczewski@soldevelo.commailto:ngraczewski@soldevelo.com

On Fri, Jun 1, 2018 at 8:39 PM, Mary Jo Kochendorfer <maryjo.kochendorfer@villagereach.org<mailto:maryjo.kochendorfer@villagereach.org >> wrote:

Nikodem,

Unfortunately I’m still a bit confused. I too share the concern that Brandon voiced regarding the R&R product grid table.

Could you clarify if you are proposing that the decision made on the pattern for “table forms” impacts the R&R product grid table attached? I was confused when you stated that the Requisition View is a table form since that does not have any inputs or error messages.

If there is any impact on the R&R product grid, we cannot move forward with choosing a table form error pattern without discussing with the Product Committee. We must propose all UI changes since it will impact current implementations of OpenLMIS v3 in Malawi. It would be great if you could pull together the options and clear examples and present at the next PC to ensure we have the whole communities input. I know it might feel arduous to also present to the PC but I do think this will impact the user experience enough that it is important to consider the PC’s perspective.

Thank you for pulling this proposal together and clarifying what the impact is. Let me know if you have any questions about what I’m asking for in terms of raising to the PC.

Thanks,

Mary Jo

From: OpenLMIS Dev <openlmis-dev@googlegroups.com<mailto:openlmis-dev@googlegroups.com >> on behalf of Nikodem Graczewski <ngraczewski@soldevelo.commailto:ngraczewski@soldevelo.com>

Date: Thursday, May 31, 2018 at 11:10 AM

To: Brandon Bowersox-Johnson <brandon.bowersox-johnson@villagereach.orgmailto:brandon.bowersox-johnson@villagereach.org>

Cc: OpenLMIS Dev <openlmis-dev@googlegroups.commailto:openlmis-dev@googlegroups.com>

Subject: Re: [openlmis-dev] Re: Error behavior on the table forms

I might have not expressed myself well enough if it comes to the distinction between table and regular forms, for which I’m sorry.

To clarify, by table form I mean any table that has any inputs inside (Requisition View, Proof of Delivery View, Shipment View and Stock Management Adjustment, Receive, Issue and Physical Inventory screens). Line item entry is the best phrase to describe it (thanks Josh!).

Everything that doesn’t reside directly inside a table (table filters, facility/program select, searches etc) should be considered a standard form.

The main purpose of this thread is to choose the best approach for table forms as we’re using three different approaches to them across the system. The standard forms are already well documented and consistent (I couldn’t find a single form, which wouldn’t work the we expect it to). I agree with Josh on that we want to have two different approaches here.

I hope that clarifies any confusion I might have introduced.

Best regards,

Nikodem

Nikodem Graczewski

Software Developer

ngraczewski@soldevelo.commailto:ngraczewski@soldevelo.com

On Thu, May 31, 2018 at 5:03 PM, Brandon Bowersox-Johnson <brandon.bowersox-johnson@villagereach.org<mailto:brandon.bowersox-johnson@villagereach.org >> wrote:

I also feel that the line-item entry—especially the R&R Form—is a special case that justifies a special solution. OpenLMIS v3 has already chosen solution #3 for the R&R Form so far (from v3.0.0 to v3.3.0). I believe stakeholders and end-users are counting on that current behavior. The validation of those R&R Forms is a very detailed, important feature, and making any changes to it would require Product Committee involvement too.

As you evaluate how to handle errors consistently, I suggest looking at the other table forms separately from the R&R Form, and also look at non-form error handling (eg, filter, search, etc). That way if you are proposing changes, everyone can understand what parts of the system you would change.

I’m sorry I missed the Technical Committee (I have a conflicting commitment), but thanks for allowing me to share input.

-Brandon

From: <openlmis-dev@googlegroups.commailto:openlmis-dev@googlegroups.com> on behalf of "josh.zamor@openlmis.org<mailto:josh.zamor@openlmis.org >" <josh.zamor@openlmis.orgmailto:josh.zamor@openlmis.org>

Date: Wednesday, May 30, 2018 at 10:01 PM

To: OpenLMIS Dev <openlmis-dev@googlegroups.commailto:openlmis-dev@googlegroups.com>

Subject: [openlmis-dev] Re: Error behavior on the table forms

I expressed this during the call, but I feel like option #3 makes the most sense for line item type entry. Moreover though I wonder if we really are looking for one approach to all situations? e.g. I don’t feel like option #3 makes any sense for the Filter component or the general search component with My Facility / Supervised Facility and other options (btw did we ever settle on a simple name for that thing?). For filter or search it seems like option #1 seems to make the most sense.

My opinion here isn’t set in stone by any means but it does seem like having at-least two approaches makes sense: option #1 should be true for everything and the next option should make the most sense for line item type entry.

For clarity I think the wiki page presents the options in a slightly different order from top to bottom than what we are using here.

Best,

Josh

On Tuesday, May 29, 2018 at 10:25:00 AM UTC-7, Nikodem Graczewski wrote:

Hello everyone,

as a follow up to the last Technical Committee meeting I’m bringing this topic to the dev group so we can decide which approach we would like to take on this matter.

There are 4 possible approaches we could take on how we want to display errors on the table forms (sorted with level of effort required - easiest to hardest):

  1. Mimic what the other forms do.
  1. Make errors appear after the fields has been touched.
  1. Make errors appear after we leave (focus on something outside) the table row.
  1. Same as 3, but also highlight table header.

To learn more about each of the approaches please visit the following link:


https://openlmis.atlassian.net/wiki/spaces/OP/pages/378929173/OpenLMIS+UI±+Error+behavior+approaches
<https://www.google.com/url?q=https%3A%2F%2Fopenlmis.atlassian.net%2Fwiki%2Fspaces%2FOP%2Fpages%2F378929173%2FOpenLMIS%2BUI%2B-%2BError%2Bbehavior%2Bapproaches&sa=D&sntz=1&usg=AFQjCNF2vDCG8MSDMA5qYJnSjvQCypInbA>

My two favorites are:

  • 1 - Mainly for consistency reasons. Implementing this approach would make all the forms (table or not) behave exactly the same across the whole system.
  • 2 - Early feedback for the user (errors are shown right after the input is dirty so the user can correct the errors early) as well as the fact we already have this approach implemented and it works fine with the pagination component.

Please, share you opinions on the matter.

Best regards,

Nikodem

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email toopenlmis-dev+unsubscribe@googlegroups.commailto:openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to
openlmis-dev@googlegroups.commailto:openlmis-dev@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/8a4a37b3-9f3a-4237-bf71-fa17dc6c21d7%40googlegroups.com
<https://groups.google.com/d/msgid/openlmis-dev/8a4a37b3-9f3a-4237-bf71-fa17dc6c21d7%40googlegroups.com?utm_medium=email&utm_source=footer>.

For more options, visit
https://groups.google.com/d/optout
.

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email toopenlmis-dev+unsubscribe@googlegroups.commailto:openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to
openlmis-dev@googlegroups.commailto:openlmis-dev@googlegroups.com.

To view this discussion on the web visithttps://groups.google.com/d/msgid/openlmis-dev/2F463C89-2265-4916-A42C-F6A0EA87D584%40villagereach.org<https://groups.google.com/d/msgid/openlmis-dev/2F463C89-2265-4916-A42C-F6A0EA87D584%40villagereach.org?utm_medium=email&utm_source=footer>.

For more options, visit
https://groups.google.com/d/optout
.

Error! Filename not specified.

SolDevelo Sp. z o.o. [LLC] /
www.soldevelo.com
<http://www.soldevelo.com/>

Al. Zwycięstwa 96/98<https://maps.google.com/?q=Al.+Zwyci%C4%99stwa+96/98&entry=gmail&source=g >, 81-451, Gdynia, Poland

Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email toopenlmis-dev+unsubscribe@googlegroups.commailto:openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to
openlmis-dev@googlegroups.commailto:openlmis-dev@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/CAGOM9mW%2BjkRAG2UMQna3Qizqeip6oypjpzAyCi6qBRnF6KRj7A%40mail.gmail.com
<https://groups.google.com/d/msgid/openlmis-dev/CAGOM9mW%2BjkRAG2UMQna3Qizqeip6oypjpzAyCi6qBRnF6KRj7A%40mail.gmail.com?utm_medium=email&utm_source=footer>.

For more options, visit
https://groups.google.com/d/optout
.

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email toopenlmis-dev+unsubscribe@googlegroups.commailto:openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to
openlmis-dev@googlegroups.commailto:openlmis-dev@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/02DA5B5A-716E-4D57-9FB9-6E2AB0C8898B%40villagereach.org
<https://groups.google.com/d/msgid/openlmis-dev/02DA5B5A-716E-4D57-9FB9-6E2AB0C8898B%40villagereach.org?utm_medium=email&utm_source=footer>.

For more options, visit
https://groups.google.com/d/optout
.

SolDevelo Sp. z o.o. [LLC] /
www.soldevelo.com
<http://www.soldevelo.com/>

Al. Zwycięstwa 96/98<https://maps.google.com/?q=Al.+Zwyci%C4%99stwa+96/98&entry=gmail&source=g >, 81-451, Gdynia, Poland

Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

You received this message because you are subscribed to a topic in the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this topic, visit
https://groups.google.com/d/topic/openlmis-dev/FTD6ta5PxWc/unsubscribe
.

To unsubscribe from this group and all its topics, send an email to
openlmis-dev+unsubscribe@googlegroups.commailto:openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to
openlmis-dev@googlegroups.commailto:openlmis-dev@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/CAGOM9mVXaMAETbfw-CQUF2%3Dj%2B3EVBnxC%2B5qiuJ2h2jsAax%3Driw%40mail.gmail.com
<https://groups.google.com/d/msgid/openlmis-dev/CAGOM9mVXaMAETbfw-CQUF2%3Dj%2B3EVBnxC%2B5qiuJ2h2jsAax%3Driw%40mail.gmail.com?utm_medium=email&utm_source=footer>.

For more options, visit
https://groups.google.com/d/optout
.

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.commailto:openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to
openlmis-dev@googlegroups.commailto:openlmis-dev@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/FAFB3858-7799-428A-AB0D-49DBBF3EB981%40villagereach.org
<https://groups.google.com/d/msgid/openlmis-dev/FAFB3858-7799-428A-AB0D-49DBBF3EB981%40villagereach.org?utm_medium=email&utm_source=footer>.

For more options, visit
https://groups.google.com/d/optout
.

SolDevelo Sp. z o.o. [LLC] /
www.soldevelo.com
<http://www.soldevelo.com/>

Al. Zwycięstwa 96/98<https://maps.google.com/?q=Al.+Zwyci%C4%99stwa+96/98&entry=gmail&source=g >, 81-451, Gdynia, Poland

Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.commailto:openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to
openlmis-dev@googlegroups.commailto:openlmis-dev@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/47E41DF4-7131-42F4-8630-35509898B372%40villagereach.org
<https://groups.google.com/d/msgid/openlmis-dev/47E41DF4-7131-42F4-8630-35509898B372%40villagereach.org?utm_medium=email&utm_source=footer>.

For more options, visit
https://groups.google.com/d/optout
.

[Image removed by sender.]

SolDevelo Sp. z o.o. [LLC] /
www.soldevelo.com
<http://www.soldevelo.com>

Al. Zwycięstwa 96/98<https://maps.google.com/?q=Al.+Zwyci%C4%99stwa+96/98&entry=gmail&source=g >, 81-451, Gdynia, Poland

Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

[http://www.soldevelo.com/sites/default/files/Soldevelo_logo_EPS_CMYK.png]

SolDevelo Sp. z o.o. [LLC] /
www.soldevelo.com
<http://www.soldevelo.com>

Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland

Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

<image002.png>

<image001.png>

<image004.png>

<image003.png>

**Nikodem Graczewski
**

Software Developer

ngraczewski@soldevelo.com


(Nikodem Graczewski) #19

Hi Josh,

I believe the reason for presenting this to PC was that we were proposing a change in behavior of already existent (and used by implementations) screen. The change wouldn’t be that big, but it still could confuse some of the user (is it a bug or a new feature?).

I agree that presenting option #3 is a good idea. My suggestion is presenting it to the Product Committee before we start working on updating the screen,s just in case they feel like option #3 is really the right way to go.

If we are OK with the option #2 I’m happy to start writing ticket for updating the following screens:

  • View Proof of Delivery
  • View Shipment
  • Batch Approval
    Best regards,
    Nikodem


SolDevelo
Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

···

On Tue, Jun 26, 2018 at 9:34 AM, Josh Zamor josh.zamor@villagereach.org wrote:

Hi Nikodem,

I think we missed one another here. I said I preferred the UX of option 3, but given the higher LOE (and need to get sign-off from PC) I thought option 2 was fine:

So I’m okay with option #2 - it accomplishes the consistency goal with a lower cost and the same UX we use for the Requisition’s line item entry. Also explains why I was confused that you and Mary Jo felt the need to get approval from the PC.

At this point it may be worth informing the PC of a different UX (option 3) and gathering additional feedback, but again option 2 seems the right approach for the UX we have today.

Glad this clears things up.

Best,

Josh

On Jun 26, 2018, at 10:25 AM, Nikodem Graczewski ngraczewski@soldevelo.com wrote:

Hi Josh,

thank you! I obviously meant 27th June to 8th July, sorry for my mistake.

I felt like we were leaning forward option #3. The main effort with this ticket will most likely be updating the pagination component to work with it, updating the screen should be straight-forward.

Best regards,

Nikodem

**

SolDevelo** Sp. z o.o. [LLC] /
www.soldevelo.com

Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland

Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to
openlmis-dev@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/CAGOM9mVrRcpmMPkqaxdvDiZ6jguHLiOT%3DSJqD3VQF1BgCRg5Gg%40mail.gmail.com
.

For more options, visit https://groups.google.com/d/optout.

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/1D07E4CC-BF87-4F56-8127-4731329E07E4%40villagereach.org.

For more options, visit https://groups.google.com/d/optout.

Nikodem Graczewski

Software Developer

ngraczewski@soldevelo.com

Between those two options my preference as I said is #3, however the UX between the two is so small that I can’t say I’d encourage investing significant effort in it. Using option #2 with a smaller LOE seems fine by me.

**Nikodem Graczewski
**

Software Developer

ngraczewski@soldevelo.com

On Mon, Jun 25, 2018 at 10:10 PM, Josh Zamor
josh.zamor@villagereach.org wrote:

How dare you! Keep such good news from us. Just kidding, congrats on the upcoming date!

A clerical note: when did we decide on option 3? I stated a preference for it, and I still have it, however I noted that the increased LOE probably wouldn’t make it worth it over option 2. If in addition choosing option 3 means a rubber stamp from the product committee is needed to change the UX, then perhaps we really should just move forward with option 2 to get consistency. I’m okay if option 3 isn’t taken up - the UX of option 2 is already accepted afaik.

Congrats Nikodem!

Best,

Josh

On Jun 25, 2018, at 10:34 PM, Nikodem Graczewski ngraczewski@soldevelo.com wrote:

Hi Mary Jo,

unfortunately, I’m out of the office from 27th July to 8th August due to my wedding. Are we OK with postponing the presentation or should I find someone to present in my stead?

Best regards,

Nikodem

Nikodem Graczewski

Software Developer

ngraczewski@soldevelo.commailto:ngraczewski@soldevelo.com

On Mon, Jun 25, 2018 at 7:38 PM, Mary Jo Kochendorfer <maryjo.kochendorfer@villagereach.orgmailto:maryjo.kochendorfer@villagereach.org > wrote:

Nikodem,

I appreciate your initiative to move things forward. My apologies of the delay on getting this out to the PC. Our last meeting was filled up with an update from TZ and we didn’t have time. We can plan to bring it up on the upcoming meeting of July 3rd. Would you be available to join the call to provide an overview of the options? I want to ensure option 3 works for everyone since it will be a change to the current behavior on the View Requisition (product grid) which is currently in production in Malawi. I think it would be a welcomed change since right now errors show up instantly.

Thanks,

Mary Jo

From: Nikodem Graczewski <ngraczewski@soldevelo.commailto:ngraczewski@soldevelo.com>

Date: Monday, June 25, 2018 at 2:55 AM

To: Mary Jo Kochendorfer <maryjo.kochendorfer@villagereach.orgmailto:maryjo.kochendorfer@villagereach.org>

Cc: Josh Zamor <josh.zamor@villagereach.orgmailto:josh.zamor@villagereach.org>, OpenLMIS Dev <openlmis-dev@googlegroups.commailto:openlmis-dev@googlegroups.com>

Subject: Re: [openlmis-dev] Error behavior on the table forms

Hello everyone,

since there wasn’t any arguments against using the approach #3, I will start writing tickets for updating the screens with this approach.

Here’s a list of the affected screens:

  • View Requisition (Product Grid)
  • Issue
  • Receive
  • Physical Inventory
  • Adjustments

If there are any questions or different preferences, please let me know.

Best regards,

Nikodem

Nikodem Graczewski

Software Developer

ngraczewski@soldevelo.commailto:ngraczewski@soldevelo.com

On Tue, Jun 12, 2018 at 9:03 AM, Nikodem Graczewski <ngraczewski@soldevelo.commailto:ngraczewski@soldevelo.com> wrote:

Hi Mary Jo,

I will try to answer your questions the best I can

Nikodem, to clarify does this include tables which don’t have editable fields/cells but have a column with action buttons? That’s not clear to me.

They wouldn’t be affected as they are not showing any errors.

Nikodem, could you clarify what this option is? Mimic which form?

Basically any form that isn’t a table form. It would behave similar to User creation for example. So we wouldn’t get any feedback unless we click the submit button (Initiate on Requisition View - aka Product Grid - for example).

Question: why is this impacted if the table doesn’t have any inputs? I only see action buttons. Or are you referring to the editable proof of delivery screen?

Question: why is this impacted if the table doesn’t have any inputs? I only see action buttons. Or are you referring to the editable requisition screen (aka requisition product grid)?

Question: do you mean View Orders? Why is this impacted if the table doesn’t have any inputs? I only see action buttons. Or are you referring to the editable shipment (aka the fulfill orders table)?

What about Fulfill Orders?

Should we be including the “batch approval” of requisitions?

When I was referring to those screens I was using their names in the system (used for headers and/or breadcrumbs), which caused a little bit of confusion. To clarify here are screenshots of every screen with a table form:

  • View Proof of Delivery

[cid:ii_jibb9j0b1_163f2b3a71d450e2]

  • View Requisition

[cid:ii_jibb8olt0_163f2b30dd813779]

  • View Shipment

[cid:ii_jibbc4si2_163f2b583a8cce74]

  • Issue, Receive, Physical Inventory, Adjustments

[cid:ii_jibbgzh13_163f2b8f6e205c1f]

Should we be including the “batch approval” of requisitions?

I didn’t include this screen as it is not part of the official release and potentially a subject to change heavily because of the amount of data displayed on it. It also is considered a table form though.

I have also added the requested recap table to the wiki document

Best Regards,

Nikodem

Nikodem Graczewski

Software Developer

ngraczewski@soldevelo.commailto:ngraczewski@soldevelo.com

On Mon, Jun 11, 2018 at 11:13 PM, Mary Jo Kochendorfer <maryjo.kochendorfer@villagereach.orgmailto:maryjo.kochendorfer@villagereach.org > wrote:

Josh,

As I mentioned, I’m still confused on what is being proposed and the impact of the current requisition product grid error behavior. It is my understanding, after slacking with Nikodem, that based on the decision made there will be impacts on the requisition product grid (Nikodem refers to it as the View Requisition screen).

Given that, I stand by my request to have this proposal brought to the PC due to its impact on current implementations. If we were suggesting to use the View Requisition table form as the standard and make other screens align, then I don’t think it would be necessary.

Mary Jo

From: Josh Zamor <josh.zamor@villagereach.orgmailto:josh.zamor@villagereach.org>

Date: Monday, June 11, 2018 at 1:02 PM

To: Mary Jo Kochendorfer <maryjo.kochendorfer@villagereach.orgmailto:maryjo.kochendorfer@villagereach.org>

Cc: Nikodem Graczewski <ngraczewski@soldevelo.commailto:ngraczewski@soldevelo.com>, OpenLMIS Dev <openlmis-dev@googlegroups.commailto:openlmis-dev@googlegroups.com>

Subject: Re: [openlmis-dev] Error behavior on the table forms

Nikodem and Mary Jo,

No, by across I’m not referring to reading the line item from left to right or right to left. I mean across multiple line items and across a larger form. e.g. An error that displays when a Requisition exceeds it’s budget or a warning if during fulfillment a I fulfill more than one lot than was requested. I don’t think we do currently, I could easily be wrong, however I’m curious if that changes LOE for the different options.

Mary Jo,

Are you sure we need to run this by product committee? I could imagine that being more the case if we were proposing to change the Requisition behavior. Rather Nikodem is trying to reconcile the inconsistent UX error behavior we have in other parts, and I believe what we’re saying is that UX on the Requisition is good enough (and the lower LOE) to replicate elsewhere and achieve higher consistency.

Best,

Josh

On Jun 11, 2018, at 10:34 AM, Mary Jo Kochendorfer <maryjo.kochendorfer@villagereach.orgmailto:maryjo.kochendorfer@villagereach.org > wrote:

Josh,

To clarify, are you talking about within a lineItem having error messages between to cells/fields within a LineItem? If so, we currently have that behavior/need within the requisition product grid as cells within one lineItem calculate off each other.

Nikodem,

I must admit that I’m still a bit confused and I want to make sure I’m clear on what you are proposing and the impact on the current system behavior. After reading this thread and the wiki<https://openlmis.atlassian.net/wiki/spaces/OP/pages/378929173/OpenLMIS+UI±+Error+behavior+approaches >, I’m still confused. Would you be willing to review the following and make sure I didn’t misunderstand your proposal. If it is correct, we will need to bring this to the Product Committee. I suggest updating your current wiki<https://openlmis.atlassian.net/wiki/spaces/OP/pages/378929173/OpenLMIS+UI±+Error+behavior+approaches > to clearly state 1. The current state, 2. The proposed options and 3. The impact. You could use the table I created below.

Below I’ve started to lay out a summarized view, but I still have open questions to you in red.

Current behavior

Screens are inconsistent. The following proposal is specifically looking at “Table Forms”. A table form is any table that has any inputs inside of the table or ‘lineItem entries’. Nikodem, to clarify does this include tables which don’t have editable fields/cells but have a column with action buttons? That’s not clear to me.

Proposed Options

The following are the 4 options are for Table forms: Nikodem, it would be useful to see a table like this

Option

Level of Effort

User Benefit

Performance Impact

Will the option slow down the experience for the user on 2G?

Screens which would change if this option is selected.

1

Mimic what the other forms do.

Nikodem, could you clarify what this option is? Mimic which form?

Tiny?

2

Make errors appear after the fields has been touched.

3

Make errors appear after we leave (focus on something outside) the table row.

When fields within a lineItem are dependent on each other the error won’t show until they focus away from the LineItem (row)

4

Same as 3, but also highlight the table header.

Depending on the option, the following screens may be impacted. See the above table for details on which would change based on the option.

  • Requisition Product grid (I’m including this because it is my understanding it would be impacted if we chose an option which is different than the current behavior. Or perhaps you are including this later, my apologies.)
  • View Proof of Delivery (#!/pod/id) Question: why is this impacted if the table doesn’t have any inputs? I only see action buttons. Or are you referring to the editable proof of delivery screen?
  • View Requisition (#!/requisition/id) Question: why is this impacted if the table doesn’t have any inputs? I only see action buttons. Or are you referring to the editable requisition screen (aka requisition product grid)?
  • View Shipment (#!/orders/id) Question: do you mean View Orders? Why is this impacted if the table doesn’t have any inputs? I only see action buttons. Or are you referring to the editable shipment (aka the fulfill orders table)?
  • Issue (#!/stockmangement/issue/id)
  • Receive (#!/stockmangement/receive/id)
  • Physical Inventory (#!/physicalInventory/id)
  • Adjustments (#!/adjustment/id)
  • What about Fulfill Orders?
  • Should we be including the “batch approval” of requisitions?

Perhaps we can schedule a call if it would be easier to connect that way. I just want to make sure I’m understanding your proposal and which options will impact which screens. Thank you again for pulling this together and hopefully we can clarify this soon and I can send across to the PC.

Thanks,

Mary Jo

From: Nikodem Graczewski <ngraczewski@soldevelo.commailto:ngraczewski@soldevelo.com>

Date: Tuesday, June 5, 2018 at 12:16 AM

To: Josh Zamor <josh.zamor@villagereach.orgmailto:josh.zamor@villagereach.org>

Cc: Mary Jo Kochendorfer <maryjo.kochendorfer@villagereach.orgmailto:maryjo.kochendorfer@villagereach.org >, OpenLMIS Dev <openlmis-dev@googlegroups.commailto:openlmis-dev@googlegroups.com>

Subject: Re: [openlmis-dev] Re: Error behavior on the table forms

Thanks for the feedback!

The reasoning behind option #3 totally makes sense to me.

About the questions I’m not sure I understand what you mean by “finding errors across line items”? Does it mean we want to bring user to the first error in the table after we attempt to submit it, or is it something else?

Best regards,

Nikodem

Nikodem Graczewski

Software Developer

ngraczewski@soldevelo.commailto:ngraczewski@soldevelo.com

On Tue, Jun 5, 2018 at 12:59 AM, Josh Zamor <josh.zamor@villagereach.orgmailto:josh.zamor@villagereach.org> wrote:

Thanks for the clarification Nikodem, now I understand better.

For line item entry only then:

I still think I favor option #3, identify errors in a line item only after some work has been done in the line item, and then you shift away from it. As well (as always) as identifying all errors when attempting to submit the entries. I recognize this is one of the hardest options and also that it’s likely personal preference - that is I prefer a UX that has fewer visual warnings as I’m working on an item, and instead prefer those visual warnings to be raised after I think I’m done: I shift to another line item or I click a button that is me indicating I’m done. I also recognize this isn’t what the Requisition screen does (option #2), as currently it raises those visual indicators within the line item I’m working on as soon as I start working on the line item and something isn’t right.

Between those two options my preference as I said is #3, however the UX between the two is so small that I can’t say I’d encourage investing significant effort in it. Using option #2 with a smaller LOE seems fine by me.

Do we have an approach to finding errors across line items? I can imagine as we get into budgets for Requisitions we’ll have the need. Would that change the LOE for anything here?

Best,

Josh

On Jun 4, 2018, at 2:54 PM, Nikodem Graczewski <ngraczewski@soldevelo.commailto:ngraczewski@soldevelo.com > wrote:

Yes, if we decide to pick a different approach than the one we’re already using for product grid, this changes will also affect the requisition product grid. The list of screens that will be affected by this is as follows:

  • View Proof of Delivery (#!/pod/id)
  • View Requisition (#!/requisition/id)
  • View Shipment (#!/orders/id)
  • Issue (#!/stockmangement/issue/id)
  • Receive (#!/stockmangement/receive/id)
  • Physical Inventory (#!/physicalInventory/id)
  • Adjustments (#!/adjustment/id)

Hopefully I didn’t miss any screen.

Best regards,

Nikodem

Nikodem Graczewski

Software Developer

ngraczewski@soldevelo.commailto:ngraczewski@soldevelo.com

On Fri, Jun 1, 2018 at 8:39 PM, Mary Jo Kochendorfer <maryjo.kochendorfer@villagereach.orgmailto:maryjo.kochendorfer@villagereach.org > wrote:

Nikodem,

Unfortunately I’m still a bit confused. I too share the concern that Brandon voiced regarding the R&R product grid table.

Could you clarify if you are proposing that the decision made on the pattern for “table forms” impacts the R&R product grid table attached? I was confused when you stated that the Requisition View is a table form since that does not have any inputs or error messages.

If there is any impact on the R&R product grid, we cannot move forward with choosing a table form error pattern without discussing with the Product Committee. We must propose all UI changes since it will impact current implementations of OpenLMIS v3 in Malawi. It would be great if you could pull together the options and clear examples and present at the next PC to ensure we have the whole communities input. I know it might feel arduous to also present to the PC but I do think this will impact the user experience enough that it is important to consider the PC’s perspective.

Thank you for pulling this proposal together and clarifying what the impact is. Let me know if you have any questions about what I’m asking for in terms of raising to the PC.

Thanks,

Mary Jo

From: OpenLMIS Dev <openlmis-dev@googlegroups.com<mailto:openlmis-dev@googlegroups.com >> on behalf of Nikodem Graczewski <ngraczewski@soldevelo.commailto:ngraczewski@soldevelo.com>

Date: Thursday, May 31, 2018 at 11:10 AM

To: Brandon Bowersox-Johnson <brandon.bowersox-johnson@villagereach.orgmailto:brandon.bowersox-johnson@villagereach.org>

Cc: OpenLMIS Dev <openlmis-dev@googlegroups.commailto:openlmis-dev@googlegroups.com>

Subject: Re: [openlmis-dev] Re: Error behavior on the table forms

I might have not expressed myself well enough if it comes to the distinction between table and regular forms, for which I’m sorry.

To clarify, by table form I mean any table that has any inputs inside (Requisition View, Proof of Delivery View, Shipment View and Stock Management Adjustment, Receive, Issue and Physical Inventory screens). Line item entry is the best phrase to describe it (thanks Josh!).

Everything that doesn’t reside directly inside a table (table filters, facility/program select, searches etc) should be considered a standard form.

The main purpose of this thread is to choose the best approach for table forms as we’re using three different approaches to them across the system. The standard forms are already well documented and consistent (I couldn’t find a single form, which wouldn’t work the we expect it to). I agree with Josh on that we want to have two different approaches here.

I hope that clarifies any confusion I might have introduced.

Best regards,

Nikodem

Nikodem Graczewski

Software Developer

ngraczewski@soldevelo.commailto:ngraczewski@soldevelo.com

On Thu, May 31, 2018 at 5:03 PM, Brandon Bowersox-Johnson <brandon.bowersox-johnson@villagereach.org<mailto:brandon.bowersox-johnson@villagereach.org >> wrote:

I also feel that the line-item entry—especially the R&R Form—is a special case that justifies a special solution. OpenLMIS v3 has already chosen solution #3 for the R&R Form so far (from v3.0.0 to v3.3.0). I believe stakeholders and end-users are counting on that current behavior. The validation of those R&R Forms is a very detailed, important feature, and making any changes to it would require Product Committee involvement too.

As you evaluate how to handle errors consistently, I suggest looking at the other table forms separately from the R&R Form, and also look at non-form error handling (eg, filter, search, etc). That way if you are proposing changes, everyone can understand what parts of the system you would change.

I’m sorry I missed the Technical Committee (I have a conflicting commitment), but thanks for allowing me to share input.

-Brandon

From: <openlmis-dev@googlegroups.commailto:openlmis-dev@googlegroups.com> on behalf of "josh.zamor@openlmis.org<mailto:josh.zamor@openlmis.org >" <josh.zamor@openlmis.orgmailto:josh.zamor@openlmis.org>

Date: Wednesday, May 30, 2018 at 10:01 PM

To: OpenLMIS Dev <openlmis-dev@googlegroups.commailto:openlmis-dev@googlegroups.com>

Subject: [openlmis-dev] Re: Error behavior on the table forms

I expressed this during the call, but I feel like option #3 makes the most sense for line item type entry. Moreover though I wonder if we really are looking for one approach to all situations? e.g. I don’t feel like option #3 makes any sense for the Filter component or the general search component with My Facility / Supervised Facility and other options (btw did we ever settle on a simple name for that thing?). For filter or search it seems like option #1 seems to make the most sense.

My opinion here isn’t set in stone by any means but it does seem like having at-least two approaches makes sense: option #1 should be true for everything and the next option should make the most sense for line item type entry.

For clarity I think the wiki page presents the options in a slightly different order from top to bottom than what we are using here.

Best,

Josh

On Tuesday, May 29, 2018 at 10:25:00 AM UTC-7, Nikodem Graczewski wrote:

Hello everyone,

as a follow up to the last Technical Committee meeting I’m bringing this topic to the dev group so we can decide which approach we would like to take on this matter.

There are 4 possible approaches we could take on how we want to display errors on the table forms (sorted with level of effort required - easiest to hardest):

  1. Mimic what the other forms do.
  1. Make errors appear after the fields has been touched.
  1. Make errors appear after we leave (focus on something outside) the table row.
  1. Same as 3, but also highlight table header.

To learn more about each of the approaches please visit the following link:


https://openlmis.atlassian.net/wiki/spaces/OP/pages/378929173/OpenLMIS+UI±+Error+behavior+approaches
<https://www.google.com/url?q=https%3A%2F%2Fopenlmis.atlassian.net%2Fwiki%2Fspaces%2FOP%2Fpages%2F378929173%2FOpenLMIS%2BUI%2B-%2BError%2Bbehavior%2Bapproaches&sa=D&sntz=1&usg=AFQjCNF2vDCG8MSDMA5qYJnSjvQCypInbA>

My two favorites are:

  • 1 - Mainly for consistency reasons. Implementing this approach would make all the forms (table or not) behave exactly the same across the whole system.
  • 2 - Early feedback for the user (errors are shown right after the input is dirty so the user can correct the errors early) as well as the fact we already have this approach implemented and it works fine with the pagination component.

Please, share you opinions on the matter.

Best regards,

Nikodem

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email toopenlmis-dev+unsubscribe@googlegroups.commailto:openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to
openlmis-dev@googlegroups.commailto:openlmis-dev@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/8a4a37b3-9f3a-4237-bf71-fa17dc6c21d7%40googlegroups.com
<https://groups.google.com/d/msgid/openlmis-dev/8a4a37b3-9f3a-4237-bf71-fa17dc6c21d7%40googlegroups.com?utm_medium=email&utm_source=footer>.

For more options, visit
https://groups.google.com/d/optout
.

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email toopenlmis-dev+unsubscribe@googlegroups.commailto:openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to
openlmis-dev@googlegroups.commailto:openlmis-dev@googlegroups.com.

To view this discussion on the web visithttps://groups.google.com/d/msgid/openlmis-dev/2F463C89-2265-4916-A42C-F6A0EA87D584%40villagereach.org<https://groups.google.com/d/msgid/openlmis-dev/2F463C89-2265-4916-A42C-F6A0EA87D584%40villagereach.org?utm_medium=email&utm_source=footer>.

For more options, visit
https://groups.google.com/d/optout
.

Error! Filename not specified.

SolDevelo Sp. z o.o. [LLC] /
www.soldevelo.com
<http://www.soldevelo.com/>

Al. Zwycięstwa 96/98<https://maps.google.com/?q=Al.+Zwyci%C4%99stwa+96/98&entry=gmail&source=g >, 81-451, Gdynia, Poland

Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email toopenlmis-dev+unsubscribe@googlegroups.commailto:openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to
openlmis-dev@googlegroups.commailto:openlmis-dev@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/CAGOM9mW%2BjkRAG2UMQna3Qizqeip6oypjpzAyCi6qBRnF6KRj7A%40mail.gmail.com
<https://groups.google.com/d/msgid/openlmis-dev/CAGOM9mW%2BjkRAG2UMQna3Qizqeip6oypjpzAyCi6qBRnF6KRj7A%40mail.gmail.com?utm_medium=email&utm_source=footer>.

For more options, visit
https://groups.google.com/d/optout
.

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email toopenlmis-dev+unsubscribe@googlegroups.commailto:openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to
openlmis-dev@googlegroups.commailto:openlmis-dev@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/02DA5B5A-716E-4D57-9FB9-6E2AB0C8898B%40villagereach.org
<https://groups.google.com/d/msgid/openlmis-dev/02DA5B5A-716E-4D57-9FB9-6E2AB0C8898B%40villagereach.org?utm_medium=email&utm_source=footer>.

For more options, visit
https://groups.google.com/d/optout
.

SolDevelo Sp. z o.o. [LLC] /
www.soldevelo.com
<http://www.soldevelo.com/>

Al. Zwycięstwa 96/98<https://maps.google.com/?q=Al.+Zwyci%C4%99stwa+96/98&entry=gmail&source=g >, 81-451, Gdynia, Poland

Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

You received this message because you are subscribed to a topic in the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this topic, visit
https://groups.google.com/d/topic/openlmis-dev/FTD6ta5PxWc/unsubscribe
.

To unsubscribe from this group and all its topics, send an email to
openlmis-dev+unsubscribe@googlegroups.commailto:openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to
openlmis-dev@googlegroups.commailto:openlmis-dev@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/CAGOM9mVXaMAETbfw-CQUF2%3Dj%2B3EVBnxC%2B5qiuJ2h2jsAax%3Driw%40mail.gmail.com
<https://groups.google.com/d/msgid/openlmis-dev/CAGOM9mVXaMAETbfw-CQUF2%3Dj%2B3EVBnxC%2B5qiuJ2h2jsAax%3Driw%40mail.gmail.com?utm_medium=email&utm_source=footer>.

For more options, visit
https://groups.google.com/d/optout
.

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.commailto:openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to
openlmis-dev@googlegroups.commailto:openlmis-dev@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/FAFB3858-7799-428A-AB0D-49DBBF3EB981%40villagereach.org
<https://groups.google.com/d/msgid/openlmis-dev/FAFB3858-7799-428A-AB0D-49DBBF3EB981%40villagereach.org?utm_medium=email&utm_source=footer>.

For more options, visit
https://groups.google.com/d/optout
.

SolDevelo Sp. z o.o. [LLC] /
www.soldevelo.com
<http://www.soldevelo.com/>

Al. Zwycięstwa 96/98<https://maps.google.com/?q=Al.+Zwyci%C4%99stwa+96/98&entry=gmail&source=g >, 81-451, Gdynia, Poland

Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.commailto:openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to
openlmis-dev@googlegroups.commailto:openlmis-dev@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/47E41DF4-7131-42F4-8630-35509898B372%40villagereach.org
<https://groups.google.com/d/msgid/openlmis-dev/47E41DF4-7131-42F4-8630-35509898B372%40villagereach.org?utm_medium=email&utm_source=footer>.

For more options, visit
https://groups.google.com/d/optout
.

[Image removed by sender.]

SolDevelo Sp. z o.o. [LLC] /
www.soldevelo.com
<http://www.soldevelo.com>

Al. Zwycięstwa 96/98<https://maps.google.com/?q=Al.+Zwyci%C4%99stwa+96/98&entry=gmail&source=g >, 81-451, Gdynia, Poland

Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

[http://www.soldevelo.com/sites/default/files/Soldevelo_logo_EPS_CMYK.png]

SolDevelo Sp. z o.o. [LLC] /
www.soldevelo.com
<http://www.soldevelo.com>

Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland

Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

<image002.png>

<image001.png>

<image004.png>

<image003.png>


(Josh Zamor) #20

Option 2 if I’ve understood correctly is what the Requisition (though not batch approve of course) does today and your goal is to create consistent error handling. If we wanted to standardize on anything but option 2, we would be changing the Requisition screen. With option 2 it’s left unchanged, right?

Best,

Josh

···

On Tue, Jun 26, 2018 at 9:34 AM, Josh Zamor
josh.zamor@villagereach.org wrote:

Hi Nikodem,

I think we missed one another here. I said I preferred the UX of option 3, but given the higher LOE (and need to get sign-off from PC) I thought option 2 was fine:

So I’m okay with option #2 - it accomplishes the consistency goal with a lower cost and the same UX we use for the Requisition’s line item entry. Also explains why I was confused that you and Mary Jo felt the need to get approval from the PC.

At this point it may be worth informing the PC of a different UX (option 3) and gathering additional feedback, but again option 2 seems the right approach for the UX we have today.

Glad this clears things up.

Best,

Josh

On Jun 26, 2018, at 10:25 AM, Nikodem Graczewski ngraczewski@soldevelo.com wrote:

Hi Josh,

thank you! I obviously meant 27th June to 8th July, sorry for my mistake.

I felt like we were leaning forward option #3. The main effort with this ticket will most likely be updating the pagination component to work with it, updating the screen should be straight-forward.

Best regards,

Nikodem

**

SolDevelo** Sp. z o.o. [LLC] /
www.soldevelo.com

Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland

Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to
openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to
openlmis-dev@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/CAGOM9mVrRcpmMPkqaxdvDiZ6jguHLiOT%3DSJqD3VQF1BgCRg5Gg%40mail.gmail.com
.

For more options, visit
https://groups.google.com/d/optout
.

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to
openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to
openlmis-dev@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/1D07E4CC-BF87-4F56-8127-4731329E07E4%40villagereach.org
.

For more options, visit
https://groups.google.com/d/optout
.

**Nikodem Graczewski
**

Software Developer

ngraczewski@soldevelo.com

Between those two options my preference as I said is #3, however the UX between the two is so small that I can’t say I’d encourage investing significant effort in it. Using option #2 with a smaller LOE seems fine by me.

**Nikodem Graczewski
**

Software Developer

ngraczewski@soldevelo.com

On Mon, Jun 25, 2018 at 10:10 PM, Josh Zamor
josh.zamor@villagereach.org wrote:

How dare you! Keep such good news from us. Just kidding, congrats on the upcoming date!

A clerical note: when did we decide on option 3? I stated a preference for it, and I still have it, however I noted that the increased LOE probably wouldn’t make it worth it over option 2. If in addition choosing option 3 means a rubber stamp from the product committee is needed to change the UX, then perhaps we really should just move forward with option 2 to get consistency. I’m okay if option 3 isn’t taken up - the UX of option 2 is already accepted afaik.

Congrats Nikodem!

Best,

Josh

On Jun 25, 2018, at 10:34 PM, Nikodem Graczewski ngraczewski@soldevelo.com wrote:

Hi Mary Jo,

unfortunately, I’m out of the office from 27th July to 8th August due to my wedding. Are we OK with postponing the presentation or should I find someone to present in my stead?

Best regards,

Nikodem

Nikodem Graczewski

Software Developer

ngraczewski@soldevelo.commailto:ngraczewski@soldevelo.com

On Mon, Jun 25, 2018 at 7:38 PM, Mary Jo Kochendorfer <maryjo.kochendorfer@villagereach.orgmailto:maryjo.kochendorfer@villagereach.org > wrote:

Nikodem,

I appreciate your initiative to move things forward. My apologies of the delay on getting this out to the PC. Our last meeting was filled up with an update from TZ and we didn’t have time. We can plan to bring it up on the upcoming meeting of July 3rd. Would you be available to join the call to provide an overview of the options? I want to ensure option 3 works for everyone since it will be a change to the current behavior on the View Requisition (product grid) which is currently in production in Malawi. I think it would be a welcomed change since right now errors show up instantly.

Thanks,

Mary Jo

From: Nikodem Graczewski <ngraczewski@soldevelo.commailto:ngraczewski@soldevelo.com>

Date: Monday, June 25, 2018 at 2:55 AM

To: Mary Jo Kochendorfer <maryjo.kochendorfer@villagereach.orgmailto:maryjo.kochendorfer@villagereach.org>

Cc: Josh Zamor <josh.zamor@villagereach.org<mailto:josh.zamor@villagereach.org >>, OpenLMIS Dev <openlmis-dev@googlegroups.commailto:openlmis-dev@googlegroups.com>

Subject: Re: [openlmis-dev] Error behavior on the table forms

Hello everyone,

since there wasn’t any arguments against using the approach #3, I will start writing tickets for updating the screens with this approach.

Here’s a list of the affected screens:

  • View Requisition (Product Grid)
  • Issue
  • Receive
  • Physical Inventory
  • Adjustments

If there are any questions or different preferences, please let me know.

Best regards,

Nikodem

Nikodem Graczewski

Software Developer

ngraczewski@soldevelo.commailto:ngraczewski@soldevelo.com

On Tue, Jun 12, 2018 at 9:03 AM, Nikodem Graczewski <ngraczewski@soldevelo.commailto:ngraczewski@soldevelo.com > wrote:

Hi Mary Jo,

I will try to answer your questions the best I can

Nikodem, to clarify does this include tables which don’t have editable fields/cells but have a column with action buttons? That’s not clear to me.

They wouldn’t be affected as they are not showing any errors.

Nikodem, could you clarify what this option is? Mimic which form?

Basically any form that isn’t a table form. It would behave similar to User creation for example. So we wouldn’t get any feedback unless we click the submit button (Initiate on Requisition View - aka Product Grid - for example).

Question: why is this impacted if the table doesn’t have any inputs? I only see action buttons. Or are you referring to the editable proof of delivery screen?

Question: why is this impacted if the table doesn’t have any inputs? I only see action buttons. Or are you referring to the editable requisition screen (aka requisition product grid)?

Question: do you mean View Orders? Why is this impacted if the table doesn’t have any inputs? I only see action buttons. Or are you referring to the editable shipment (aka the fulfill orders table)?

What about Fulfill Orders?

Should we be including the “batch approval” of requisitions?

When I was referring to those screens I was using their names in the system (used for headers and/or breadcrumbs), which caused a little bit of confusion. To clarify here are screenshots of every screen with a table form:

  • View Proof of Delivery

[cid:ii_jibb9j0b1_163f2b3a71d450e2]

  • View Requisition

[cid:ii_jibb8olt0_163f2b30dd813779]

  • View Shipment

[cid:ii_jibbc4si2_163f2b583a8cce74]

  • Issue, Receive, Physical Inventory, Adjustments

[cid:ii_jibbgzh13_163f2b8f6e205c1f]

Should we be including the “batch approval” of requisitions?

I didn’t include this screen as it is not part of the official release and potentially a subject to change heavily because of the amount of data displayed on it. It also is considered a table form though.

I have also added the requested recap table to the wiki document

Best Regards,

Nikodem

Nikodem Graczewski

Software Developer

ngraczewski@soldevelo.commailto:ngraczewski@soldevelo.com

On Mon, Jun 11, 2018 at 11:13 PM, Mary Jo Kochendorfer <maryjo.kochendorfer@villagereach.orgmailto:maryjo.kochendorfer@villagereach.org > wrote:

Josh,

As I mentioned, I’m still confused on what is being proposed and the impact of the current requisition product grid error behavior. It is my understanding, after slacking with Nikodem, that based on the decision made there will be impacts on the requisition product grid (Nikodem refers to it as the View Requisition screen).

Given that, I stand by my request to have this proposal brought to the PC due to its impact on current implementations. If we were suggesting to use the View Requisition table form as the standard and make other screens align, then I don’t think it would be necessary.

Mary Jo

From: Josh Zamor <josh.zamor@villagereach.orgmailto:josh.zamor@villagereach.org>

Date: Monday, June 11, 2018 at 1:02 PM

To: Mary Jo Kochendorfer <maryjo.kochendorfer@villagereach.orgmailto:maryjo.kochendorfer@villagereach.org>

Cc: Nikodem Graczewski <ngraczewski@soldevelo.commailto:ngraczewski@soldevelo.com >, OpenLMIS Dev <openlmis-dev@googlegroups.commailto:openlmis-dev@googlegroups.com>

Subject: Re: [openlmis-dev] Error behavior on the table forms

Nikodem and Mary Jo,

No, by across I’m not referring to reading the line item from left to right or right to left. I mean across multiple line items and across a larger form. e.g. An error that displays when a Requisition exceeds it’s budget or a warning if during fulfillment a I fulfill more than one lot than was requested. I don’t think we do currently, I could easily be wrong, however I’m curious if that changes LOE for the different options.

Mary Jo,

Are you sure we need to run this by product committee? I could imagine that being more the case if we were proposing to change the Requisition behavior. Rather Nikodem is trying to reconcile the inconsistent UX error behavior we have in other parts, and I believe what we’re saying is that UX on the Requisition is good enough (and the lower LOE) to replicate elsewhere and achieve higher consistency.

Best,

Josh

On Jun 11, 2018, at 10:34 AM, Mary Jo Kochendorfer <maryjo.kochendorfer@villagereach.orgmailto:maryjo.kochendorfer@villagereach.org > wrote:

Josh,

To clarify, are you talking about within a lineItem having error messages between to cells/fields within a LineItem? If so, we currently have that behavior/need within the requisition product grid as cells within one lineItem calculate off each other.

Nikodem,

I must admit that I’m still a bit confused and I want to make sure I’m clear on what you are proposing and the impact on the current system behavior. After reading this thread and the wiki<https://openlmis.atlassian.net/wiki/spaces/OP/pages/378929173/OpenLMIS+UI±+Error+behavior+approaches >, I’m still confused. Would you be willing to review the following and make sure I didn’t misunderstand your proposal. If it is correct, we will need to bring this to the Product Committee. I suggest updating your current wiki<https://openlmis.atlassian.net/wiki/spaces/OP/pages/378929173/OpenLMIS+UI±+Error+behavior+approaches > to clearly state 1. The current state, 2. The proposed options and 3. The impact. You could use the table I created below.

Below I’ve started to lay out a summarized view, but I still have open questions to you in red.

Current behavior

Screens are inconsistent. The following proposal is specifically looking at “Table Forms”. A table form is any table that has any inputs inside of the table or ‘lineItem entries’. Nikodem, to clarify does this include tables which don’t have editable fields/cells but have a column with action buttons? That’s not clear to me.

Proposed Options

The following are the 4 options are for Table forms: Nikodem, it would be useful to see a table like this

Option

Level of Effort

User Benefit

Performance Impact

Will the option slow down the experience for the user on 2G?

Screens which would change if this option is selected.

1

Mimic what the other forms do.

Nikodem, could you clarify what this option is? Mimic which form?

Tiny?

2

Make errors appear after the fields has been touched.

3

Make errors appear after we leave (focus on something outside) the table row.

When fields within a lineItem are dependent on each other the error won’t show until they focus away from the LineItem (row)

4

Same as 3, but also highlight the table header.

Depending on the option, the following screens may be impacted. See the above table for details on which would change based on the option.

  • Requisition Product grid (I’m including this because it is my understanding it would be impacted if we chose an option which is different than the current behavior. Or perhaps you are including this later, my apologies.)
  • View Proof of Delivery (#!/pod/id) Question: why is this impacted if the table doesn’t have any inputs? I only see action buttons. Or are you referring to the editable proof of delivery screen?
  • View Requisition (#!/requisition/id) Question: why is this impacted if the table doesn’t have any inputs? I only see action buttons. Or are you referring to the editable requisition screen (aka requisition product grid)?
  • View Shipment (#!/orders/id) Question: do you mean View Orders? Why is this impacted if the table doesn’t have any inputs? I only see action buttons. Or are you referring to the editable shipment (aka the fulfill orders table)?
  • Issue (#!/stockmangement/issue/id)
  • Receive (#!/stockmangement/receive/id)
  • Physical Inventory (#!/physicalInventory/id)
  • Adjustments (#!/adjustment/id)
  • What about Fulfill Orders?
  • Should we be including the “batch approval” of requisitions?

Perhaps we can schedule a call if it would be easier to connect that way. I just want to make sure I’m understanding your proposal and which options will impact which screens. Thank you again for pulling this together and hopefully we can clarify this soon and I can send across to the PC.

Thanks,

Mary Jo

From: Nikodem Graczewski <ngraczewski@soldevelo.commailto:ngraczewski@soldevelo.com>

Date: Tuesday, June 5, 2018 at 12:16 AM

To: Josh Zamor <josh.zamor@villagereach.orgmailto:josh.zamor@villagereach.org>

Cc: Mary Jo Kochendorfer <maryjo.kochendorfer@villagereach.orgmailto:maryjo.kochendorfer@villagereach.org >, OpenLMIS Dev <openlmis-dev@googlegroups.commailto:openlmis-dev@googlegroups.com>

Subject: Re: [openlmis-dev] Re: Error behavior on the table forms

Thanks for the feedback!

The reasoning behind option #3 totally makes sense to me.

About the questions I’m not sure I understand what you mean by “finding errors across line items”? Does it mean we want to bring user to the first error in the table after we attempt to submit it, or is it something else?

Best regards,

Nikodem

Nikodem Graczewski

Software Developer

ngraczewski@soldevelo.commailto:ngraczewski@soldevelo.com

On Tue, Jun 5, 2018 at 12:59 AM, Josh Zamor <josh.zamor@villagereach.org<mailto:josh.zamor@villagereach.org >> wrote:

Thanks for the clarification Nikodem, now I understand better.

For line item entry only then:

I still think I favor option #3, identify errors in a line item only after some work has been done in the line item, and then you shift away from it. As well (as always) as identifying all errors when attempting to submit the entries. I recognize this is one of the hardest options and also that it’s likely personal preference - that is I prefer a UX that has fewer visual warnings as I’m working on an item, and instead prefer those visual warnings to be raised after I think I’m done: I shift to another line item or I click a button that is me indicating I’m done. I also recognize this isn’t what the Requisition screen does (option #2), as currently it raises those visual indicators within the line item I’m working on as soon as I start working on the line item and something isn’t right.

Between those two options my preference as I said is #3, however the UX between the two is so small that I can’t say I’d encourage investing significant effort in it. Using option #2 with a smaller LOE seems fine by me.

Do we have an approach to finding errors across line items? I can imagine as we get into budgets for Requisitions we’ll have the need. Would that change the LOE for anything here?

Best,

Josh

On Jun 4, 2018, at 2:54 PM, Nikodem Graczewski <ngraczewski@soldevelo.commailto:ngraczewski@soldevelo.com > wrote:

Yes, if we decide to pick a different approach than the one we’re already using for product grid, this changes will also affect the requisition product grid. The list of screens that will be affected by this is as follows:

  • View Proof of Delivery (#!/pod/id)
  • View Requisition (#!/requisition/id)
  • View Shipment (#!/orders/id)
  • Issue (#!/stockmangement/issue/id)
  • Receive (#!/stockmangement/receive/id)
  • Physical Inventory (#!/physicalInventory/id)
  • Adjustments (#!/adjustment/id)

Hopefully I didn’t miss any screen.

Best regards,

Nikodem

Nikodem Graczewski

Software Developer

ngraczewski@soldevelo.commailto:ngraczewski@soldevelo.com

On Fri, Jun 1, 2018 at 8:39 PM, Mary Jo Kochendorfer <maryjo.kochendorfer@villagereach.orgmailto:maryjo.kochendorfer@villagereach.org > wrote:

Nikodem,

Unfortunately I’m still a bit confused. I too share the concern that Brandon voiced regarding the R&R product grid table.

Could you clarify if you are proposing that the decision made on the pattern for “table forms” impacts the R&R product grid table attached? I was confused when you stated that the Requisition View is a table form since that does not have any inputs or error messages.

If there is any impact on the R&R product grid, we cannot move forward with choosing a table form error pattern without discussing with the Product Committee. We must propose all UI changes since it will impact current implementations of OpenLMIS v3 in Malawi. It would be great if you could pull together the options and clear examples and present at the next PC to ensure we have the whole communities input. I know it might feel arduous to also present to the PC but I do think this will impact the user experience enough that it is important to consider the PC’s perspective.

Thank you for pulling this proposal together and clarifying what the impact is. Let me know if you have any questions about what I’m asking for in terms of raising to the PC.

Thanks,

Mary Jo

From: OpenLMIS Dev <openlmis-dev@googlegroups.com<mailto:openlmis-dev@googlegroups.com >> on behalf of Nikodem Graczewski <ngraczewski@soldevelo.commailto:ngraczewski@soldevelo.com>

Date: Thursday, May 31, 2018 at 11:10 AM

To: Brandon Bowersox-Johnson <brandon.bowersox-johnson@villagereach.orgmailto:brandon.bowersox-johnson@villagereach.org>

Cc: OpenLMIS Dev <openlmis-dev@googlegroups.commailto:openlmis-dev@googlegroups.com>

Subject: Re: [openlmis-dev] Re: Error behavior on the table forms

I might have not expressed myself well enough if it comes to the distinction between table and regular forms, for which I’m sorry.

To clarify, by table form I mean any table that has any inputs inside (Requisition View, Proof of Delivery View, Shipment View and Stock Management Adjustment, Receive, Issue and Physical Inventory screens). Line item entry is the best phrase to describe it (thanks Josh!).

Everything that doesn’t reside directly inside a table (table filters, facility/program select, searches etc) should be considered a standard form.

The main purpose of this thread is to choose the best approach for table forms as we’re using three different approaches to them across the system. The standard forms are already well documented and consistent (I couldn’t find a single form, which wouldn’t work the we expect it to). I agree with Josh on that we want to have two different approaches here.

I hope that clarifies any confusion I might have introduced.

Best regards,

Nikodem

Nikodem Graczewski

Software Developer

ngraczewski@soldevelo.commailto:ngraczewski@soldevelo.com

On Thu, May 31, 2018 at 5:03 PM, Brandon Bowersox-Johnson <brandon.bowersox-johnson@villagereach.org<mailto:brandon.bowersox-johnson@villagereach.org >> wrote:

I also feel that the line-item entry—especially the R&R Form—is a special case that justifies a special solution. OpenLMIS v3 has already chosen solution #3 for the R&R Form so far (from v3.0.0 to v3.3.0). I believe stakeholders and end-users are counting on that current behavior. The validation of those R&R Forms is a very detailed, important feature, and making any changes to it would require Product Committee involvement too.

As you evaluate how to handle errors consistently, I suggest looking at the other table forms separately from the R&R Form, and also look at non-form error handling (eg, filter, search, etc). That way if you are proposing changes, everyone can understand what parts of the system you would change.

I’m sorry I missed the Technical Committee (I have a conflicting commitment), but thanks for allowing me to share input.

-Brandon

From: <openlmis-dev@googlegroups.com<mailto:openlmis-dev@googlegroups.com >> on behalf of "josh.zamor@openlmis.orgmailto:josh.zamor@openlmis.org" <josh.zamor@openlmis.orgmailto:josh.zamor@openlmis.org>

Date: Wednesday, May 30, 2018 at 10:01 PM

To: OpenLMIS Dev <openlmis-dev@googlegroups.commailto:openlmis-dev@googlegroups.com>

Subject: [openlmis-dev] Re: Error behavior on the table forms

I expressed this during the call, but I feel like option #3 makes the most sense for line item type entry. Moreover though I wonder if we really are looking for one approach to all situations? e.g. I don’t feel like option #3 makes any sense for the Filter component or the general search component with My Facility / Supervised Facility and other options (btw did we ever settle on a simple name for that thing?). For filter or search it seems like option #1 seems to make the most sense.

My opinion here isn’t set in stone by any means but it does seem like having at-least two approaches makes sense: option #1 should be true for everything and the next option should make the most sense for line item type entry.

For clarity I think the wiki page presents the options in a slightly different order from top to bottom than what we are using here.

Best,

Josh

On Tuesday, May 29, 2018 at 10:25:00 AM UTC-7, Nikodem Graczewski wrote:

Hello everyone,

as a follow up to the last Technical Committee meeting I’m bringing this topic to the dev group so we can decide which approach we would like to take on this matter.

There are 4 possible approaches we could take on how we want to display errors on the table forms (sorted with level of effort required - easiest to hardest):

  1. Mimic what the other forms do.
  1. Make errors appear after the fields has been touched.
  1. Make errors appear after we leave (focus on something outside) the table row.
  1. Same as 3, but also highlight table header.

To learn more about each of the approaches please visit the following link:


https://openlmis.atlassian.net/wiki/spaces/OP/pages/378929173/OpenLMIS+UI±+Error+behavior+approaches
<https://www.google.com/url?q=https%3A%2F%2Fopenlmis.atlassian.net%2Fwiki%2Fspaces%2FOP%2Fpages%2F378929173%2FOpenLMIS%2BUI%2B-%2BError%2Bbehavior%2Bapproaches&sa=D&sntz=1&usg=AFQjCNF2vDCG8MSDMA5qYJnSjvQCypInbA>

My two favorites are:

  • 1 - Mainly for consistency reasons. Implementing this approach would make all the forms (table or not) behave exactly the same across the whole system.
  • 2 - Early feedback for the user (errors are shown right after the input is dirty so the user can correct the errors early) as well as the fact we already have this approach implemented and it works fine with the pagination component.

Please, share you opinions on the matter.

Best regards,

Nikodem

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email
toopenlmis-dev+unsubscribe@googlegroups.commailto:openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to
openlmis-dev@googlegroups.commailto:openlmis-dev@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/8a4a37b3-9f3a-4237-bf71-fa17dc6c21d7%40googlegroups.com
<https://groups.google.com/d/msgid/openlmis-dev/8a4a37b3-9f3a-4237-bf71-fa17dc6c21d7%40googlegroups.com?utm_medium=email&utm_source=footer>.

For more options, visit
https://groups.google.com/d/optout
.

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email
toopenlmis-dev+unsubscribe@googlegroups.commailto:openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to
openlmis-dev@googlegroups.commailto:openlmis-dev@googlegroups.com.

To view this discussion on the web visithttps://groups.google.com/d/msgid/openlmis-dev/2F463C89-2265-4916-A42C-F6A0EA87D584%40villagereach.org<https://groups.google.com/d/msgid/openlmis-dev/2F463C89-2265-4916-A42C-F6A0EA87D584%40villagereach.org?utm_medium=email&utm_source=footer>.

For more options, visit
https://groups.google.com/d/optout
.

Error! Filename not specified.

SolDevelo Sp. z o.o. [LLC] /
www.soldevelo.com
<http://www.soldevelo.com/>


Al. Zwycięstwa 96/98
<https://maps.google.com/?q=Al.+Zwyci%C4%99stwa+96/98&entry=gmail&source=g >, 81-451, Gdynia, Poland

Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email
toopenlmis-dev+unsubscribe@googlegroups.commailto:openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to
openlmis-dev@googlegroups.commailto:openlmis-dev@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/CAGOM9mW%2BjkRAG2UMQna3Qizqeip6oypjpzAyCi6qBRnF6KRj7A%40mail.gmail.com
<https://groups.google.com/d/msgid/openlmis-dev/CAGOM9mW%2BjkRAG2UMQna3Qizqeip6oypjpzAyCi6qBRnF6KRj7A%40mail.gmail.com?utm_medium=email&utm_source=footer>.

For more options, visit
https://groups.google.com/d/optout
.

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email
toopenlmis-dev+unsubscribe@googlegroups.commailto:openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to
openlmis-dev@googlegroups.commailto:openlmis-dev@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/02DA5B5A-716E-4D57-9FB9-6E2AB0C8898B%40villagereach.org
<https://groups.google.com/d/msgid/openlmis-dev/02DA5B5A-716E-4D57-9FB9-6E2AB0C8898B%40villagereach.org?utm_medium=email&utm_source=footer>.

For more options, visit
https://groups.google.com/d/optout
.

SolDevelo Sp. z o.o. [LLC] /
www.soldevelo.com
<http://www.soldevelo.com/>


Al. Zwycięstwa 96/98
<https://maps.google.com/?q=Al.+Zwyci%C4%99stwa+96/98&entry=gmail&source=g >, 81-451, Gdynia, Poland

Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

You received this message because you are subscribed to a topic in the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this topic, visit
https://groups.google.com/d/topic/openlmis-dev/FTD6ta5PxWc/unsubscribe
.

To unsubscribe from this group and all its topics, send an email to
openlmis-dev+unsubscribe@googlegroups.commailto:openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to
openlmis-dev@googlegroups.commailto:openlmis-dev@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/CAGOM9mVXaMAETbfw-CQUF2%3Dj%2B3EVBnxC%2B5qiuJ2h2jsAax%3Driw%40mail.gmail.com
<https://groups.google.com/d/msgid/openlmis-dev/CAGOM9mVXaMAETbfw-CQUF2%3Dj%2B3EVBnxC%2B5qiuJ2h2jsAax%3Driw%40mail.gmail.com?utm_medium=email&utm_source=footer>.

For more options, visit
https://groups.google.com/d/optout
.

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to
openlmis-dev+unsubscribe@googlegroups.commailto:openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to
openlmis-dev@googlegroups.commailto:openlmis-dev@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/FAFB3858-7799-428A-AB0D-49DBBF3EB981%40villagereach.org
<https://groups.google.com/d/msgid/openlmis-dev/FAFB3858-7799-428A-AB0D-49DBBF3EB981%40villagereach.org?utm_medium=email&utm_source=footer>.

For more options, visit
https://groups.google.com/d/optout
.

SolDevelo Sp. z o.o. [LLC] /
www.soldevelo.com
<http://www.soldevelo.com/>


Al. Zwycięstwa 96/98
<https://maps.google.com/?q=Al.+Zwyci%C4%99stwa+96/98&entry=gmail&source=g >, 81-451, Gdynia, Poland

Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to
openlmis-dev+unsubscribe@googlegroups.commailto:openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to
openlmis-dev@googlegroups.commailto:openlmis-dev@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/47E41DF4-7131-42F4-8630-35509898B372%40villagereach.org
<https://groups.google.com/d/msgid/openlmis-dev/47E41DF4-7131-42F4-8630-35509898B372%40villagereach.org?utm_medium=email&utm_source=footer>.

For more options, visit
https://groups.google.com/d/optout
.

[Image removed by sender.]

SolDevelo Sp. z o.o. [LLC] /
www.soldevelo.com
<http://www.soldevelo.com>


Al. Zwycięstwa 96/98
<https://maps.google.com/?q=Al.+Zwyci%C4%99stwa+96/98&entry=gmail&source=g >, 81-451, Gdynia, Poland

Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

[http://www.soldevelo.com/sites/default/files/Soldevelo_logo_EPS_CMYK.png]

SolDevelo Sp. z o.o. [LLC] /
www.soldevelo.com
<http://www.soldevelo.com>


Al. Zwycięstwa 96/98
, 81-451, Gdynia, Poland

Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

<image002.png>

<image001.png>

<image004.png>

<image003.png>