data sources app v2 - Githubissues

josh-chamberlain commented 2 months ago

Context

We have a wireframe for the next iteration of the app. This issue divides up the work into categories and human-sized chunks.

Primarily, we are iterating and expanding on our existing prototypes, linking them together into something more cohesive and engaging.

We're doing the work on the data-sources-app-v2 fork.

Navigation

Home → https://pdap.io
Search → app/search
`Open a request → app/new-request
Help → https://docs.pdap.io
Donate → https://pdap.io/donate
Profile → app/profile (visible when logged in)
Login → app/login (when not logged in)

Front end views

All these views are public, but some actions are only available to logged-in users.
Since we tend to use one branch for the back end tweaks needed for any front end feature, they're one issue.

In rough order of priority, but see the kanban:

Back end changes

In addition to minor back end changes referenced in the issues above.

Style

Most of these views have a ~75% pane on the left for information and form actions, and a 25% panel on the right for details and CTAs.
We should see how a pretty vanilla application of our design system looks, then add anticipated new components from the wireframe

Design system:

Policy

https://github.com/Police-Data-Accessibility-Project/data-sources-app/issues/158

Docs

Throughout: READMEs for devs; docs pages for people looking for data; GitHub and Discord wayfinding for volunteers.

joshuagraber commented 2 months ago

Hey, @josh-chamberlain, I've had a look through the issues here. Everything looks pretty straightforward, I just have a few comments and questions:

General:

Colors, etc, are changing, yes? If so, design-system will need a new major version to reflect that. Would it also be possible to add some component style definitions in Figma for this purpose? Note: (I'm going to create a beta release flow for design-system so that we can release these updates easily without going to production. It's a bit overdue anyway. Symlinking for testing is not ideal.)
We will also need some new components in design-system for this.
- Checkbox input
- Style 1: expressed in "record types" section
- Style 2: expressed in "location" section
- Dropdown component (for filtering section)
- Loading spinner and/or loading shimmer. (Maybe we want to think about this at the design level? Given that a lot of these pages and their sub-components will require data fetching, I think we need better loading states either way.)
Will different users have different permissions/roles to gate the features they are permitted to interact with?

For #249

What does "coarse selection" mean?

For #250

users who are logged in can click a "Follow search" button to be notified about new sources in the search

Once we have "saved searches," is the plan to build some kind of event emitter to send these notifications? Do we mean to use email, sms, push?

For #254

links to a github issue for the request, where collaborators can comment

Are we auto-creating this issue when a user makes a request? Will the backend handle this or should we expect to do it client-side?

Nice to have client enhancements that I'd love to get done here as well since we're re-doing most of the client:

Lazy loading of route components (have been meaning to add this anyway for performance reasons)
Lazy loading of any sub-components that require expensive network calls
Subtle transition animations for routes and elements entering / exiting the DOM

Thank you. I've added some issues to design-system to start on some of this (60, 61, 62, 63, 64).