Do These Stairs Feel Right To You?
Why it's critical to know the end-user audience when designing an app.
The mobile world is growing fast. In such an ecosystem there seems to be a never ending stream of new devices and platforms to support. Each platform has its own look and feel, its own SDK, its own programming language, and the task of writing an app for all of them quickly becomes daunting. To combat this, several technologies have emerged that offer a “Write once, deploy to all” model which allows developers to engineer and manage one code base, also known as "hybrid app development". As the mobile ecosystems mature, so do the hybrid solutions to support them. Two of these solutions stand out among the crowd; PhoneGap and Appcelerator.
Will Your Target Audience Care?
When discussing visual elements you have to know your target audience. Mainly, you must ask yourself if the app will be for internal use within a company or aimed at everyday users. This becomes increasingly important as the various platforms deviate in user interface design. Everyday users can be finicky. They expect an app to look like other native apps. If the app doesn't look "right" it may be replaced with a similar app that does. Employees do not have this luxury. For better or worse they are stuck with the supplied app. For this reason developers must pay close attention to visual elements when targeting everyday users, but can be a little more lax for internal apps. With this in mind, lets dive into the visual drawbacks with hybrid solutions.
Run Everywhere Doesn't Mean it Looks the Same Everywhere
I mentioned earlier that users expect apps to look "right". I say “right” because depending on what platform you are developing for, “right” will be very different. Take this simple example:
Each platform possesses different ways of managing tabs. Android lays the tabs out along the top while iOS lays them out along the bottom. Which one is “right?” This is just the tip of the iceberg when it comes to the UI differences between major platforms. If this were to be implemented in PhoneGap, there are two separate pages, with separate designs and resources for just one view. If you have some sort of navigation between views, then you have two layouts for all of those. It’s pretty easy to see how this quickly turns into having a few separate pages for just about every view. This is not worse than native development, however, because you would still have separate views, designs, and resources for each platform. What is worse is that you lose all of the built-in functionality of these UI components. Native platforms handle buttons, sliders, navigation, tabs, images, and so much more for you, all with built in APIs. This code is completely lost when developing with PhoneGap, and is reduced when using Appcelerator.
Animations Not Included
Now, you may be thinking that UI components are pretty easy to replicate. After all, HTML5 has built in UI components that look pretty good and their respective functionalities aren’t that hard to code. While this wouldn’t be wrong, it looks past a huge subtlety that can be the straw that breaks PhoneGap's back: animations. Animations are everywhere in mobile applications. They happen with nearly every tap, swipe, pinch and rotation. These touch interfaces are at the very heart of what makes mobile computing fun. Take swiping, or tapping and dragging one finger, for instance. This basic part of nearly every app is extremely hard to do well through HTML5. While some developers have been able to solve the performance issues and do a decent job of scrolling, there are not many non-native apps that perfect it. This is due to all the little nuances of scrolling; scrolling acceleration and deceleration, gesture precedence, etc. These logistics all matter to the everyday user because they are accustomed to the native defaults. By changing these values, it is a bit like adding or subtracting a fraction of an inch from all the stairs on a staircase. The staircase is still usable but something feels wrong.
Visuals That Go Out-of-Style
The last major point about visual differences with hybrid solutions is forward compatibility. Even if you were to develop a hybrid solution with a great layout that is designed for all the different systems, nailed the animations, got scrolling to feel natural, and executed well on the user experience; the user interface can still change out from under you. Over time, all of the mobile platforms have changed the way they look. The vast majority of the time these changes will happen naturally with an OS update. For apps that are written in native code, the changes will automagically happen to their app so it looks up to date. These screenshots show a simple calculator running on Android 3.x on the left, and Android 4.x on the right.
Do you notice all of the subtle changes? When a user updates their phone it doesn’t take long to get used to seeing the new layout of things and expect them. When developing with a hybrid solution all of this automagic is lost, and a new design will have to be made and implemented to stay up to date.
It is important to note that Appcelerator allows you to bypass many of the flaws I am referring to by compiling to native code. By using the built in modules that are specifically designed for iOS or Android, you can create interfaces that will animate correctly and update with new versions. However, you still have to design and implement different views, and the SDK is still limited. As close as the interface might get to looking native, it will never look identical to a fully native app.
Time to Weigh In
So, it comes back to knowing your audience. If your app is targeting average users, they will know that something feels wrong. On the other hand, if the app is to be used internally it may not be an issue if the app doesn’t look or feel perfect. It might just have to work. In the real world, most applications will fall somewhere in the middle of just being functional and having to be the Rolls Royce of apps. The important part is to weigh out what UI components you can do without, the time it will take to compensate for the ones you can’t, and the time to develop all the views that will have to be separate. Take that information and really think about how much time will be saved with hybrid development, because in more cases than not, development time is the same whether developing natively or not.
This is the first blog in a three part series about hybrid app development. Part two will focus on the difficulties of adding functionality to a hybrid app, and the third will be about hybrid development in an agile world.