I believe I’ve narrowed in on the basic building blocks of the new file_wrangler_2. I’ve been designing and re-designing and re-re-designing, trying to get a handle on how to make the ideas in my mind’s eye fit with reality. Some ideas turned out to be overly ambitious, some were unwieldy, some were just plain BAD ideas.
Ultimately, what I came to realize was that I was defining the “vocabulary” for working with file names; and in the future this may be a similar vocabulary for work with other aspects of a group of files. There are a few things we need in an interface to make that happen:
- Define the Scope of the Action
What is the target of the user’s actions? Yes, its a batch of files, but what SPECIFICALLY does she want to do with those files? Give them new file names? New folder names? Both? and thinking into the future… modify some aspect of metadata? Set the spotlight comments?… Dare I dream to FTP them? This starts to get into the question of, “What is the scope of file_wrangler?” but its liberating to dream of the potential and possibilities. - Define the Target(s) of the Action
As with the original Filewrangler, the file list is front and center and big, big, big. This is the reason someone is using the program; this is what is most important. There are other aspects of the interface that necessarily need some room on-screen, but we can still emphasize the file list’s importance by promoting it to the top of the window. - Filter the Target(s)
The same logic that allows certain renaming functions can also be used to target or exclude certain files in the file list. We COULD force the user to pre-filter before bringing files into the program, but that just seems antagonistic. The whole point of the program is to help you “wrangle” your files, which implies the files at that moment are unorganized. Some utility to refine the choice is absolutely necessary. - Define the Data for the Scope
In the case of file_wrangler_2 (at least, initially) the data is the file name. Tools for common renaming needs tend to be broken into a few concepts:- global and local name changes (make the whole name UPPERCASE vs. put the date in this exact spot)
- custom or extracted data (insert a specific word vs. insert the modification date)
- specific and relative changes (put a sequence before the name vs. insert the date before the 5th occurrence of the letter “V”, wherever it may occur)
Further, we need to consider the basic actions performed on any data in any program in all of the course of history: CRUD (create, read, update, delete) which is really just CRD (update is a create and delete combo-action).
These four aspects of the program have essentially driven the design of the UI layout. The window is divided into four sections that correspond with the above mentioned concepts. As much as possible, I am using Apple’s Human Interface Guidelines to drive design decisions and reduce the learning curve. I believe its metaphors and physical behavior will be instantly familiar to most Macintosh users.
Open Apple’s Dictionary program on OS X and look at the Dictionary/Thesaurus scope buttons. This is my intention for defining the scope in file_wrangler_2.
Look at Filewrangler 1 to see how file lists are presented, but let us also look at the Finder to see how one will sort a file list. I envision a right-click on the column headers to add/remove additional data columns. Just as the Finder does, I also envision allowing direct editing of individual file names.
Setting the filters and setting the renaming choices is the big trick, but we can get a sense of how to handle such things by looking at Automator, but with a twist. I am working on “Build-a-Filter” and “Build-a-Name” wells into which filtering and renaming options are dropped, rearranged, and otherwise work a bit like Lego blocks. Each block represents a very focused, very discrete function of the program and the order of the blocks defines the order of those elements within the name. With each additional block, the interface becomes more dense, yet almost by definition its density increases only at the rate the user defines.
Eventually I came to realize that every user of every renaming program has different ideas about what is important and how best to perform renaming actions. I can only hope to satisfy a specific percentage with the first release, then expand my user base with dot releases. This realization was surprisingly liberating for the design process. I can NEVER make EVERYONE happy, but I will certainly do my best to build an excellent program with a consistent vision.