Error behavior on the table forms
Nikodem Graczewski
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):
- Mimic what the other forms do.
- Make errors appear after the fields has been touched.
- Make errors appear after we leave (focus on something outside) the table row.
- Same as 3, but also highlight table header.
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.
Best regards,
Nikodem
josh....@openlmis.org
Brandon Bowersox-Johnson
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
--
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...@googlegroups.com.
To post to this group, send email to
openlm...@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
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
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 openlm...@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 view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/2F463C89-2265-4916-A42C-F6A0EA87D584%40villagereach.org.
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
Mary Jo Kochendorfer
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
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev...@googlegroups.com.
To post to this group, send email to
To view this discussion on the web visit
--
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...@googlegroups.com.
To post to this group, send email to
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...@googlegroups.com.
To post to this group, send email to
openlm...@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
- 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)
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
To view this discussion on the web visit
--
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
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
To view this discussion on the web visit
--
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 openlm...@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.
SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com
Josh Zamor
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...@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.
Nikodem Graczewski
Nikodem
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 <ngrac...@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
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 openlm...@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 openlm...@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.
Mary Jo Kochendorfer
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 <ngrac...@soldevelo.com>
Date: Tuesday, June 5, 2018 at 12:16 AM
To: Josh Zamor <josh....@villagereach.org>
Cc: Mary Jo Kochendorfer <maryjo.ko...@villagereach.org>, OpenLMIS Dev <openlm...@googlegroups.com>
Subject: Re: [openlmis-dev] Re: Error behavior on the table forms
Thanks for the feedback!
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev...@googlegroups.com.
To post to this group, send email to openlm...@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...@googlegroups.com.
To post to this group, send email to openlm...@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...@googlegroups.com.
To post to this group, send email to openlm...@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...@googlegroups.com.
To post to this group, send email to openlm...@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...@googlegroups.com.
To post to this group, send email to openlm...@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...@googlegroups.com.
To post to this group, send email to openlm...@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.
Josh Zamor
To view this discussion on the web visithttps://groups.google.com/d/msgid/openlmis-dev/2F463C89-2265-4916-A42C-F6A0EA87D584%40villagereach.org.
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...@googlegroups.com.
To post to this group, send email to openlm...@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...@googlegroups.com.
To post to this group, send email to openlm...@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.
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...@googlegroups.com.
To post to this group, send email to openlm...@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...@googlegroups.com.
To post to this group, send email to openlm...@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.
Mary Jo Kochendorfer
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
Nikodem Graczewski
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.
Nikodem, could you clarify what this option is? Mimic which form?
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?
- View Proof of Delivery
- View Requisition
- View Shipment
- Issue, Receive, Physical Inventory, Adjustments
Should we be including the “batch approval” of requisitions?
Best Regards,
Nikodem
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 view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/47E41DF4-7131-42F4-8630-35509898B372%40villagereach.org.
SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com
Nikodem Graczewski
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
Best regards,
Nikodem
Mary Jo Kochendorfer
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 <ngrac...@soldevelo.com>
Date: Monday, June 25, 2018 at 2:55 AM
To: Mary Jo Kochendorfer <maryjo.ko...@villagereach.org>
Cc: Josh Zamor <josh....@villagereach.org>, OpenLMIS Dev <openlm...@googlegroups.com>
Subject: Re: [openlmis-dev] Error behavior on the table forms
Hello everyone,
- View Proof of Delivery
- View Requisition
- View Shipment
- Issue, Receive, Physical Inventory, Adjustments
To unsubscribe from this group and stop receiving emails from it, send an email toopenlmis-dev...@googlegroups.com.
To post to this group, send email to openlm...@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...@googlegroups.com.
To post to this group, send email to openlm...@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...@googlegroups.com.
To post to this group, send email to openlm...@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...@googlegroups.com.
To post to this group, send email to openlm...@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...@googlegroups.com.
To post to this group, send email to openlm...@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...@googlegroups.com.
To post to this group, send email to openlm...@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...@googlegroups.com.
To post to this group, send email to openlm...@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
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,
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.
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 openlm...@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
SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com
Josh Zamor
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 <ngrac...@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
> On Mon, Jun 25, 2018 at 7:38 PM, Mary Jo Kochendorfer <maryjo.ko...@villagereach.org<mailto:maryjo.ko...@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
>
> Date: Monday, June 25, 2018 at 2:55 AM
> To: Mary Jo Kochendorfer <maryjo.ko...@villagereach.org<mailto:maryjo.ko...@villagereach.org>>
> Cc: Josh Zamor <josh....@villagereach.org<mailto:josh....@villagereach.org>>, OpenLMIS Dev <openlm...@googlegroups.com<mailto:openlm...@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:
>
> * Issue
> * Receive
> * Physical Inventory
> * Adjustments
>
> Best regards,
> Nikodem
>
> Nikodem Graczewski
> Software Developer
> On Tue, Jun 12, 2018 at 9:03 AM, Nikodem Graczewski <ngrac...@soldevelo.com<mailto:ngrac...@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:
>
> [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]
>
> 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
> On Mon, Jun 11, 2018 at 11:13 PM, Mary Jo Kochendorfer <maryjo.ko...@villagereach.org<mailto:maryjo.ko...@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....@villagereach.org<mailto:josh....@villagereach.org>>
> Date: Monday, June 11, 2018 at 1:02 PM
> To: Mary Jo Kochendorfer <maryjo.ko...@villagereach.org<mailto:maryjo.ko...@villagereach.org>>
> Cc: Nikodem Graczewski <ngrac...@soldevelo.com<mailto:ngrac...@soldevelo.com>>, OpenLMIS Dev <openlm...@googlegroups.com<mailto:openlm...@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
>
>
> 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,
> 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.
>
> * 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?
>
> Thanks,
> Mary Jo
>
> Date: Tuesday, June 5, 2018 at 12:16 AM
> To: Josh Zamor <josh....@villagereach.org<mailto:josh....@villagereach.org>>
> Cc: Mary Jo Kochendorfer <maryjo.ko...@villagereach.org<mailto:maryjo.ko...@villagereach.org>>, OpenLMIS Dev <openlm...@googlegroups.com<mailto:openlm...@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
> On Tue, Jun 5, 2018 at 12:59 AM, Josh Zamor <josh....@villagereach.org<mailto:josh....@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
>
>
> 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 Requisition (#!/requisition/id)
> * View Shipment (#!/orders/id)
> * Issue (#!/stockmangement/issue/id)
> * Receive (#!/stockmangement/receive/id)
> * Physical Inventory (#!/physicalInventory/id)
> * Adjustments (#!/adjustment/id)
>
> Best regards,
> Nikodem
>
> Nikodem Graczewski
> Software Developer
> On Fri, Jun 1, 2018 at 8:39 PM, Mary Jo Kochendorfer <maryjo.ko...@villagereach.org<mailto:maryjo.ko...@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
>
> Date: Thursday, May 31, 2018 at 11:10 AM
> To: Brandon Bowersox-Johnson <brandon.bowe...@villagereach.org<mailto:brandon.bowe...@villagereach.org>>
> Cc: OpenLMIS Dev <openlm...@googlegroups.com<mailto:openlm...@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
> On Thu, May 31, 2018 at 5:03 PM, Brandon Bowersox-Johnson <brandon.bowe...@villagereach.org<mailto:brandon.bowe...@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
>
> Date: Wednesday, May 30, 2018 at 10:01 PM
> To: OpenLMIS Dev <openlm...@googlegroups.com<mailto:openlm...@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):
>
> 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.
>
> 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.
>
> Best regards,
> Nikodem
> --
> You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
> To post to this group, send email to openlm...@googlegroups.com<mailto:openlm...@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>.
> --
> You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
> To post to this group, send email to openlm...@googlegroups.com<mailto:openlm...@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.
> Al. Zwycięstwa 96/98<https://maps.google.com/?q=Al.+Zwyci%C4%99stwa+96/98&entry=gmail&source=g>, 81-451, Gdynia, Poland
> --
> You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
> To post to this group, send email to openlm...@googlegroups.com<mailto:openlm...@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>.
>
> --
> You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
> To post to this group, send email to openlm...@googlegroups.com<mailto:openlm...@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>.
> 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
>
> --
> 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 post to this group, send email to openlm...@googlegroups.com<mailto:openlm...@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>.
>
> --
> You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
> To post to this group, send email to openlm...@googlegroups.com<mailto:openlm...@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>.
> 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
>
>
> --
> You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
> To post to this group, send email to openlm...@googlegroups.com<mailto:openlm...@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>.
> [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
> [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>
> <image002.png>
> <image001.png>
> <image004.png>
> <image003.png>
Nikodem Graczewski
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
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 <ngrac...@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
>
> 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 <ngrac...@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....@villagereach.org<mailto:josh.zamor@villagereach.org>>, OpenLMIS Dev <openlm...@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
>
> On Tue, Jun 5, 2018 at 12:59 AM, Josh Zamor <josh....@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 <ngrac...@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
>
> 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 <openlm...@googlegroups.com<mailto:openlmis-dev@googlegroups.com>> on behalf of Nikodem Graczewski <ngrac...@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 <openlm...@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
> 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 openlm...@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 openlm...@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%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.com<mailto:openlmis-dev+unsubscribe@googlegroups.com>.
> To post to this group, send email to openlm...@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 openlm...@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%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.com<mailto:openlmis-dev+unsubscribe@googlegroups.com>.
> To post to this group, send email to openlm...@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 openlm...@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%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.com<mailto:openlmis-dev+unsubscribe@googlegroups.com>.
> To post to this group, send email to openlm...@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%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>
SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com
Josh Zamor
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.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev...@googlegroups.com.
To post to this group, send email to openlm...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/CAGOM9mVrRcpmMPkqaxdvDiZ6jguHLiOT%3DSJqD3VQF1BgCRg5Gg%40mail.gmail.com.
Nikodem Graczewski
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?).
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
Nikodem
> ngrac...@soldevelo.com<mailto:ngrac...@soldevelo.com>
>
> On Mon, Jun 25, 2018 at 7:38 PM, Mary Jo Kochendorfer <maryjo.kochendorfer@villagereach.org<mailto:maryjo.kochen...@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 <ngrac...@soldevelo.com<mailto:ngrac...@soldevelo.com>>
> Date: Monday, June 25, 2018 at 2:55 AM
> To: Mary Jo Kochendorfer <maryjo.kochendorfer@villagereach.org<mailto:maryjo.kochen...@villagereach.org>>
> Cc: Josh Zamor <josh....@villagereach.org<mailto:josh.zamor@villagereach.org>>, OpenLMIS Dev <openlm...@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
> ngrac...@soldevelo.com<mailto:ngrac...@soldevelo.com>
>
> On Tue, Jun 12, 2018 at 9:03 AM, Nikodem Graczewski <ngrac...@soldevelo.com<mailto:ngrac...@soldevelo.com>> wrote:
> Hi Mary Jo,
>
> ngrac...@soldevelo.com<mailto:ngrac...@soldevelo.com>
> ngrac...@soldevelo.com<mailto:ngrac...@soldevelo.com>
>
> On Tue, Jun 5, 2018 at 12:59 AM, Josh Zamor <josh....@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 <ngrac...@soldevelo.com<mailto:ngrac...@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
> ngrac...@soldevelo.com<mailto:ngrac...@soldevelo.com>
>
> On Fri, Jun 1, 2018 at 8:39 PM, Mary Jo Kochendorfer <maryjo.kochendorfer@villagereach.org<mailto:maryjo.kochen...@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 <openlm...@googlegroups.com<mailto:openlmis-dev@googlegroups.com>> on behalf of Nikodem Graczewski <ngrac...@soldevelo.com<mailto:ngrac...@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 <openlm...@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
> ngrac...@soldevelo.com<mailto:ngrac...@soldevelo.com>
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 openlm...@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 openlm...@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.
Josh Zamor
Nikodem Graczewski
that's correct. Option #2 is the current approach of the product grid.
Best regards,
Nikodem
Josh
> To unsubscribe from this group and all its topics, send an email to openlmis-dev+unsubscribe@googlegroups.com<mailto:openlmis-dev+unsu...@googlegroups.com>.
> To post to this group, send email to openlm...@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+unsu...@googlegroups.com>.
> To post to this group, send email to openlm...@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%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.com<mailto:openlmis-dev+unsu...@googlegroups.com>.