Designing and developing between platforms is similar to traveling through different countries. You go through precisely the same motions—sleeping, eating, sightseeing, wherever you are—but the customs of the us you're visiting dictate how you will go about doing them. In some countries, it's ok to push people to the train, or enjoy a burger that has a knife and fork. Similarly, in the event you developed your products first for iOS, you ought not simply expect that you could port it into Android without issue, since your app will feel lost in translation. It's important to be aware of the idioms and behaviors of the platform when you begin design and development. That way your users is able to use and easily understand your app around the platform that may be native to them, and you'll have the most clear and true version of your product or service — where ever it's used. This guide will walk you through some practical techniques for moving from iOS to Android (and returning) without suffering a cultural divide.
Get knowledgeable about Material Design
Material Design can be a new procedure for cross-product, cross-platform design using tangible surfaces, bold graphic design, and meaningful motion that can help define just how software should behave. It is also the default visual language for Android 5.0+ devices, so learning the principles in the system will hugely benefit your project where ever you start developing.
close
The Material Design guidelines offer comprehensive guidance, but we've isolated some key themes to target when you're received from iOS.
Surfaces & depth
iOS conventionally relies on a blur effect to point depth, but you might want to focus using a considered usage of elevated surfaces and shadows in Android. These qualities sign up for objects in material design and help make a spatial model that'll be consistently applied across apps.
Interaction & motion
Material Design places many emphasis on user-initiated motion and touch response. When you touch a component, along with the touch ripples that emanate through your finger, buttons can improvement in elevation (essentially, their shadow grows) to meet” your finger. This magnetic” reaction is really a departure from common touch feedback styles like color change or dimming on iOS and throughout the web. This magnetic reaction is authentically digital.
Furthermore, both touch ripples and magnetic reaction smoothly transition involving the default and pressed state, as opposed to using two discrete images. This is really a great example on the notion of visual continuity in material design by using an almost microscopic level.
Layout grid
A convention from graphic design that's ubiquitous in Android and material design would be the strict adherence into a grid system. Everything aligns with an 8dp grid (see DPs below), making a consistent visual rhythm across apps. For example, buttons will often be 48dp tall, the app bar is 56dp tall automagically, and spacing between elements was in multiples of 8dp.
It's important to be aware of the idioms and behaviors of each and every platform before you begin design and development.
close
Additionally, text as well as other elements often left- or right-align to keylines, which can be akin towards the vertical rules that comprise margins in a very magazine or book. The standard keylines for phones are 16dp and 72dp, but the can be customized to suit specific app needs/challenges.
Typography
Type plays an imperative role in Android and Material Design. Roboto will be the default font family for Android, and incorporates a number of weights together with a condensed variant. However, similar to with iOS, you must incorporate your brand's typographic palette in your app. Make sure to test out your fonts using a couple of Android devices, since Android's font layout engine and rasterizer differ from the one in OSX and iOS. Sometimes a similar typeface look better in a font format than another, so be sure you sample each OTF and TTF with the typeface. Finally, typography runs on the slightly finer baseline grid of 4dp, so line heights really should be 20dp, 24dp, 32dp, 36dp, etc.
So what's different about Android?
Now that you understand a little bit about material design, let's discuss how Android is unique from iOS and also other platforms.
Use density-independent pixels (dp) and design in vector at 1x
On Android, the true secret unit of measure would be the density-independent pixel, often abbreviated DIP or DP. If you're originating from an iOS or website design background, DPs are essentially comparable to points on iOS or CSS pixels. Measuring and sizing things in DPs ensures your designs possess a consistent physical size across devices of varying density.
close
1dp = 1px @ 1x (where 1x on Android is 160dpi)
Measuring and sizing things in DPs ensures your designs have a very consistent physical size across devices of varying density.
Designing anything from layouts to icons in DPs using vector software like Sketch or Illustrator (or using shapes in Photoshop) makes all the math much easier and doesn't sacrifice any on the visual quality you normally get from raster images. When referring time to export such things as icons and other static assets, export for your key densities below.
Density bucket
Scaling factor
Density
MDPI
1x
160dpi
HDPI
1.5x
240dpi
XHDPI
2x
320dpi
XXHDPI
3x
480dpi
XXXHDPI
4x
640dpi
Note that Android will scale your assets down or up available for you, therefore you don't will have to provide one for every bucket. Developers also employ a bunch of tools that they can for automatically generating downscaled versions. Additionally, Android 5.0 has built-in support for vector icons and then there are many tools on the market that obviate the advantages of exporting per-density icon assets. For much more about units of measure and density, read the recommendations inside the material design guidelines and Sebastien Gabriel's Designer's Guide to DPI
Apps vs. activities
Under the hood, an Android app is simply a collection of activities”—each activity is usually a single screen within the app. Activities are connected using intents.” For example, whenever you press control button in activity A, it might trigger an intent representing launch activity B”. Sounds straightforward, right? What makes intents really powerful is:
Their chance to work across apps (like enhanced versions of custom URL schemes for native desktop and iOS apps)
They might be generally defined and also return information on the previous activity (e.g. launch an image-taking app and provides me the photo”)
Intents make it therefore you don't need to reinvent the wheel.
For example, suppose you're creating a messaging app. It's common to permit users to send out images of these kinds of apps. Your first inclination could be to design a camera screen, along using a photo gallery picker, and perhaps even an image editor. Fortunately, intents make it and that means you don't need to reinvent the wheel, and yet, they provide the user careful analysis use whichever camera app, photo picker, or photo editing app they've installed. The flow can be:
The user presses send photo” as part of your app. It triggers an intent representing take or opt for a photo”. Most camera apps on Android support this intent into their take a photograph” activity.
The user gets delivered to their camera app of. After using the photo, the digital camera app might suggest to them an edit photo” option. The camera app can trigger an intent representing edit this photo.”
The user may be presented which has a list of apps that could edit photos and an individual may make a choice. After editing the photo, they will press OK” and stay directed to your app. The photo-editing app passes back the edited photo for the camera app, which then passes back that photo for a app.
Your app takes the edited photo and sends it off inside a message.
Many on the App Extensions provided in iOS 8 have equivalents on Android that happen to be implemented using intents. For example, to permit apps to express a photo or little bit of text along with your app, simply make sure the compose a message” activity as part of your app supports intents representing share this little bit of text” and share this photo.”
Intents also permit you to replace websites using their native app equivalents. For example, if the item detail activity with your app says it may support intents representing view /item/,” clicking on the link like that in a very web browser will allow the person to choose between visiting that page or since item in your native app (and even save their preference).
The system status bar, navigation bar, and physical buttons
On Android, users usually have access to system Back, Home, and quite often Overview (formerly Recents) functions. The system controls for Back, Home, and Overview may be presented as hardware keys or to be a software-rendered button bar for the bottom in the screen known as the navigation bar” on Android (never to be confused with navigation bars on iOS, which, like app bars on Android, house app titles and actions).
close
Android devices have a persistent status bar, providing use of notifications and knowledge about the local time, signal strength, battery level, plus much more. Android will account for your software navigation bar (if present) along with the status bar, automatically reserving that space and decreasing the portion on the screen available on your app. For example, on the Nexus 5, as you move the screen is 360x640dp, the navigation bar in portrait mode is 48dp tall and also the status bar is 24dp tall, which means your app has 360x568dp space to provide content. While you may hide the status bar (and also the navigation bar in limited situations), make sure you leave it UI present and permit users immediate usage of those system functions. Android 4.4 and 5.0 introduced latest features allowing you to draw behind the machine UI to show your app content more immersively. Finally, you're bound to have hardware volume keys, so typically, worried about include volume controls inside your software UI.
The system Back button
The system Back button is going to be always on every Android device, either being a physical button or within the screen inside system navigation bar. As a designer, you rarely must define functionality to the Back button. You normally won't need to customize Android's automatic Back button behavior. By default, pressing Back closes the existing screen and takes you to your previous screen, even though it was an element of another app (e.g. if another app opened your photo editing app using intents). If you're on the first screen within your app, pressing Back takes you towards the user's home screen. Pressing Back on the home screen doesn't require any further back. Note that this Back button is distinct on the Up icon that appears inside your app in greater detail screens. While Back navigates users temporally, Up navigates within the app's hierarchical structure, and may never kick anyone out from the app, even in the event you entered at a different app. Keep in mind which the text for the right with the Up button isn't related on the button enjoy it is on iOS. If that text occurs, it needs to represent a title to the current screen.
Bottom tabs
On iOS, it's normal to use a bottom tab bar to modify between views inside the app. The bottom navigation material design pattern includes guidelines for adopting this navigation structure on Android, including implications with the Back button, scrolling and swiping behavior, and visual styling.
It's also common on Android try using a tab bar with the top in the screen. A top tab bar is preferable in the number of situations:
If swiping between tabs is desirable (avoid swipe for bottom navigation)
If another element such as being a music player's ‘now playing' bar necessitates the bottom area
close
Finally, don't forget some these key differences involving the two approaches:
Bottom navigation bars can persist across category and detail screens, even though this is highly discouraged for top level tab bars
Bottom navigation bars always represent the highest level in the app's information hierarchy, whereas top tabs is usually used for any level
A navigation drawer generally contains additional top-level targets when in combination with bottom navigation bars, while top tab bars will almost always be subordinate to items from the navigation drawer
Gestures
Offering touch gestures to work your app is often a great approach to make the experience fast, fluid and delightful. You should always consider user expectations for gesture-based interaction with a platform. On Android, most from the common gestures have very standardized behaviors, so users will expect your app to back up those. There's a complete section inside the material design guidelines covering gestures, but it is most crucial that you get a couple on the key gestures right.
Horizontal swipe is ubiquitous on touch devices. Unlike iOS, on Android, swiping horizontally in just a tab must switch tabs—it's an integral expected behavior. Outside of tabs, swipe is usually for carousels as well as to dismiss elements from the collection, including removing an item from the list. It's uncommon to provide horizontal scrolling on Android; snapping to page boundaries might be more common.
As for your vertical axis, continuous scrolling is preferred on Android, and snapping to page boundaries is sort of discouraged. Material design encourages using scrolling techniques like pinning to optimize layout at various scrolling positions. For example, the app bar may slide away because you scroll down and reappear since you scroll back.
Swiping on the left or right edge from the screen can be another common gesture. Unlike iOS, where left-edge swipes call for back one screen, Android reserves edge swipe for two main behaviors. First, if there exists a drawer towards the left or right on the screen, such to be a navigation drawer (or hamburger menu”), swiping inward through the side on the screen should open the drawer. Second, degrees of training internally swipeable content inside a tab, swiping through the edge should change tabs.
One final gesture to contemplate is long-press. On Android, long-pressing a product should either select it , begin dragging an item, or loosen up. Avoid using long-press for contextual menus, or less expected behaviors like shortcuts along with other functionalities. Because long-press is usually a somewhat hidden gesture, its behavior isn't normally apparent, therefore it is especially wise to stick to platform norms. If you really should expose contextual actions on items, work with an onscreen affordance just like the overflow icon and popup menu
Takeaways
Android uses DP units, which can be basically points in iOS or CSS pixels. 1dp = 1px @ 1x (or 160dpi)
On Android, apps can integrate deeply with apps, obviating the necessity to reinvent the wheel for such things as taking photos or sharing content to social media marketing.
Android gives a system Back button together with Home and Overview for task-switching.
When deciding between bottom navigation and top tab bars , consider information hierarchy, persistence across category and detail screens, and swipe behavior.
Long-press should either select something, begin dragging it, or do nothing at all. Don't use long-press for unexpected behaviors.
Android design in practice
Now that we've covered some from the core differences in Android, let us check some suggestions and pragmatic tips.
What size should my artboard be?
One of essentially the most popular questions designers have when beginning is what size artboard make use of. While there is absolutely no set of exact sizes that might cover all Android devices, the table below must be a good kick off point. And to be a general rule, designing with the 5” phone and 9” tablet sizes can get you most of just how there.
What about stretchable UI elements?
Android includes built-in support for stretchable images (for things such as custom buttons), a lot like iOS' stretchable image constructs. On Android, they are called nine-patches.” Unlike iOS, Android nine-patch images contain pixels across the perimeter indicating stretch, padding and optical boundary information:
Because nine-patches include this extra information, their filenames must end to differentiate from regular PNG files.
Nine-patches are less popular these days since material design's simple shapes (e.g. flat rounded rectangles) could be described directly in code. However, they feature a ton of flexibility for custom UI elements. If you're with them to build stretchable UI elements, remember to produce corresponding nine-patches to get a variety of densities, to ensure your UI elements look crisp on any screen. There are tools that allow you to simplify the development of nine-patches across different densities for instance the Asset Studio
Old versions of Android
A common concern when building for Android is variability in platform versions, along with the differences from the visual styling and UI framework available across these versions. For example, while Android 5.0 introduced first-class support for shared element transitions, these bankruptcies are not available in early versions on the platform.
You may immediately think you need to make two versions of one's app: one that is built for material design and Android 5.0, and another for earlier versions. While it's certainly possible to utilize this approach, time spent.
For most portions of material design, there exists a very clear, often canonical path based on how it might be implemented across OS versions.
In reality, designing (and developing) for earlier versions of Android isn't everything that challenging. For most portions of Material Design, there exists a very clear, often canonical path depending on how it may be implemented across OS versions. For example:
Essential UI components like toolbars, navigation drawers, tabs, FABs, dynamically colored form controls, etc. can be found across platform versions using support libraries like AppCompat along with the Android Design library.
Most content elements like type, iconography, and imagery aren't linked with any specific platform release, and may be easily implemented across platform versions.
While many newer transition and animation features, like animated vector drawables, circular reveals, and shared element transitions are only positioned on Android 5.0, you'll be able to often fall returning to simpler transitions like fades, slides, and scales, to see a similar story. This doesn't require creating a completely separate app — just special casing smaller waste functionality.
It's important to engage in a very dialogue together with your developers early and frequently.
It's required to engage in the dialogue with the developers early and infrequently to discuss how wise to approach each aspect of the app for earlier versions of Android. Rarely in the event you need to do special-case design work with previous platform versions.
Designing for Android tablets
Unless you should do something very different for tablet users, you won't need to design an absolutely separate app. Instead, you must design 1 app that definitely makes the best using space on phones and tablets.
The step to successfully optimizing for larger screens is adaptability. Android tablet screens vary from 7” to 12” diagonally, and that means you can't just constrain yourself to one size within a orientation. Just like with responsive website development, you need to instead think of how your app should formulate based on different available screen widths. More specifically, consider each of your respective major content elements and have yourself questions like:
How wide until wrinkles of text run a long time (a lot more than ~75 characters per line)?
How wide until image aspect ratios or layout become awkward?
How wide until full-width buttons get too wide?
The strategies these question should assist you to uncover natural breakpoints within your content that trigger the creation of larger margins, image sizes, font sizes, or additional content or navigation panes. This approach will lead with a more versatile UI than should you base your design decisions purely on device form factor. It'll also help it become easier to back up both portrait and landscape orientations for tablets, that's very much an expectation of Android tablet users.
Once you've understood your natural content breakpoints, a few couple additional things to bear in mind when coming over to Android tablets from your iOS world. Unlike Apple's iPads, most Android tablets employ a 16:9 screen ratio (the Nexus 9 as a possible exception). This means that while fullscreen video always looks great, your slightly shorter landscape layouts may need some vertical scrolling, and also your slightly narrower portrait layouts might not exactly fit several content panes when you originally thought. Again, content-based breakpoints are the best friend here — always think first in regards to the content and second about screen size.
For much more about designing for Android tablets, read the layout structure , app structure , and whiteframes resources within the material design guidelines, and also this oldie-but-goodie article
Takeaways
Design your app once and optimize the design and style for tablets and older versions of Android — don't design separate apps per configuration.
There's a clean, canonical route to implementing material design across all versions of Android.
Use this list of common artboard sizes when conducting wireframing or mockups.
Android offers 9-patches realistically work like iOS stretchable images but stretch information built to the graphic itself.
Next steps
Designing for Android with Material Design isn't all of that different from designing for other mobile-focused platforms. There are a small pair of core platform standards, along having a comprehensive group of meticulously documented guidelines and recommendations. But moreover, you will find there's whole lot of room for creativity and innovation Material Design is meant to be flexible and open-minded, focusing around the fundamentals of interaction and visual and motion design across products and platforms, to ensure designers can express their ideas freely. While you're thinking increase next great app, go on a look at several of of these types of material design on Android And contact us on Google+ or Twitter after you've published your hard work!
Further reading
Google Design
Google Design is usually a cooperative effort led by the group of designers, writers, and developers at Google. We work across teams to share original content, produce events, and foster creative and educational partnerships that advance design and technology.
Discover
Tidak ada komentar:
Posting Komentar