Back story : how iKana 2 was designed

The most obvious change in iKana 2 is the new visual appearance. After spending a lot of time working with iOS — and with all the media focus these days being on the iPhone and iPad — it’s hard to ignore its influence. Far from being a purely cosmetic change, I think this new UI significantly enhances the usability of iKana. What the iPhone has taught us since its launch in 2007 is that we can radically rethink a lot of user interaction, whether that’s by making a streamlined workflow a more integral part of the user experience, or by making content interaction more direct.

iKana 2 features an iOS-style UI:

Wither the Mac way?

The old Mac way of doing things has been under fire for some time now. Traditionally, apps were heavily based around having multiple windows, full of tool palettes, drawers and other UI cruft. In more recent years the focus has moved towards making apps single-windowed. Take the iLife suite as the original Mac champion of this concept: it has, in turn, led us towards apps bristling with tabbed user interfaces and modal panes that are switched via source lists (e.g. iTunes). You trade the visual mess of having UI scattered all over your screen (which you need to manage) for having to continually dig out what you want from an inscrutable stack, using some mixture of split panes, tabs, toolbars and source lists (which you need to manage). The iOS way sees everything laid out in a dynamic hierarchy that you can easily navigate, where it’s hard to get lost and where visual clutter is all but eliminated. You can argue that it’s less efficient for some tasks, but the efficiency of any UI drops as its complexity increases.

You can see the struggle to make user interfaces more cohesive all over the place. Old habits are hard to break, and it’s often easier to replace one problem with another rather than actually address the underlying issue (yeah, I’m looking at you, Adobe). The old “if only my widget manager had a widget manager manager, all my problems would be solved” kind of thinking often prevails. A great example I saw of this recently was a Firefox developer who had reinvented the concept of a window manager but to handle tabs inside FireFox. Yeah – spatial tab management.

iKana 2 early on in development:

Back to iKana…

iKana’s UI, while functional, wasn’t as intuitive as I’d have liked. As you can see in the above screenshot of an early build, there are navigation elements scattered all over the interface.
The real breakthrough came when I started thinking about and designing the interface for iKana Nōto – the iPad edition. Obviously it was going to use a lot of the same visual elements as iKana touch, but with all that space there was plenty of room to expand into. Then I found myself looking at iKana 2 and thinking, “why haven’t I fundamentally rethought this thing before?”. There was clearly a better way to implement this interface, and it was the one I’d just mocked up for the iPad. Still, I wasn’t totally sold on whether the idea would translate to the desktop until after I built the kana browser. This awesome custom control worked beautifully, but it really needed the iOS style navigation mechanism to feel properly integrated into the UI. It couldn’t just replace the old browser pane or be a souped-up source list.

The kana browser evolving:

The devil’s in the master-detail

iKana, like many apps, is primarily based around a master-detail interface. In this kind of UI you have little things in a list, and when you select one you get more information, the detail as it were. The problem is that lists and tables don’t always work well or use screen space efficiently. The greater the level of detail you have, the harder it is to display it all at once. So you start breaking things out of the source list or adding extra layers of navigation, but that has a negative effect on the workflow and intuitiveness of the app. The problem partly stems from the shortage of standard Mac UI controls up for the task of presenting complex hierarchies of data. Those that are capable would require massive customisation to work well for, for example, browsing a kana set.

It’s exactly this sort of situation where the iPhone UI particularly shines: it’s ideal for quickly ploughing through information while retaining the context. There’s also no conventional restriction on that navigational process. You can move from a list of kana sets, to a grid of kana, to anything else, and it all works smoothly and feels natural. There’s no jumping to different parts of the UI to dig out the next stage of the navigation process. One screen simply slides into the next as you zoom in or out of the information hierarchy.

It’s this sort of logical, drill-down-able UI that iKana 2 brings to the table. It may all seem obvious in hindsight, but then the more natural something is the more obvious a solution it usually seems.

No doubt there will be some critics of this approach. It is a departure from the old Mac way of doing things, from tabs and source lists (all of which have valid uses in certain apps an iOS-style UI may not suit). In this case, though, I think it works well, and I urge you as a user to try it out (and if you’re a developer, maybe give it some thought the next time you’re designing a UI for a desktop app).