Hi all! My name is Jonathan Stark and I’m speaking to you today from my home office in Providence RI. \n\nI’m obsessed with wireless computing and its effects on society, and because of that I spend an inordinate time thinking about mobile app development, training, and strategy. \n\nIt’s worth mentioning that my clients are typically large organization who need to reach large groups of customers and employees with their mobile initiatives, so my strengths skew toward cross-platform apps and mobile web. \n\nToday we’re going to talk about principles of mobile interface design. I think most are pretty self-explanatory on their own, but it’s a long list and it can be a bit overwhelming when taken together. I’m going to start with some big picture perspective, then run through ten subject areas, and finish with some advice about design process and take questions from the group. \n
\n
As designers and developers, we have to concern ourselves with issues on mobile that don’t really exist on the desktop.\n
I think because mobile devices are physically smaller than desktops and laptops, people tend to think of them as shrunken down “real” computers or somehow less powerful. But when you think about it, smartphones are actually more powerful than desktops in many ways. \n
Because of the differences between mobile and desktop, it’s imperative to get yourself into a mobile mindset before getting started. \n
You ARE going to have to leave stuff out. \n
Know what makes your app different and amplify it. There are lots of fish in the sea of mobile apps. If there’s nothing special about your app, why would anyone pick it? \n
Mobile devices are intensely personal. They are our constant companions. Apps that are friendly, reliable, and fun are a delight to use and people will become quite attached to the experience. \n
App developers too often focus on\n\n* what they want\n* what would be fun to develop\n* personal business goals\n\nThese are all good places to start, but you have to put yourself in your users shoes if you ever hope to create an engaging experience. \n
The image of the busy professional racing through the airport with a bag in one hand and smartphone in the other is what lots of people picture when they think about mobile computing context. But it would be a mistake to think that it’s the only one. \n\nTo begin to put ourselves in the shoes of our users, we need to consider three major mobile contexts, which I refer to as:\n* Bored\n* Busy\n* Lost\n\n
Immersive and delightful experience that picks up where user left off is important. \n\n* ebay sells multiple ferraris per MONTH on mobile. \n* personally, smartphones and tablets have completely replaced traditional television.\n* still, interruptions are highly likely so be sure to pick up where user left off.\n
Ability to accomplish micro-tasks incredibly quickly and reliably in a hectic environment is important.\n\n* Tunnel vision\n* Huge targets\n* Bold design\n
In transit, in unfamiliar surroundings, or in familiar surroundings but interested in something unknown. \nConnectivity and battery life are big concerns. \n
\n
I can’t stress this enough. \n
Because of the “constant companion” nature of our relationship to smartphones, paying a lot of attention to getting the little details perfect will be noticed and appreciated. I think of this like the “fit and finish” of a car. The engine might be powerful and the body style gorgeous, but if there’s a lot of road noise or rattling on the highway, the experience will begin to degrade for the commuter. \n
With the advent of touchscreen interfaces, everyone is always talking about “finger this” and “finger that”. In reality, the thumb is what we need to design for. Unless the user has her smartphone is using two hands, it’s almost impossible to get a finger on the screen. And even in a two handed grip, she’s likely to type with two thumbs. \n
44px is the magic number\nDon’t put the Send button adjacent to the Backspace button\n
Let your content shine by minimizing chrome wherever possible. \n(Aside about fixed position headers and footers in web dev)\n\n
Think of an adding machine, a bathroom scale, or even a computer - the controls are beneath the display. And for good reason - if they weren’t, we wouldn’t be able to see what was going on with the content! \n\nContrast this real-world design consideration with traditional web or desktop software, where navigation and menu bars are virtually always at the top. This made sense because the mouse pointer is nearly invisible. Not so with the meat pointer.\n
I assure that that “below the fold” exists for mobile. Also, having a non-scrolling screen has a more solid and dependable “feel” than a scrolling view because it’s more predictable. Of course, certain screens have to scroll, but it’s good to avoid it where you can. Also nice to give visual clues that scrolling is possible by reverse animating into view. \n
If you are going to use one of the common nav models, be sure to pick the one that is makes the most sense for your app. \n
Weather app on iPhone\n
Music app on iPhone\n
Settings app on iPhone\n
\n
Minimize keyboard interaction where you can\n
There are a wide variety of keyboards and variations(ascii, numbers, keypad, email, url, etc..). Be sure to pull up the one that is best for each field. \n\n(Aside that Android Market allows people to install custom keyboards, so you can’t be 100% sure how much screen real-estate is being taken up)\n
Auto-correct, auto-capitalize, auto-complete. Consider each in the context of every input field in your app. \n\nSo annoying to have auto-correct or auto-caps on an email field. \n\n\n
Some people (cough-me-cough) have fat fingers and sometimes need the roomier key layout available in landscape mode. \n
\n
\n
\n
\n
A common vocabulary for gestures doesn’t exist yet so it’s too soon for most apps to skip visible controls that can be used with a single-finger. \n
\n
\n
\n
Consider adding an orientation lock for apps that invite long sessions\n
\n
* Provide instant visible feedback for every interaction\n* Except when you shouldn’t (tap highlights when scrolling)\n* Use spinners or progress bars to let users know that your app is working on it\n\n
* Only use alerts when something it truly borked\n* Keep language reassuring and friendly\n* Don't use modal alerts for "FYI" type information\n\n
* Confirmation dialogs should only be in response to user actions\n* "Safest" choice should be the default button in the confirmation \n\n
\n
\n
Gives the illusion of speed\n
If possible, launch screen should be a "content-less" image of your app \nAnything that looks interactive (buttons, links, icons, content) will create frustration\nBranded launch screens make user feel like they're sitting through an ad\n\n\n
\n
A polished icon suggests a polished app\nIcons live shoulder to shoulder with other icons\nTherefor, an icon is an ad (not an art piece)\nBe literal - show what your app does\nUse a strong silhouette\nDon't go overboard with text\nIt's usually not attractive to scale down large icon for smaller sizes\n\n
Simple apps should be self-explanatory\nComplex apps might require a "tips & tricks" overlay\nUI might need work if you are considering lots of help text\nAugment empty lists with helpful instructions\n
It can be tempting to jump right into code... DON’T! \n\nAs the saying goes: “Weeks of coding can save you hours of planning”\n
\n
\n
Simulators are not very useful because you can’t “feel” the app, it’s not the right size, and there might be bugs.\n
I am routinely shocked at people’s mental model of an app on first launch. Just the other day, a developer a work with built a screen that made perfect sense to her, but left me utterly confused. \n\nEven if you are the customer, get a second opinion. \n
