search

openoakland / woeip

A platform for impacted communities to understand their local air quality and advocate for environmental justice.
https://woaq.org
MIT License
29 stars 16 forks source link

As a user, I want to be able to see what dates in the calendar have data. #395

Closed gsehrlich closed 2 years ago

gsehrlich commented 2 years ago

Is your feature request related to a problem? Please describe. After uploading some data, if I close the page and return to it, I can't see which dates have data without opening each date one at a time.

Describe the solution you'd like The calendar should have a marker or color coding for dates that have data. If there were some way to zoom out to a twelve-month or multi-year view, that might help the user scan for dates that have data.

Describe alternatives you've considered A list on the side of dates for which data has been uploaded most recently.

Labels

mnorelli commented 2 years ago

Love this idea. And... I would find it helpful that when clicking Save after uploading a pair of collection files, the Maps page opens to the date collected of those files. Would this necessitate a new issue?

theecrit commented 2 years ago

@mnorelli

I would find it helpful that when clicking Save after uploading a pair of collection files, the Maps page opens to the date collected of those files. Would this necessitate a new issue?

It does this already! :D Let me know if it's not working for you and we can open a bug issue.

theecrit commented 2 years ago

I think this is a really useful story to add (I could've sworn it used to do this, but I just tested it and sure enough it does not).

It also raises a larger question around how we handle time. We've been prioritizing the data collector audience, which has resulted in us taking a very session-specific view of the data. But residents (and others) may want a view of AQ over time, or in aggregate. Example stories:

We could create separate issues for each of these, but I feel like we should step back and do some design exploration around these together, so we can consider a more holistic approach. Our UX folks currently are focusing on mobile responsiveness but maybe we can capture these in a single design issue for now, for when we're ready to tackle that? And folks can comment on that issue with ideas/thoughts in the meantime.

mnorelli commented 2 years ago

Glad you have the same experience <whew!> I'm watching Tim's code walkthru and see that the route that's supposed to load the /maps page at the /upload page's upload file date is set in ../web/src/components/upload/confirm.js. The problem might be related or connected to this?

mnorelli commented 2 years ago

@gsehrlich notes that, for him, the map page does resolve to the uploaded files' collection date. Maybe there is something local affecting this for each of us and not the code?

And @gsehrlich and I talked about time in relation to the data, especially relating to trends over time. Looking forward to an exploration around this!

gsehrlich commented 2 years ago

So I've dived into the code and I think I know how I could implement this. As a newcomer to software development and React and Django, I'm not sure if this is the best way of doing it. Feel free to weigh in—I'd appreciate it!

Currently, the user picking a date from the datepicker triggers the frontend to ask the backend for the metadata about the collections on that single date. Then it uses the metadata to send another request to the backend to get the actual pollutants data.

To implement the feature in this issue, I'm thinking that when the map page loads, it should just ask the backend for all the metadata from the collection table. The metadata would be used to style the datepicker. The frontend would no longer request the backend for the metadata each time a date is picked, instead referring to the already-loaded metadata to construct the request for the pollutants data.

Concretely, in the frontend (web/src/components/map/utils.js), I'd rewrite the getCollectionsOnDate function as getAllCollections. In the backend (web/src/components/map/utils.js), I'd remove the unnecessary date filter from CollectionViewSet.get_queryset. In the frontend again (web/src/components/map/index.js), I'd write a new useEffect hook that triggers on page load and rewrite the existing one that triggers when a new date is picked.

My questions:

  1. Would this be fast enough? We're only loading a few dozen bytes of metadata per collection, but I'm not sure how big we expect the database to get. Or is there another reason not to load all the metadata at once?
  2. Is this an appropriate amount of existing code to change to implement something new? Should I get rid of the parts that have been made unnecessary, as indicated above, or leave them?

Thanks :)

P.S. I haven't figured out how to zoom the calendar out. It doesn't look like a built-in feature of the Semantic UI datepicker.

exchrotek commented 2 years ago

In practice, if we were writing this app and expected millions of users to be uploading collections of data from the Dustrak, maybe then that could be a problem? Perhaps you could impose a pre-defined size limit or date-range limit of loading just for good practice. Only if they click in the UI to the previous year do you query the collections table for another year's worth of data and highlight the calendar dates that have data.

gsehrlich commented 2 years ago

Thanks! Thinking about it some more, I realized the size of the metadata would only be a problem if there are hundreds of collections per day, which the calendar doesn't need to know anyway. I'll leave the date-specific functionality as is and write a new calendar-styling query that just gets the first collection on each day.

exchrotek commented 2 years ago

Last sub tasks to get done: Get rid of "Today" button element Change background of date in the month to white

TangoYankee commented 2 years ago

As the application moves toward using start date as a way to navigate around data, it may be beneficial to update the database structure. A start date model/table could help keep these requests performant. The start_date field could be its primary key. Each start date could have a one to many relationship with the collections taken on that date. We could add a "start_date" endpoint that will return a list of all start dates. We could also add query params to request start dates within specific date ranges.