iPad UI Design for the Enterprise, Part 1
We spend a lot of time working and educating our prospects and clients on interface design. Not to say that that I am a user interface design expert myself, but at Propelics I do have acess to some of the best information architects and user interface people in the business. Our clients, however, are typically sorely unprepared in this area.
That unpreparedness is to be expected, though. We’re primarily working with business (CxO, SVP, VP of sales, service, engineering, etc.) and IT (CIO, SVP, VP of IT, App Dev, etc.) to identify processes where we can change the customer experience using the iPad. These teams are used to working in Enterprise applications; customizing the functionality of core business process applications (SAP, Siebel/Oracle, Salesforce.com, etc.) or building data entry or reporting interfaces from tools-based providers (MS SharePoint, BusinessObjects, etc.). Applications where “design” is formatted information delivery.
But this. This amazing ability to build tablet based customer facing iPad applications. This is significantly different than adding drop downs to Salesforce.com screens. This right here is quite different.
But I’m getting ahead of myself.
First, some history
The Graphical User Interface (GUI) design, or now as it’s called “user interface (UI) design”, really began in the mass market with the introduction of the Macintosh in 1984. Sure, there was a single predecessor to the Mac, but as for a wildly used GUI released to the public there was only the Macintosh. The look and feel of the original MacOS (or, the Finder) in version 1.0 followed some simple, well thought out principles. Buttons, scroll bars, menus. These items were crude, but consistent. It stayed that way through MacOS version 8 in 2001. 17 years of operating system advances, but some of the very basic elements and interaction principles of the OS were exactly the same. The “Okay” button with the solid surround, or the “Edit” menu item always being #2 in the upper left after “File”. These were the standards, the rules if you will, for developing applications for the Macintosh.
When developers built applications for MacOS through those 17 years, they followed an evolving guide famously called the Apple “HIG” – Human Interface Guidelines. The HIG was the bible. In the early days of GUI design (say, prior to 1994?) the HIG was followed to-the-letter. With that conformity and singularity of approach, the user always knew how to navigate. Always knew how to “get home”. The operating system itself was a baked in as “part” of the application. MacOS ensured there was always a location for menus, a title bar for every window the application creates, and Command-Q was always “Quit” in every application that was on the machine. It was a necessary part of the application – it really couldn’t exist without that operating system infrastructure. From the user’s perspective it was a look and feel benefit at the time that really separated the Macintosh from Windows – there was nothing even close to this conformity within applications delivered in Windows.
This approach within Apple began to shift when the PowerPC based MacOS was killed off in 2001 for Mac OS X – the BSD-derivative operating system you know today. Over the last 10 years, Apple has shown a greater tendency to experiment with menu function, button placement and function, scroll bar dynamics, window layout and controls – virtually all elements of its once-sacred HIG.
With the introduction of the iPhone and its operating system iPhoneOS in 2007, the HIG slate was wiped clean. Able to begin from scratch, Apple worked on the creation of the new HIG for iPhoneOS: A set of guidelines on how to interact with the OS through the finger vs. the Finder.
Then in 2008, a year after the iPhone debut, Apple released the Xcode developer tools and the ability for developers to build their own applications for the iPhone, both public and private. The “Wild West” application design and functionality phase began – with tens of thousands of developers flocking into this new space – each with their own ideas on what makes good UI design on the iPhone and eventually the iPad.
The HIG is dead, or is it?
Today, on the iPad, the HIG exists. But how much of this approach should make it into your application? Will following these guidelines produce the best possible application for your users?
Let’s look at some popular iPad UI design examples in the consumer space:
The Flipboard UI design was completely new at the time of its release – changing the way we as information consumers digest content. Repackaging content as delivered by the content creator into a format built for the user to quickly scan, consume, and ignore.
The Wall Street Journal – built on the opposite theory of Flipboard. An application design that is architected to feel natural to the user by presenting information in a manner that is centuries old in structure, but with the interactivity of a modern UI design on the iPad.
The Kindle App – built for the sole purpose of reading without distraction by the removal of all objects that get in the way between you and the printed word. I purposefully brought back some window controls in the screen shot above for this conversation.
These apps completely disregard the Human Interface Guidelines when it comes to the conventional, but excel in intuitively delivering the intended functionality of the application through UI design.
With our customers, we try to enforce a simple rule: It’s not only about the UI design, it’s about delivering a core process elegantly through an efficient interface. How can we work to strip away the 80% of the process and application in use today that is never touched by the end user, and focus on delivering an elegant, simple, functional application that delivers the 20% of process that gets us to our intended result? Whether that result is a closed sale or just an increase of customer perception, we deliver something that “just works” for the end user and customer.
Steve Jobs has famously been quoted in reference to Apple design:
People think it’s this veneer — that the designers are handed this box and told, ‘Make it look good!’ That’s not what we think design is. It’s not just what it looks like and feels like.
Design is how it works.
We feel the same is true for Enterprise App design. We feel that a great user interface follows the way people think and work, not on the capabilities of the device or the amount of functionality or data that can be jammed into a 1024×768 screen. It’s about what complexities and steps can be removed from the process, not added in. And nowhere is this foundation more important and more needed than in the Enterprise. Enterprise applications and processes have gotten so fat and complex to handle every situation, they have forgotten how to handle most situations with elegance and simplicity. They have lost the ability to “just work”.
From our perspective, the Human Interface Guidelines is an atlas of the roads well traveled in interface design. These roads work, and they’re proven in allowing the end user to quickly understand the controls of your application. But in the end, it’s your process, your user base, and your customers. And only they will know if the application just “works”.
Part II of this topic will continue with content related to end user expectations, the simplification of process, and what type of team is needed to deliver successful results on the iPad.
I love to hear your feedback. Please leave me a comment below, reach out to me on twitter @ericjohncarlson, or email me at firstname.lastname@example.org. Lastly, check out our iPad in the Enterprise Primer for some background on how we approach the iPad in the Enterprise.