Page MenuHomePhabricator

Allow user to "dim" images across the app
Closed, ResolvedPublic

Assigned To
Authored By
JMinor
Jun 28 2017, 9:49 PM
Referenced Files
F8887101: T169151 dark dim.PNG
Jul 28 2017, 9:17 PM
F8887102: T169151 dark.PNG
Jul 28 2017, 9:17 PM
F8860249: toast.mov.gif
Jul 26 2017, 11:32 PM
F8795110: Reading Controls Dark.png
Jul 18 2017, 10:50 PM
F8795109: Reading Controls Default.png
Jul 18 2017, 10:50 PM
F8795111: Reading Controls Sepia.png
Jul 18 2017, 10:50 PM
F8761651: image dimming options.png
Jul 14 2017, 9:55 PM

Description

Why are we doing this?

As a part of the larger work on Reading themes and Appearance preferences we would like to include a way for users to 'dim' images for added reading comfort. Images are a large part of the Explore feed and without image dimming light or bright images might cause reading discomfort for some users.

User story

I use the Wikipedia app reading themes to read comfortably in the dark or in the evenings. I love all of the informative images in Wikipedia articles and in my feed, but light or bright images can make reading at night uncomfortable even when I have the Dark reading theme applied.

Design constraints

  • Reducing image saturation will not work on black and white images
  • Reducing image brightness can cause colorful images to appear 'blown out'

Design

Reading Controls Default.png (667×375 px, 175 KB)
Reading Controls Sepia.png (667×375 px, 179 KB)
Reading Controls Dark.png (667×375 px, 197 KB)

Image dimming toggle is disabled on Default and Sepia modes. Image dimming active on Dark mode.

Design details

  • When image dimming is enabled, decrease image opacity to 65%
  • In the first release image dimming will only be available on the Dark theme.
  • The toggle will appear disabled on the Default and Sepia themes.
  • The default is for image dimming to not be enabled (users will have to toggle image dimming on after switching to Dark theme)
  • If a user has image dimming set to on/enabled on Dark theme, it would be ideal to remember this selected state if they toggle between themes (eg. image dimming on, on dark mode > toggle to default > toggle back to dark mode, image dimming should still be enabled).

Questions / future considerations

  • Should the opacity be set at 65%? If not what is better? Play around with image opacity here: https://jsfiddle.net/carolynlm/k9b0d5qh/3/
  • If we want to support image dimming for Sepia in a later release, I'd suggest that we utilize an opacity overlay of #7B4E10 at 25%

Event Timeline

cmadeo subscribed.

For now, surprisingly, I think that using Opacity as the control for image dimming would be my preference. Personally I think it works best across both Sepia and Dark mode and although it does not 'dim' images on Default mode, it does reduce their visual impact.

Notes:

  • Opacity on Darkmode
  • Opacity on Sepia (perhaps overlay) would be a secondary priority
  • Dimming is disabled on Default mode

Image dimming on the native side is enabled in 1174 (with the fixes for remembering dimming preference and updating to 65% opacity). Remaining work is to enable image dimming for the article view.

If the user switches to dark mode, switches on image dimming, then switches to light or sepia, should the toggle be switched on and disabled or switched off and disabled?

Thanks @JoeWalsh!

If the user switches to dark mode, switches on image dimming, then switches to light or sepia, should the toggle be switched on and disabled or switched off and disabled?

The toggle should be switched on and disabled

Design review notes:

  • Add a label to image dimming

@Mhurd, if opacity (either image or overlay) can be used, great! However, if we use CSS filters for this functionality, I recommend we do not invest in supporting dimming for old Android devices.

@Niedzielski and I got the article image dimming transform all mergified!

Here's the integration PR: https://github.com/wikimedia/wikipedia-ios/pull/1651

@cmadeo @JoeWalsh Guessing we want to do the following for both the article and settings appearance interfaces:

  • flip the dim switch to off position when either default or sepia are selected
  • gray out the "Dim images" text when item above happens (and make it black again whenever the button can again be used)

@cmadeo: almost thinking we should hide the dimmer switch and label when it can't be used, as we'd kicked around before...

Oh, looks like we've yet to hook up dimming to the native article lead image too.

@JoeWalsh Feel free to re-assign this ticket to yourself if the remaining related tasks above make sense.

@Mhurd, thanks! It came out great! Android integration PR is here although there is distinct dim switch to control it independently of dark mode (Android TBD).

@Niedzielski go team! :) Pretty excited about all these cool theme bits!

@Mhurd, yay! This is very exciting!

Signing off on this ticket and will update T169145 re: when dim images is set to off and the user is on default or sepia it's unclear that they are unable to utilize this toggle.

Hi, please write some testing criteria steps so I know what results to expect vs. what has not been working properly. I've been also testing reading themes on the ticket https://phabricator.wikimedia.org/T169255 in case anything I wrote there is of help here.

Testing criteria

  • load an article which has both a lead image and some images below the lead image
  • tap the theme icon on the toolbar at bottom of article
  • tap the dark theme button
  • toggle the 'Dim images' button
  • ensure the lead image and the images below it are reduced in brightness when 'Dim images' is enabled

Tap image below for animation of testing steps:

toast.mov.gif (720×396 px, 2 MB)

ABorbaWMF subscribed.

Tested on iPhone 7+ with iOS 10.3, iPhone 4 with iOS 9.3, and iPad Pro with iOS 10.3 on Beta App version 5.6.0 (1185)

Seems to be working well.

Testing on iPhone 6s (iOS 10.3.3) and Wikipedia app 5.6.0 (1185). This is fixed as image is dimmed when dim images button is toggled.

T169151 dark.PNG (1×750 px, 659 KB)
T169151 dark dim.PNG (1×750 px, 669 KB)

Rockin! Glad we got this in for v1.