1

Some context, we are using a third party authentication platform where ecommerce sites can choose to display this platform within an iframe during their checkout process. We have media queries that detect the iframe size and thus would tell the site which size/screen design to display. The problem is, sometimes and we do not know for sure why atm, the screen will appear cut off within the iframe. Attaching image for clarity. The user is unable to scroll or drag the screen to get to the CTA and will feel compelled to abandon the transaction.

Now, we feel strongly that this is a technical issue, but I am still being instructed to provide a design (visual) solution(s). For example, adding in directional arrows to the UI so a user can still navigate in the case scrolling is not enabled. Has anyone ever had to deal with something like this? Any advice for designing or implementing iframes?

enter image description here

Thanks!

  • Your image suggests a mobile application, correct? – Andreas Mehne Aug 21 '19 at 20:27
  • Yes, and it could be either in a browser or native app. – eileenwong Aug 21 '19 at 21:11
1

It looks like a responsiveness failure to me.

The result appears like a technical glitch - which it is, on the device surface - but the first step toward a fix may lie in more explicit UI spec instructions on dev implementation, which I'll get to.

An iframe is essentially a window to some other content embedded within a window.

A good and frequently used example is the (usually small until expanded) map view within applications like Yelp, OpenTable (gastronomy) or Strava, Fitbit (sports), or even Uber, where the map that shows you nearby available rides is critical.

These maps are typically fed by an external service from Google or Apple (you can typically tell by their graphics), which is why you need to tell you device to "allow tracking my location" or so. Because the apps I mention need to display other dashboard style information alongside the map content, their UI designers will assign a carefully calibrated size (W and H) and location (X and Y) to the iframe 'hosting' the map. This is strictly all that's required. The iframe becomes a portal to the portion of the map of interest to the app's purpose (with the surroundings acting as 'mask'), but within the iframe you can usually pan, zoom and scroll. And, of course, toggle the map to full-screen view and back.

In-frame scrolling is standard behaviour of iframes - it should not have to be enabled as such.

Iframes are typically implemented responsively - provided the front end is done well: As the iframe loads it 'asks' the target device How tall and wide are you? and adjusts its size and location accordingly. Perhaps width is not defined in absolute pixels but by equal left and right padding, presenting you a proportionately wider portal on a larger device. Or at a more abstract level by sticking to a column layout. This is essentially what you describe; however I'm not sure these rules were actually heeded. A few well-placed nagging questions may shed some light on that matter.

https://material.io/design/layout/responsive-layout-grid.html#

If an iframe was dimensioned in absolute terms, and those absolute terms were based on a larger device, perhaps even desktop browser window, it will anchor its top left corner to the specified X and Y positions on a smaller screen, but overshoot the available display zone towards the right and bottom, rather than adapting.

Failing all other approaches you could handle this by an explicit instruction above the iframe to use gestures to pan or zoom to the desired content (if those gestures are recognised) but needless to say that is extremely poor UX, which to me calls the whole business model of using a third-party offering via iframe into question.

Make the product manager / owner your ally - trust me, I recognise push-back situations like that from a distance! A third-party iframe, if that's the way to go, has.to.work flawlessly.

Now, in terms of due diligence, be sure to include explicit specs in your UI documentation or comp - or ask the UI designer you collaborate with to do so if this isn't your core responsibility - to heed responsive or adaptive iframe sizing. You can always add a few concrete examples by researching the smallest and largest of the most common smartphone and tablet screens - iPhone, Samsung, etc. - and make a visual representation of the problem. Essentially, and this is essential to push-back politics that must not tailspin into blame storming: We as designers need to articulate in our specs to the developers which undesired UI effects must not occur, i.e. iframes with 'blind zones' as per your example above. The onus is squarely on the developer to figure out how to build it. Your UI spec may need to be more explicit in terms of iframe behaviour rules - and that will help convey to the technical team that you mean business. Dev's, in my repeated experience, do respond well to design intent presented with purpose and precision.

Your case is further complicated, of course, by not being a map, which you can zoom and scale freely, but a canned third-party form of a given (and likely fixed) size. Do you know what that size is - esp. its width? With that, you might be able to devise scaling rules in your spec. Let's say you find that the rightmost 15% get cut off on most devices. In that event you could ask the devs to put in a scale factor expressed as a percentage, until the form fits full-width without lateral scrolling. It's hard for a forum audience to pursue this further without more detail on the specific content. Good luck!

| improve this answer | |
  • Goodness! Loads of great points you made. I appreciate your time and experience on this matter – eileenwong Oct 3 '19 at 0:52
0

Using an iframe to load critical information or action buttons would lead to such issues, whether it is a third-party screen or not. But, that is an implementation issue (and so is the solution) so, I will focus on what could be done to improve the user experience.

1. Capture data from the iframe and load it inside the app

This is the best option, in my opinion. I have seen many apps do it. They pick the relevant data (fields, text, buttons) from the iframe and show it on an overlay. That means, if the HTML successfully loads, the UI would work no matter what happens to the CSS or the JS code. The iframe just stays in the background and isn't visible to the user. The other benefit to this is continuity as an in-app view would always look more organic and seamless as compared to an iframe

2. Have an in-app button that allows the user to reload iframe

There is a possibility that you might not be able to do that during a transaction but if it's possible, do give the user that control. It allows them an alternative action and some indication that there might be a possibility of fixing the problem rather than having to cancel the transaction.

What if this is happens on a mobile browser?

That's a very unfortunate scenario. The solution to this is mostly technical so I can't help with that. I guess adding a scrollbar would be a temporary workaround

| improve this answer | |
0

From a technical standpoint, assuming this is a web application, I feel this would be easily fixed with a max-width: 100vw. It looks like you need to restrict the width of the iframe to match the viewport and also need to remove any margin/padding so it spans the full width. The iframe itself should handle any scrolling required to view overflowing content as that is the entire point of an embedded frame.

From a UX standpoint, you should avoid an iframe if at all possible. Generally it is better to redirect the user to the third party platform to complete the required flow (especially on mobile) and then redirect back to your application once completed. Most third party integrations should allow this.

While this may seem a bit counterintuitive at first as you are redirecting traffic away from your application, it does have a few benefits. Firstly, the UI will utilize all of the users available screen space rather than being squashed into a tiny window. This will lead to less frustration from the user as they will have to scroll less and will benefit from a more familiar UI. Another benefit is that they can see the URL change to a domain that they recognize and trust which will make the user more comfortable proceeding with the transaction as it is much more likely to be secure.

| improve this answer | |
  • Hi James, your UX points are all valid! While I myself agree that a full redirect seems better, when testing our application, users seems to have a better experience with the iframe because they don't always look for those subtle cues such as the url or even our logo (we are financial giant) albeit small in the corner. So just the feeling of getting redirected may be alarming to them. That said, merchants are able to choose redirect or iframe, although some entities such as Visa and Mastercard strongly suggest iframe use. – eileenwong Mar 3 at 20:38
0
  1. You can make inframe responsive it's like load website into mobile app right? so I think best practice for solve this problem is make it responsive
  2. Yes for fast resolve you can add scroll top to bottom and left to right
| improve this answer | |
  • Yes, I believe contents in the iframe can be responsive which is why we were so frustrated with this problem. I believe my developer was able to solve this issue by tinkering with the absolute position. – eileenwong Mar 3 at 20:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.