fix: adjust content based on testing feedback #88
Conversation
| 'extend.front': 'Add a front extension', | ||
| 'extend.outbuilding': |
There was a problem hiding this comment.
Services currently have mixed use of extend.outbuilding singular and extend.outbuildings plural (among other similar examples, but this one seems to be most widespread as it affects granular children).
It's less than ideal to include both, but I'd rather be able to remove project types later when service content is tidied up than fail to validate all possible journeys through live services now.
There was a problem hiding this comment.
Agreed that whilst we're below v1 this is the most pragmatic approach.
Removing any fields would be a breaking change in the schema but I think at this stage that's actually relatively insignificant as we'd be the ones affected (and the old ones wouldn't get used).
It might be worth looking into how we can decorate these field as deprecated before removing them - possibly overkill at this stage though if it proves tricky tbh!
| @@ -73,13 +85,14 @@ export const ProjectTypes = { | |||
| 'alter.openings.add.door.side': | |||
| 'Add new doorways to the side of the building', | |||
| 'alter.openings.add.window': 'Add one or more new windows', | |||
There was a problem hiding this comment.
This one is still window not windows?
There was a problem hiding this comment.
Just seen comment below about remaining singular and plural instances 👍
There was a problem hiding this comment.
This example is actually different than the singular/plural "duplicates" like "outbuilding" below - from what I found in content, it's actually always singular window in the parent case, and then children switch to plural windows 💫
door is always singular, so this was easy to confuse ! I'd love to do a big find&replace exercise to clean these up soon, and really pay attention to these subtle details to better align values in this particular enum.
| 'extend.front': 'Add a front extension', | ||
| 'extend.outbuilding': |
There was a problem hiding this comment.
Agreed that whilst we're below v1 this is the most pragmatic approach.
Removing any fields would be a breaking change in the schema but I think at this stage that's actually relatively insignificant as we'd be the ones affected (and the old ones wouldn't get used).
It might be worth looking into how we can decorate these field as deprecated before removing them - possibly overkill at this stage though if it proves tricky tbh!
Feedback coming out of theopensystemslab/planx-new#2529
My first draft of this data dictionary was a bit too optimistic about which "Select the works" old flows and new triage flows are actually in use. I've gone through a number of example submissions and other flows now and filled out all possible project types. I think this should be more comprehensive now 🤞