This was a project that was fun to build as well. The app was meant to be a cross-platform AirDrop replacement — people near each other could transfer files to each other without hassle. (This XKCD cartoon spoke about the pain of transferring files, and I couldn't agree more: https://xkcd.com/949/)

User Experience

So, the key to this project was the UX. Most people don't constantly have to transfer files on a constant basis. If they were expected to use a complicated system for their occasional use, they'd never use it. Again, the occasional nature of the use meant that it couldn't be an app or have a sign up page. It just needed to work.

IDs

One of the key parts of a file transfer is the identity of each client. Apple's AirDrop uses the user's ID which the OS has since it has access to it. However, since I was building a web app, an ID of some sort would have to be generated. What kind of an ID, though? The fact that the ID would usually be communicated verbally ruled out the use of letters of the alphabet because phonetically similar letters could cause confusion. On the surface, a set of numbers sounded like it would solve the problem, but it really didn't — a sequence of numbers isn't memorable, and when searching through a bunch of users numbered a certain way, it might mean the user forgets the number, or similar numbers might confuse the users. A search box would have to be introduced to help. Besides, numbers are just bereft of personality!

So, finally, we came up with a system that paired an animal with a personality trait e.g. “Adaptable Emu” and “Gregarios Magpie”. These are amusing enough to be memorable, and additionally have enough complexity about them to be unmistakable when communicated verbally. And, they had personality; a smile on a user's face is nothing to scoff at!

Localisation

Since it was a web-app, the system could potentially used by people in different countries. This could mean thousands of users at any given time, and a lot of searching for a particular user. However, the most common use case was two people sitting beside each other wanting to transfer a file between themselves. This could have been achieved using geo-location, but that would mean throwing up permission requests to the users. So, I found an ingenious way (if I may say so myself) to group users: by their local area network. It so happens that though users on a network might have different private IP addresses, their external IP addresses are all the same. So, I built the system so that it would ping a server, and get its external IP address. These users were then grouped together in the database. Only other users on the same network would show up for any particular user. More often than not, that meant only one other user. This meant there'd be the most minimal amount of searching.

Software Development

The front end was built with Elm. (The most wonderful web front end language I know!) The app uses Firebase on the back end, to register and group users. Owing to time constraints, I used Firebase Storage to act as the medium. Since Elm has no direct way to interact with Firebase, the app relied heavily on ports.

The files were uploaded to a not-easily-guessable path, for security reasons. They were also set to be deleted right after they were downloaded or after a set period of time.

One of the improvements that was planned was to use WebRTC to route the data, eliminating the need for Firebase Storage. The goal was to run this app with as little cost as possible because it was being offered to users for free.