Implement changes in formbuilder

[PG-Momik]

Design Link

https://www.figma.com/design/upgUy5i65LYC3iiqYVnACW/IATI-Publisher-Platform?node-id=16112-37956&node-type=canvas&t=mahWshNfBoQ5zZ6G-0

Tasks

• Remove indentations for sub elements (Remove padding from indented form)
• Remove Borders in Sub elements
• Convert element into accordion (collapsible on element level)
• Remove indentation for add more x button
• Wrap add more x subelement button in border
• Make gap between subelements consistent (pb-11, pb-6 will now become pb-1.25)
• Show mandatory * on sub element label (top level child, ex: Result->Title)
• Info text position change for sub element label
• Modify delete sub element button.
• Delete sub element confirmation model + highlight deletion area.
• Add optional label (??)
• Discuss special cases with designer:
  - Activity reporting org (info box)
  - Activity sector/transaction sector (freeze)
  - Activity recipient region / Activity recipient country (freeze)
  - Language and currency attributes (default val prefilled)

Task workflow

We have 8 form builders.

• Chose 1, remove all classes that affect indentation, border, etc that have been changed in design.
• Note down all affected elements (say group 1) that will be rendered by this builder.
• Start implementing design changes to affected element's form. Upon completion, verify if changes for this element works for other elements of this group.
• Continue making changes until design changes for all elements in this group is complete, make sure the design implementation is consistent.
• After completion of this group, make changes to next group whilst making sure that the preceding groups have not broken. One form builder can invoke next, there will be forms that contains entire forms as child form (activity document link form renders as a child form for result)
• Repeat.

@emmajclegg I've listed down the possible tasks and my approach for implementing the design. As u see will be a lot of back and forth for every small changes made. While this might sound like a lot of manual back work and inefficient, the other approach for us to implement the design would be to totally discard form builder and start from scratch, which will be more time consuming.

[PG-Momik]

@emmajclegg Quick updates on this:

1. Review of required vs optional
   This subtask is almost complete and ready for testing by QA. Before we send it to be tested on our side, can u review this file.
   Required_v_optional_sheet.xlsx
   In the file, I've basically listed down the elements that contain nested forms/subelements for organisation and activity. I've marked the subelements required or optional. Could you verify if this is correct and matches the standard.

Note

Changing what is displayed as required or optional in the future will NOT be difficult.

---

2. Delete state
   In the design the delete state looks like this:

There are clear margins / spaces around the highlighted area in the design. Since I'm modifying the existing form builder code, implementing the design accurately has proven to be challenging than it initially seemed. Currently the delete state looks something like this (which IMO looks usable) :

My question is how important is the delete state? It is doable but will exceed my initial estimation by ~2/2.5 days.

cc: @BibhaT

[emmajclegg]

Thanks for the update @PG-Momik - I've saved a copy of your mandatory vs. optional subelements sheet and checked it. I've used the IATI activity and organisation schemas to do this, as it's normally easier to look at the code than refer to the IATI website guidance pages.

For your question about the delete state - the design version is neater, but I agree your current version is workable and probably not worth spending extra days on now (especially if it could be revisited in future when we have more time). I care more about things like interface text being easy to read (i.e. avoiding light grey text on a white background), and mandatory labeling being correct.

Any questions, let me know.