Well, this is not an easy question to answer. Developers are certainly bullish about its future prospects. And Facebook, React Native’s creator, would have you believe they’ve solved every app development problem that has ever been from this point forward, unto eternity. But is it that simple? Before we can hazard a guess about React Native’s future we need to understand why it exists and what problem it was designed to solve. And before we can do that, we need to learn about native application development.
Native applications are apps written specifically to take advantage of components unique to the platform the app is being developed for. iOS and Android, the two main players in the mobile app market, are completely different operating systems. Their UIs (user interfaces) are very different, as are many of the base assumptions about content display and functionality built into their code bases.
This means that native apps will only run on the mobile operating system they’re developed for. A native Android app uses Android-specific components and language, and won’t run on an iOS device, and vice-versa. In order to develop an app that runs on both platforms you essentially need to develop the app twice, creating and maintaining two separate code bases in two different languages. This is a terribly inefficient system which is why, in the early days of mobile app development you often found apps supported by one OS or the other but not both. Developers simply didn’t want the hassle involved with porting their app over to the other environment.
In answer to the challenges presented by maintaining two separate, OS-specific code bases developers began creating hybrid apps, apps that ran on both platforms but shared a common programming language. To accomplish this all of the OS-specific tasks had to be handled by a go-between, a container that the app was nested inside of. Remember that iOS and Android have different ways of doing pretty much everything. This container bridged the gap between what the app was attempting to do and how the specific operating system expected you to do it. The container was a translator of sorts, taking generic instructions from the cross-platform app and translating them into OS-specific actions.
One of the most common ways of accomplishing this early on was to develop a web app, an app coded like a website, using HTML, CSS and Javascript, which would normally be served up through a mobile web browser. But instead of serving it through a normal browser like Chrome or Firefox the web app was served through a webview, a native app shell that functioned like a browser but interfaced directly with critical UI components on each mobile platform. This allowed the user the experience of running a native app while all of the heavy lifting was being carried out by what was essentially a web app.
This was a functional solution but it lacked a certain amount of finesse and consistency that developers usually require. The Ionic framework, which uses HTML5 along with CSS and Javascript, was developed to help rectify some of sticking points of the web view strategy. Among others, Ionic replicates all of the standard UI elements for both iOS and Android, allowing developers to focus on their app instead of working to make their user interface consistent with both platform’s design standards.
These hybrid approaches drastically reduced the labor costs involved in cross-platform development, but it was not without problems. Having to effectively run real-time translation between what the app is trying to do and how the OS expects things done reduces run-time speed and efficiency. These cross-platform hybrid apps often struggled at feeling like fully native apps. There was always the potential for buggy and sluggish performance. Hybrid apps solved the problem of cross-platform development but couldn’t escape the fact that they were, at their core, a hack. What was needed was a development tool that allowed a single codebase which behaved like a native app in both environments.
React Native takes a novel approach to cross-platform development. Instead of saddling an app with messy, real-time translation duties like you find in hybrid apps, React Native generates fully-compliant, native code for multiple devices off of a single code base. No container program is needed to translate between the app and its environment because, using a single language and a single set of instructions, React Native creates a native iOS app and a native Android app. This is a huge boon to developers looking to create native applications for multiple mobile operating systems. It lets them focus all of their efforts on writing the app, wasting very little time making it run everywhere it needs to.
Apps built using React Native are ALMOST native apps. They can’t be called truly native because they aren’t developed using fully native techniques, but the final output uses exactly the same building blocks that true native apps use to interface with the device they’re running on. This means they are indistinguishable from native apps in the most meaningful ways. Developers can create native apps without writing a single line of code in the native environment. This optimized workflow is why so many developers consider React Native the future.
But this isn’t the end of the story. React Native certainly has its detractors, it’s own functional problems, and several other persnickety issues that could limit its viability going forward. For one, there’s no guarantee that Facebook will continue to develop and support the package. It would certainly take some doing on their end to extricate themselves from the framework since their own apps are built with it, but it’s possible that over time they may sunset the framework and move to something else. The issue is that React Native is currently dependent on the support of a somewhat monolithic patron. However, this risk could be mitigated by recent announcements that Facebook is converting more of the framework to open source, meaning the wider development community will be able to develop and maintain the package themselves.
Facebook has recently announced large-scale architecture improvements and other modifications to improve the speed and efficiency of the framework. This seems to demonstrate a strong, ongoing commitment to React Native.
And there is a strong user community building up around it. This, paired with Facebook’s plans to open source more of the framework is a strong point in its favor. It could well be that in the future development of the package moves away from Facebook and into the public domain, which increases its future viability.
There are quite a few notable projects developed using React Native. Walmart’s app, Instagram, SoundCloud, Wix, UberEats, and AirBnB are just a few. Most of these cite the shared codebase and faster development times as the biggest benefits to making the change. However it’s interesting to note that AirBnB just recently announced that they will be sunsetting the package in favor of something else. Their decision, after two years of development, highlights some of the issues React Native developers face.
AirBnB is a very large-scale app deployment with a lot of moving parts. They were finding that, instead of developing once they were actually having to develop four times. They needed their core React Native team, teams to debug and handle the native side of the equation in both iOS and Android and a team to help develop the React Native architecture itself. As a relatively immature framework, a lot of effort had to be put into making React Native do what AirBnB needed it to. They were still saving time, but not enough to make up for the framework’s shortcomings as they saw them. This demonstrates how no one development strategy is right for every startup and that a variety of strategies must, and will exist as long as mobile development continues to develop.
If the package we ever to be discontinued you’d find a lot of developers up a creek without a paddle, save the one they’re bludgeoning themselves with for backing React Native. A development environment isn’t some ancillary, third party extension or library that can be replaced in your app if it’s discontinued. Apps developed using React Native are entirely dependenton it. If it were suddenly deprecated React Native apps would become nearly impossible to maintain and update without an extremely deep knowledge of every single component in the React Native architecture, which few developers possess. This is a consideration startups need to weigh before development begins using any development model.
React Native uses Javascript as its main development language. Many seasoned developers consider Javascript to be an unsafe, problematic language, and would much rather develop in heartier languages such as Java or Objective-C. It’s conceivable this insistence on Javascript could dissuade enough developers away from React Native in the long run to prevent ubiquitous adoption, although most hybrid models also employ Javascript so if your goal is to avoid it native development may be your best option.
It’s certainly possible that the model of app development spearheaded by React Native is the future of app development. But that doesn’t mean Reactive Native will be the tool people use. There are almost certain to be other development environments that imitate React Native and improve on the paradigm. It’s possible that React Native will wither and die in the face of a stronger competitor. Or an open source competitor that works like React Native but doesn’t require a centralized authority to keep the platform updated and viable.
Can there really be a conclusion? The trust of the matter is, no one can predict the future, but we can say with a reasonable amount of certainty given what we know now, that React Native, or some other development environment that uses a similar approach, is likely the future of app development FOR NOW. Until a better approach is formulated or until some major, game-changing pitfall is encountered, the React Native model for cross-platform app development is the best approach available for most modern developers. If Facebook continues to support and improve it and it continues to be adopted at its current rate it will be a major player in the development world for years to come.
Until it isn’t.
The post Is React Native future of app development? appeared first on OCDLAB.
]]>Last night I had a nightmare where an eerie voice was dictating me to press 0 for some weird crap, 1 for something even more bizarre and what not. Yeah, the good old, not-so-Intelligent Voice Response (IVR) systems. The good news is, these IVRs might soon become a thing of the past, as smart voice bots equipped with artificial intelligence (AI) start revolutionizing customer services across various business sectors.
Bots in their various unique avatars, understand natural language and efficiently deliver chat (and voice) services. These contemporary bots are fast, self-learning and are continually getting smarter. While ordering food, making reservations, etc. are the most typical examples, bots can do much more, and with some decent learning data, they can mimic the human conversation to a reasonable accuracy.
I am sure, about everyone out there had this experience at least once in the lifetime. You call a customer service number, most likely, already frustrated with whatever problems you were dealing with at that time. Rather than finding a (semi) considerate human being on the other end, a robotic voice starts directing to choose from a plethora of options. Not exactly a good start, right? To make things worse, you can keep pressing nine, but nothing would change until the spooky robotic Satan had its way with you. Of course, the technology was relevant at some point, and perhaps it still helps organizations to categorize the inbound traffic to a certain degree. However, the inconvenience and frustration it causes to the valuable customers are way beyond that helping factor.
According to a Forbes article, a survey by LivePerson revealed that 53% of Americans spend 10-20 minutes on hold every week whereas 86% of people said that they go on hold every time they call a contact center. Needless to say, the industry could use a more humane solution which would not want you to get inside the phone and smash the machine voice on the other end.
The first-generation commercial bots were developed in the mid-1990s, but have evolved now through the advancement of artificial intelligence (AI), machine learning and higher data processing speeds. These bots are also known as chat bots, smart bots or AI-bots, and can handle repetitive, mundane and time-consuming tasks.
Have you seen FAQ sections on the popular websites? If done right, FAQs could be an invaluable asset for business and services (to reduce the number of support tickets).
It could help to answer a lot of those questions. Of course, that was a human who paid attention and anticipated those questions. In the layman terms, bots could be considered as an advanced version of these FAQs. Throw in some artificial intelligence to a step by step FAQ, and there we have a bot in its minimalistic avatar. Bots understand the natural language conversations and work using a decision tree. Depending on the question, bot answers using a pre-defined sequential flow. This is, of course, a simple example and modern-day bots are way smarter than that. These bots can learn from user responses collected over time. Bigger the data size, brighter the bot. The machine learning plays a huge role here, and while the user sees a smooth-talking bot on the front-end, there is a lot that goes under the hood to make that bot sound so smart.
Organizations utilize machine learning algorithms to develop intuitive interfaces to program dialogues in text mode. Sometimes these do not use AI; instead, they work using rule-based methods. A well-trained chat bot can deliver impressive results ‘just like a real person.’ If open questions are formulated, chat bots provide the answer based on keyword research. Therefore, a chat bot’s ability to interact with a customer is typically restricted to straightforward requests.
A significant part of voice bots is derived from text-based chat bots. The most notable advancement is in Natural Language Understanding (NLU)-capabilities that allow software to match the traits of human speech with relevant actions while extracting the specific objects and figures from speech. New machine learning platform help to improve recognition accuracy and enable computer speech sound much like a human.
Latest voice assistants from Google and Amazon combine both bot and speech technologies. Take Google Assistant, which is a two-way conversational voice-activated device and performs day-to-day tasks like booking an appointment. Amazon Echo, a smart speaker, can provide information on news, sports, daily updates as well as play music by connecting to an intelligent AI-based Alexa voice service.
Then there are voice assistances like Siri and Contana for various smartphones that we use on day to day basis without even realizing that it is also a sophisticated bot.
A 2017 Deloitte study of 450 different contact centers revealed that customer interactions over a voice channel would reduce by 17% by 2019, but, will remain significant at 47%, that is three times higher than chat, web and email, the next largest interaction channels.
It is predicted that implementing self-service, chat bots, voice bots, and automation will not reduce the agent headcounts. Combination of technology and infrastructure is needed to support voice-based services in the contact center. As the competition for automation is higher; today’s IVR systems are undoubtedly going to be replaced with voice bots. If this happens, more agents are required to handle the increasing load of complex tasks.
Nevertheless, bots are becoming common in businesses to provide chat-based services round-the-clock with reduced costs. Statistics from contact center software shows that the average price of customer service via phone is nearly €35 to €50 per interaction, while, the text chat costs are much lesser and is roughly €8 to €10 per session. These chat bots can stay online longer and help customers with necessary information.
IoT focused bots are on the way to revolutionize EAM (Enterprise Asset management), MRO (Maintenance, Repair, and Operations), and FSA (Field Service Automation) markets.
Interestingly, many businesses are revamping their support desks with the new whiff of AI voice-based services. However, there are some challenges before it could become mainstream. For example, integrating traditional telephone systems to voice-bot platforms is not easy. Then there are issues related to data privacy and compliance. With voice bot, outbound calls in the contact center seem to be a better fit as the agenda is known, but, it is hard in case of inbound calls due to the evolution of unknown conversation scenarios.
Things are changing as we speak and several companies are helping reshape the traditional helpdesks. Voca.ai has recently introduced telephone voice bots for financial call centers. IBM also has made a lot of progress in developing simpler bots.
Voice bots are still in the early days for this technology, particularly in contact centers. While these might not replace agents and IVR anytime soon, it is bound to happen with a mix of technology and humans.
The short answer is, it depends. Every business has different operational challenges, and as one size doesn’t fit all, there can’t be a generic answer to this question. Book a free consultation with our bot development experts to find out if a bot is a good fit for your business or you are better off with an old-fashioned contact center or IVR.
The post Can Bots replace call centers and IVR? appeared first on OCDLAB.
]]>