Art-Director of Studio development WOXAPP Artem Map about why mobile development is better to use a native design instead of web elements. We are often clients come with a ready-made design, made without considering the requirements of the operating systems iOS and Android.
Good web designers draw a problem for mobile development interface. “Design will make a friend web designer and mobile development will order separately” – in the end appear in the design of web elements, which are not suitable for mobile applications. Such elements are confusing for users who degrade the experience of interaction with the application and delay the development time.
Gathered a few tips on how to avoid it.
Written is our experience in native mobile development. We will be glad, if you share your experience, comments and additions. Apple and Google own the design principles of interfaces and its own visual language.
Why was it made. For example, the user uses the mail or an alarm clock, it opens your app and sees familiar elements. He knows how to use them, they are predictable and comfortable.
This makes the application clear. Many call it a “native design”. What threatens the use of “negativnih” elements in the design of.
1) increase the timing and cost. For example, you wanted to fancy switcher, as you have on the website.
Instead of a standard item which is added one line of code you are working on all item States (on, off, clamped, inactive), adapt it for the screen orientation and so on. This increases the time and money. Add native element can be for 0-3 hours, and make your own – 1-2 days.
2) Maintaining old versions of the operating system. With the release of a new operating system or API, you will have to maintain a beautiful Lebowski element for all previous versions.
Lets fingers. You need pereklichka on Android. The first option. You take native worth the small price (Switch).
There is a new version of Android, and your pereklichka is automatically displayed in accordance with the requirements of the new operating system. The second option.
You draw “their”, beautiful, not like everyone else, worth the small price. Update operating system this pereklichka will not change, it stays that way. First, in the fresh OS will be your visually outdated. Second, all earlier versions need to monitor the correct operation and to maintain this element. It is necessary to you?.
The left – screen app with negativnye elements. On the right is native. Two visually similar notice.
But the left is a custom alert, right – native. To draw in the notification of the selection items is logical and convenient, but for the web. In the mobile app is better to use a modal screen.
Below shows the native and negativny segment control. In both embodiments performs the same function, but negativny the option to make complicated and expensive. Sometimes the designer takes your Android experience to iOS because Android uses. And Vice versa.
For example, draw a field to enter, where a placeholder is raised. It negative for iOS, this feature from Android. Design for Android and iOS are two different design. For example, one screen of the app for different platforms.
As you can see, the list of elements and their location are similar, but each platform uses its own native elements. The global navigation project through the “hamburger menu” is a problem. For example, in iOS it generates quite a lot of problems, because the native architecture of the application is based “twig” through the TabBar native element “hamburger” no.
Here is an article those who refused the hamburger menu and that got in the end. Speaking about the design of mobile applications, we mean not only a visual solution, but also its architecture.
Navigation and proper content structure thought out in the first place. In iOS and Android different architecture of the screens.
For iOS apps, navigation is built linearly with Tapbara. Globally in the application there are several main branches. Being on the same branch, you can move on to another.
For example, to return from the third step from zero is impossible, you need a linear return to the previous step. From third back to second, from second to first and only then to the beginning of branches. For Android option is a little different. Navigation is built with buttons “Back” and “Up”.
To switch between the attachments screen, you can not only linearly. With the button “Back”, as in iOS, you go back one step back to the beginning. Using the “Up” button, you are taken from any screen in the beginning of the branch.
In this case, it is very important to build and work through scenarios these buttons to not confuse the user. Often a client wants a special animation — “so that the pins fell down on the map and menu layers traveled”. Appropriate beautiful animation enhances the experience of interaction. Inappropriate increases time and is expensive.
IOS and Android have a few dozen native animations. For example, swiping screens, animations, pop-UPS, pressing the button and waiting for it to load.
They need to show the user the origin of the content and where to disappear. This improves the interaction with the application. To use your custom animation is expensive.
Yes, it is beautiful and creates the right expectations, but you pay off it. Its really a multiple impact on the performance of the application. It is desirable to use the native animation and wary custom. Sometimes, the client comes with the design of 10-15 key screens, thinking that this is the designers job is completed.
Loss of condition and scenario, result in long term improvements and approvals. Often such conversations: I thought, after you will be a confirmation window!
So it is not on the design.
This is a standard thing, I thought that was clear. Detailing the state of the elements and scenarios depends on your confidence Builder. If no such certainty, on the design detail to work through all the scenarios and States. It will save time and frustration when developing.
And will help you to write a detailed specification. Send your speakers and front-end cases [email protected]