About this project
When VCU transitioned from Lotus Notes to Gmail for students, faculty and staff began reporting problems sending large files to students via email. Gmail’s limit of 25 megabytes was insufficient for many of their needs, and I started receiving requests to use various other systems as temporary storage for large files, including blogs, Blackboard, and other less appropriate tools.
Rather than encourage incorrect use of other systems, I took it upon myself to solve the problem by building FileDrop so that anyone at the university could temporarily share large files with anyone else via email.
My role on the project
I pitched the idea to my boss as something I could build on the side that would solve a growing problem. He saw that it would help alleviate support requests and larger problems in the future, so he gave the go-ahead to start building it. Over the course of 3-4 months, I designed the front-end and build the back-end as well. I then recruited staff members within Technology Services to test the system and fixed any issues that arose. Before releasing it to the university at large, I documented how it worked along with some basic tips for using it.
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.
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
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.
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.
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.