Hearing the words "enterprise app" usually strikes
fear in the heart of any adept app user. Will the navigation structure feel
like something from 2010? Will it look like a website from 1995? How hard will
it be to use? You know you'll have to use it regardless, but you know you won't
want to use it more than is absolutely required.
Don't let these fears come true with your enterprise app.
Here are a few of the best ways to ensure your enterprise app is up to par.
MAKE IT BEAUTIFUL
Enterprise apps are usually required for employees to use,
and the visual aspects can often be deprioritized since users will have to use
the app regardless of its general appeal. It may be unnecessary, but putting
extra attention into how the app looks can do a lot for your brand internally.
This could be through following the latest design language from Apple or
Google, which are fairly extensive and can help your app feel more intuitive.
Also, whether users see it as battery-saving or just the
cool, new visual style, the demand for dark mode is growing. As more and more
apps adopt these crepuscular themes, apps that only offer a bright white theme
will look out of date.
GAMIFY ENGAGEMENT
Gamification has become a buzzword that many don't fully
understand. When properly gamified, an app deepens engagement by offering
implicit and explicit benefits from more frequent interactions. If you show the
user how often they are doing a desired task and how this compares to the
average, you imply that others can see their behavior and give them a baseline
to compare themselves to.
his can be a way to motivate users to take action more often
and use their competitive nature to help motivate them in ways that are useful
to the business. Providing milestones or checkpoints to reach also helps users
understand which areas they still need to complete to finish a task or
workflow.
MAKE IT SOCIAL
Another form of direct engagement is to allow users to
interact with each other through your app. There's a joke in app development
circles that every app becomes a chat app eventually, but there can be some
truth to it.
Allowing users a way to connect with others at the exact
time they need to without needing to switch to another app can be extremely
useful. It probably doesn't need to be as full-featured as Slack, but having a
way to send quick feedback on something in the moment can help keep users
engaged.
MULTITASKING
With so many forms of communication, at some point, users will need to be able to reference the data in your app. Whether this is for sending an email, comparing it to a presentation or entering information back into your app, users will want to use more than one app at a time, so support for multitasking should be added as early in the development cycle as possible.
In addition, Apple will require all public iPad apps
published after April 2020 to support multitasking, so adapting your interfaces
to support this extra method will soon be necessary for some apps anyway.
KEEP UPDATING
From my years of experience building apps, one truth I've
learned is that apps are never done. The mistake some companies make is to
"let off the gas" once they complete a release and put off their
planning for six months or longer. This can be a detrimental mistake, as new
capabilities and standards are constantly evolving.
Tracking and prioritizing these ideas can take a fair amount
of time, so you end up going a year without any updates, which often is too
long. This can lead to rushing features out, which usually means they aren't
well polished, and it becomes a downward spiral of quality that is hard to
recover from.
SURPRISE AND DELIGHT
In the end, it's about exceeding expectations. Historically,
any app used for "doing work" has pretty low expectations from users,
so it shouldn't be too hard to do better. This may be by adding some subtle
animations or transitions in the standard workflow, integrating with other apps
on the phone or allowing exports that can be quickly emailed for review.
Taking location into account might help you suggest
different tasks based on where they're at or the time of day or month. Little
things like this may seem inconsequential compared to building an augmented
reality experience, but dozens of small positive interactions can add up to a
much bigger benefit than you might think.
Enterprise applications are likely to become as critical as
B2C apps in the next few years, and businesses that take into account the
consumer mindset will be more successful and will drive more engagement with
employees, which could lead to a more productive and successful business. The
return on investment on both the bottom line and employee satisfaction would be
well worth any additional investment and can help set up an industry leader for
success in the hyperconnected digital age.
In
building some of the world’s leading mobile development products, Bottle Rocket
is embracing the reality that development tooling can evolve at the same rate
as the consumer solutions themselves. As users demand more personalized
experiences, product development teams demand new technology to drive
competitiveness.
Recently,
the linchpin that allowed mobile device providers control of the hardware and
software to create connected experiences for users has been removed. The
development landscape has now shifted to encourage open source communities to
contribute mobile advancements like pattern libraries, development frameworks
& backend SDKs. This has resulted in delivery teams now targeting both iOS
& Android devices with a single codebase.
To
that end, in 2018, we saw several cross-platform mobile development approaches
emerge as clear market leaders in the enterprise delivery conversation. React
Native, being atop this list, is seen as the arbiter of the latest
cross-platform movement. React Native is based on the powerful React JS web
library supplemented with APIs that ultimately connect to mobile device
operating systems. This paper will focus on the React Native library framework.
As
we accept business’ natural desire to expand mobility offerings we’ll explore
React Native as a catalyst for enablement. And as with many tools used by
growing businesses we’ll pinpoint opportunities to begin to transition to a
more platform-specific approach.
React
Native, as with most cross-platform tools, has a resounding focus on the
developer. While the end-user is certainly a consideration, it’s the developer
that benefits the most from the arsenal of hooks and bridges into a core layer
that sits on top of native software APIs. Those native software APIs then
communicate with the device to deliver memorable experiences for end-users.
It’s no secret that even the best React Native performance can only hope to
mimic native architecture. That said, if done well, the benefits to your
organization could come in the following forms:
MVP scope delivery: Assuming
your MVP goal is to test a focused business hypothesis, you’ll quickly realize
the value of being able to release to the full dual-platform market using a
single delivery team skill set.
Aggressive time-to-market
capabilities: Considering JavaScript and React JS development resources remain
plentiful, you can pair these core web competencies with solid mobile guidance.
Visual quality comparable to
native: Performance notwithstanding, the user interface APIs available in React
Native deliver satisfactory navigation & views. For the majority of
standard views most users will experience acceptable scrolling and swiping.
PRODUCT CONTINUUM
Indicated
above, React Native is an invaluable tool to kickstart your development effort
on a new app or validate a React JS web product in a mobile environment — a
catalyst for rapid prototyping is a great lens to view React Native through.
Building quickly, validating your enterprise hypothesis and iterating
aggressively can make the difference between you having a stronger quarter than
your competitors.
But
as, most of the software your company uses, you will outgrow React Native. In
fact, you plan to outgrow most of the technology you use in order to make way
for more suitable tools for the future. Plan for where your business is going
as opposed to where it is currently. On any company’s product continuum you’ll
begin with modest yet differentiating features so you can begin gathering usage
data. React Native is going to open so many doors for your company to build
quickly and maybe at a lower cost to deliver business value rather than rigid
ROI.
Figure 1 — Product Growth Continuum by Al Nolan Solution Architecture @ Bottle Rocket
As
your behavior and usage data begin to identify patterns, your feature goals
will harden and organizational processes will begin to form around your digital
offering to protect its future. We’ve identified key triggers to look for in
your organization and analytics to make measurable decisions about your
transition into core enterprise architecture, dev/ops & native development.
The alternative is to be blind-sided by overwhelming consumer demand which
could absorb any market gains achieved by your aggressive time-to-market
schedule or cost savings.
SIGNS YOUR ORGANIZATION HAS OUTGROWN REACT NATIVE
1.
A Mobility Practice is Born
The
mobile channel rightfully holds a significant place in most organizations’
hearts & minds. Many enterprise revenue targets are directly affected by
the success or failure of any group’s ability to navigate the mobility space.
The response: a mobile center of excellence whose focus will be about the form
factor and user and almost never the software itself.
The
experience required in these conversations — if technical — will be platform
focused. A seat at this table will require intimate mobile experience — leaning
more towards iOS/Android knowledge rather than web technology. In the event no
formal center of excellence is formed, mobility practice standards are formed.
How users interact with a brand through its mobile touchpoints usually garners
executive-level attention and requires a material amount of research. These
findings are focused on device adoption, device engagement, device
capabilities, device roadmaps, etc. The endgame being how do users interact
with their “devices” and where can our brand’s message exist in their worlds?
None
of this is to say that React Native contributors can’t be valuable in mobile
road-mapping but it would be their device/platform knowledge rather than their
ReactJS knowledge that rule the day. Organizational maturity around the future
of mobile demands a mobility practice with individuals steeped in form-factor
knowledge.
2.
A Bridge to Somewhere
What
makes React Native so practical and ultimately the most popular cross-platform
tool is its ability to translate JavaScript threads to Native threads through
bridge. Developers with a competency in JavaScript, being the most wide-spread
non-compiled language available, can now make the leap to React and then React
Native to begin writing JSX within hours.
However,
what’s natively available in React Native (polyfills like fetch, geolocation,
localized state management, console logging, etc.) may not always accommodate
your desired features at scale. You would then need to pay keen attention to
writing your own native modules so understanding the bridge and how it
communicates with JavaScriptCore (for iOS) and JNI (for Android) is critical.
Custom
features like video manipulation, voice integrations with Siri, global state
management, etc. are examples of areas where organizations have recognized the
need for enhanced capabilities, built their own native modules and contributed
them to the open-source communities. It’s easy to say that these are limits in
React Native but another way to look at it is that the core framework handles a
vast amount of use cases and enables — custom API creation through native
through modules for the rest. The limitation, though, is because of React
Native architecture custom code may need to be developed natively and bridged
because it can not simply run as-is at run-time.
3.
Single-threaded architecture limits concurrent features
Both
the JavaScript realm and Native realms are lightning-fast on their own. We all
have experienced countless apps (web & mobile) where either JavaScript or
Native performance has delivered surprise and delight. Although it’s only React
Native applications that rely on a pairing between both native and JavaScript
performance through the bridge mentioned before.
Behind
the scenes, your completed app can only ask the operating system to open a
single thread for reading and responding to all the JavaScript written. With
React Native and its single-threaded nature, communication between both realms
has 1 communication stream at a time.
Messages
between touch events, API calls and route to a subsequent view can get
entangled and even dropped altogether if not architected carefully. All things
held equal, even an inexperienced native developer can run into performance
slowdowns per feature but without the single-thread limitation, the user may
never be affected. This architecture requires special attention to be paid to
what features and functions are most important at any given moment because the
pipeline processing these requests is extremely narrow.
Presenting
a full-screen camera view may not seem like an insurmountable task for React
Native and by itself, it’s pretty manageable. But what if we want to add the
ability to swipe a screen view on top as well as adjust the opacity based on
how much far the swipe has progressed. Now we’re immediately challenging the
bridge to manage the camera view, x-coordinates of a modal as well calculation
of a variable to pass to a styling object. Keep in mind this will not break
React Native but it certainly doesn’t keep bridge communication over your
single thread to a minimum.
For
an app with minimal features whose goal is to prove out a very specific use
case, this will not be a concern. But as an enterprise grows and internal
groups begin to rightfully ask for features this pattern may become an
expensive performance hurdle to handle with React Native.
4.
Product market fit demands platform-based experience
Product
Market Fit (PMF) is the holy grail of product development. Eventually, your
users will demand a solid experience paired with a feature set that delivers on
your value proposition. This doesn’t necessarily equate to PMF. In fact, it’s
only the beginning. You want to address more than the product itself. The
market (defined by a feedback loop, revenues, competition, choice, etc.) will
begin to reveal underserved needs that will require quick competitive
responses. Your responses to these market gaps while still maintaining your
market share start to form your PMF.
As
this organic business pattern unfolds, the final key is uncovered: a targeted
customer experience. At the moment in which you can deliver on your brand
promise, create a healthy feedback loop and acquire new customers at will
you’ve reached the pinnacle of PMF fit.
So
where does React Native fit in? In software development, product solution fit
is the pattern of validating an MVP. An MVP is meant to gather data and prove a
specific business hypothesis by delivering the least amount of features. As you
begin to gather data you’ll want to make small measurable tweaks to your
releases. This is an enterprise’s optimal case for React Native considering the
resource investment around building a native practice may outweigh the value of
the information gained.
Once
you begin to gain traction, you must extend your delivery practice beyond
software into the relationship with your current & potential customers.
Today, the analytics & reporting tools required to measure & maintain
these relationships require complex library integrations that are better suited
for native experiences.
The
quest for PMF doesn’t end at development’s door. Product groups have to be able
to think primarily about the customer’s experience and not be hindered by the
risk of a library or plugin being unavailable for upgrade along the journey.
React Native relies on a significant number of libraries to access native APIs
in order to maintain its competitive edge. If any of these libraries are out of
compliance or not maintained it could risk the entire project roadmap.
Eventually,
Android users will demand an Android-specific experience along with
complementary features. IOS users will demand an iOS-specific experience along
with complementary features. Biometric integrations, payment, navigation &
routing, media access, etc. are all critical for immersive mobile experiences
yet have all had their share of implementation issues when it comes to React
Native.
5.
Platforms eventually demand different release cycles
As
you iterate and explore your product’s traction in the marketplace you will
notice bugs, fixes & feature opportunities on each individual platform. An
iOS improvement that is already an inherent feature in Android can trigger a
targeted release. An iOS-specific bug, unrelated to Android, should trigger a
targeted iOS release. Why is this important? Your single React Native codebase
-which had been an advantage up to that point — now requires a fork.
There
are certainly methods to target platform-specific upgrades but your development
organization now has to maintain a React Native codebase with custom iOS &
Android scripts or native modules.
Your
goal of carrying a small single-celled team of JS engineers now must evolve.
You now must consider an issue-specific Android knowledge base and track this
issue against industry best-practices. Will the issue be addressed in the
latest version of React Native? Will the issue persist as long as its native
code integrated with React Native? These are questions you’ll need Android
knowledge readily available to answer. And you must also do the same for iOS.
6.
Intellectual property concerns warrant core technology to be proprietary rather
than open-source
React
Native is open-source code. The libraries you inevitably integrate will be open
source. Your deployment tooling will be open source. Open source technology has
made huge contributions to software development at large and this is not a
claim that it is a pattern that is bad for business.
However,
even with the recent adoption of more open source tooling at the enterprise
level, your organization now has to manage the licensing, crediting &
contributions of these tools — publicly. If your enterprise, like an increasing
amount of enterprises, has the appetite to employ this practice knowledgeably
and responsibly then the open source concern is minimal at best. Just know that
each license of each library should now be reviewed with the same scrutiny as a
non-disclosure agreement or any other commercial licensing agreement.
7.
Performance efficiencies/advantages required at scale
React
Native, which is still considered beta, is a framework created by Facebook but
is now community managed. As the major contributors advance the APIs and tackle
reported issues they will release new versions on an unpredictable cadence.
This means that critical changes your organization may need may be reported by
you and others but fixed on an undetermined schedule.
And
when one set of issues is fixed, that new version may introduce breaking
changes to existing code previously addressed by in-house workarounds.
In
fact, it has been widely noted that libraries are regularly abandoned and run
the risk of no longer being maintained. A mature development organization can
address this phenomenon with forks of their own but it’s good practice for enterprises
to work with libraries that offer accurate, secure & predictable results as
often as possible.
CONCLUSION
Whether
its financial management software or customer relationship management tools,
your organization will have a tendency to outgrow its original intent. In
managing 100 receivables per month, certain software may be the perfect fit
whereas managing 1000+ may require an upgrade or a pivot altogether. Your
revenue will grow. Your teams will grow. And at the root of that growth are
customers demanding more and more custom experiences.
You
don’t want any software or its limitations to hinder you from thinking more
about your customer than the method you use to reach them.
At Bottle Rocket, we occasionally
take time out of our week to focus on exploring new technologies. We call these
“Hack Weeks” and they generally consist of small teams forming and meeting for
an hour or two each day to try out some new ideas.
In early December, we had a hack week around office apps that we called “Teemwork Makes The Dream Work,” a play on words that uses the Teem moniker for an extra level of puns. We had several teams explore integrating with Teem, and several that worked on other ideas. With Hack Week, anything is on the table! So let’s dig in to a few of the ideas we saw:
OFFICE TEMPERATURE TRACKING
Tyler Milner, one of our iOS Jedi, decided to dig up an old Rocket Science
project of his called BR Ice Box. The project observes the
temperature readings from the Bluetooth beacons around the office and stores
that information in a Firebase Realtime Database, displaying a list of all of
the beacons and their corresponding temperatures in a list. The main idea of
the original app was to make it easy for people to figure out the
warmest/coldest areas of the office.
For hack week,
he decided to build upon this project, extending the functionality to also send
the temperature readings to the Teem API. In the Bottle Rocket kitchen, we have
a large television that shows a list of meeting rooms and their current
availability. His goal was to also display the temperature information that the
app picks up on that screen as well, so people could get a sense for office
temperatures without needing to download or use an app.
Overall, I didn't get very far in my implementation of the Teem API since it took some time to write the code that executes the Teem API's OAuth flow. I did get the OAuth flow working, and was able to successfully get an access token and verify I could hit Teems API to get a list of room information, but I didn't have time to take my temperature readings and execute the necessary PATCH calls to attach my temperature readings to each meeting room.
Tyler Milner
Hack Week doesn’t require successful completion of the projects that are started, the learnings from the experimentation lead to more ideas. Next up was an experiment with using a keyboard within iPad apps.
KEYBOARD FUNCTIONALITY ON IPAD
John Davis explored using a
third-party framework to expand an application’s support for keyboard-based
navigation.
I believe great keyboard support sets apart iPad and Mac applications that feel well considered and accessible from those that feel preliminary. The need to discover efficient solutions and patterns to implement this results from two fronts: Apple’s allowance of iPad applications to run on Mac, and a drive to better support accessibility standards that require keyboard controllability.
John Davis
The framework John explored is named
KeyboardKit and is developed by Douglas Hill. The demo app highlighted
components, like tab bars and navigation bars, provided by the framework that
come with easy to use support for invoking buttons and navigation actions via
the keyboard.
As with most hackweek projects he was
short on time and not able to explore much more, but he found the framework
falls short in the same ways that Apple’s provided tools fall short. That said,
it helped him learn how simple it can be to add these interactions to an
application and provide a more complete experience to users.
SLACKBOT + ANALYTICS
Several weeks ago, a few Rocketeers
discussed the idea of using a Slackbot as an internal test bed for analytics
and user engagement tools. For Hack Week, Jason Brewer was interested in the
effort it took to develop a Slackbot and how feasible or successful this idea
might be.
I found that developing an intelligent Slackbot was as easy as getting an API key and standing up a Node JS server. Then I needed something for it to do so I grabbed several easy public APIs that returned nice JSON and connected them to key words the Slackbot watched for.
Jason Brewer
To bring in the analytics and
engagement element, he had the idea to just let users engage the Slackbot with
no context or information about its features and collect analytics on the
discovery of its ‘random’ features. Using the workspace we have as a result of
our partnership with Amplitude, he integrated an Amplitude package into the bot
and defined events to track:
User joined the channel
User asked for help
User asked for a clue
User ‘discovered’ a feature (by typing one of the key words that
triggered the feature response
By gamifying the interaction, he was
able to collect data from other Rocketeers who played with the slackbot. Few
people found all the features, but quite a few people participated and enjoyed
interacting with a rudimentary AI. He was able to collect data around which
features were the easiest to discover, and how the clues given by the slackbot
impacted the successful discovery of more features. This kind of analysis is
similar to what we see in our clients’ analysis, so it was nice to experiment
with a version of this ourselves.
Hack Week is a great time to explore
new ideas, and experiment with technology we have been following. We never know
where these ideas could lead, and if you any questions, or would like us to
explore ideas with you, feel free to reach out. [Link to contact us page].
When it comes to designing a
mobile experience, it’s easy to think users will be satisfied with something
that mirrors your website. That may be true, but it’s important to consider the
unique benefits of the mobile platform. Here are a few common mistakes we see
all the time in the mobile industry.
NOT BUILDING 'THE ONE THING'
The most important mobile feature for any given app isn't
usually surprising. Just ask a few users “What do you wish we could let you do
from anywhere?” The challenge is that this “one thing” can require changes
throughout the whole organization -- new APIs, new interface designs and maybe
even operational changes. Having a restaurant mobile app without mobile
ordering would mean that very few people would use it, and it could never have
much impact on your business. It may be the hardest feature to build, but if
it’s the right one, the return on investment will be more than worthwhile.
NEVER UPDATING YOUR UI
Humans are fickle. We get bored easily, and we want newer and
better, faster and more features. If your app still looks the same two years
after it launches, users could be enticed to try a new app. The design guidelines
from Apple and Google are constantly being tweaked and updated, and it’s smart
to keep comparing your app to them. Be sure to look for areas that could be
improved. As new features come online, you may want to rework your experience
to highlight them -- or guide users to the most popular areas. And with dark mode being
supported by both platforms, users will expect this battery-saving change from
all apps soon, and blindingly white apps will start being left behind.
IGNORING YOUR USERS
Everyone has an opinion, and sometimes the only thing worse than
users sharing them is users not sharing them. If the perception is that you
don’t care about your users, they will leave and never come back. Responding to
reviews is possible on both the App Store and Google Play, and this can be a
great way to engage with your users. It not only shows the individual that you
care, but it signals your empathy to other users as well. Sometimes users are
just confused, or they can’t find something in an app, but a negative review
can make it look like it’s not possible. A response from your team can help users
find what they’re looking for. You’ll never please everyone, but if you’re not
receiving any negative feedback, you probably don’t have any passionate users.
MOBILE ONLY
Mobile experiences are often the most-used experiences,
and some new services may be only available through mobile. This can lead to
frustrated customers who want to do the same activity through a web browser on
a computer when they have access to one. Instagram famously launched as
only an iPhone app and did not have a web experience for almost three years.
Even today, you can’t visit the website and upload a photo to your Instagram
feed. Instead, you have to use another service that accesses the API. Few
brands can afford to be this cumbersome for users, so think about what other
ways users will want to interact with your service -- and make sure your app
runs on those devices.
MOBILE IS MORE THAN APPS
Beyond just the mobile app, you must think about how users can
interact with your brand. Going back to my first recommendation of building the
right "thing" for mobile, you also need to think about the right
thing for other devices. What do your users want to do from their watch? What
about their voice assistant? If they have an iPhone and an Echo, how do Siri
and Alexa help build out their experience? With Car Play and Android
Auto, users can even interact with your brand from their car, but
their expectations will probably be different. Brands need to meet users where
they are going to spend the most time since users often already think of them
as always available anywhere, not just always available from their mobile
device.
TIE IT ALL TOGETHER
Mobile experiences are here to stay, and they will be a baseline
expectation for most businesses. Unfortunately, companies can’t always pivot
their business to be mobile-first overnight, so transformation takes time.
Hopefully you can avoid these pitfalls in the long term -- and keep them in
mind as you continue to center your experience around your users.
Digital transformation has become a hot topic as of late. Once you decide that your business needs one, how do you go about actually implementing the technology to bring your business forward? Here are three key ways that most businesses need to adapt for the digital age, and some technology that can help get you there:
Bottle
Rocket’s own SVP, Technology was honored last night at the annual Technology
Ball gala with the organizations first ever Women in Technology Luminary Award.
Amy was recognized as an exceptional woman in the field of technology who has
made a positive impact within her organization and/or the technology community
in Dallas.
A
“luminary” is defined as “a leading light who has achieved success in their
chosen field and who serves as a positive inspiration or influence to others. “Congratulations
to all the other amazing finalists for their accomplishments - you're all
luminaries to me,” said Amy in her acceptance speech. “Thank you to Bottle
Rocket for supporting my passion and vision, and for creating an inclusive
environment with many other female leaders by my side. And a huge thank you to
Technology Ball and SEI for shining a light on female technology leaders and
helping to inspire a new generation.”
Bottle Rocket is a digital transformation company that leverages a unique Connected Customer mindset to build technology-enabled solutions that propel businesses and delight customers.
