To use the app, users have to increase the brightness of the screen and this causes the battery to run out faster and still the best experience is not perceived.

It is an app that users use daily for 6 hours under sunlight taking meter readings located in the customers' house.

They make a tour in the street visiting around 500 houses.


Natural sunlight, at least in its visible spectrum, is the closest thing you'll ever get to a perfect white. So I would not try to resolve this with colour.

Take a step back and consider the following...

  1. Salience of the (critical) information your app provides to the users while they take utility meter readings,
  2. The exact nature of that information and where it fits into specific tasks performed to read the meters (and record those readings in the app?)
  3. The time range within which your users can realistically accomplish their workflow, and individual tasks within it.

To break this down...


The obvious battery friendly solution appears to be to keep most of the screen dark and present critical numbers with high brightness contrast. Unfortunately a dark screen attracts glare, and since your user cohort likely uses sunglasses on certain days, their UV lens polarisation will compromise any LCD screen's legibility. This problem is hard to solve - to my knowledge - by using a specific colour... unlike, for instance, using red or orange display numbers in a very dark environment, which is a good adaptation for night vision (military applications, emergency lighting etc.)

I would therefore - counterintuitively perhaps at first - brighten up the screen. Most mobile devices adapt backlight strength to ambient lighting conditions these days. Display the most critical info with enhanced contrast, and factor smudgy, fingerprinty, oily and perhaps cracked screens into the equation as potential added burdens. Start by checking a range of typefaces used in road signage, for example, and then calibrate font size and weight for legibility in bright conditions.

This unfortunately means you need to manage the potentially voracious battery consumption of your app in other ways, and that gets me to my next point.

Specific Tasks

What is the exact purpose for which your users need a mobile device?

Do the utility meters have a barcode ID which the device can scan, followed perhaps by some short range data connection like IR-opto interface that transmits meter readings to the device? In that case, it is important for the utility worker to obtain accurate information - perhaps, just to be sure, they read the captured/scanned info on their smartphone screen while cross-checking it against the meter's (printed) ID tag on its type plate, and (analogue, mechanical) reader counter, and only then save the reading - knowing it's devoid of errors.

Job-shadow your users a number of times and record their workflow. How uniform is the (fully made-up, speculative) scenario I describe above? Is there much variation? Are the automated readings prone to frequent errors? Does the technology of the meters vary, from up-to-date, bluetooth bells and whistles snazziness to fully mechanical 1930s style readers where all data must be captured manually?

Once you have a fairly realistic usage scenario, incl. potential case-by-case variation, check how long the mobile device screen actually needs to be backlit:

Time Range

Backlight, but also data transfer, are the main battery gobbling culprits on mobile devices. You have limited influence over data transfer but one thought would be to check if your app records the 500-or-so daily meter readings in its own memory, or if it relates them to some centralised, remote database (given sufficient signal strength). You may find some hidden savings in the type and amount of data transfer. That will be a good conversation to have with the RF engineer on your project - or an external expert.

Mobile applications can, and often do, override the device or user determined time until the screen dims at first, and then switches off to preserve power. If you can aggregate typical task durations from observing users go about their workflow (and yes, with a stopwatch if possible), use that to make a data-informed (!) recommendation of the two time thresholds. On first consideration it seems perfectly acceptable to me to have the screen go dim fairly quickly but not have it time out altogether because switching a prematurely timed-out #@$%& backlight back on requires distracting activities like PIN entry (older), fingerprint ID (newer) or iris recognition (techy to be sure, but highly problematic in your environment).

Work with the engineers to establish a rough aggregate battery budget for a six-hour workday with 500 meter reading cycles - the fact that you have these numbers is an encouraging start. Consider a reminder or prompt to the effect of always starting such work shifts with the battery fully charged so your users don't learn that lesson in a more painful manner; in some rural location.

So to sum up, it may not be an easy answer like picking a specific colour. Instead, work with fine tuning adequate contrast (1), field observations of your users (2), and by homing in on the sweet spot of screen backlight duration (3). Good luck!

| improve this answer | |

Not the answer you're looking for? Browse other questions tagged or ask your own question.