Jack of all trades, master of none

E-mail is the jack of all trades, but the master of none. There are better ways to transfer files, hold discussions, deliver notifications, broadcast newsletters, schedule meetings, work collaboratively, and manage personal information. But even though e-mail isn't the best tool for any of these tasks, it provides a single interface to all of them. Here's a challenge: Let's improve the various functions performed by e-mail without multiplying the interfaces people must learn in order to use those functions. [Full story at InfoWorld.com]

I also mentioned the old idea of passing attachments "by reference" rather than "by value" -- that is, emailing links to uploaded attachments, rather than including the attachments themselves. Several people responded to that, including two whose emails I'm quoting here with permission. For John Heery, the issue is IT control:

I thought your solution for having an e-mail client that could pass a file "by reference" was a great one, and one that several of us at work use with a two step process. We drop the file on a shared drive, and then just send a link.

However, your assessment of why people use e-mail to transfer files may be accurate for Infoworld, but I seriously doubt it is on the mark for most companies. As IT locks down systems in an ever increasing game of black ops, e-mail is just about all we poor users have left. My laptop doesn't have a floppy or CD-RW, so I can't write onto removeable media. The USB port is my current option, until IT discovers I bought a jump drive to move files around. FTP isn't an option, in fact, the FTP ability of IE 6 has been disabled on my machine. My co-workers and I couldn't stop laughing as you rattled off WebDAV, scp, and Radio UserLand. These may be great little secrets for IT people, but at least at our company they aren't made available. We can't even determine what we set as our default browser webpage.

Lotus Notes is our mail client, and it's forced to do the file transfer. For a while, several of us received training in Lotus Application Development and developed some great database tools for our groups. IT has removed that ability. They only support work they developed, and even if you agree to forego support, development by users is not an option. In the ever expanding cold war with IT, my fellow Engineers and Technicians have now retreated to the MS-Office applications. Converting our former Lotus Notes apps to Access with VBA has given us power to develop flexible tools...for the time being. Last week we discovered our ODBC connection between Access and Notes had been disabled. Another battle in the war.

I've used a desktop computer since 1984 when I was required to own one for Engineering school. It's insulting to be told by the new MSCE qualified IT kid that if I'm given the ability to change screen resolution on my laptop, I'll just get into trouble down the road. Please. I run the same OS on my home machine as an Administrator and never have any problems. The problem isn't the variety of tools, nor is it the users. It's the availability. [John Heery]

Several other correspondents said the same thing: they'd love to implement the idea, but lack the means to do so. It's ironic but inevitable that the PC, which was originally the information worker's secret weapon in the "ever expanding cold war with IT," has become the raised-floor sanctuary guarded by the priesthood. I can definitely see both sides of that argument. But in this day and age, when anybody can sign up for a free blog site that requires only a vanilla browser to use, I guess I'd ask this of IT: Do you want users to route around you by sharing files insecurely in free services, or would you rather admit that link-addressable filespace on the public web is as essential a tool of modern work as an email address is?

Jon Hoover also liked the idea, is in a position to do something about it, and wonders how to bend Exchange to this purpose:

Just a comment on your "E-mail's many hats" article, which I enjoyed reading. Recently, an "administrative assistant turned graphics and marketing person" in our organization was found to be sending SEVERAL 100-350 MB attachments to users out on the Internet -- via email, of course. This became apparent very quickly as our Pentium 2 333 MHz Exchange 5.5 server choked down that much data, our T1 flooded, and our mail store approached the Exchange file size limit it has been flirting with for quite some time. I instituted a limit policy that very day, which had always been in the back of my mind (for example, what happens when a virus is created expressly for the purpose of filling Exchange mail stores by sending huge attachments to an entire Global Address List when it detects it is on a LAN connected to such an Exchange server -- sending small attachments to other users not directly connected to the server).

The problem, of course, was that everyone was sending large files. The limit I instituted for outgoing is now 3.5 MB, incoming at 10 MB. These are, in my opinion, very large limits, but complaints quickly grew. I created a samba share on our network which users could drop files into, making them immediately available through a symlink to our public web server. The URL could then be emailed instead of the actual file.

Now, how big of a next step is it to create a form in Exchange which can automatically copy a file into the share, and insert the URL (or URLs) into the email message. Taking it a step further, can the form accept directories to send, zipping them first and copying them to the share? Can it add a password to the zip archive and place it into the body of the message?

Thoughts? I may just have to find a guy in house to put this to task, the more I think about it. [Jon Hoover]

I've no experience with Exchange development, but I told Jon I'd float his query here in case somebody has a solution they'd like to share. For a first level of security, the URL contained in the email message could look like this:

https://user:password@domain.com/~user/proposal.pdf

By the way, I notice that Chad Dickerson is hiring a developer for InfoWorld. Cool! I'm sure there are lots of other priorities, but maybe we can also task the person to make our own email infrastructure smarter.

Former URL: http://weblog.infoworld.com/udell/2004/04/28.html#a986