Daily UI Challenge: Calculator

Brief: Design a calculator. Standard, scientific, or specialty calculator.

Choosing a standard calculator design for the iPhone, I made a point for this challenge to not look at other calculator designs — other than “calculator iOS” and the physical calculator — to avoid the over-saturation of ideas; I’m a sucker for falling into that trap. I find that looking through existing examples can sometimes create more smoke, and the opportunity to understand the construction, behaviour or reasoning behind a design can often be lost.

I began with a very quick brainstorm to establish what the main buttons of the calculator were and identify any additional features that might be included, for instance, the clear/all clear and copy/paste functions. For reference, I opened up the basic iOS calculator to better understand it’s functions, paying special attention to the ergonomics and behaviour of the interactions.

A quick brainstorm to establish “key” buttons — numbers, sum actions (addition, minus, multiply, divide & equals), decimal, clear and the percentage and negative/positive toggles.

I was aiming for something inspired by the circular dial from old telephones — but there was no way that would fit on an iPhone screen unless I had spindle fingers.

I already had some ideas in what I wanted to implement into the design such as have the clear/clear all button be close to the main digit display. I also took inspiration from call keypads by replicating the circles and their layout — surely there’s no reason why a calculator couldn’t have the same layout or order of numerical characters, right? I then focused on what else would need to be added and aimed to make the shapes somewhat balanced as a collective.

Exploration on separating the main action keys — multiply, addition, subtract and divide — and anchoring them toward the bottom of the screen

I wanted the design to be central to the screen with the most used buttons to be contained and reachable by a single thumb — no tilting that phone!

One of my biggest bug-bears is having to tilt the phone into my hand in order to reach a button, which is why I’m just a little bit in love with the “swipe left to right” behaviour to return to the previous screen. It’s not a huge deal for more complex applications, but a calculator should be accessible and support the haste of the user.

In an effort to give space to the design, I wanted to anchor the main action buttons (add, subtract, divide, multiply) towards the bottom of the screen. One idea was to have a single button for all four actions by press-holding the button to show the row of actions, then thumb-navigating to the symbol and releasing. Although this is better for space, the extra interaction lacks practicality so I went with a standard horizontal layout in the end.

Entry visual confirmations. Left to right: dark grey button on tap, dark orange button on tap, black border remains on action key, black border is removed upon new numeric entry.

I started to look at the visual communication in the design and interaction of the iOS calculator; there are visual changes on each button press — both grey and orange — to confirm an interaction.

One thing I noticed was that during the input of the sum the current action becomes less apparent once a new number is input, for instance, the multiply symbol remains on until you enter a new number. After that it becomes “inactive” and it’s harder to ensure I hit the correct button. I’ve lost count of the number of times I will press the multiply button, enter my number then think “Did I definitely hit multiply just now?” — there’s no consistent clarification.

Exploring the input journey and what elements needed to be visually active at what time.

There are two keys that I found aren’t used all that much — the positive/negative button and the percentage button — and after a quick chat to the people around me it became apparent that it wasn’t clear exactly how/when to use these buttons. These don’t require as much real estate as the core numerical buttons or action buttons, so I shifted these up to the top along with the c and ac buttons.

I was keen to include the clear button near to the display so that tapping on the main display would clear it, switching between c and ac accordingly. There’s a slight illusion that’s going on here in regards to the small “tappable” c button, when in fact the touch box is much bigger, encompassing the main display and both spaces to the left/right of the c symbol.

Although visually iOS is no longer skueomorphic, skueomorphism is reflected in the layout and button shapes to reinforce the fact that this application is a calculator. r.

I also realised there’s a reason square buttons may be more effective than circle buttons, and why the layout doesn’t resemble that of the phone pad — skueomorphism. If something is representative of the real world object or interaction, it feels familiar and users are I more likely to accept it. I liked the idea of the calculator resembling the phone keypad, but once mirrored to my iPhone, my intuition couldn’t shake the urge to dial a number or enter a pin code; I wanted to use it for everything but a calculator.

To alleviate this I tried changing the order of the numbers to reflect a traditional calculator, shifting the ‘0’ to the bottom left, the decimal central to the bottom row and equals symbol to the right of it. Ultimately, this still didn’t feel right and so I shifted the visual design to a grid-based one.

In the final iterations I made a few slight amendments — the main changes being a reduction to the size of the horizontal action buttons along the bottom, and aligning the +/-, ac and % buttons along the top with the number pad. This served two purposes; they remain out of the way and they’re still reachable without tilting the phone or over-stretching the thumb.

The first iteration resembling a phone key pad > keeping the format but repositioning the numbers to better reflect a traditional calculator > changed circles to a grid-based visual

In terms of the visual and colour scheme, I really wanted a space where I could allow for subtlety when it comes to selection and using visual language to track the user flow through each entry.

I wanted a simple scheme; something that wasn’t noisy with hugely contrasting colours; something that could be easily communicated through visual language — brightness.

The human eye is incredibly sensitive to changes in brightness — it has to be in order to see — but how can I communicate this in my design? The main display needs to be the brightest — it’s the most important — and everything else subdued when not in immediate use. When a button is tapped, or there’s a function that may be active then there has to be a visual change.