[Enhancement]: add display/render hinting for fields on applicationForm

[jmergy]

Summary

Right now, and historically, PDC has not been all that concerned with rendering the data for people to see in displays. But, now that we have Exchange and hoping for other applications down the road not to mention integrations into existing platforms, etc.

Problem / Opportunity

It might make sense to add an optional attribute to the fields on the applicationForm. This would be helpful, if included, so any rendering of the proposal data against that application form could be pulled from the data.

This is coming up with Changemaker Direct.

Proposed solution

Rather than having to design the form for data entry here and maintain rendering or PDC data in Exchange or other platforms, it would be ideally nicer to just defer to data parameters on the field specific to the applicationForm on whether to render it as a single text line, multiple line, or whatever. It feels like it would be similar to what we are doing with the position attribute.

Could we add an optional parameter at that level to signal preferred rendering?

Acceptance criteria

No response

Priority

Medium

[jmergy]

@kfogel I know we discussed this and just flagging for you.

[jmergy]

Maybe add something like this as a parameter option for applicationFields??

`

Field Type	Common Schema Identifier
Text	type: "string" + format: "text"
Long Text / Rich Text	type: "string" + widget: "textarea"
Number	type: "number"
Boolean	type: "boolean"
Date	type: "string" + format: "date"
DateTime	type: "string" + format: "date-time"
Select / Picklist	type: "string" + enum: [a, b, c]
Multi-select	type: "array" + items: { enum: [...]}
File	type: "file" or type: "string", format: "uri"
Email	type: "string", format: "email"
Phone	type: "string", format: "phone"
Hidden	type: "string", visible: false
`

[slifty]

Forgive me as I process out loud a bit!

Universal Data Integrity

Right now fieldType is a BaseField concept because it allows for some universal validation regardless of which application form a value came from (e.g. phone values must be valid phone numbers to be marked as isValid). If an ApplicationFormField has it's own field type / is able to override the BaseField's field type then we lose that data integrity because any given value associated with a base field could have come from an form with an ApplicationFormField-level override.

For example with overrides, the "Administrative Phone Number" BaseField is no longer guaranteed to be a phoneNumber because maybe an ApplicationFormField marked it as an email.

I think we lose something important with that direction, so I would suggest we not.

Bespoke Validation (ApplicationForm level)

Until now the PDC had not been designed to be a GMS, but rather to aggregate data from a range of GMS's. This has let us have the luxury of simplified validation that's more focused on good UX related to aggregate data access. For example, we don't have opportunity-specific validation support (e.g. "this particular application form only allows X Y Z values for BaseField foo"). We rely on the GMS to validate its data according to bespoke context before syncing it with PDC. Not pushing back on iterating, just highlight the importance of reflection as we embark.

I think that the enum / Picklist use case highlights this nicely. What happens when Application Form Foo has different enum values for a given base field vs Application Form Bar?

For instance, a base field of "Project Domain" might have a constrained set of valid entries for The Future Moon Initiative and a completely different set of constraints for The Pennsylvania Ecology Challenge. For UX (see next section) we could absolutely iterate the system to allow a given ApplicationFormField to specify constraints which allow for drop-downs when editing / adding data in the context of a specific application form field. However, we lose that ability when for any use case that spans multiple application forms (e.g. "faceted search").

UX Elements

It may help for us to use the earlier frame of "universal vs application specific" when thinking about the UX.

• I think we should definitely expand text to have a longText field type which would signal text area.

• Number, boolean, date, dateTime, file, email, and phone should all be base field types for sure.

• Hidden feels like it should probably be a form field attribute rather than be related to type? I assume hidden data should be rendered in non-application-form contexts (e.g. viewing proposals, etc)?

• Picklist + multi-select are where things get a bit gnarly and I suspect will need another round of thinking. As I mentioned before I don't think this can be a base field level attribute, and I don't think we can enforce it outside of an application form context. I think this is akin to bespoke validation (which enables UX QoL improvements such as a dropdown), similar to saying "number in the range of 1 to 100" it's "text in the range of {this list of values}". We could have this be an attribute of ApplicationFormField, but it has some big implications I think. As an aside: will we want Organization data (editable outside of an application form field) to have this type of enum constraint?

[jmergy]

@slifty totally agree with your points on this. No fundamental changes on the way we are handling baseFields now. I like it.

As far as the UX, we don't want to try and do much here at all to be helfpul. This is the first time trying to provide some formatting or rendering information of the data has come up. I could see us adding an optional describer to the applicationForm field more as an accurate rendering of the source data proposal as a help for other systems, if they wanted it, to better render the data at the other platforms since it will be varied and be so application/source-dependent.

That format example list was just to point at what it could be but I like your refinement on what could even be reasonable or not is great.