Bit Literacy - Mark Hurst [51]
The biggest problem with storing project e-mails in the e-mail program is that it makes project files harder to find, since they’ll then reside in multiple places. The e-mail program can’t store all the files for a project, after all. Setting aside the possibility of photos or audio, consider the variety of documents that a project can generate:
Incoming e-mails (communications from team members or people associated with the project)
Outgoing e-mails (messages that the user writes and sends to other team members, the boss, or the client)
Meeting notes that the user writes (using a text editor or Word) and saves onto the hard drive
Meeting notes that another team member writes and then e-mails as an attachment
Drafts of deliverable documents—contracts, spreadsheets, presentations, and so on—and successive revisions
Finalized, approved, and delivered versions of those documents
To manage these bitstreams, most users unfortunately do what’s easiest in the short term: they let the bits stay wherever they were originally created. This is “organizing by default,” the worst possible strategy, and it leaves users disorganized, out of control, and thus susceptible to any technology company that promises to fix the mess. Consider what happens when files sit where they arrive, or wherever they go by default when the user clicks “Save”:
Incoming e-mails stay in the e-mail inbox—along with all other kinds of incoming e-mail, project-related or not.
Outgoing e-mails stay in the Sent Mail folder—along with every other e-mail the user sends, project-related or not.
Meeting notes stay wherever Microsoft Word happens to put the file when the user clicks Save—typically the desktop or a messy Documents folder, where a random assortment of non-project-related files may reside.
Deliverable documents—drafts, revisions, and final versions—could sit in any number of places, depending on what software created them. The bits could be in the user’s e-mail program as an attachment, on the user’s desktop, in a generic Documents folder, or in a shared environment used by a project team: an intranet, extranet, or a Web-based workspace.
Organizing by default scatters project files to many different locations, which makes it difficult and time-consuming for anyone to find a given file. If someone asks, “Where is that last version of the PowerPoint file that we were working on last week?”, team members may have to check their inboxes, e-mail folders, desktops, and the intranet, just to cover the first few possible locations. Worse yet, they may then have to compare files to see who found the right revision. Without consistently following a discipline for storage, the file could be anywhere, named anything, and found alongside any number of irrelevant files.
In contrast, storing files in a project folder, in the file system, makes it quick and easy to find files. It’s like the fail-safe method of never losing one’s keys at home: just put them in the same place, every time, when you get home. If an item belongs in only one place, and the user always puts it there, then there’s never a question of where to find it later. The goal of bit-literate file management, then, is to minimize the possible locations for a given file, ideally storing all files related to a project in a single folder.
Given different technology environments, and the various demands on a user or project team, the goal of “one folder” is sometimes unachievable. Project teams, for example, may require individual members to store some files on their own computers, while sharing other files in a team workspace. Even so, the goal remains to minimize the potential locations for a file. Especially for an individual user, the ideal of one folder is often achievable.
To sum up, there are two main advantages to this approach:
It’s easier to find a given project file, since there’s only one folder in the file system where it could be. There’s no need to search the entire computer. And once the user opens