Matt Gemmell

My new book CHANGER is out now!

An action-adventure novel — book 1 in the KESTREL series.

★★★★★ — Amazon

Mac OS X Mobile

Interface & Tech 8 min read

First, a necessary disclaimer: there is no Mac OS X Mobile. It’s a fictional version of OS X designed for PDA devices, which I’ve just made up and which I’m going to discuss in this blog post, since I’ve been thinking about PDAs a lot lately. Once again: this is all theoretical and just for the purposes of discussion.

Now that that’s out of the way, let’s talk about a few different areas of good PDA OS and UI design, which hopefully we’ll see in an Apple-branded mobile device some time in the future. Throughout this post I’ll make references to Windows Mobile 5; you can see plenty of screenshots of Windows Mobile 5 here.


PDAs tend to have a one-window (modal) interface; there’s no room for overlapping areas on a small screen. We can have as many windows and processes as we need, but they’re stacked perfectly on top of each other, all implicitly maximized. Window widgets are limited to Close and possibly a widget to “minimize” (i.e. hide) the window, revealing the previous visible window automatically. Windows Mobile’s close-widget at the top-right of the screen functions either as “Close” (if the window is for a modal dialog or a document), or as “hide” (if the window is an application’s root window, or if the window is the last document in an application and the application has no root window when no documents are open). I think that there’s grounds to clarify the function of the button, obviating the need for utilities like Magic Button on WM.

Since this is a one-window interface, the Close widget will always be in the same physical place, and since we’re running multiple apps at once, closing an app (window) isn’t the same as quitting it (which would presumably be done from the app-name menu, or a process manager utility). I’ve found the top-right position of the Close widget in Windows Mobile to be awkward at times, but I’m not entirely sure where else to put it. To the left of the app name menu, right beside the Apple menu? That would be awful on a desktop OS, but I think it can work on a mobile OS where the boundary between app menubar and window titlebar is already very blurred.


The essential UI elements for a PDA OS are scrollable panels, tabs (which makes it all the more surprising that Palm OS only got them very recently), and pop-up menus (which Palm OS tends to use instead of tabs, presumably due to them taking up constant screen-space regardless of the number of available options). Radio buttons are still great, but for fewer items than on a desktop OS. Pretty much every view should be contained in a scrollview (set to automatically hide the scrollbars when not needed). Verbosity of labeling must be reduced, almost to the point of terseness, and the use of group boxes and nested controls should be limited to when it’s absolutely necessary. PDA UIs are essentially infinitely-tall but very narrow forms, and application design must reflect this.

It’s worth noting here that I actually agree with Windows Mobile’s practice of putting tabs and menubars/toolbars at the bottom of the screen rather than the top; it focuses the user on the task at hand, and on the work area for the current application. Combined with putting the most common modes and controls in the leftmost tab, it really has the effect of getting the tabs out of the way - and it also means that when the onscreen keyboard is visible, you can still see more of the actual application, since the keyboard obscures the tabs area rather than another chunk of the application window.

Control size

There’s more target-acquisition precision with a stylus than with the mouse, so buttons can be a bit smaller. Button labels should be in a larger font compared to the size of the button than they are on a desktop OS, of course. I think that rectangular rather than rounded buttons make more sense, since we don’t have much room to waste on rounded end-caps which don’t contain useful labels. At the very least, the corner radius can be reduced.


As is now normal for PDAs, an onscreen keyboard should be available, probably sliding up from the bottom of the screen. Inkwell-style handwriting recognition is also necessary, and would probably take place anywhere on screen if inking was enabled, rather than on a dedicated virtual silkscreen area as on Palm OS.

Animations and transitions

The system would probably use 2D animations rather than 3D; for example, sheets can slide down and back up, etc. 3D animations require more space and more processing than their 2D equivalents, and I think they’d just get in the way of the extremely task-focused nature of a PDA interface.

Process management

We’d still have multiple apps running, even when their last window is closed. Interestingly, Windows Mobile works that way too, presumably for reasons of fast access to common/recent apps. Perhaps we could auto-close the least recently used running app (assuming it has no unsaved documents) when the user tries to launch a new one, to keep as many processes in RAM as possible.

UI element design

2D UI elements seem more appropriate, and the iApps have been moving that way for some time (the widgets in iCal’s info panel are an example, as are some of Address Book’s widgets). PDA UI has to be a bit higher-contrast then the desktop equivalent, since everything is physically smaller, but proportionately larger compared to the screen of the device, and must also be viewed in wildly differing lighting conditions. Subtle color variations tend to lose their distinguishability in bright daylight, for example. A strong, vector-based design will be both easily readable and also looks modern.

Pointing events

There will be no mouse-over effects; this is a touch-screen device, after all. There’s no explicit pointer on screen nor is there a mouse-location except during click or drag events (though UI elements can be selected for directional-pad navigation and triggering). Contextual menus will be triggered by click-hold, and where appropriate tooltips could also be shown by this method.

Standard APIs and applications

We can assume the existence of APIs for access to a shared address book (transferred as vCards), a set of tasks and events (in iCalendar format), and a body of emails (as mbox files). We’ll probably have notes too, as RTF or RTFD files.

We can assume the existence of a system-wide spellchecker, a basic rich-text editor with RTFD capability, a web browser based on the Safari rendering engine, a file-browsing and app-launching application (with support for Bluetooth OBEX file-transfer and mounting of remote volumes via Wifi), a preferences/config application, and a monitoring utility (processes, system info, memory, storage, network). Similarly, we can assume the existence of basic mobile versions of Address Book, iCal and Mail. Hopefully we’ll also have a mobile version of iChat. Wifi, Bluetooth and infrared connectivity are de rigueur, of course.

We can assume we have basic mobile versions of QuickTime Player, iTunes, iPhoto and DVD Player. We will also naturally have a synchronization client which can talk to iSync. Other basic apps would likely include a Calculator and a version of Stickies (perhaps with sync ability to its desktop counterpart), and it would be nice to have a few games and an Office formats viewer. I’d really like a terminal application, and an Apple Remote Desktop viewer would be most welcome too.

I really like the idea of having a “Today screen” like Windows Mobile does. It seems utterly obvious and essential to me to have the initial/primary screen show a summary of the data you’re most likely to need (count of unread emails, upcoming events, due tasks, time and data, owner info, and status). The panels would each have options, be reorderable and removable, and would support a plugin API. The entire Today screen would simply be another process, started at launch time and always running, much like the Finder.


Obviously we’ll have an Apple logo at the top-left corner, probably functioning very like the Start menu in Windows Mobile, i.e. showing a quick list of recently-used apps/files/folders, a customisable static list of apps for easy launching (though scrollable, not arbitrarily constrained to 7 or so items as in WM), and finally a couple of fixed items to launch the app-launching utility and the preferences utility. To the right of the Apple menu, it makes sense to have the name of the app, as usual, perhaps as a menu-item to spawn a few common commands. The rest of the bar should essentially be the status bar we’re all familiar with from the right of the Mac OS X menubar. I think that the app name should be below (behind) the status bar area if the horizontal space can’t accommodate both, and that the Apple menu should be in front of everything. That would make sure that the essential functions of the system were always accessible even if the user had a large number of status items running.

Menubars for each application will have to be shortened drastically, and I think it makes sense to combine menubars (containing maybe 3 or so menus at most) with toolbars, containing a similar number of small-icon buttons. That way, the Apple menu, application menu, statusbar items, app menus and toolbar items all fit onto two lines of the display, leaving plenty of room for the frontmost application’s contents. Another possibility is to have a toolbar, and stow the menus away as a softkey, much like WM5 does in the Office Mobile applications.

Design and layout

Vertical scrolling is king on PDAs (naturally we’ll support orientation-switching, and hopefully a minimum resolution of VGA). Generally speaking, UIs are designed with multiple options below one another, and judicious use of tabs (on Windows Mobile) or pane-switching via drop-down menus (on Palm OS) to split up long lists of options. UI design on PDAs is also necessarily different from desktop UI design due to the problem of your hand occluding a portion of the display. On a desktop OS, we commonly have labels to the right of checkboxes, radio buttons etc, and we have explanatory text below the actual control. On a PDA, and assuming right-handedness for the stylus, that’s precisely where your hand is going to be if your stylus point is over the relevant control. So, the placement of help text and labels has to be thought through carefully, and there’s perhaps a case for allowing some empty space at the bottom of a scrollable panel to allow the user to scroll the last control to nearer the top of the screen, so they can read relevant labels and explanatory screen-text without their hand getting in the way. This is a good opportunity to support handedness at system-level too, for the sake of our sinister cousins.

One-handed navigation

Windows Mobile 5 attempts to allow one-handed navigation throughout the system by borrowing the concepts of “softkeys” from mobile phones, i.e. having a couple of hardware buttons whose current function is context-dependent. On a mobile device with a touchscreen these functions don’t actually have to be triggered by hardware buttons, of course (the user can simply tap the actual function label on the screen), but the idea has the greatest utility when mapped to physical buttons (to that end, WM5 allows you to remap any of your device’s hardware buttons to function as either the left or right softkey). I think that’s a useful concept to borrow, though it should be optional - i.e. you should be able to specify that you don’t want to see the softkey bar, and reclaim that area of the screen for applications. I’m not sure, but I think that WM5 forces you to always have the softkey bar onscreen, which is both potentially wasteful of screen space if you’re using the stylus anyway, and also encourages app developers to rely on the existence of softkeys to navigate their UIs. That’s acceptable on a phone/smartphone, but not on a PDA.

Final thoughts

All in all, it’s actually amazing how much Windows Mobile gets right. We were talking about this in the office the other day, and aside from some confusing categorization of things (like the old Windows classic problem of “where do I find the settings for such-and-such?”, it’s a really tight and well-focused mobile operating system. I’ve never been one to praise Windows, but I’ve got to hand it to the Windows Mobile team - they’ve done a pretty great job creating an OS that’s easy enough to transition to from a desktop operating system, but which makes sense on a mobile device and doesn’t get in the way of what users want to do with a PDA.

I’d really like Apple to release a PDA with a mobile version of Mac OS X, of course, but until then Windows Mobile comes pretty close to what I’d see as my ideal PDA operating system, and when Missing Sync is updated to allow synchronization with OS X, I’ll be very happy indeed. Just need to find a decent OS X theme for WM5 now. There’s my reputation to consider.