Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Switch to dark mode for the Museum Experience! #280
Fixes # .
Describe your changes.
- Theme functions accept an attribute indicating whether this project is currently being displayed in a museum on this device (In dark museum exhibits, we want guests to see the tablet screens in dark mode rather than a jarring, white screen) - In a future commit, We'll key off of the role attribute in the project object (currently using project name as a placeholder).
+ Also considered whether to push the museum mode logic down into NavBar.js component instead of settings at the classifierNavigator.js level. Decided, for now, to leave them at the classifierNavigator level because: 1. Only the classifier pages change in museum mode, but the NavBar settings are set all over the app. 2. Currently, the NavBar settings explicitly request the title, the presence of the hamburger menu, and the presence of back navigation...the three exact things that change in museum mode. This suggests that the NavBar settings represent a more generalized level of UI customizability than a specific 'mode.' Because of this, it is strange that the NavBar component ALSO has a setting for preview mode (in which the nav bar turns red). To make the levels of abstraction here consistent, we would want to switch out 'isPreview' in settings for 'color,' and set that color to red wherever we key off preview pages. (Another twist: 'isBeta' follows yet a third abstraction gradient with respect to the NavBar).
wgranger left a comment
Most of the comments on code structure are simple items (camel vs. snake, removing unused props) however, there are a couple notes that would clean up the code a bit and perhaps catch a couple missed dark/light mode items. Giving the code a test run now to see if I missed anything.
…r, which shows on many pages that do not contain a project. WIP: Still need to determine how to: - Set a default background color in the NavBar component for non-project pages - Determine whether the other settings defaults in the NavBar component are working - Make sure we only define $headerColor and $testRed in one place (rather than copy-pasting the rgba values)
…r comments from previous commit message. At some point, we still should consider: - Decoupling preview mode from the color of the safe area container
Hi @wgranger !
Another commit forthcoming with some changes apropos of the comments you have made. Thank you!
Becky and I did initial visual design review of the app together today. She has a few things that she would like to think about and get back to me on how she would like them done, so depending on how long that takes her, this branch might lie dormant for a bit until it's time to make those changes.
- These attributes were double-setting some styling, so when we went to remove that styling, it made it confusing why they were still being set.
… light and dark mode + No disabled styling specified for dark mode. Will discuss with designer when she gets back in office, guessed in the meantime.
- Each button now has its own class with its own styling rules. - This improves legibility; we're no longer overloading a button with a type attribute of 'answer' for buttons that aren't answer buttons. - It also improves rendering speed; fewer of the buttons run a conditional to render, and those that do only contain a single conditional. - The 'type' attribute SHOULD no longer be necessary. I am removing it in a separate commit so that, if the attribute is being used for something I didn't foresee and is difficult to pull out, I can reset easily.
wgranger left a comment •
Overall, the code here looks pretty good. I especially like how the buttons are extended in
A few items I noticed while running the app in museum mode.
If any of these issues will not affect museum-mode, I think it's fine to save them for another PR (given time constraints), but we need to open an issue for anything that isn't addressed in this PR.
Thank you! I appreciate your validation on this choice :)
Yes, I do believe this is intended behavior. I will talk to Laura and some of the research teams using the drawing classifier to ensure that this is the expected behavior.
Yep! I was able to reproduce this. I was able to fix it by including an icon for the field guide item.
There are a few ways we can prevent this in the future:
As I understand it, researchers and citizen scientists use the field guide to remind themselves of how things look that they are classifying in the project. So the utility of the field guide lies largely in the presence of a picture. For that reason, I think it would make sense to do #2.
Lol, you sure can! Successfully reproduced in citizen science mode. (In museum mode this will not happen because the side menu is not available there).
I made an issue for this: #297
Correct! This is a known thing. Issue created: #298