The Android team at Orion Labs has been using Tuple for a few months now. Our team is distributed across the country and using Tuple has really helped synchronous connections on the team. I thought I would share a few simple tips/tricks to get the most of the experience.

Tuple is a remote pair programming tool. It allows for voice, camera, and screen sharing. But the magic sauce is that it allows for remote control too. If you used Screen Hero back in the day, or more recently the remote control tools in Slack then you may already be familiar with this concept. Remote control allows both parties to control the same computer, specifically both supply keyboard and mouse input. So both people can trade off “driving”. This makes it really great when one person has an idea during a pairing session. They can quickly hop in the driver seat and type out their idea instead of having to communicate it word-for-word. If you’ve ever tried to remote pair without these feature you know how frustrating it can be.

Even though I think Tuple is great, here are a few tips I’ve picked up over the last few months, including a few Android-specific ones, that should make the experience even better.

Out of the box Tuple will default to 4k resolution. This is probably too high for most people. I have my resolution default to “High (15 in. Retina)” (talk about knowing your audience) since I mostly pair on my MacBook without an external monitor. This is the “client” resolution. So if I’m pairing with a “host” with a 4k monitor, Tuple will down sample the signal to match my settings. I’m not sure how things work in reverse. If I’m hosting from a 15 in. retina display, I assume the client is stuck with a max resolution equal to my 15 in. display. This helps cut down on wasted network bandwidth.

Next, I setup a keyboard shortcut to enable and disable the microphone. Tuple lets you set this from the preference pane. This makes staying in the flow much easier with no need to regularly pull up the Tuple pane to toggle a mic button. I assume Tuple is smart enough to know the mic is off and not try to send an empty audio stream. So muting yourself when not talking has the added benefit of reducing network traffic.

This is a remote pairing problem in general, not specific to Tuple and I am as guilty as the next person of this: Trying to call out code by encircling it with the mouse. Wiggling the mouse around to highlight a block of code or other part of the screen is guaranteed to confuse the other person. Even the best remote pairing tools on the fastest network connection will probably not capture enough of the mouse movement frames to accurately represent a mouse pointer “lasso”. Tuple has a bubble tool for pointing, but this only helps the client call out something to the host. The host can’t use this tool to call out something to the client. For a host to call out code I suggest just highlighting it. I have also started using a mouse highlighting tool. This helps the “navigator” keep track of where the “driver” is clicking, regardless of whether the driver is the host or client.

As of this writing Tuple is only available on MacOS. So this next one is Mac-specific. Turn off all OS-level animations. This includes my least favorite: minimizing items to the Dock. These animations just don’t translate well across network connection and end up looking janky and distracting to the client.

As the host, you are exposing your whole computer to the client. Unlike Google Hangouts, you are not given the chance to share only one window. So you should close any other programs that might be private: email, chat, browser tabs. I even turn off MacOS notifications. Because Tuple can share CMD + TAB input, it’s easy to accidentally switch windows as the client into the host’s other programs. I go one step further and re-open the browser in incognito / private mode so that I don’t leak browser history. I personally don’t use my work machine for personal stuff, but I know that a lot of people do.

Tuple can be a little finicky when the host has dual monitors. So we’ve taken to verbally establishing at the beginning of the call that we are both seeing / sharing the same display. This helps avoid confusion where both people are looking at different screens but thinking they are looking at the same screen.

The first Android specific tip is again related to screen resolution. Our team uses Android Studio for development work. When the host has a large monitor, it can be difficult for the client to see the small font. Sadly the only out-of-the-box way to zoom the Android Studio editor window is with two finger pinch/zoom. I’ve found that this doesn’t translate well through Tuple. I think for this to work the host would have to have their trackpad settings configured to match the client. So instead we have setup on all of our machines the same two Android Studio keyboard shortcuts. We set CMD + CTRL + Z and CMD + CTRL + X to zoom in and out of whichever editor pane is open.

Sadly there is no way to change font in other UI panes within Android Studio.

Lastly, we use Vysor extensively on the Android team to view our physical Android devices on our monitors. It is really helpful during our demo days, when we present new work to the whole engineering team. We’ve found it equally useful when remote pair programming through Tuple. The client driver can operate the host’s physical device, through Tuple. Again, be careful of privacy concerns here. The client has full control over the host’s phone. We usually each have a work-only phone that doesn’t have any personal information / apps on them for this reason. An emulator will work too but you are asking your machine to do more work this way: Run Android Studio, an emulator, and Tuple. Things can slow down much faster this way.

We will continue to use Tuple to get great work done at Orion Labs and we’ll learn a lot more in the process. Tuple just rolled out a free trial option so you can give it a try without committing.

I was not paid or asked to give this review of Tuple. I just like their stuff.