woeip
woeip copied to clipboard
openoakland
As a neighborhood citizen scientist or resident, I want to understand what a dot on the map represents
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:
- What the specific PM2.5 reading for that location is.
- What time of day the reading was recorded.
- Any other readings for that location (since the map defaults to displaying only the max reading for a given geopoint).
- Where the reading falls in terms of health risk.
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:
- [x] All PM2.5 readings taken at the selected lon/lat point for the displayed collection session.
- [x] The time of day for each reading.
- [x] A color indicator for at least the max reading.
- [x] Add link to EPA-hosted information about AQI. (Jess to provide)
Wireframes
- See the happy path prototype for functionality.
- Draft tooltip wires (option 3b)
~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):~
Technical considerations
- [x] Assumes #237 is complete.
- [x] The primary sensor reading displayed should be pulled from most recent timestamp at that location.
- [x] “Other readings” should only appear if there are other readings.
- [x] “Other readings” should display in reverse chronological order.
- [ ] Popup and its contents must be discoverable by screen readers.
- [ ] Screen readers must be able to read back the content in proper order without confusing the user (for example, any color indicators need to be properly named and defined).
- [ ] For mobile users, tooltip should display on tap (w/ tap to remove).
- [ ] TBD (needs testing): For desktop users, tooltip should display on either hover or on mouse click.
Potentially helpful documentation
- Semantic UI's "Flowing Popup" component
- MapBox docs: Display a popup on click
- MapBox docs: Markers and Popup component
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.
#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
- [x] return point values on hover
- [x] get the value for the first point
- [x] write value and other properties to a popup
- [x] get time and date values and show them for first point
Configure the popup per spec
- [x] draft colorbar
- [x] create variables that affect pointer color and position on color bar
- [x] build as a component
- [x] wire up point return value(s) to popup component
Handle multiple points in a radius
- [x] list as "Other Readings"
~~- [ ] add EPA AQI link~~ if showing info using a hover, can't click inside the box that the hover reveals
- [ ] refactor for screen readers
~~I'll ask for assistance expressing the colorbar CSS in ReactJS and connecting it to returned point properties~~ figured it out, yay
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: @.***>
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.
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: @.***>
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: @.***>
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!
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.
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: @.***>
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: @.***>
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
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: @.***>
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:
- Remove them altogether and replace them with the primary action.
- Add a secondary menu where you can either tap once for the hover effect and once more for the primary action.
- Place the hover information on its own page.
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:
- Remove them altogether and replace them with the primary action.
- Add a secondary menu where you can either tap once for the hover effect and once more for the primary action.
- 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: @.***>
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
