http://npr.github.io/responsiveiframe/

iframes + responsive design == awesome apis

Dion Almaer
Ben and Dion
Published in
3 min readApr 18, 2016

--

When you work on something, you often talk about what is broken and what could be better. We are reeeeeally good at doing that in the Web community, partly due to the fact that we see how the sausage is made thanks to the transparency of the standards work, and the evolution of popular frameworks on Github.

I mentioned how one of the great features of the Web is progressive rendering, and the huge win users get by being able to see and consume without having to wait for an end point.

Another feature that I feel like we take for granted is the <iframe>, in fact we often malign it. We think about iframe busting. We think about the poor running content (often ads) that are running in there. We see weak user experiences and we blame that poor <iframe> and forget about the good that it offers as a tool in the toolbox.

We took the poor frame, enhanced it to be an iframe, and then went even further with seamless iframes in the hope that it would give us something of a component model for the web. We can do better, but it sure is helpful.

Glueing with iframes

I was using a website the other week, and it was a typical enterprise glue effort that took youtube video, and a Q&A up-voter application and put it together to do the job. All of this was done without the need for YouTube or the Q&A system to know about each other.

Isn’t this API design at its best? As “software eats the world” we think about the complex services that we are able to place behind an API. Rich payment systems? Stripe has you covered.

The foundation should probably contain endpoints, but it is nice to go up the stack to deliver UI functionality to boot.

Connie Chan is an old co-worker and friend, and as a partner at a16z she spends a lot of time working in China, and deeply understanding it. She has some great writing on the context there, and how the US media often doesn’t get the translation quite right.

With the buzz around chat bots these days, she noted what they look like on WeChat:

It doesn’t make sense to be limited to text interfaces, and why would we be? As soon as anything non-trivial is needed we can take over the UI to put a user in a nice flow. What better way to do this at scale than via a WebView via native, or an iframe on the web?

Responsive

When you are ready to show a user a richer UI, you need to consider the variety of screen sizes and capabilities. The web has had to handle a huge variety of form factors from its inception, and with @media queries it has gone from strength to strength.

With the advent of responsive design, you are able to build one UI API that can handle a huge variety of host interfaces. This is great, as the host can control the size of the iframe and responsive takes care of the rest.

We have voice, chat, VR, AR, and a host of new technology coming our way. The future isn’t set for those platforms, but if the web can be a part of it, you can build experiences that can fit right in.

In the past all software grew until it became an email client. I think that we are seeing that apps are growing until they become user agents.

Invest in a great web experience and you can help users no matter where they are coming from, and where you are being hosted.

--

--