Closed TylerMatteo closed 2 weeks ago
Blocked by #18 and nycplanning/ae-zoning-api#251
Partially blocked by #28, but work could begin on the detail panel by manually navigating to the /city-council-districts/<cityCouncilDistrictId>
route.
@TylerMatteo
Would it be more precise to make the route /city-council-districts/<cityCouncilDistrictId>/capital-projects
and not just /city-council-districts/<cityCouncilDistrictId>
?
We're showing capital projects within a city council district, not details about the district itself. This would complement the route we use for a specific capital project- /city-council-districts/<cityCouncilDistrictId>/capital-projects/<managingCode>/<capitalProjectId>
When user selects a CCD from the Filter by District menu, user is navigated to new
Is navigation to the list of capital projects prompted by selecting the from the menu? If so, what is the purpose of the "Go to Selected District" button?
List of projects is paginated, with pagination arguments stored as query params. See Page schema from the underlying API for reference.
The linked Figma designs are showing numbered pages. Are there updated designs which reflect that we don't know beforehand how many pages there are? I worry this will cause confusion for the person working on this ticket.
User can dismiss the project list detail panel to return to root / route
Should the query parameters be kept? For example, if you've selected Community District 37, should the query parameters still be 'districtType=cd&districtId=73'
When user selects a CCD from the Filter by District menu, user is navigated to new
Is navigation to the list of capital projects prompted by selecting the from the menu? If so, what is the purpose of the "Go to Selected District" button?
By "selects a CCD", I meant actually clicking the button. I'll clarify.
Would it be more precise to make the route
/city-council-districts/<cityCouncilDistrictId>/capital-projects
and not just/city-council-districts/<cityCouncilDistrictId>
?We're showing capital projects within a city council district, not details about the district itself. This would complement the route we use for a specific capital project-
/city-council-districts/<cityCouncilDistrictId>/capital-projects/<managingCode>/<capitalProjectId>
Yep, typo. Fixed above.
I am looking at the panel for the list of capital projects in the desktop version. Would it make sense to make it taller?
@TylerMatteo and @pratishta
I was interacting with the draft in the QA environment. I realized that placing the offset
and limit
in the URL also means that users can easily edit these values. When the limit is changed from 7, or the offset is changed from a multiple of seven, the app may end up in an odd state- like being on page "3.5".
I was thinking about two approaches to address these odd states: 1) Add checks of the "offset" and "limit" values to enforce their validity. This respects the acceptance criteria but adds complexity to the implementation 2) Replacing these query parameters with a single "page" query parameter. The enforcement for this is much simpler- merely checking whether the value is an integer greater than 0. However, it is a change to the acceptance criteria.
Either approach adds a wrinkle to the scope of the ticket. As such, if we do want to make these adjustment, it may make sense to push the changes to a follow-up ticket.
Replacing these query parameters with a single "page" query parameter. The enforcement for this is much simpler- merely checking whether the value is an integer greater than 0. However, it is a change to the acceptance criteria.
This is the approach I was going to suggest with something like ?skip=14
for page 2 as the query param. I think offset and limit are not useful terms and difficult for users to navigate anyway if we're trying to design around the routes and history.
difficult for users to navigate
Good point. If this is creeping into UX territory, maybe it would behoove us to get input from the design fellows?
User can dismiss the project list detail panel to return to root / route
Does this happen when we click on the up chevron?
If so, do we preserve the query params for the filter menu (?districtType=ccd&districtId=23
) or no we reset to /
?
After stand up today, we've reached a few decisions:
page=1
param
Acceptance Criteria
/city-council-districts/<cityCouncilDistrictId>/capital-projects
route and sees the content panel with the paginated list of projectsProjects on the map are filtered to only those that overlap with selected CCD. For projects that partially fall outside the CCD, all parts of the project should still be visible.Moved to scope of #62Selected CCD boundary is highlighted (figma)Moved to scope of #62Page
schema from the underlying API for reference. Preserve other existing query params, such as those for keeping track of filter menu state./city-council-districts/<cityCouncilDistrictId>/capital-projects/<managingCode>/<capitalProjectId>
/
routeDesigns
desktop and mobile
Out of scope