Design process - Units Convert 2

In early December 2013, I attended Tech Talks in Berlin. These are always worth attending to, but this time it was especially worth it for me. I have just finished and submitted version 1.0 of my Units convert app and I had two goals:

  • to hear what Apple designers thought of it
  • to see if I can pitch the app so it’s featured on the store

At the UI Lab, I received some nice praise, the designer I spoke with specifically pointed out several “gems” as he said, but also gave me pretty blistering critique about several aspects of the app. Apart from that, I had a chance to pitch directly to App Store marketing staff and it went rather well. The person I spoke with was enthusiastic about the app and its UI and told me to send them an email when it was live on the store.

I did. And nothing happened. This stung a bit, but feeling down never got anyone any good, so I dug up the notes from the UI Lab meeting and in early January and sat down to take a fresh look at the app and figure out what I can improve. This is a short video walkthrough of the version 1.0, as shipped.

Obvious issues

The first thing Apple designer told me is that I have two primary colors – I had orange and also sky-blue color I used for highlights. “That’s a no-no, you don’t do that – you should emphasize current state with filled/inverted icons using the same color.”

The next problem was that highlighted pair of units was fixed one row of units from the top on the favorites screen (0:56 in the video above), but glued to the top on the category screen (at 0:08, for example). “That’s inconsistent and it does nothing for the app. Also, why have the highlight at all, when you convert to the whole column? Regarding the position – I think it should be always centered in the available space, with keyboard shown or not.” That was all solid advice and in hindsight, an obvious approach. It was lazy of me to not do it like that in the first place.

Minor annoyance he pointed out is that scroll indicator should not be visible in the middle of the screen. “Hide them completely, scrollbars on touch devices are mostly never needed.” Now that was a very interesting comment and so very true.

The larger issue here is that scrolling transition between the regular and highlighted state of the unit cell was abrupt and did not follow the scroll (at 0:16). The reason was that I could not (at the time) technically do what I needed to do to make the transition smooth, thus I opted to apply the state when the finger is off the screen. In my own usage of the app, I almost never used the scroll – I would tap the unit I want to convert from/to. However, every single person I showed it to in Berlin used scrolling exclusively, no one tried to tap, even if the unit was just below the currently highlighted one.
Thus this visual issue became the primary sore point.

Less obvious issues

Navigation through the app was rather confusing. In the app demo, you can see how favorites are collected using browse or search (starting from 0:22), but look what happens from 1:30 – I’m trying to go back to the category grid – it takes almost a dozen taps.

Granted, the main feature and design goal of the app was to pick your favorites and almost exclusively use that screen, occasionally searching for something. You are supposed to “live” on the Favorites but still – it’s not really an excuse.

Speaking of Favorites – it’s not obvious how to add units to it. As you browse through the app, there is no indication that you can swipe the highlighted pair of units. I expected that customers would at some point, out of curiosity, tap the star button in the navigation bar. Since no units were favorites up to that moment yet, customer will see a short movie tutorial (15s) that shows how to add units something to it.

To say that Apple designer was not pleased with that solution would be an understatement. He proposed to show the tutorial on first start of the app and to also keep the link to it somewhere, at all times. Personally, I don’t like intro tutorials thus I opted for a different solution (see “contextual hints” near the end of the article).

The gems

He really liked the custom keyboard, especially that calculator part could be collapsed (see it at the 0:06 in the video). Since I implemented UIKeyInput protocol, it behaved like regular keyboard and it’s a seamless experience.

Another gem is the custom gesture and animation to add a pair of units to the Favorites (at 0:25 in the demo video). It removes the need for Edit mode, which would require an Edit button to be placed somewhere, further complicating the UI. A quick slide to the left is all that’s needed. Removing from Favorites is done in the same way, thus again no need for Edit mode/button.

The plan

It’s clear as a spring day that while the basic premise of the app was good, there was a lot of room for improvement. It’s no wonder App Store editors chose to pass the app.

You can rightfully ask – how could you miss so many issues? It can be surprisingly easy, especially for individual designers/developers working on their own. You get tucked in your vision of the app and lose track of larger picture. That’s why the iterative process I outline in this article is very important. You need to constantly question yourself every step of the way and reconsider every UI and workflow decision. It often happens that at one point you do something that’s good on its own but as you do three further things it becomes a bad fit.

At first I planned to spend two weeks to fix these issues and release an update. But along the way I realized that one change led to another and ideas for improvements kept popping up. In the end it took about 2.5 months of constant daily iterations.

It was all worthwhile though, as the 2.0 release earned a prominent feature placement on the App Store. This is a step by step story of how the app evolved.

Primary color and selected icon state

First things first – remove the blue highlight and draw inverted icon states. This was straightforward and easy to do.

With the help of custom controller transitions, introduced in iOS 7, the icon of the chosen category on the grid perfectly blends into its position in the destination view and thus gives the customer a sense of hierarchical place.

And right there, the first un-planned improvement idea hatched.

Move the category scroller to the bottom

Looking at that transition and thinking how to center the highlighted pair of units I chose to move the scroller to the bottom.

Why? While the scroller is useful when browsing so you can immediately switch to the next category, it was not the primary content for the page and should not take up so much space.

At that point, customer has already chosen the desired category and it makes sense to use the space at the top for the primary content – the units. This was especially useful on iPhone 4/4S and when keyboard was shown.

Navigation hierarchy

Logically, this app has two top navigation levels: main screen with category grid and favorites. That’s why I used faux-3D effect when switching to and from favorites to emphasize its importance. From category grid you can go down to specific category, while Favorites have no sub-levels.
And that’s it.

Everything else in the app are asides; either content that exists on their own (about/help and settings) or auxiliary views that somehow lead into the said hierarchy (search which leads to specific category). Such content blocks are prime candidates for modal views. They should never insert themselves in the main hierarchy.

Additionally, there is no reason for the help and settings buttons to appear anywhere except on the main screen. In reality, they are rarely used and thus there is no reason to repeat them.

With all that said, main screen navigation bar looks like this:

From here, you can either go to favorites or search or you can choose a category in the grid. If you do the latter, then your options are to go back to main screen or again switch to favorites or search:

I hid the back button here and instead used an icon that represents the grid. The reason was to enforce the sense of place and remove doubt where the tap leads. When you go to favorites from the main grid, these are your options:

Imagine for a moment that instead of the grid icon I left the default back button to lead back to the main screen. That becomes problematic if you switch to Favorites from one of the categories as back button would then lead back to that category, not the main screen.

You can rightfully say – but iPhone users already know what back button does, they are trained since the early days. I agree and there-in lies the problem. It was created and added back in the iPhone OS 1.0, which was pretty limited regarding in-app navigation and even starting position. With introduction of the state preservation and restoration in iOS 6, apps no longer presents themselves with the same starting place. Thus when you exit the app on particular category or on favorites and return to it days or weeks later, the meaning of “going back” is long lost.

Hence the grid icon is a better hint as it improves consistency in behavior. It’s always the same and always leads to the same screen.

Additional benefit is that use of icons instead of default back button creates nice visual balance to the navigation bar.

A better unit cell state transition

The key to implement seamless state transition is to use custom subclass of the UICollectionViewLayoutAttributes and inform the cell how far it is from the text field. Then use that value to calculate the appropriate scale for the text size.

At this point, the obvious issues were all accounted for. This is a moment when you need to look at the bigger picture, search for places that needs subtle improvement.

“Well, where do I tap to input numbers?”

This was the question few of my friends asked when I showed them the app. The light gray 0 in the middle was the only number of the screen and I thought it’s obvious enough. As is usually the case, it’s obvious to me because I put it there and knew where to look for.

How to make it more obvious..?

First attempt: separate it visually from the column of text and see how that fares.

Not bad, but it will attract the customer eye even better if it animates in:

This certainly improved its usability, but after using it for few days it did not feel right. As designer, I rely pretty much on gut feeling and over the years I learned to trust it. In this case, I did not like the fact that input is separated from its natural place.

One of the best things touch devices did in the field of HCI (human-computer interaction) is that they removed the interaction middlemen. You know, things like a mouse: you move the mouse to move the cursor/content on the screen. Thus, if I’m entering a value for the particular unit – say square inches – then that input should happen right next to the square inches unit cell.

Thus I was back to the original problem and no obvious solution at the time. How to proceed? Experience tells me that when you are stuck – wether designing or coding or anything, really – the best course of action is to sleep on it. I reverted the changes and moved on to other areas of the app, while keeping this in the back of my mind.

Polishing the gem

Apple designer did praise my custom “add to favorites” interaction but that isn’t the reason to leave it untouched. There is always room for additional polish and here I found plenty of room. Here how it looked like in version 1.0:

A bit of technical background is needed here: two unit columns are implemented as embedded collection view controllers so they can be independently scrolled. The text field sits on top of them in its own container view that’s sized to cover exactly one row of units. Thus when you slide your finger it actually happens over that container view. At the moment gesture is recognized, this sequence is executed:

  • parent controller asks each embedded controller to make a snapshot of its highlighted cell
  • snapshots are embedded in container view, one next to each other so they mimic the original look
  • container background color is set to highlighted color (originally it’s transparent) so the real cells below are not visible

This had few unfortunate side effects.

If numbers are present in the cells – as they mostly will be, doing conversion is point of the app – they will be visible in the snapshot and will “fly out” towards the top along with the units. It’s nothing harmful, but still – it’s a cruft and should not be there; after all, you are adding unit pair, not concrete values with units.

Second issue is that unit on the left is moved outside the visible area so just before you tap the button to move the unit pair into favorites, it may look as though only one unit will be added (it depends on the length of the unit symbol).

This issue was easier to fix. Instead of simply sliding the container to the left, glue it to the left edge and change its size. At the same time, I set the constraints on the snapshots so they squish a bit as you slide.

First issue – removing the number values – was not simple since snapshots are flattened views, basically bitmap images. At this moment, I had multiple options how to proceed: post-process the image, change view hierarchy before snapshotting etc. It was not immediately clear which one would be better or even feasible. So I left this one for later as well, as there was plenty yet to work on.

Best way to avoid getting stuck in large project is to pick off the low hanging fruit first. Work on the smaller, easier tasks and the mere progress that you are constantly making will do wonders for your overall productivity.

Don’t convert to the same unit

One such small task is to filter out source unit from the destination column. For example, if square foot is chosen on the left hand side, remove that unit from the right hand-side.

This change has multiple benefits, the chief being that prevents the possibility of customer mis-selecting units and in the worse case select the same unit on both sides and then add that 1:1 conversion to the Favorites.
At first look, this is minor annoyance which can easily be reverted. But still is an annoyance and details like this matter a lot towards the total experience of using the app.

Improve visibility for the input text field

Coming back to this problem, I tried adding a slightly transparent background to the text field. This, combined with the shrinking text size of the units, made it stand out more during the scroll since units are temporarily hidden.

This was certainly an improvement, but still… not quite there. It does not resolve the primary problem – how to notice the input field before you start scrolling, which is usually when category is open. As before, I left it on the to-do list and moved on.

Beautiful, readable numbers

There are some incredible ranges of possible values in Units convert and naturally, at some combinations it’s inevitable to encounter value with dozen or more digits.

Naive approach would be to enable automatic scaling of the UILabel’s font size, but that won’t work in all cases. Easy example is conversion of 1 petabyte into bits – it’s over 9 trillions…or something like it.

No, the correct way to handle this is to use powers of 10:

To emphasize this, I used NSAttributedString and applied several Core Text features. First, slightly dim the color of the power of 10 part. Then use the correct Unicode character of the mathematical symbol for the multiplication to visually enforce the separation. Top it off with kCTSuperscriptAttributeName attribute applied to just the powers value to force the use of correct superscript characters from the font.

Display of numbers can be improved even more, with the help of one of the crown jewels of iOS 7: Text Kit. Look at the uneven spacing of the numbers in “4,184” value in the following screenshot, especially around “1”:

Adjusting just one property of UIFontDescriptor, using this code:

UIFontDescriptor *fontDescriptor = numberLabel.font.fontDescriptor;
NSArray *numberSettings = @[
  @{UIFontFeatureTypeIdentifierKey: @(kNumberSpacingType),
      UIFontFeatureSelectorIdentifierKey: @(kProportionalNumbersSelector)}
UIFontDescriptor *numberFontDescriptor = [fontDescriptor fontDescriptorByAddingAttributes:@{UIFontDescriptorFeatureSettingsAttribute: numberSettings}];
numberLabel.font = [UIFont fontWithDescriptor:numberFontDescriptor size:fontDescriptor.pointSize];

gives us proportionally spaced digits:

Details which matter.

Enforce icon consistency

Clear and consistent visual language is one of prime attributes of application quality. As I said in the intro, you need to look at what you have every few steps and realign the structure, workflows and/or visual language of the app.

After the previous changes, every icon in the app was using the same line width – except the category grid. My original intention with those icons was to emphasize the grid versus the navigation bar but after simplifying much of the UI in the rest of the app it became apparent that large icons with bold lines are a visual sore, not visual aid.

A quick change of one line in the code and the grid looked much better:

More generous padding around the icons and their captions greatly improved scan-ability of this grid.

Dynamic Type

Now was to time to look into the possibility to support another iOS 7 jewel: dynamic type. This is great feature, very reminiscent of the responsive web design approach. When properly implemented, it’s huge accessibility and usability improvement.

In Units convert, supporting dynamic type would be a real game-changer because there’s a lot of text here, a lot of rather small-sized text (unit names).

Application either needs to offer its own text size options or to react to system-wide changes. I built a simple settings view that allowed me to switch between the system font and custom font I preferred for this kind of app (Avenir).

From there, when switched to system font, it’s relatively easy to respond to size changes from the Settings app:

So, that’s done. However, look carefully at the unit cells as text size is switched from default to smallest and then to largest. It’s easier to notice the issue with screenshots placed side-by-side:

If you use the same size of the cells regardless of the text size you must accommodate for the largest size first which naturally leads to too much wasted space with smaller text. This is not good design; layout itself must react to the text-size changes, exactly like web pages do with responsive web design. Test this with the system Mail app which Apple used as example at WWDC 2013 – email header expands to accommodate larger text sizes.

Further, you need to slightly adjust the spacing between the labels based on their text size. It’s not like Apple didn’t repeatedly nudge us all to start using auto-layout as soon as we can. :) It makes layouts behaving like this very, very easy.

Custom fonts

With that done, it was time to implement custom fonts. As I wrote on my blog right after iOS 7 was announced – I very much dislike the use of Helvetica Neue, especially in text heavy apps. Avenir (Next) is much friendlier, warmer typeface thus a better fit for this app. To properly test the code I was about to write, I added two font options: Helvetica Neue Light and Avenir.

Notice how the system and custom fonts are mutually exclusive. If you choose system font, in-app options are disabled. If you choose custom font, then you can also chose between 5 distinct sizes.

I don’t see any benefit attempting to apply system-wide text sizes to your own custom fonts. One of Apple’s goals with Dynamic Type was to fine-tune the exact font size and appearance for each size grade. They did that for Helvetica Neue and if you change the font their adjustments may actually be a bad fit.

Not all fonts are equal and their parameters (like em width, x-height etc) may vary quite a bit. In the video above, I emphasize one issue this variability can create. When using Helvetica Neue Light, notice at 00:24 how the text of “British termal unit (ISO)” fits into one line. When font changed to Avenir, “(ISO)” part was cut off (see it at 00:34) because it dropped to the second line. I resolved this by introducing arbitrary per-font factor when calculating minimum required size of collection view cells.

Finally, whatever you do here, make sure that each change customer makes is instantly applied. This can be a tricky thing, as internal caching iOS does for performance can sometime completely prevent you from applying the changes. Particularly nasty control is navigation bar which responded to nothing I tried. In the end Peter Steinberger helped me out suggesting to use this after setting the font:

[self.navigationController willAnimateRotationToInterfaceOrientation:self.navigationController.interfaceOrientation duration:0.f]

A hack, but it did the deed. At least for now, I will watch for this as Apple updates iOS.

Custom colors

My personal preference is to use warmer less-contrasting color schemes unlike Apple system apps whom mostly use white background with very strong main color, like blue or red. Plus, with the introduction of the iPhone 5c, it was fun to explore the possibility to offer each 5c (and 5s) color as option for the app’s main tint color.

At the end of the video, you can see that with dark theme, changing just the text and background colors is not enough – keyboard and search bar appearance must also be adjusted properly:

Painting the basement

When polishing the app, every part should be equally taken care of, no matter how (in)significant it is. This is how About/Help screen looked like in version 1.0:

Clear and usable but pretty bland. With just few icons and better spacing, it looks so much better:

Improving custom “remove from favs” animation

This gesture needed some polish – look carefully what happens when slide is stopped before the threshold is reached:

Instead of nicely animating back to initial state, it abruptly jumps to it.

That’s much nicer.

Proper polish on add/remove favorites gesture

Coming back to this gesture, apart from the issue with the number values, one thing still gnawed on me – the text squishing. It happens because the snapshots are bitmap images and thus, since width is more constrained then height, the unit text was distorted.

The proper fix for this is to forego the snapshots and instead replicate the cell’s subview hierarchy and embed that into the container view. Only then it’s possible to adjust layout constraints such that unit names and symbols glide towards each other and start compressing only when absolutely necessary – did I already mentioned how great auto layout is? It works wonders here.

Replicating view hierarchy is actually pretty easy – simply dequeue another cell off each collection view and populate it with proper values, hiding what’s not needed etc.

Contextual hints

With that finally resolved, the only remaining issue was how to teach new users about the gesture. I decided to simplify the help instructions on the empty Favorites view, simply displaying 3 short textual steps.

Along with that, first time you open one of the categories, a hand appears that activates the gesture and shows what you should do.

This video shows another hint – the number text field is always slightly enlarged when loaded to draw user’s attention to it. A satisfactory solution to the text field discovery issue.

There’s another screen in the app which could benefit from this sort of gradual introduction. That’s Settings – it has so many options and colored boxes and dozens of labels that it’s pretty overwhelming when loaded all at once. Instead, the first time it’s opened it “introduces” itself and each subsequent time example cell slides from above while the actual settings slide from the bottom.

This makes it pretty clear what’s what and how it should be used.

One more thing…

All this work up to this moment took over two months. Through constant daily usage I was able to identify many pieces to improve and adjust. At this point, thinking about “is there something left to do” I realized that I almost never used the category scroller at the bottom of the unit columns. Not once.

That made it pretty clear it should be nixed. In its place, I added custom spatial transition similar to what system Calendar and Photos apps are using. When you tap desired category, unit columns expand out of its box and when you go back to the grid, the units collapse back into the same box.

It’s beautiful and strangely satisfying animation.

The end

I was extremely happy with the final version.

When it was approved, I sent an email to App Store’s editorial staff about the possible promotional feature hoping to receive an answer in a week or two. To my surprise, even before they answered (it was indeed about a week later) Units was added among “Best new apps” in the Utilities category the next day.

It might be that it was already on their radar since I sent them an email about version 1.0. Still, it was a nice reward that all this effort was worth it and immediately awarded. Since then, Units convert is prominently featured with its own banner in the Utilities category for almost two months now.

The moral of the story: work hard, always strive to do your best and never lose faith – hard work will be recognized and awarded in the end. If you wonder how did I contact App Store editors, make sure you watch iOS 7 Tech Talks video entitled “App Store Distribution and Marketing for Apps” (or for Games, it’s mostly the same). There are multiple venues of talking with Apple and you can choose one that best fit your needs and your app.

Please download Units convert from the App Store or learn more about on its web site.