DEVELOPER PROTIPS: DESIGNING APPS FOR iOS AND ANDROID

estrapadetubacityΚινητά – Ασύρματες Τεχνολογίες

10 Δεκ 2013 (πριν από 3 χρόνια και 8 μήνες)

61 εμφανίσεις

CONTENT INDEX
PREFACE. SUMMARY AND ACTION ITEMS
I. THE PURPOSE OF THIS DOCUMENT
II. GENERAL SUGGESTIONS
A. DESIGN PHASE
B. ASSET DELIVERY
III. iOS- SPECIFIC TIPS
IV. ANDROID- SPECIFIC TIPS
V. HELPFUL ADDITIONAL READING
2

2

3

3

5

6

7

9
DEVELOPER PROTIPS:

DESIGNING APPS FOR iOS

AND ANDROID
NOTES
2
PREFACE. SUMMARY AND ACTION ITEMS
While each of these items is explained in greater detail throughout this docu
-
ment, here is a list of a few simple things you can do to make your design and
development experience for native mobile development better.



Read the UI guidelines for the platform(s) you are supporting. In particular,
consult Apple’s iOS Human Interface Guidelines
1
and the Android Design
2

page at Google. Pay particular attention to differences in expected navigation
patterns, as these can significantly change design across platforms, and even
across versions of a platform.



Learn what functionality is available on the platforms, versions, and devices
you want to support. Take advantage of cool technology, but be careful to
ensure that you know what its limits are and can provide fallbacks when
certain items aren’t supported.



Figure out how you’re going to support different screen sizes. An Application
Style Guide is a great way to make this clear, but providing guidance on this
is an absolute necessity.



Make sure your PSDs are clear and platform-appropriate. Make sure you’re
not giving iOS designs to Android developers, or vice-versa. Show your hit
states, keep related items in folders, and use layer comps wherever possible.



Talk to developers before finalizing your designs. Developers for each platform
can give you feedback that can save you tons of time in implementation,
particularly if you are targeting an unfamiliar operating system or a version
of an operating system still under development.
I. THE PURPOSE OF THIS DOCUMENT
Designing for native mobile development, particularly when working cross-
platform, can be extremely challenging. While some issues present themselves
across all platforms, every mobile platform has different design conventions,
screen size handling, and built-in controls. Attempting to build a single set of
designs that will be easy to implement on every platform is impossible.
We’ve created this document based on our experiences when working with
native mobile designs provided by clients. We want to help you limit the time
spent recreating native controls from a different platform, figuring out color
schemes, and requesting assets that meet the needs of the platform and applica
-
tion. The goal is to give you more time to focus on the really cool stuff.
We want, in short, to provide guidelines that will help you during your de
-
sign process to create the best experience for your users in every application,
while keeping your costs and timeline for development as reasonable as possible.
1.
Apple HIG, including iOS 7: https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/MobileHIG/
index.html - Consult your development partner for prerelease documentation for new versions of iOS.

2. Android Design site: http://developer.android.com/design/index.html
NOTES
3
II. GENERAL SUGGESTIONS
Some elements of mobile design and development apply no matter what the
platform. We’ve broken these out into things to take into consideration during
the initial Design Phase, when you are coming up with the ideas for your User
Interface, and the Asset Delivery Phase, when you are preparing to deliver Pho
-
toshop documents to developers.
These tips apply to any mobile development platform, though we will be
primarily contrasting iOS and Android, as they are presently the most popular
platforms at the time of this writing.
3
A. DESIGN PHASE



Having a mobile device gives you both less and more flexibility in terms
of how users interact with your application: The bad news is that your hit
targets will need to be bigger than on a website in order for users to actually
be able to select the items they’re trying to hit. The good news is that swiping
between screens becomes a much more viable option for navigation, and on
some devices multi-touch gestures, accelerometers, gyroscopes compasses,
cameras, GPS integration, and other advanced technologies can help create
very unique experiences. While all devices support tapping and swiping,
ensure that if you want to use any advanced technologies, you are aware
of the limitations of each technology, which devices support each option,
and can provide some sort of fallback for devices which do not support a
particular technology.



Consider making an Application Style Guide, similar to one you would make
for a website. Answer some of the questions your designers will need to
know as they come up with the designs, and some of the questions your
developers will have as they implement those designs. For example:



What are the hexadecimal colors that will be used within the application
for backgrounds, buttons, text, or other repeated elements?


Are there standard hit states for buttons?


Are there standard sizes for rows in a list of items?



How should the app handle text that is longer than the designs permit for -
should it scroll? Should it truncate? Should it ellipsize?



On different screen sizes, should elements grow to fit the height of the
screen, or should they stick to the top of the screen, remaining the same
height and/or width?
Even if you’re only starting with one platform, having this style guide built out
can help immensely when transitioning designs to a future platform. Designers
and developers can clearly see what you intended during the original design
phase just by looking at the style guide. Without a style guide, they might need to
3. US Smartphone Subscriber Market Share, July 2013. http://www.comscore.com/Insights/Press_Releases/2013/9/comScore_
Reports_July_2013_U.S._Smartphone_Subscriber_Market_Share
NOTES
4
make assumptions (which introduce additional risk) or seek clarification (which
requires additional time) for designs and implementations for a new platform
based on designs and implementations for the original platform.



During your design phase, look at your designs on a device. Export your
PSD or Illustrator document as an image at the size it will appear on a screen
(on multiple screens if you are working with Android), and open it on the
target device. This is a really easy way to tell if elements that look great on
your computer will be too small (or large) for a mobile device. There are a
few tools of varying price and sophistication available to facilitate this:



For iOS only, there is an app called Briefs
4
that allows fast prototyping
and display on an iPhone with a companion app. The iOS companion app
is free, the Mac app that facilitates it is currently $199.



For iOS and Android, there is an app called Prototyping On Paper
5
that
you can use to create quick, tappable prototypes on a device with either
pictures you take within the app or images imported from the Camera Roll.
Pricing is based on how many prototypes you are currently using.



For a free solution, you can export your comps at the appropriate size to a
Dropbox folder, then using the Dropbox app on the appropriate platform,
open the comp on a device. It won’t be tappable, but it can quickly give
you a good idea of whether your controls are appropriately sized.



Make sure you are aware of what controls various devices provide you as
part of the operating system and hardware. For example, iOS only provides
the Home button, which developers programmatically have no access to.
Android provides a system back button either through hardware or software,
and Android developers can intercept taps for this button if they wish to
do so. In this example, your designs need to account for a way for users to
navigate backwards through the app in iOS, but you may not necessarily
need to do so on Android. Android also offers developers access to other
hardware buttons not easily accessible in iOS, such as the volume keys.



Learn and understand the design conventions for each platform, and on
Android, what is available in the version you are targeting. Due to wildly
different screen sizes, pixel densities, and aspect ratios, you
cannot
use iOS
assets for Android or vice versa. There are also dozens of differences in the
user interface elements each system provides developers. It is significantly
less time-consuming for developers to re-skin a system-provided item rather
than try to implement one designed for a different system from scratch.



If you have custom animations within your application, please provide
animatics or similar animations in other applications your developers can
use for reference. This will help eliminate guesswork in implementation and
can help your developers call out any potential pitfalls of implementing your
desired custom animations.


4. Briefs App: http://giveabrief.com/


5. Prototyping On Paper: http://popapp.in/
NOTES
5



Seek feedback from developers before finalizing your designs. We
can often point out areas where a small amount of additional work
in the design phase can save dozens to hundreds of hours during the
implementation phase, or where you’re unnecessarily departing from an
accepted convention of a platform. This can be especially helpful if the
platform you are designing for is not the platform of the device you use
on a daily basis, or if you are targeting a version of a platform which has
not yet been released to the public.
B. ASSET DELIVERY



Particularly if you have not provided a Style Guide or have hit states that fall
outside its bounds, make sure that you use Layer Comps instead of multiple
PSD files to show hit states. This helps ensure during the design process that
hit-state buttons are all the same size as standard buttons, and helps us slice
your elements accurately during development.



Put related interface elements in folders in your Photoshop document - this
makes them much easier for the devs doing the slicing to find and saves time
during this process.


Make sure you are using the correct Color settings for your PSD:


Color Mode is set to RGB



Document is using Photoshop’s default “North American Web/Internet”
Color Settings


RGB Working Space must be “sRGB IEC61966-2.1”.


RGB Color Management Policy must be set to Convert to Working RGB.



PSDs without these color settings will result in inaccurate colors when
implemented.



Make sure that if you have text with layers of effects on top of them, the
layers are separated out rather than blended together - otherwise we will not
be able to slice them properly. In short,
do not use layer effects unless they
can be flattened.
Blending-based layer effects are particularly troublesome
to implement, and should generally be avoided.



Make sure every folder with new versions of PSDs is labeled with the date
delivered. Please let your development team know exactly what has changed
in the PSD when delivering changes, particularly if development has already
commenced. This helps us focus on implementing changes rather than
figuring out what has changed.



If you choose to use any font other than those included with the system (iOS
encourages the use of Dynamic Type, which is optimized around Helvetica
Neue
6
, while Roboto
7
is the only font included on Android as of 4.0 Ice
6. Apple HIG section on Typography: https://developer.apple.com/library/ios/documentation/userexperience/conceptual/mobilehig/ColorImagesText.html
7. Android Typogrophy including all about Roboto: http://developer.android.com/design/style/typography.html
NOTES
6
Cream Sandwich), make sure your custom fonts are properly licensed for use
in mobile applications and are provided to the developer in the proper format
for each platform. TrueType (.ttf) or OpenType (.otf) files will work for iOS
and Android - consult your development team directly for confirmation for
other platforms.
III. iOS- SPECIFIC SUGGESTIONS
iOS design has, until recently, been somewhat easier than Android design,
largely due to the dramatically smaller number of devices that need to be sup
-
ported. Right now, there are only three screen dimension types to support. At
Retina resolution (all devices supported by iOS 6 except the iPad 2, iPad Mini
and the iPhone 3GS), these are iPad 2048x1536, 640x960 iPhone/iPod Touch,
and 640x1136 iPhone/iPod Touch. Final PSD comps should be provided at
these sizes.
The biggest opportunity and danger in iOS design at this moment both lie in
the significant changes in User Interface and Interaction which Apple introduced
with the announcement of iOS 7. Apple has fundamentally rethought much of
the philosophy behind their User Interface and User Experience, leading to a
look and feel that departs dramatically from iOS 6.
There are several things that you can do to help keep implementation of your
iOS designs as smooth as possible:



Read the Human Interface Guidelines
8
for both their overall theory and
for notes on the individual elements you are designing. They can be very
helpful in terms of keeping you away from common pitfalls. Apple has made
significant clarifications and revisions to this document for iOS 7, building
on their decade of mobile User Experience research - take advantage of it
to the fullest extent possible. In addition, if you are transitioning an existing
app to iOS 7, Apple has put together a fairly thorough guide
9
for this.



When designing, make sure that you facilitate supporting non-retina
devices by placing all your elements on even pixel numbers and making
them even pixel heights and widths. This facilitates resizing these elements
appropriately for non-retina devices - non-retina is exactly half the size of
retina, so all pixel measurements should be divisible by 2. If they are not,
you’ll wind up with assets that cause sub-pixel rendering, which both creates
a surprisingly large performance hit and looks blurry.



Make sure you’re aware of the standard sizes for iOS UI elements. Going
outside this size range can be done, but it may add a significant amount of
time to development depending on the element. Apple, frustratingly, does not
provide a list of these sizes, but graphic designer Ivo Mynttinen put together
an excellent Cheat Sheet with several of these listed.
10
8. A pple Human Interface Guidelines: https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/MobileHIG/index.html -
Consult your development partner for prerelease documentation for new versions of iOS.
9. iOS 7 UI Transition Guide: https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/TransitionGuide/index.html
10. iOS 7 Design Cheat Sheet: http://ivomynttinen.com/blog/the-ios-7-design-cheat-sheet/
NOTES
7



Apple recommends all hit targets be 44x44 points (a point is 1 pixel in non-
retina devices and 2 pixels in each direction in Retina devices). On iOS, it’s
relatively easy to make hit targets larger than the images themselves, but you
may wish to have the full image you’re going to use as a target be that size
so the user can see the full extent of the tappable area.



For pre-release/newly released versions of iOS, recall that Apple likes to
give the developers the tools to create many of the same interactions that
they use in their stock applications. They also expect developers to follow
many of the same design guidelines they have created for any new version.
Always carefully examine any updates to existing stock applications for
guidance towards new direction for your own applications.
Note that in the future, you should engage your development partners early
whenever any major changes are announced in conjunction with a Non-Disclo
-
sure Agreement. This will help you make sure you are aware of both new tools
and tricks Apple has provided to improve your application and any new pitfalls
that might affect your existing UI or functionality adversely.
IV. ANDROID- SPECIFIC SUGGESTIONS
Android design can be a real challenge. The myriad of screen sizes and the frag
-
mentation both among operating system versions (named for various candies
and desserts) and among manufacturer modifications to each of those versions
can lead to all sorts of weird quirks in design support.
In addition, we’ve found in practice that many designers do not use an An
-
droid device as their primary mobile device, so they are generally less familiar
with the conventions of the platform than they are with a platform they interact
with on a daily basis.
Because of those factors, we’ve got a somewhat larger number of sugges
-
tions to help you make your design process successful with Android:



Take a read through the Design Guidelines
11
that the Android team has put
together since wholly revamping the User Interface in v4.0 (Ice Cream
Sandwich). This contains a myriad of examples of interface elements and
design patterns that are now commonly available for Android. Three in
particular to pay attention to, and all of which have been back-ported as far
back as v2.3.3 (Gingerbread) are:



The Action Bar design pattern
12
. It looks somewhat similar at first glance to
the UINavigationBar in iOS, but is philosophically and programmatically
very different.



The Navigation Drawer
13
. Note that Google’s implementation of this is a bit
different than the version seen in many existing iOS and Android apps, particularly
the older versions of the Facebook app: Bringing out a navigation drawer
overlays your content rather than pushing your content over to one side.
11.Android Design site: http://developer.android.com/design/index.html
12. Action Bar Design Pattern: http://developer.android.com/design/patterns/actionbar.html
13. Navigation Drawer design pattern: http://developer.android.com/design/patterns/navigation-drawer.html
NOTES
8



Navigation patterns, in particular the Up vs. Back pattern as it relates to
the Action Bar. Google’s page on this
14
has several excellent examples
with clear diagrams of the differing actions that can happen when the
user presses the system back button vs. pressing the Up button on the
Action Bar.



Supporting sophisticated user interfaces has become significantly easier since
Android v4.0 (aka Ice Cream Sandwich, or ICS). Unfortunately, only a small
subset of the changes have been added to the Support library that allows
some elements to be usable on Android v2.3 (a.k.a Gingerbread), which as of
this writing, was still on 30.7% of currently active Android devices.
You can view the overall Android install base at any time by on the Dashboards
Page at the Android Developer site
15
, but you should also consider whether your
user base might be one that is more likely to have a newer phone before deciding
to support Gingerbread. Most sophisticated UI elements and animations *can*
be supported on Gingerbread, but it can take anywhere from dozens to thousands
of lines of additional code (and therefore significantly more time) to do so.
The decision to support Gingerbread devices should be akin to deciding to
support a legacy browser: Consider realistically how much of your user base
will be using the older technology, and whether serving that audience until they
upgrade is worth the additional cost of development.



Decide what screen sizes and pixel densities you wish to primarily target
up front, and provide appropriately sized assets for each. If you are only
targeting phone-sized devices, we have seen solid results with 480x800 hdpi
and/or 720x1280 xhdpi as baseline screen sizes/resolutions. The Android
Cheat Sheet for Graphic Designers
16
can help you figure out how to scale
your assets appropriately.



Note that social sharing in Android is significantly different than in iOS.
For Android, a system called “Intents” allows applications to register for
sharing links and other items, and users can easily use their social network
of choice to share a link. There’s a great post summarizing this at the Google
Developers blog
17
- the “Intents over Integration” and “Avoid One-Off
Integrations” sections are a concise summary of why using system-level
sharing rather than individual share buttons is the superior approach. There’s
also an example at the bottom of the post of what sharing from the ActionBar
looks like in modern versions of Android.



Be aware that design changes can take longer to implement on Android than
iOS. Android assets have to be sliced *very* precisely to allow for proper
layout on multiple screen dimensions when views are complex, so having
custom assets finalized at the beginning of development is particularly
desirable for Android.
14.

Android Navigation Patterns: http://developer.android.com/design/patterns/navigation.html
15. Android Dashboards page: http://developer.android.com/about/dashboards/index.html
16. Android Cheat Sheet For Graphic Designers: http://petrnohejl.github.io/Android-Cheatsheet-For-Graphic-Designers/
17. Android Sharing With Intents: http://android-developers.blogspot.com/2012/02/share-with-intents.html
NOTES
9
V. HELPFUL ADDITIONAL READING
Beyond the links already referenced in the footnotes of this document, Here are
a few additional links we’ve found to be very helpful.
MULTIPLE PLATFORMS



Matt Gemmell’s How Designers Can Help Developers and its companion
piece, How Developers Can Help Designers. Primarily targeted at iOS
devs, but helpful guidance for all platforms. Designers Helping Devs:

http://mattgemmell.com/2012/02/02/how-designers-can-help-developers/
Devs helping designers: http://mattgemmell.com/2012/02/06/how-
developers-can-help-designers/



Flat Design -
A blog covering well-done iterations of the popular flat
design for multiple mobile platforms and the web- there’s no direct link,
but click the “App” button to see examples of iOS and Android apps.
http://fltdsgn.com/
ANDROID



Mobile Design Tips For Android -
Designer favorite Smashing
Magazine’s comprehensive list of tips: http://mobile.smashingmagazine.
com/2012/07/26/android-design-tips/



Don’ts Of Android Design -
A solid reference of pitfalls to avoid,
particularly when transitioning your application from iOS to Android: http://
www.androiduipatterns.com/2013/06/donts-of-android-design.html



Android Design Protips -
A nice little set of Android Design protips from
Android UI guru Roman Nurik, including a great calculator for converting
Device-Independent Pixels to pixels for design purposes: https://plus.google.
com/+RomanNurik/posts/9FhozUbg2i2



Android Design in Action -
A YouTube talk show with several high-level
Android designers going through the best practices and common pitfalls of
design for Android. https://www.youtube.com/playlist?list=PLWz5rJ2EKK
c8j2B95zGMb8muZvrIy-wcF



Android Notification Icon Design Guidelines -
For icons that show in the
status bar when the user receives a notification. Note that these are different
based on what operating system your user is running: 2.2 (Froyo) and below,
2.3 (Gingerbread), or 3.0 (Honeycomb) and above. http://developer.android.
com/guide/practices/ui_guidelines/icon_design_status_bar.html



Android Niceties -
A good collection of modern Android user interface
design. Particularly useful for seeing how people are taking advantage of the
Action Bar. http://androidniceties.tumblr.com/
NOTES
10



Tips For Android Tabs -
Android handles tabbed interfaces very differently
than iOS, and this is a good summary of the Android conventions. http://
www.androiduipatterns.com/2012/08/tips-for-android-tabs.html



Supporting Multiple Screens -
The extensive, official, slightly overwhelming
guide to supporting multiple screens (ie, both phones and Tablets) in the
same application. https://developer.android.com/guide/practices/screens_
support.html



Android Asset Studio -
An open-source method to help you create
appropriately sized assets for various screen sizes and pixel densities. https://
android-ui-utils.googlecode.com/hg/asset-studio/dist/index.html



Action Bar Style Generator -
An open-source tool to help quickly and
easily preview potential styles and generate appropriate resource files for
your ActionBars. http://actionbarstylegenerator.com



Android Holo Colors -
An open-source tool to help quickly and easily
generate the appropriate Android native-control-friendly colors and icons
for your application. http://android-holo-colors.com/



Enchant, Simplify, Amaze: Android’s Design Principles -
A ~40 minute
talk from the 2013 Google I/O conference about UI principles for Android:
http://www.youtube.com/watch?v=s0HIP8EdlnE
iOS



App Design Workflow -
A great article from the prinicipal designer at
Bjango who detailed his entire workflow very thoroughly: http://bjango.
com/articles/appdesignworkflow/



Teehan + Lax’s GUI PSDs -
PSDs representing the GUI of iOS and giving
you an outline for the phone. Note that as of this writing, they have not
updated for iOS 7, but these can give you a running start if you need http://
www.teehanlax.com/blog/?s=gui+psd



Designing for Retina Display -
A two part article from Bjango highlighting
some tips and techniques for effective Retina display design. Part one, with
basic tips: http://bjango.com/articles/designingforretina/ Part two, with lots of
good questions and answers: http://bjango.com/articles/designingforretina2/



Beautiful Pixels -
A good design blog covering highlights of recent
iOS applications. Also covers the occasional Android app. http://
beautifulpixels.com/



Pttrns -
A site with a collection of various design patterns easily sortable by
type - Activity feeds, calculators, popovers, etc. http://pttrns.com/



11
NOTES