Smartphone Battery Life Sucks

Every time there’s a new iPhone, Apple’s the first to note just how many millimeters they’ve managed to shave off the back. Like many people, it seems they’re self-conscious about their waistline. But when it comes to the diet, it’s muscle being trimmed, not fat.

One of the limiting pieces of smartphone technology is the battery. Battery technology is evolving slowly. They can only hold a certain amount of energy and be dis/charged so many times. Compare that to other pieces of smartphone technology: screens are getting bigger, processors are getting more powerful, and there’s so many radios (LTE, NFC, Wi-Fi, Bluetooth) I could contact the Enterprise on half the non-ionizing EMR spectra.

While smartphones grow more powerful, they’re also getting more power hungry. Companies are currently prioritizing two things: thinness and fast and convenient charging. And boy, do they want to be thin. On the iPhone 6 page, Apple proudly proclaimed that this eighth iteration of iPhone was:

iPhone at its largest. And thinnest.

Apple’s marketing department has kicked thick to the curb, describing products as just X mm thin. As if thinness was ever truly important once we stopped carrying around Motorola DynaTACs and everyone’s favorite indestructible Nokia bar phone. Thinness sells, but it’s a hollow promise. Battery technology is slowly evolving. It isn’t fast enough to keep up with smartphone form-factor shrinkage.

Even Apple has recognized that this is a problem. Enter the Smart Battery Case, Apple’s official entry into the already huge battery-equipped case market. Apple has sold these cases in their own store for some time, so they know there’s demand. But these cases, including Apple’s own, are ugly and obstruct the device that Apple spent a lot of time designing and refining. Further, they make the phone thicker than if it was properly equipped out of the box and increase the cost by $99. Ouch.

Phones used to last for weeks on a single charge. I’m lucky to get through the day with my Nexus 5 idle in my pocket. The reality here is that we (as consumers and as industry professionals) shouldn’t be prioritizing mere millimeters when it is entirely possible to make lightweight phones that are comfortable to hold and enable at least a full day of use.

Reprioritizing is, well, a priority. Fast/convenient charging should stay on the list. Then pour money into new battery technology. But here comes the hard part: the industry as a whole should consider smartphones at peak thinness. (Or would that be graphed as valley thinness?) Stop obsessing over thinness and make everything power efficient.

Right now, the screen of a smartphone uses the most power out of any other component. That includes the processor itself. In fact, processors for mobile devices are quite efficient. The code that runs on that processor, however, typically isn’t. Neither are the radios used to enable wireless communication.

Improving the hardware is one side of the efficiency coin; the software should be heavily optimized, too. With faster processors and more resources available to software engineers, it’s tossed by the wayside. (Remember: we put people on the moon with less computing power than modern, non-smart watches have.) That means extensive code rewrites and the addition of contextual awareness to reduce usage that unnecessarily drains the battery, like fetching Facebook updates while you’re asleep or trying to maintain a full LTE connection in your pocket.

With hardware and software efficiency maxed out, thinness removed as a development priority, and hopefully soon the commercial availability of new technologies like suitable supercapacitors and graphene batteries, we may yet see another phone with a battery life that can outlast a person’s ability to stay awake.

Qualcomm’s Quick Charge and Qi wireless charging technologies can help ease the pain of being tethered to the wall/car/other power source. Provided, of course, you have a device and charger compatible with Quick Charge or Qi everywhere.

In the meantime, when you shop for a phone, treat your phone like your clothes: get the size you fit in, not the size you want to be.

Maybe we should just go back to using Nokias…

3 Ways Sites Know You’re Giving Them Fake Information

Forms on Web sites are certainly thorough and demanding. They require certain details to seem accurate, and won’t rest until they get it. But how do Web sites know that you’re providing a fake phone number or verify that your credit card is valid before you even submit the form?

Phone Numbers

Phone numbers are one of the many details you’re probably reluctant to give away to a stranger online. Like many pieces of information, the right tools can use a phone number to search through data related to the phone number, and so on, and they may arrive at your identity, demographic information, home address, employer, et al.

When someone doesn’t believe it’s necessary to give away their phone number, they may decide to use a fake phone number. They try “555-1234” and discover that the form knows!—well, sort of.

The phone numbers in 25 North American countries are detailed using the North American Numbering Plan, or NANP. That plan specifies the Numbering Plan Areas and their three-digit area codes; each Central Office (exchange) is given a three-digit prefix; and finally, there is a four digit subscriber number. The result is a ten-digit telephone number that looks something like:

(123) 555-4321

So how does a form know that’s an invalid number? NANP has rules about what phone numbers are valid. For example:

  • The first digit in an area code or prefix can only be 2–9.
  • The next two digits in an area code or prefix can be any digit from 0–9. (However, NANP isn’t assigning area codes with a 9 as the second digit.)
  • In geographic area codes (like 503 or 971, not like 800 or 888), a prefix cannot be N11 (where N is any number between 0–9).

So all the validation program needs to do is check to see if any of these are true, and if it’s not, just say “Sorry, that’s not valid.”

But there are limits to these programs. While it’s possible to make a system that will call or text you to verify the validity and ownership of the number (in fact, many services like Twitter or Facebook will confirm the number to make sure it’s really yours), it’s fairly uncommon and can be costly depending on the sheer volume of form submissions.

You can meet the requirements of NANP to produce a possible number, but there’s no guarantee that the number isn’t actually in service. When in doubt, use a company’s own telephone number. The form validator probably doesn’t check for that.

Credit & Debit Cards

Here’s another one that may surprise you. Credit and debit card numbers can be validated without contacting your card issuer’s payments system. Do note that a valid number and a number backed by an account are two separate things.

Let’s start with those forms that automatically detect which network your card is on before you’ve even finished typing your number. That’s actually very simple: the first six digits of your card number aren’t unique. They’re the Issuer Identification Number (IIN), and they show who issued your card. Each network is made up of many issuers, so they can often be detected in the first two digits. For example, any card number starting with 51–55 is a MasterCard; with 4, a Visa; 65, Discover. (There are other numbers for these and other networks.)

Now on to the next part: How can a Web form guess if you’re putting in a card number that could be right? After all, it’s a waste of time (and possibly money, through payment gateway fees) to check every card number with the issuers for validity; there should be some sort of sieve to cut most errors or egregious brute-force attempts out.

Your credit or debit card has a bit of mathematical magic in it, intended to prevent those errors. Not only is it in your credit or debit card, but it’s in all kinds of systems to verify that the integrity of a piece of information is not compromised; for example, if someone accidentally fat-fingers the wrong number during data entry.

In a credit or debit card number, the last digit is the check digit:


The check digit is calculated using itself and all the other digits of the card number using something called the Luhn algorithm, also called the mod 10 algorithm. It’s designed to protect against just those kind of errors. To show how the validation works, I’ll check an account number.

The card number I’m going to check is 4242-4242-4242-4242. Seems like this wouldn’t be valid on first glance, but remember: a computer doesn’t see the number the same way we do. The card number validator is looking for an answer of 0; if it’s 0, it’s a valid number. If it’s any other digit, the number is bad. To find that answer, it will first take every second digit, counting backwards from the check digit, and multiply them by 2:

4 2 4 2 4 2 4 2 4 2 4 2 4 2 4 2

8 2 8 2 8 2 8 2 8 2 8 2 8 2 8 2

Then, the validator will sum all the digits:

8 + 2 + 8 + 2 + 8 + 2 + 8 + 2 + 8 + 2 + 8 + 2 + 8 + 2 + 8 + 2 = 80

Finally, the validator will get the modulus of the sum and the number 10. That’s a fancy way of saying divide 80 by 10 and look at the remainder. Because 80 is divided evenly by 10, the remainder—the modulus—is 0. The card number 4242-4242-4242-4242 is valid. It’s not associated with an account; actually, this number is a common test number for services like Stripe.

If the account number had totaled 144, the modulus would have been 4 (10 can go into 144 evenly only 14 times); because four isn’t zero, that card number is invalid.

These two checks—the Luhn algorithm and accepted card issuers’ IINs—combined is a sufficient and computationally inexpensive way to check card numbers before the form is even submitted and the final check between the Web site’s payment gateway and a card issuer is conducted.


This one’s actually a bit tricky. Usually it relies on having a collection of real names for streets, cities, and states/provinces, alongside possible addresses. Because of the scale of that information, this kind of verification (or at least the data) is typically outsourced to a third party. These aren’t foolproof. There may be a house at 700 Main Street and 750 Main Street, but not 725 Main Street. If 725 Main Street was entered into a form, the validator might think it’s a real address because 700 and 750 are real, or because a range of addresses are valid (700–800).

In Short

These forms don’t actually know if information is real or not. There are ways to check if information is genuine, by using it: calling you, checking with your card issuer, or sending a postcard to your address. Those methods are typically cost prohibitive for most Web sites to use, so they rely on the methods you’ve seen here (and many others!) to essentially guess if the information you supply is genuine.

Some terms of service will actually prohibit supplying false information under penalty of perjury, and until there is change in how those implied contracts are handled, someone may actually end up in trouble for entering a fake phone number. More often than not, a Web site is either legitimately in need of your information to make a purchase, to verify your identity, or to complete a task you’ve given. Unfortunately, sometimes they may just be collecting data about you to sell you things or sell others your things.

One last thing: validation is not verification. Just because a number can be issued or used doesn’t mean it’s in service.

You Need to Build for the OS, Not Your Brand

I wanted to make a few notes to those developers who want their apps to have the same brand-overpowering ‘custom’ experience across operating systems.
First, you’re creating an experience for a specific operating system. Each OS has their own specific, special interaction model. For example, all three mobile OSes implement the ability to go back in an application, but they each do it differently.

You’re building for the user, not your brand. 99% of users will not have an iPhone, Nexus, and Lumia next to each other comparing each platform’s app. In fact, it’s probably just you, as a developer, and you shouldn’t be doing interface comparisons on completely different systems anyway. It’s bad practice.

Developers need to stop making their applications about them when it’s about the user. Your experience should not be vastly different from the rest of the device. There’s probably a reason they chose to use that device, so you’re basically giving them the shaft. That’s not a way to make users happy.

The Web has made developers think they can customize their native applications to the point they’ve been removed from the OS itself and what the user is expecting. Once again, the Web is not native, and native apps are not Web sites.

So, in summary:

  • Design your app to look and behave like a core application on the user’s operating system. It should say ‘iOS’ (or whatever you’re developing for), not ‘[Your Brand Here]’. You already have someone using your app, you don’t need to keep selling it to them. It will annoy them.
  • You aren’t the user. You’ve heard it before, but apparently some people need to hear it again.
  • Don’t go against the grain or break the host OS’s interaction model because you don’t like it. That’s not a good enough reason.
  • Don’t use a custom font for anything in the UI. The system font across all three platforms—Windows, iOS, and Android—have been designed for readability and consistency. Breaking that is jarring to the user. It’s a bad idea.
  • Don’t make the user’s experience of their own phone inconsistent.

‘Back’ Is Different For Everyone

Not every mobile operating system is built equal. It’s not just their look or the size of their app stores. Let’s take a look at something you might not think is different: the ‘back’ button. It’s one of the most fundamental interface components for mobile devices, where space is limited.

iOS has a per-app back button in the top left corner, along with a left-to-right swipe gesture. If you open a Web page from an email message, you can only get back to the email message and its app by opening the app switcher.

Windows uses a system-wide back button that handles navigation inside an app and between apps. So, if you open a Web page in an email message, you can just press the single back button to close the page and go back to the message. Pressing and holding the back button opens up the list of apps in the order of interaction. It also allows a user to cancel an operation: a dialog can be dismissed by pressing the system’s back button instead of adding another button—cancel—in the mix.

Android has a strange combination of the two. It has two mechanisms for traversing both interaction paths. The primary path is the trail of interaction: you open one app, navigate through it, open a link in a browser, and the trail includes all of those. That means when you press the system’s back button, it goes back to the previous item in the user’s action history: a previous Web page, the email message you opened a link from, etc.

Android’s secondary path, used much less often, is the app’s own navigation layout, which is traversed using an arrow in the top left corner. This path is independent of a user’s actions, and will neither leave the current app nor traverse the interaction path. A usage example would be if one app opens another app to a specific item. Pressing the system’s back button at this point will go back to the previous app. If a user wants to stay in the app but go to a parent view, like a list containing that item, they would use the top-left back button within the app.

Heartbleed / CVE-2014-0160

Let’s talk about something that affects you. It’s called CVE-2014-0160. You probably know it by Heartbleed. It is a security problem which affects at least 60% of the Web, including Facebook. Here’s how Heartbleed works.

While sysadmins panic (which did include me for a short time), here’s what you should do:

When you receive communication from an affected Website saying that they have fixed the problem, change your password on that site immediately. If they only acknowledge the problem exists but don’t mention a fix, do not change your password: their site is still vulnerable. If a few weeks pass with no confirmation the problem was fixed, you should change your password anyway.

Going forward, keep an eye on your financial statements for fraudulent activity and use unique passwords for every account. (Here’s why: if a vulnerability appears on site A but not site B, it won’t compromise your account on site B since they only have your personal information from site A.)

You can keep track of your passwords, and generate more secure passwords, using password tools like LastPass. If you want to control where your encrypted passwords are, you can use 1Password or KeePass. You can also use a notebook or special password journal (any office supplier will have either).

Whichever option you choose, make sure you keep your passwords somewhere safe and keep a copy outside your home in case of disaster. A safe deposit box or trusted friend/relative’s house, depending on your level of trust/paranoia, are both good options for most people.

Oh, and a report from Bloomberg says the NSA has known about this vulnerability for years and has exploited the bug. Articles with other commentaries and statements from the NSA (dishonestly) denying their exploitation of Heartbleed are available on MSN, CNET, and The Huffington Post.

For more information about Heartbleed, go to, or for more technical information visit Heartbleed’s entry in the Common Vulnerabilities and Exposures database, maintained by The MITRE Corporation.

User Expectations Regarding Files & Mobile Applications

There has been a fast foray by most business software companies into ultra-mobile computing. Microsoft is finally starting to catch up on non-Windows Phone devices with Office for Android. I say that they’re only starting because I met a critical flaw in their own application.

Mobile software has taught users—myself included—that you only need to save documents on full-fledged computers, not smartphones or light tablets (i.e., anything with an ARM chip). It’s great, because that’s one less step to do with a tiny keyboard on a tiny display using an interface that wasn’t designed for handling files.

In fact, it’s one of the intentional decisions made by Apple, and later Microsoft, with their respective mobile platforms: removing the file system from the average user’s view. This is great for most users: you don’t expose the underlying system, so the system appears less complex and it’s less intimidating up front for people who haven’t learned to use the system.

Apple took this step with OS X: they’ve hidden the Library folder in users’ home directories and have somewhat replaced their file browser from being the center of interaction when you first turn on a Mac by introducing Launchpad.

While the rest of the industry starts moving away from exposing the file system to non-power users (and Apple just hides it from everyone), the shift is clear: we don’t open files directly anymore. Instead, we always open applications to handle files.

Some developers have handled this well. Their apps automatically save changes, even to drafts. If the operating system terminates the application when it’s in the background, the file is safe and, to the user, the application’s state hasn’t changed when the user switches back to it. And there’s no need to worry about finding a place to save a file when you press Save; you just need to tap the name of the new document, Untitled, and type in a new name. It’s saved until the user tells the application to destroy it.

Now, here’s my gripe: a certain app for Android doesn’t do that. It still uses parts of the file metaphor (which is partly due to Android as a platform having a silly insistence on exposing the file system for normal users despite everyone else realizing it makes things more complicated) and, its most egregious sin, doesn’t autosave files or drafts.

I just lost an entire hour’s worth of fiction I wrote before sleeping that I’ll never be able to recover, because someone didn’t think about how the modern device’s user environment handles files as part of the industry’s standards, the platform, and the user experience.

If your application doesn’t automatically save changes, please warn me now so I can avoid it.

Determining Types of Files With No Extension on Linux & OS X

Determining types of extensionless files on OS X and Linux

Being lazy and in a rush, I saved a download with its default name, thinking I’d remember what kind of file it was without adding an extension. Needless to say, I didn’t—but a quick search revealed a solution, and I’d suggest adding it to your toolkit. Hit up the link or run man file in your friendly local terminal emulator for more.