Date or Tell – An Uncomfortable Dating App


See or tell is a “getting to know you” app that aims bring two anxious daters closer together by exposing the personal content on their phones.


Phones are more and more intrusive these days.  It’s hard to go an entire meal without someone checking their phone for facebook posts, or texts, or the latest instagram photos to fill their feeds.  At the same time as we parade these things around in public, many of us fear what would happen if our phones got into the wrong hands.  I’ve known several people who react quite intensely when I pick up and start using their phones.  In fact, at this point, holding someone else’s phone feels foreign.  The content on their phone might be vastly different from the content on my phone.  The catch is that much of that content is considered private.   When we take photos, often we make the implicit assumption that unless we explicity show that photo to someone (or post it somewhere), it will only ever be seen by us.  That morning selfie of your bedhead.  The shots you take to see if that pimple is receding.   The videos of you playing Hey Ho poorly on the guitar.  They’re all there, and they’re all hidden from the world.

But what if they weren’t?


The motivation left the app a bit wide open.  What information did we want to expose?  How did we want to frame it?  And technically how would we do it?  Well, turns out the first two questions become moot once we started playing with some technology.

First attempt – Voice Recognition

Google’s WebSpeech API looked promising for recording conversations.  Our initial idea was to record, and when the app picked up a keyword, it would intrude into the conversation, offering information about that keyword.  It wasn’t quite in line with sharing secret information, but we wanted to tie it into personal data.  So if I said “mom”, the app would read my last text message from my mom out loud.

Turns out the WebSpeech API doesn’t’ work on webkit! Which meant we were dead in the water with this idea, because after a full day of searching, I couldn’t find anything that would fit our needs.  So, time to scrap idea #1.

Second attempt – People Search

Our next idea was to gather information about each of our users by scraping the web for information.  It sounds relatively easy, but in practice there’s no good way to do this.  Unless you want to ask your users to log into a bunch of different accounts, much of the information on the web is actually pretty private.  Facebook profiles in particular are pretty hard to get at unless you log in and happen to be friends with the other person.  There’s twitter, sure, and instagram, but that information is already so public that it doesn’t really get at our point.

I looked into people search API’s and found a few sketch examples – Pipl and Full Contact.  Pipl has a demo where you can enter a person’s name, and it spits back some basic information – date of birth, jobs (looks like it was pulled from linkedin), education (again probalby linkedin), addresses (this info exists on whitepages), what look to be twitter followers.  Not bad, but not free.  Full contact was no better.  So, it was starting to look like people searching was out, too

Third (and final) attempt – Photo Sharing

So after scraping ideas 1 and 2, we landed on sort of a game, where users could choose to answer a personal question, or share some private information from their phone.  This again proved problematic since iOS doesn’t allow apps access to the root file system, thus most private information is actually off limits to apps.  This makes sense as a security measure.  You don’t necessarily want any random app having full access to your photos, or your text messages.  Apple provides hooks in which you can access some of that data, but it requires direct action from the user.  For example, for the app to access a photo, the user actually has to select a photo from the iOS photo selector screen.  Which meant randomly grabbing random photos from the user’s camera roll was out.  So were text messages.  It’s possible to access someone’s private calendars, but that was less exciting to us than photos.  So for the sake of building something, we decided to go with a less impactful model of our game See or Tell.

The Build

The underlying architecture is fairly simple.  Two phone’s connect to a socket server, and enter a specific room.  Once in the room, the server will keep track of the game state and send messages to the clients when they need to update.  This keeps both phones constantly in sync with one another.


Alice and Bob are on a date.  They both open the app and enter room Qwer.  They are greeted with level 1 questions.  Bob ask’s Alice to show him her last google search.  Alice, knowing her last search was ‘what do bed bugs look like’, decided it might be a bit radical to share that on a first date, with someone she just met.  So she chooses “I won’t answer”.


Alice is then prompted to select a photo from her phone and share it with Bob.

They both wait a spell while the photo is sent between phones.


And when the photo is ready, it pops up on Bob’s phone.  Who can then close it and continue the game.  After this round, the questions flop and it becomes Alice’s turn to ask Bob a question.


And that’s it!

Looking forward

Obviously this app is not where we want it.  We had much grander ideas about sharing personal data, but ran into some annoying technical limitations that causes us to pivot quite a few times.  But even with this format, there are ways to make it more impactful.

  1. After a user shares a photo, the other user can decide if they accept that photo as ‘personal’ enough.  If, for example, Alice shared a photo of her cat, Bob could decide that the photo didn’t measure up to the level of intimacy as the question would have brought about, and ask Alice to either go back and answer the question, or share a more personal photo.
  2. The same can be done for when the user decides to answer a question.
  3. Add more data to share – i.e. calendar data, access metadata on photos, geolocation, steps, health information from healthkit.  When the user doesn’t want to answer, their phone will select a random type of data to share.
  4. UI and UX development.  Right now it’s two screens and a few buttons and p tags.  And simple is good, but it needs some design to spruce things up.
  5. Is there a better way to share a photo than sending an entire base64 string to the server, then back to the second client?

Leave a Reply

Your email address will not be published. Required fields are marked *