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 neighborhood citizen scientist or resident, I want to understand what a dot on the map represents #331

Open theecrit opened 3 years ago

theecrit commented 3 years ago

Description

Each dot on the map represents a PM2.5 reading recorded at a specific time and place. Each dot will be color coded according to the EPA AQI (per #237). But as a citizen scientist, I may want more details, including:

Acceptance criteria

The basic approach is to display a popup containing metadata when the viewer hovers over or clicks on (TBD) a specific geolocation marker. This popup should include:

Wireframes

~Design direction 2 (needs design exploration)~

~In this approach, the geolocation metadata would appear in a separate area of the interface (see example below). This might mean replacing the session metadata sidebar, or adding a new section below/above the map itself.~

~Designs~ ~Example from Willet et al (note this issue doesn't cover any time-based representations):~

Screen Shot 2021-06-30 at 10 35 24 AM

Technical considerations

Potentially helpful documentation

TangoYankee commented 3 years ago

Resource for developers: Adding interaction to points in a data layer

exchrotek commented 2 years ago

Resource: https://visgl.github.io/react-map-gl/

exchrotek commented 2 years ago

Michael is getting used to ReactJS. He has it so you can now hover over an area and a pop up shows the data value and x,y coordinates.

mnorelli commented 2 years ago

331 breakdown of steps to implement

- [ ] set click listener on a point does it make sense to create listeners for every point? why not just collect a mouse click and see what's under it?

Instead

Configure the popup per spec

Handle multiple points in a radius

- [ ] add EPA AQI link if showing info using a hover, can't click inside the box that the hover reveals

I'll ask for assistance expressing the colorbar CSS in ReactJS and connecting it to returned point properties figured it out, yay

exchrotek commented 2 years ago

To play Devils 😈 advocate, and because I genuinely don't know, what are the disadvantages of having an onClick listener for every point on the map?

Is this currently a decision for whether hover or click should display the pop up box of metadata for each point?

On Tue, Feb 15, 2022, 5:50 PM Michael Norelli @.***> wrote:

331 https://github.com/openoakland/woeip/issues/331 Pseudocode

  • [ ] set click listener on a point does it make sense to create listeners for every point? why not just collect a mouse click and see what's under it?

Instead

  • return point values on hover
  • get the value for the first point
  • write value and other properties to a popup
  • get time and date values and show them for first point

Configure the popup per spec

  • draft colorbar
  • create variables that affect pointer color and position on color bar
  • build as a component
  • wire up point return value(s) to popup component

Handle multiple points in a radius

  • list as "Other Readings"
  • add EPA AQI link
  • refactor for screen readers

I'll ask for assistance expressing the colorbar CSS in ReactJS and connecting it to returned point properties

— Reply to this email directly, view it on GitHub https://github.com/openoakland/woeip/issues/331#issuecomment-1041008972, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADSBYHQWWKR76XWX5BHMYMDU3L7GXANCNFSM45IAK73Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you commented.Message ID: @.***>

mnorelli commented 2 years ago

Please bring devils! Thanks, @exchrotek !

I found it really easy to implement a return of points around an x/y versus a listener-per-point, which I guessed would add processing load and a slew of events to manage. In this novice's estimation, the Mapbox solution for this seemed simpler, more familiar to me, more elegant.

And, no, not a fixed decision to hover instead of click. I thought (please advise if needed) that I'd start with hover for proof-of-concept, then split off the hover/click decision after the code and CSS were established. Easy to switch, I thought.

Similarly, whether to have the returned point info, which might be quite a long list, in the map or on the right of the map outside the frame is still to be decided, again once user map interactions can return data.

exchrotek commented 2 years ago

Hahahaha 😈😈😈

Correct me I'm wrong, but it sounds like the onClick is just using a very common event handler from the React library. By Mapbox solution, are you referring to some mind of hover event handler is built into mapbox?

On Tue, Feb 15, 2022, 8:39 PM Michael Norelli @.***> wrote:

Please bring devils! Thanks, @exchrotek https://github.com/exchrotek !

I found it really easy to implement a return of points around an x/y versus a listener-per-point, which I guessed would add processing load and a slew of events to manage. In this novice's estimation, the Mapbox solution for this seemed simpler, more familiar to me, more elegant.

And, no, not a fixed decision to hover instead of click. I thought (please advise if needed) that I'd start with hover for proof-of-concept, then split off the hover/click decision after the code and CSS were established. Easy to switch, I thought.

Similarly, whether to have the returned point info, which might be quite a long list, in the map or on the right of the map outside the frame is still to be decided, again once user map interactions can return data.

— Reply to this email directly, view it on GitHub https://github.com/openoakland/woeip/issues/331#issuecomment-1041100178, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADSBYHS5R2DMGGKUGVHKJELU3MTBZANCNFSM45IAK73Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>

exchrotek commented 2 years ago

Yikes I had plenty of typos using mobile there.

Basically what I was trying to say, is the hover option less process intensive because it's a built in event handler in Mapbox? And is the click event handler you're considering the one that is part of one of the common React library? Is there a click handler in built to Mapbox as well?

On Tue, Feb 15, 2022, 10:44 PM Brian D Fu @.***> wrote:

Hahahaha 😈😈😈

Correct me I'm wrong, but it sounds like the onClick is just using a very common event handler from the React library. By Mapbox solution, are you referring to some mind of hover event handler is built into mapbox?

On Tue, Feb 15, 2022, 8:39 PM Michael Norelli @.***> wrote:

Please bring devils! Thanks, @exchrotek https://github.com/exchrotek !

I found it really easy to implement a return of points around an x/y versus a listener-per-point, which I guessed would add processing load and a slew of events to manage. In this novice's estimation, the Mapbox solution for this seemed simpler, more familiar to me, more elegant.

And, no, not a fixed decision to hover instead of click. I thought (please advise if needed) that I'd start with hover for proof-of-concept, then split off the hover/click decision after the code and CSS were established. Easy to switch, I thought.

Similarly, whether to have the returned point info, which might be quite a long list, in the map or on the right of the map outside the frame is still to be decided, again once user map interactions can return data.

— Reply to this email directly, view it on GitHub https://github.com/openoakland/woeip/issues/331#issuecomment-1041100178, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADSBYHS5R2DMGGKUGVHKJELU3MTBZANCNFSM45IAK73Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>

mnorelli commented 2 years ago

I was a little confused before. I'm using the onHover method inside of ReactMapGL component. (It so reminds me of the Mapbox hover event, I assumed it was so.) I don't actually know the performance hit vs. hella onClick listeners, but it's so much less work since the data is added as one big layer made from an array of points, not individual points that have to be handled. I think this is intention of this ReactMapGL/Mapbox map data structure and attendant methods. See line 99 in ../web/src/components/map/box.js in branch 331_dot_attributes. Hope that helps!

mnorelli commented 2 years ago

We'll need to decide if this works as a hover or if it should be a click. Again, getting back to the topic raised in a thread I can't find now, it all depends on how WOEIP uses or wants to interact with these data.

exchrotek commented 2 years ago

Sounds like something that would benefit from some ux input! If you're making tonight's meeting, I'm sure Niels, Jess, Frances, and Anna can chime in!

On Tue, Feb 22, 2022, 4:37 PM Michael Norelli @.***> wrote:

We'll need to decide if this works as a hover or if it should be a click. Again, getting back to the topic raised in a thread I can't find now, it all depends on how WOEIP uses or wants to interact with these data.

— Reply to this email directly, view it on GitHub https://github.com/openoakland/woeip/issues/331#issuecomment-1048345276, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADSBYHUKQPSDDPP3EPVWX5LU4QT3RANCNFSM45IAK73Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>

exchrotek commented 2 years ago

Michael, random thought came to mind. 😈 Hovering wouldn't work on a mobile device. Regardless of what is chosen for desktop version, if we wanted to accommodate mobile users, we would need to have onClick enabled for mobile at the very least

On Tue, Feb 22, 2022, 4:51 PM Brian D Fu @.***> wrote:

Sounds like something that would benefit from some ux input! If you're making tonight's meeting, I'm sure Niels, Jess, Frances, and Anna can chime in!

On Tue, Feb 22, 2022, 4:37 PM Michael Norelli @.***> wrote:

We'll need to decide if this works as a hover or if it should be a click. Again, getting back to the topic raised in a thread I can't find now, it all depends on how WOEIP uses or wants to interact with these data.

— Reply to this email directly, view it on GitHub https://github.com/openoakland/woeip/issues/331#issuecomment-1048345276, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADSBYHUKQPSDDPP3EPVWX5LU4QT3RANCNFSM45IAK73Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>

mnorelli commented 2 years ago

The code I'll request be pulled will not yet:

I'm hoping we can accept the hover code for desktop and make a new issue to cover those items

exchrotek commented 2 years ago

Perfect, and yes totally agree that this specific issue only concerns desktop version, not mobile; that should be a separate issue like you mentioned. I may be speaking out of turn, but I imagine Jess wants to prioritize MVP completion of desktop before we do any actual coding for mobile view. Nonetheless, having this conversation already will be useful for later.

On Tue, Mar 1, 2022, 5:14 PM Michael Norelli @.***> wrote:

The code I'll request be pulled will not yet:

  • be accessible to screen readers
  • implement onClick for mobile I'm hoping we can accept the hover code for desktop and make a new issue to cover those items

— Reply to this email directly, view it on GitHub https://github.com/openoakland/woeip/issues/331#issuecomment-1056032088, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADSBYHV675KGRIY6H2F532DU526JHANCNFSM45IAK73Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>

hawser commented 2 years ago

I did a basic search for hover alternatives on mobile, it seems as if there really aren't any. The advice I found stated, "You can manage hover effects with touchscreens but it can be a little awkward. You may be better off designing them out altogether and using something else entirely. If you’re set on using them on your desktop site, you generally have three alternatives to hover effects on mobile websites:

  1. Remove them altogether and replace them with the primary action.
  2. Add a secondary menu where you can either tap once for the hover effect and once more for the primary action.
  3. Place the hover information on its own page.
exchrotek commented 2 years ago

We might just be able to get away with having both onClick and onHover in code. Then, the UI doesn't have to change at all. Not sure if map box api allows for that, but general reactJS it should be possible I believe. That would seemingly accommodate mobile users, and the experience doesn't change for desktop users. This is assuming that having onHover is inactive on mobile and doesn't somehow induce strange behavior on mobile.

On Wed, Mar 2, 2022, 10:31 AM Niels Thorsen @.***> wrote:

I did a basic search for hover alternatives on mobile, it seems as if there really aren't any. The advice I found stated, "You can manage hover effects with touchscreens but it can be a little awkward. You may be better off designing them out altogether and using something else entirely. If you’re set on using them on your desktop site, you generally have three alternatives to hover effects on mobile websites:

  1. Remove them altogether and replace them with the primary action.
  2. Add a secondary menu where you can either tap once for the hover effect and once more for the primary action.
  3. Place the hover information on its own page.

— Reply to this email directly, view it on GitHub https://github.com/openoakland/woeip/issues/331#issuecomment-1057247637, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADSBYHXIN7AGUUBHFWWHGULU56XW5ANCNFSM45IAK73Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>

gsehrlich commented 2 years ago

Per conversation today with @exchrotek (and a previous comment by Michael), we need a hover box to stay open when the cursor moves so that the user can access the question mark button shown in the wireframes (referred to here as "EPA AQI link"). We thought on hover the box should open and on click it should stay open.

If we implement this, I'm thinking on hover the cursor should also change to a pointing hand. Once the box is open, another click outside the box closes it (and could open another). Do we also need an X in the top right of the hover box? Do we need it to close when Esc is pressed?

This might be an interim solution to the touchscreen problem too.

@hawser

theecrit commented 2 years ago

@theecrit to write up post-MVP issue for full educational window.