Remember that scene in Iron Man 2 where Tony Stark takes out his phone, puts some content on the nearby TV screens and then controls the content playback with his phone?

Wouldn’t it be nice to push to or pull content from one device to another like that?

Up to now, the web development problem has been how to get the content we have on the desktop/laptop onto a small screen like a phone or tablet. And that has been a big task. It is a difficult thing to do and hard to do well. This is an important step and we are in mid-stride. But along the way the dynamic has changed to some degree, and not many people are really talking about this change.

Today, many people have not just a phone and desktop/laptop PC, but they also have a tablet, a wrist device (watch, fitness tracker, etc.), an Internet enabled game console, and an Internet enabled TV. All of these devices can be used as discrete islands with which to interact with content, but the real power is when we can combine all of these discrete islands together into complex chains of interaction.

Between these islands are gaps and we need to start discussing ways to bridge these gaps.

Each device that we want to transition to has a gap that must be bridged in order for content, and with it interaction, to flow. The flow across these gaps take two forms: push and pull.

A push gap is when I have content on one device that I want to push to another device. Take for instance the Iron Man example, Tony Stark had video that he wanted to push to a TV screen. This is something currently being worked in through a number of technologies such as Apple’s AirPlay and Google’s Chromecast.

A push gap can take many takes many other forms as well. Say I want to share a url with someone or I want to simply take the music I am listening or TV show I am watching and move it to another device. Perhaps you have a document you are editing on one device and now want to move from a desktop pc to a tablet so you can sit on your couch and proof read it.

That is a push gap at a macro level, but push gaps at a micro level exist as well.

A micro push gap may not necessarily span devices, but may only span applications. A common example of this is pushing a url from a read it later application like Pocket and displaying it in the browser. In the case of Android, this can be a pretty seamless operation via Android Intents. I “share” the url to my prefered browser, interact with the content, and then hit the system back button to go back to Pocket to continue with what I was doing. That is a well constructed bridge.

In iOS, I may, or may not, be able to open the url in Safari, and almost certainly not in any other browser directly. I may simply get trapped in a limited functionality webview. If I do make it to Safari, the route back to the application I was in is anything but seamless. This is a poorly constructed bridge.

What about external push gaps where another device is attempting to push some form of data to my device.

New Bluetooth LE devices are beginning to come online that have the ability to broadcast data that my phone or tablet can then receive and take action on. How will this work? Will this be built into the OS or will an app have to be downloaded in order to interact with this push signal to bridge the gap?

Considering the limited functionality available in browsers today, it is unlikely that they will be able to respond directly to this pushed data and heaven forbid if one of these devices would like to know something about you like your location or what direction are you looking at this time. A well constructed bridge simply doesn’t exist in the browser today. But perhaps a combination of native app and web browser could serve as this bridge, a synergistic flow between native and web dependent on the content and interaction that is required..

What about pull gap bridges? Today these bridges exist in things like NFC and QR Codes. Look at a pull bridge as information that someone would like to pull from you and they often require a bit of intentionality for both security and privacy reasons. For instance NFC is good for payments because you have to take your physical device, tap the reader of the requestor, and then exchange a bit of data, in this case payment information.

I haven’t even discussed a gap that desperately needs a bridge, notifications. Notifications, when used judiciously, are fantastic. But once I interact with that notification, I don’t want to have to deal with it again on every device I own. That is a poorly constructed bridge.

Our devices today are full of gaps, as designers and developers, we need to begin to identify and then decide how to bridge these gaps in a seamless and simple way. The tsunami of devices are already upon us and it won’t be long until our customers will be demanding these bridges. Unfortunately, the conversation still revolve around silos of data and interaction when we consider projects.

In your last project, did the conversation of seamless interaction flow come up? Did you consider how the interaction would bridge a native or web container dependent on what was best for the content that someone would need to interact with? What sensor data might enhance a person’s interaction with your data? How will I bridge some of these gaps?

Design today can no longer only take into account one mode of interaction. Instead it must consider what bridges it needs and how to cross the gaps in a multi-device world.

My daughter is in the eighth grade, and the school she attends has introduced a number of technology items this year. I think this is great and want to definitely encourage them for doing this, but I have a number of issues with the way this technology has been integrated, deployed and used.

Problem 1: No discernible strategy.

Somewhere along the line decisions have been made that simply seem to make no sense. The students are provided iPad mini’s, but use Dropbox for files and Google Apps for office automation applications. Sounds very fashionable, but not very practical.

Here are some of the issues with this. Now each student and teacher has to maintain at least 3 accounts (iCloud, Dropbox, and Google). Content creation into Google Apps on an iPad is a less than optimal experience. Of course you have no keyboard so data creation is complicated at best.

Possible Solution: Pick an ecosystem that covers your use cases and go all in. If you are going to use Google for email and office automation, then pick Android or Chrome OS. If you are going to use Microsoft, then pick Office 365 and Windows. If you choose Apple, then use iCloud, iOS and OSX. As soon as you mix and match you are actually using the weakest parts of each ecosystem.

Problem 2: No predetermined use cases.

It appears that each teacher and each student is left to fend for themselves on how best to use and implement each technology use case as it works for them. The issue with this is that it is often not an efficient use case and they miss huge potential use cases because they are simply ignorant of the capabilities of the technology.

Possible Solution: Iron out the use cases in advance, get faculty buy in, and phase out antiquated paper based workflows that introduce a good deal of cost and overhead that can easily be eliminated in a paperless workflow. Be consistent.

Problem 3: Fashion accessory versus tool

Technology is not a fashion accessory. Technologies are tools in a tool box. If you treat it like a toy, it will be used like a toy. It seems that iPad’s were chosen not due to how well they fit the use cases, but it was because parents want the kids to have iPad’s.

Possible Solution: Examine the use cases and apply the correct hardware and software to fit those use cases. Treat the technology like you would a spiral notebook, pencil, and protractor.

I think it is great that technology solutions are being introduced at younger and younger ages, but these solutions are treated as non-essential games, luxury items and applied in an inconsistent way matching few if any use cases, it will be hard to sit back and honestly say that these experiments in education failed later.