Together with @Klaudia_Palkowska, we are currently working on creating a mockup for Facility Type Approved Product (FTAP) viewing and editing (link) and for Orderable (link). We have found an existing ticket to Edit/Manage Facility Type Approved Products (link) which already contains prepared mockup:
The mockup assumes that there is an ‘Orderable’ section in the ‘Administration’ menu. After clicking ‘edit’ user is moved to ‘Orderable’ detail view. In the ‘Facility Types’ tab, we can create/update FTAP by clicking a button for a given Facility Type and Program. If the FTAP is “active” the button reads “Active”. If the FTAP is non-existent or in-active the button reads “Configure”.
The mockup is compatible with the current form of FTAPs (the newly added ‘active’ flag is also visible). The newest version of FTAP should be displayed/edited. Moreover, saving the FTAP configuration should be handled in the following way (slightly different than in the existing ticket):
If active flag checked -> FTAP is created or updated (if already exists) with active flag set to true
If active flag unchecked -> set FTAP active flag to false (no deletion committed)
For the program orderables, the workflow would be implemented in a similar way. There would be a separate ‘programs’ tab which would contain the list of all available programs. In each program row, there would be a configure/active button which would navigate to the program-orderable detail view with the related inputs to set. See the mockup below:
We should discuss if a constraint should be added to limit programs available in the ‘Facility Types’ tab to the programs selected in the ‘Programs’ tab. As far as I’m concerned, there are no such constraints on the backend (there was a constraint ftap ←→ programOrderable but it has been removed link).
Do you have any suggestions or do you see any impediments?
Managing orderables and managing FTAPs requires separate rights. This means it’s possible for a user to have one right and not the other. We either need to handle this on our UI or suggest merging the two rights into one. I’m not sure if there’s a use case for only editing FTAPs - I can’t see one.
Required/Non-required fields need to be handled appropriately on the UI.
Even though there’s no constraint on the backend to program orderables anymore, it doesn’t mean having FTAP for a program that is not supported by an orderable makes sense. In the ticket you have linked (https://openlmis.atlassian.net/browse/OLMIS-2320), there’s a nice comment by @joshzamor that explains when a product can be managed at the facility type level - I think it’s best if our UI reflects exactly that and only displays programs that are active for the orderable in the facility type assignment tab (in other words, you have to first create or mark as active a program orderable for the product before you start assigning it to facility types in the given program).
@Sebastian_Brudzinski Thanks for your suggestions. Merging the rights for managing FTAPs and orderables totally makes sense for me. I also can’t see any case when a user should be able to edit only one of the mentioned resources. As for required/non-required fields, we should probably just follow our styleguide and add asterisks next to the required field label.
@Sebastian_Brudzinski Thanks for reply.
Ad. 3 I wonder if we should add some additional constraint/trigger function on the database level to secure it on the backend. Otherwise, inconsistency may occur.
Thanks @pcieszko - I think we may be over-complicating things if we decide to do that, especially now that versioning is nearly in place. Having a constraint on Program Orderables is also problematic (see reasons why they were dropped in the topic I’ve linked) since Program Orderables are not a restful resource, rather they are a part of an Orderable, and they may be dropped and re-created as needed. I think UI allowing you a little less than backend is fine here, especially that having those additional FTAPs (for orderables not approved for the program) doesn’t break anything - they will simply not be available.
I think the feedback on the mockup that is most sticking out to me is:
The FTAP tab (not the detail page), looks like it’ll end up scrolling horizontally quite quickly as most countries have 5-8 programs. This seems like the space could be better used.
I’m a bit confused about the use of Active in the FTAP detail, as well as it’s use on the tab: on the tab it’s Active/Configure, and on the detail page it’s Active/Inactive. Having both labelled Active feels like we’ve overloaded the meaning. I think this is also true for the Programs tab and the Program Orderable Edit page.
Instead of showing all of the available programs on the FTAP tab, we could limit it to only programs that are active for the selected orderable. That should limit the columns in most of the orderables to one-two programs only. This is a constraint that we do not have on the backend, but an FTAP for a program that doesn’t have a corresponding entry in program orderables doesn’t make sense anyways, right?
One question/suggestion: should we add some information next to configuration fields? I mean does the user will know what for instance the Display Order means in the program configuration view? What values should be put there? Or what will happen if he/she enable/disable the full supply option? Same for FTAP screen.
That makes sense though I can’t say that we won’t encounter products outside of our current v3 implementations though that won’t span more than 2 programs. That gives me pause.
Configure/Configured works, though it’s really hard to tell at a glance then, in english, which is and which isn’t configured.
@Klaudia_Palkowska and @Sebastian_Brudzinski, for both of these issues isn’t it easier and more intuitive to have the dual drop-downs such as v1 and v2 had? Not as pretty but it saves on space and felt pretty intuitive to me.
I think we should certainly figure out some helpful hints here. Perhaps @ibewes or @Samim_Villagereach you could help us figure out what those hints are?
The first workflow is for a user who has access to editing data in both Programs and Facility Types tabs.
In this approach, we save the space on the screen and avoid possible horizontal scrolling by:
Displaying only active/configured programs and Facility Types.
Putting the Programs in just one dedicated column that clearly indicates the active ones for a Facility Type.
We also avoid cluttered the view and the danger of having too many buttons all over the screen.
The buttons in this approach directly indicate actions available and adding Delete button informs the user that they can remove the item from the list.
Items can be also added easily with one visible button above the table. Having this button on the screen enables displaying only active programs but adds one or two dropdowns to the modal. It shouldn’t slow down the work significantly though and helps in maintaining clarity on the screen.
The second workflow is illustrating the journey for a user without access to editing information in Programs and Facility Types tabs.
The „Add" buttons were removed from the views since they won’t be used by this kind of user, as well as “edit” and “delete buttons”. The only button that allows for action is the „Preview" button that enables to preview the already existing configuration in modals without the possibility to edit any data.
I just started writing tickets for implementation and now I see some details that I didn’t see before. Do we want to have the edition in a modal? I’m afraid it’s against our style guide but on the other hand, editing association to supply partner (Administration > Supply Partners > Edit Supply Partner) is implemented in that way (form for association’s edition is displayed in modal).
For FTAPs addition modal, I think we have a typo, a modal should contain the dropdown with facility types instead of facility type approve products.
Moreover, I don’t see Active flag in the modals. Is that intentional?
The last question is about Info/General tab. Do we want to implement it in the way the mockup above Aleksandra’s reply shows?
Regarding the typo, I already corrected this and in the link to the mockups provided it should be now correct.
We gave up on the active flag because in this approach we only display active programs which means that the information regarding active state seems redundant (everything displayed would be in an active state) if we want to make something inactive we just remove it from the list with the Delete button. Does it make sense to you?
Regarding the modals instead of separate screens - I’ve seen it used in similar cases but if this isn’t consistent with a style guide it shouldn’t be a problem to make a separate screen out of the modals. Modals, however, seem like a comfortable and user-friendly way of handling this process.