The first post in this series described the typical, yet minimal, approach to file management within an application, which leaves most of it to the operating system. Yesterday’s post was about a hybrid pattern that sees the application providing convenience features for working with multiple files. In the third and final pattern, the application takes on all file management responsibilities.
Dreamweaver is a good example of the third model. To do what it does, it has to have an understanding of an entire site. What are all of the files that are part of the site? What is its directory structure? Which files are linked to what other files? It therefore provides a UI for managing and navigating the entirety of a site.
Dreamweaver has users create a “site” by giving it a name, filling out metadata, and picking a location in the OS file system. It considers the selected location to be the top level of the site hierarchy, and all descendants are part of the site. The Manage Sites dialog lists all of the sites that Dreamweaver is managing and allows the user to create new sites, edit the settings and metadata of existing sites, make duplicates of sites, remove sites (this doesn’t delete files from the file system—it just tells Dreamweaver to stop considering them to be a site that it is managing), export, and import sites.
Once a site has been created, it can be viewed in the File palette, which presents only the portion of the file system that is considered to be part of the site (i.e. from the selected directory down). The user may choose which site to view, but can only view one site at a time. Within the File palette, they can interact with the file system pretty much as they would through the OS. They can create new folders and new files, delete them, open them, move them, etc. Any changes made within the palette are made directly to the file system. Likewise, changes made within the file system will be reflected within the File palette.
This model may then be coupled with either of the first two models, presenting open documents collectively in one window, or one document per window. Dreamweaver’s recent versions employ the tabbed window variant of the BBEdit model, but previous versions followed the Word model.
The benefit to using the Dreamweaver model is that the application may provide unique functionality based on the connections between multiple documents that wouldn’t be possible (or at least not as usable) if file management were left completely to the OS. For example, if an HTML file is dragged from one folder to another in the File palette, Dreamweaver will ask if you want to change all links in the entire site to reflect that change. If you were to move the file using the OS, Dreamweaver wouldn’t know about it. Other applications that follow this pattern are Espresso and iMovie.