VCU FileDrop
Sharing large files over the web simply
The approach
I started by chatting with a friend at another university who had built a similar system. I wanted to learn some of the problems I might encounter as well as what his users had found most valuable. I then began designing and building the system from the front end so I had an idea of how it would look and flow.
Once I had the front end built, I began wiring up the backend. I was able to skip most of the user management by attaching to VCU’s Central Authentication Service. Starting with the basic send flow, I built the form progressively so that users without javascript could send a single file using a normal file input. I then layered a more powerful javascript file upload system on top that uploaded files asynchronously so most users could attach multiple files to a single message.
Because I wanted users to be able to send large files to anyone, I couldn’t rely on the VCU authentication service for retrieving files. Instead, I created a temporary authorization “password” for each unique message and recipient. Recipients could simply click a link in the email notification they received to go straight to their file downloads. Alternatively, they could enter their email address and temporary password to get the files for a particular message.
I also added a management view so that senders could see a historical list of the files they’d sent as well as everyone who had downloaded them. For any current messages (see constraints below), senders could download or delete the files from the service. For fun, I also showed them how many files and messages they’d sent and what file size those files totaled.
Finally, I created a view for tracking overall usage statistics to help get a better idea of how the system was used over time. Because the system was constrained on storage (see more below), the first element on this page showed how much storage was used versus available. After that, I added elements to track overall and current usage, including recent activity broken down by day for the last 3 weeks, 2 months, and monthly views of the last year. For fun, I also added statistics tracking the averages and records for certain relationships (like files per day, file size, recipients per message and more).
Delight is in the details
Growing constraints
When I began building FileDrop, I only had access to a small VM with a total of 100 gigabytes of storage. Foreseeing that the system would quickly fill up since the intention was to send large files, I built FileDrop to store files for a maximum of two weeks. After that, they were automatically deleted.
I built in several failsafes to alleviate issues as they arose. First, recipients were notified in the initial email when their files would expire. Second, if (and only if) they haven’t downloaded the files, the system sent two additional follow-up notifications near the end of the expiration window — an initial reminder 3 days before and a final warning 1 day before.
In addition, when the system reached 75% of storage capacity, it sends email to several high-level admins who can either increase the VM storage capacity directly or look into any issues that might have arisen. When the system reached 95% of storage capacity (meaning 5gb or less of storage available), it automatically disabled the form for any new uploads and fired off more warning emails. The usage statistics interface also allowed admins to track usage at any time to make sure it was in acceptable bounds and predict when it may need to be adjusted.
Since the system went live, server admins had to double the VM storage capacity twice, increasing it to a final total of 400 gigabytes.
The results
Since it first debuted in the summer of 2010, nearly 10,000 people at VCU have used Filedrop to send over 250,000 files to over 35,000 people. Over 13 terabytes of data have flowed through my humble little app. It was used regularly through August 2015 despite the fact that faculty, staff, and students all had access to shared file services like Google Drive.
This was the last screenshot someone sent in January 2015 before they shut the app off in August. The final numbers are presumably a bit higher.
Lessons learned
Here are a few things I’d do differently or update given the chance:
- One of the first features I wanted to add that I never got around to was auto-completion of emails when sending files, based on the VCU LDAP userbase and then on previous external emails.
- I developed the statistics page before the system had much data to query against, so the queries ran sums, averages, and more against live data. In retrospect, this was a terrible choice, and I wish I could rewrite the system to store statistics separately with cron jobs updating the necessary data on a nightly basis and only live queries running against today’s data.
- I created this app before I had any experience with usability testing. Discovery research was pretty easy because I had faculty and staff emailing me regularly requesting the abilities built into the tool, but I wasn’t nearly as rigorous as I could have been about testing the system after it was built. I have no doubt that some of the interactions and flows could be improved on.
- At the time, drag and drop support for uploading files was pretty low (unless I opted for a Flash solution). I wish that I could have added that along with a progress bar for tracking upload progress.
- Now knowing that some users have sent messages with hundreds of files, I wish I had built a system for zipping up large file batches so users didn't have to download lots of files individually.