During this fall, some of our early applications (such as Tanner) will be used for a third time. Thankfully, they seem to be running fine with just some minor tweaks. Many more will be run for the second time, such as the hugely successful checklist. One component of the checklist is the assignment of a first year seminar and a writing class for the first years. This went through a major rewrite this year based on what we learned from the way placement was done last year. Since we retain historical data in these apps, we can analyze, re-simulate, and achieve better results.  One more that we did this year is the automated assignment of classrooms based on faculty preferences. Went extremely well and based on the feedback we receive, we will keep refining the apps. In the meantime, we keep getting a lot of requests and we are moving along…

Let us get on to email attachments! I don’t know if you are one of those who began using email before attachments were implemented in early 1990’s. I was one of them. You needed to run an external program such as BinHex on the file to be sent, copy and paste it to the text of the email. Then instruct the recipient on how to unwind it and hope they have the program that you used. Many of us also belonged to BITNET at that point in time and it provided a relatively easy way to “SHIP” a file, which was considered easier. But then came the Internet, the availability of easy to use mail clients such as Eudora and the implementation of MIME for exchanging images, files etc. These additional entities are the “Attachments”. However, technology has improved tremendously in the meantime and it is time to rethink attachments.

There is no denying that attachments are super convenient. One has been used to it for several years now, pretty much everyone knows how to deal with them, sending and receiving them is platform agnostic, though the underlying attachments themselves can potentially be platform specific or software specific etc.

Regardless of the reason why we send attachments, proliferation is a huge problem. If we want a group of people to collaborate on a document, it is attached and everyone is asked to use track changes and then one person consolidates the changes. With services such as Google Docs, this is totally unnecessary, waste of time and error prone. Not to say that there are multiple copies of each version of the file that gets shipped back and forth. In this day and age of cheap disk, this is no longer a big issue, but it creates clutter and confusion.

Most of us no longer attach multiple pictures or videos to emails. We have learned to use web based albums on Facebook, Google+ or Picasa, or YouTube/Vimeo to share images and videos. So, why not practice the same with documents and spreadsheets and powerpoints?

The advantages are clear – you have a single, central copy. So, if there are errors, you don’t need to correct, apologize and resend it to everyone. The changes are maintained centrally and reflected immediately. Collaboration in Google Docs is a cinch. Version control helps you easily see the history of changes and who made them. Of course, not all the work one needs to do can be done this way. For eg. there are specific requirements for publications for which the faculty already have the appropriate templates and Endnote libraries created that work well with Microsoft Word. One could still save these word files on Google Drive and work on it and access it from anywhere and share it with others. Just that the editing will have to be done differently. Similarly, there are many file types that are not supported in Google Docs, but one could use Google Drive as a shared drive and avoid the overhead of attachment.

The need to have a local copy is so severe for many, that when they ask us to create web-based applications, they always want the ability to download Excel files. Given the dynamic nature of the data on the web, the moment a file is downloaded, it is out of date! In the early days of internet when connections were not reliable, one needed to download files so they can work on them offline, and then upload them back or send it to others, but now, most likely the file they downloaded is saved on Google Drive. they anyway need to connect to the internet to access it, so why not access it directly on the application? I think it is much easier to ask for functionality that one wants (different reports, different sorts etc.) to be built in the web application so that it benefits a larger group of people. Besides, depending on the application and the data, it may be risky to download that data locally to your computer!

Sometimes, attachments are used because they provide a level of comfort to people. For eg. some feel that saving documents containing important or private information in a shared folder and sharing is less secure than sending them as attachments. Depending on many circumstances, both can be equally secure or equally vulnerable.

Of course, habits die hard. Maybe LTS can help by establishing an Attachments Anonymous 🙂