"Wait... what? You’re displaying people’s passwords by default? Simply put, yes. We decided to optimize for usability and ease of log in over questionable security increases. On a touchscreen phone, its trivial to move the device out of sight of prying eyes. Or easier still to simply hit the Hide action to obscure a password."
Hybrid development, or the approach of building native apps using Web technologies, has gone through its fair share of highs and lows. But, despite high-profile abandonments from the likes of Facebook and LinkedIn, hybrid development continues to be used by a substantial number of developers.
For instance, a VisionMobile 2014 study of over 7,000 developers found that “15% of app developers use HTML5 beyond the browser, via hybrid apps or HTML5-to-native tools.” PhoneGap’s about page touts that the library “has been downloaded over 1 million times and is being used by over 400,000 developers.”
But what do those numbers mean for the future of hybrid? Is hybrid as a platform growing or shrinking? Is performance still a limiting factor for hybrid apps? In this article we’ll attempt to answer those questions. We’ll look at where the hybrid ecosystem is today, and where it’s heading.
Mobile apps can be generally broken down into native, hybrid and web apps. Going the native route allows you to use all of the capabilities of a device and operating system, with a minimum of performance overhead on a given platform. However, building a web app allows your code to be ported across platforms, which can dramatically reduce development time and cost. Hybrid apps combine the best of both worlds, using a common code base to deploy native-like apps to a wide range of platforms.
This article provides many hints, code snippets and lessons learned on how to build great hybrid mobile apps. I’ll briefly introduce hybrid mobile app development, including its benefits and drawbacks. Then, I’ll share lessons I’ve learned from over two years of developing Hojoki and CatchApp, both of which run natively on major mobile platforms and were built with HTML, CSS and JavaScript. Finally, we’ll review the most prominent tools to wrap code in a native app.
"We like to win, but we hate to lose. According to the rules of persuasive psychology, we are more likely to prefer avoiding losses than to acquiring gains. This can be applied to how product offerings are framed and communicated. By underlying that a product is protective of a customer’s existing well-being, wealth or social status, such strategy might be more effective than trying to provide a customer with something additional which they don’t already have. Do insurance companies sell the payout that can be gained after the accident or the protection of the things we hold dear to us?"
Some interesting guidelines arose from this brief analysis of our test results. Coupling the following guidelines with Luke Wroblewski’s form design guidelines will help you to build the best form possible in each different situation.
Label position—Placing a label above an input field works better in most cases, because users aren’t forced to look separately at the label and the input field. Be careful to visually separate the label for the next input field from the previous input field.
Alignment of labels—In most cases, when placing labels to the left of input fields, using left-aligned labels imposes a heavy cognitive workload on users. Placing labels above input fields is preferable, but if you choose to place them to the left of input fields, at least make them right aligned.
Bold labels—Reading bold labels is a little bit more difficult for users, so it’s preferable to use plain text labels. However, when using bold labels, you might want to style the input fields not to have heavy borders.
Drop-down list boxes—Use them with care, because they’re so eye-catching. Either use them for important data or, when using them for less important data, place them well below more important input fields.
Label placement for drop-down list boxes—To ensure users are immediately aware of what you’re asking for, instead of using a separate label, make the default value for a drop-down list box the label. This will work for very long lists of items, because a user already has the purpose of the input field in mind before the default value disappears.
Contrary to what you may read, peppering your form with nice buttons, color and typography and plenty of jQuery plugins will not make it usable. Indeed, in doing so, you would be addressing (in an unstructured way) only one third of what constitutes form usability.