Webview hidden costs
Webviews seem to be an easy way out for when resources are short and you already have a responsive web page. Seems like a no brainer for those non-critical pages like terms and conditions, or for whole flows that we know we’ll never get enough budget to handle in native coding. But there are a lot of little problems that can make the user experience quite awkward. Below I’ll be discussing the most common ones, according to my experience.
Menu
Responsive web pages usually contain a menu near the top where you can navigate to different parts of the web page. This is a two fold problem, first because from this menu it’s possible to reach any place in the web page — including screens implemented fully in native. And second because each webview in the app should be limited to a single flow/funnel.
Also, it ends up pushing your CTA down the fold.
Headers and footers and big logos.
Native apps have their own headers, which are called navigation bars. So imagine having both a navigation bar and a web page responsive header. Not very useful, and will take quite some space, in some cases consuming all the “above the fold”. Web desktop designs love big logos, and they’re usually carried over to their responsive designs. The CTA is then pushed a bit further down the fold.
And footers, well, native apps don’t have them. It’s a convention, but I have never seen one in a full native app. They could be added, but nobody does it. Don’t try to outsmart the crowd unless you really know what you’re doing.
In some extreme cases it’s even worse because some of these elements are sticky, effectively reducing your big expensive 7'’ screen to a 5'’. Well, that’s if you started with a big phone anyway.
Don’t try to outsmart the crowd unless you really know what you’re doing.
GDPR banner
Who knew that native mobile apps used cookies to track users? Hmmm. Well, less pixels for the real stuff.
So many elements pop up on the top of the screen that we can’t even find that CTA anymore.
Navigation bar
The native navigation bar is supposed to tell the user at all times where he is, and while navigating back and forth this is an inexpensive helper, specially because neither the web address nor tab title are going to be visible anymore. It is totally possible to implement communication between the Webview and the native code to update the navigation title, but that’s often overlooked or downplayed.
Back button
This was supposed to be an easy one, but somehow I have met more cases of bad rewritten history breaking the back/up button behaviour than I expected.
Confirmation pages and end of flows
In a lot of cases when you reach the last screen in a flow there is some state that is changed in the backend. When native developers implement that last page it’s not uncommon to trigger some kind of mobile database update, so there’s no outdated information while the user navigates throughout the app. However, if the last screen in the flow is not native you’ll either have to integrate the javascript with the native code to trigger such events, or risk showing stale information.
Session management
This is an easy problem to explain, and not that easy to solve. Basically, it means that if the user logs on the native view, he shouldn’t have to type her password again when going into the webview. It means that we have obtain session keys from one domain and convert them to the other while doing some sort of invisible, seamless new login. Sounds easy, but it’s guaranteed to give you a handful of annoying issues. In some cases the user is allowed to login first in the webview, so it’s necessary to transfer the session in the other direction as well.
Kind reminder: don’t store passwords on devices if you can avoid. They will make for a lot less effort for solving this problem, at the cost of being less secure. Even storing them on the keychain can be argued to be an obfuscation approach. See how gmail deals with it on https://android.stackexchange.com/a/29195/135337
Location permission
This one is more common than it should. If your project needs location services both in the native code and in the webview the user will need to authorize it twice.
Bugs
If any bugs surface on the iOS’s webview you’ll probably need the frontend developer to debug it. The downside is that he can only do that from a computer running OS X.
Is there a better way to trigger the OCD in your user than having different screens with different button/typography styles?
People won’t wait for the page to load before interacting with it
Web pages are slow compared to native apps, no news here. However a good practice is to block the screen with a loader so the user can’t interact with a partially loaded screen. I swear, I do that every time I have the chance. Then you need to add a timer in case it never finishes loading, either because of network timeout or other issues.
A note on screen loading times: in the ideal case where the data is locally available from the phone’s database or internal files the user would be able to see the full screen loaded much in less than 100ms after an action, even if a db query is involved. As a reference UI transitions on mobile apps tend to last about 300ms, but that’s an intentional delay to make the experience better. And they can’t be replaced by a loading animation.
UI consistency
There are rare projects where the design style is uniform across different platforms. If you’re in that situation consider yourself a lucky person. Otherwise, is there a better way to trigger the OCD in your user than having different screens with different button/typography styles?
These are not the only cases though. Can you tell me what’s the point of having 2 crosses on the following screen?
The problem with hyperlinks is actually not what they do, is how they look. Unless they’re fine print and you don’t want people to go there, transforming them into a button is the most decent thing to do.
Hyperlinks — can you hit them?
Mobile guidelines say that anything that is tappable must be this or that big. Android states it should be at least 7mm x 7mm, or the “thing” will possibly be too small to hit safely. Apple has similar requirements for iOS apps. And browsers provide augmentation so it’s actually easier to hit those targets, while mobile apps don’t. And google also has similar guidelines for web pages with touch screens: https://developers.google.com/web/fundamentals/accessibility/accessible-styles.
Bottom line, they worked very well for many years when people were chained to their mouses. Unfortunately they don’t play well with touch devices. The problem with hyperlinks is actually not what they do, is how they look. Unless they’re fine print and you don’t want people to go there, transforming them into a button is the most decent thing to do.
Hyperlinks — please don’t leave my app!
Actually I lied. Hyperlinks can be a problem depending on where they lead to. It’s not uncommon to see a few of those that lead us to a different domain! Your native developer can control whether those links should be blocked, allowed inside the webview or launched outside the app in a full blown browser. There are cases where each one of those is the most appropriate, but getting all the rules right can be a headache.
Actually I lied. Hyperlinks can be a problem depending on where they lead to.
Banners to install the mobile app
It happened to me in one occasion where the responsive page had a banner to install the mobile app. As a consequence, when we displayed a Webview inside the app we could see an invitation to install the app we were running!
Fortunately we had a strong team that caught and fixed it before going to production.
Credits for stock photos:
- Girl with Phone Photo by Sarah Diniz Outeiro on Unsplash.com
- Money Bills Photo by Niels Steeman on Unsplash.com
- Puzzle Photo by rawpixel on Unsplash.com
