0

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 at 20:27
  • Yes, and it could be either in a browser or native app. – eileenwong Aug 21 at 21:11
0

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!

  • Goodness! Loads of great points you made. I appreciate your time and experience on this matter – eileenwong Oct 3 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

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.