Apps Comment: Why Rekoop have gone Native
Following on from our Tikit versus Intapp debate on the merits of HTML5 versus Native apps, Phil Ashworth of Rekoop has added this comment…
The Rekoop applications are very purposely all native applications, you could list many pros and cons between the two technologies but ultimately the reasons why are below:
1. User experience. We now live in world where users of mobile devices expect the same levels of interaction and performance that you would expect from a desktop environment. This unintentionally benchmark has developed from years of use of native applications. Applications designed and written for the environment they were intended for. A simple example – Windows XP/7/8, where is the application close button… (the X in the top right corner of the screen). This example highlights the difference between training every single user on how to exit an application versus them just knowing how. As soon as you make a user question what something does or how it works you put a barrier between them leaning it and their willingness to continue.
The challenge with the one-size-fits-all HTML5 approach is how do you do this for operating systems where the close button natively is in a totally different location(Android/iOS/Windows)? Ultimately there is always a compromise, this usually tends to be a UX design that is consistent UX between all flavours of devices but with a learning curve on each device to understand how the app works differently to the native applications (Phone/Mail/Calendar apps). Rekoop does the opposite here, we purposely design our application to seamlessly flow for the intended operating system, native is the only way to do this.
3. Native features. All devices /manufactures are not the same so why should the software be. We strive to get the most out of our applications from call/email/SMS/calendar appointments/geotagging/wearable tech, each native application will take full advantage of every native feature the device/OS can provide us. This isn’t quite so simple with HTML5, you are dependent on another API giving you access to these calls.
4. Past HTML5 failures are well documented (Facebook/LinkedIn). These seemingly simple applications that only involved displaying data and posting of updates failed to make HTML5 work for them.