Spent the better part of last week (and will spend quite a bit of time this week) mocking up the UI for file_wrangler_2. The basic, driving concept behind the design decisions is in understanding how to break down renaming tasks into discrete, actionable units. While studying similar software (A Better Finder Rename, Renamer, etc.) I came to realize that my approach to the renaming process attacks the problem from the reverse angle.
Upon inspecting other file renamers, we can see that a group of folders/files is dropped into the application, then a series of tasks is performed on those folders/files. While this certainly gets the job done, it introduces a lot of repetition in the interfaces, and can make it difficult to understand how one task is affected by other tasks in a multi-step process. Does task C insert something before the 3rd occurrence of some text introduced in task B? Does task D then remove that insertion by mistake? The renaming steps in most programs are performed sequentially, but the process involved in each step may or may not be a relative change to the state of a file name. Some changes are global, some are relative, some are local, some are order-dependent, some are not, and so forth.
What I’ve been working on lately is understanding how to present a methodology that is as clear as possible about how a user-defined change will affect the file names. To do this means to flip over the interface conceptually and re-focus on why the user is using the program in the first place: to rename something. To rename something means she needs to build the blueprint for what the new name should look like. I wish to build a kind of “build-a-name” tool, rather than take that task-oriented approach. In other words, I want you to be able to tell file_wrangler_2, “Look, this is a template of how I want the naming to work. Do it like this.”
In my mock-ups I have created an interface concept that packs 80% of what A Better Finder Rename does into a window 2/3 the size of the Category/Action space on any given window of ABFR. No flipping between screens to get to the renaming actions, yet a definitively clear representation of what the user intends. This sounds like an incredibly dense interface, and it will be but only if the user desires it to be. This will be made clear in the coming weeks as I share a screenshot or two, but for now rest assured that the interface should allow for complex renaming tasks to be defined quickly and intuitively without overwhelming anyone with a hugely complex interface from the get-go.
I look forward to sharing more with you as I refine and finalize the designs.
P.S. – I am considering a name change for file_wrangler (née Filewrangler, née File Wrangler). Suggestions are welcome.