UI Components: One name to rule them all
As we were telling you last week, magic happens when engineering meets design at Polidea. However, and like for every good magic spells, you will need ingredients and tools to bewitch properly your apps. In the realm of mobile tech this translate in terms of UI components. At Polidea, we like to label our components in order for the designers and developers to have a common understanding of the features each one of the buttons will have in your app. This post will lead you through the main elements that build up the interactivity of most of the mobile apps installed on your phone, and their respective common denomination.
Android: Buttons are what we have come to expect from the web – they are self-contained elements or text links which can be placed pretty much anywhere you want (which doesn’t mean you should place them all over the place; just that you can).
These elements can be customized with colour, or the background can be changed entirely; you either provide an image file or specify a shape. Shadows and a ripple effect for the ‘pressed’ state are available easily from Android 5.0 up. Below 5.0 you can evenly highlight the button when pressed.
iOS: On iOS, buttons are more diverse and often differ depending on context. Small, standard actions are expressed with circular icon buttons, standalone actions with an outlined button, while actions on list have their own row.
You can customize all the types when it comes to label, colour, text colour, background and outline, separately for each state (normal, pressed, selected, disabled).
Android: By default, inputs on Android are underlined and transparent; they mostly appear on solid colored backgrounds.
You can however add a 9-patch or shape background to the field itself, on top of being able to customize colours for the cursor, text, hint, the optional label and the color of error messages which appear underneath the text field. You can customize the font in the text field itself, but customizing it in the label and error message is a lot harder and may take a lot of time. You cannot by default customise the placement of the error message.
iOS: Text fields appear in two ways on iOS. When they are the core of a given interface (think composing an e-mail) they take up the whole width of the screen; subsequent fields are separated by a subtle line. When they are elements (like a login screen), they are mostly single-line fields and outlined.
You can customize the wording of the hint, font, colours of text and outline. Interestingly, there is no native support for labels or error messages; developers will have to write both from scratch. It is hard to customise the cursor.
Android: There are three distinct selection controls here: the checkbox for multiple choices from a set, radio buttons for single choices from a set and the switch for binary on/off situations. They all can easily change colours. If you want to change anything beyond that, you will have to provide custom images for all states separately, in case of the switch all elements have to be separate assets (toggle shape, background).
iOS: Apple explicitly provides only one selection control, the switch. You can find a checkmark in some of the built in apps in iOS, but they only appear to select rows of a list. It seems that the suggested way of creating checkboxes or radios when you need them is to customise a round button with on and off states in whatever style you need.
Android: We have a variety of options at our disposal here. There are two main types of indicators in material design: linear and circular. Both come in the form of determinate and indeterminate, so the choice is really of whatever fits your interface better. Typically, linear indicators are used on cards and circular indicators are used when the whole screen is refreshing or fetching additional data.
You can customize the colour from 5.0 up. Before that, you can’t really customise anything.
iOS: Here we only have two options available out of the box: determinate (progress bar) and indeterminate (spinner). Apple suggests you use the determinate indicator wherever you can.
For both of them you can pick one of two styles (big/thick vs small/thin) and change their colours. Anything above that will require developers to write a custom control.
Android: Android has a good selection of components for alerts. You can go for snackbars, which appear at the bottom of the screen, when you don’t want to stop the user from what they are doing. When you need the user’s immediate attention, like when asking for permissions, use the pop up style.
Both styles can be customised with colour, text colour, custom backgrounds etc. They are pretty flexible.
iOS: On the other end of the spectrum, iOS gives one type of alert, a pop up. You have functional choices, with one, two or three buttons, bold and regular type on the buttons.
Visually, there is nothing you can do with these system alerts. It is common practice to write custom components for alerts, but it is an added effort.
Android: The header element is called the app bar here, and it is a special kind of toolbar, as it accommodates navigation and branding (in contrast to, for example, a floating search bar, which is also a toolbar).
It is extremely customisable, you can add icons, change colour, text colour, make it transparent etc. It is a primary navigation element on Android, and appears in most apps that users are familiar with, so it is not advisable to omit it entirely.
iOS: As usual, the header element on iOS, the navigation bar, is not as flexible as the Android app bar. It is used in the same context though.
You cannot change its size or location, but you can change colour, fonts, text, swap out the right hand text for system icons (like play, pause, camera, trash, search, refresh, bookmark) or add your own icon, and you can swap out the title for a logo or other image.
Polidea’s labelling not only discards misunderstandings when it comes to the features of each buttons, but it also gave the possibility for the designers to create the first mockup app without having to design each and every elements, yet the developer would already know the feature of each one of them and will be able to start coding. This very common denomination is a perfect example of the synergy operating between designers and engineers at Polidea. In return, this harmony drives our project toward a greater efficiency of execution and therefore more time to enhance the quality of your app. That is how magic happens…again! Stay tuned for more mobile app development wizardry…