Being a programmer, I use version control software a lot. A while ago, there was a great upsurge in such software. I suppose it started with Versions and Cornerstone, then continued with Git clients like Tower, Github and SourceTree.
Yet none of them really innovated on their command-line brethren. This may seem like an odd desire, but there are areas where GUI clients can improve on the command-line clients backing them.
Support the User's Workflow
In one talk at NSConference, Aral Balkan once said that your UI shouldn't look as if your database had just thrown up all over it. This is what I'm reminded of when I look at SourceTree.
It feels like someone took a window and just threw in a pushbutton for every action, a text field for the commit message and a checkbox for every option. It presents me all of Git at once. It overwhelms not only me, but also my screen space, as it usually shows much more on the screen than I need at any single time, but since all of it has to be visible, it is all too small to be comfortably used.
All version control software needs to become more aware of context, of "what is it time for now". Give the user a screen display that only shows things relevant to the current operation.
The File List
The file list is not just useful for when you want to commit a change. It can help with code navigation: I'm in a big project, I've edited a few files, I've viewed many more. I need to get back to that spot I started my change in after implementing some needed subroutines and their tests. The recents list in Xcode won't help me there, too many files I came past on my search for the right spot, some in the main tab, some in multi-file search. But my VCS knows which files I just touched.
I just go into the VCS GUI client, to the list of changed files, and there are the 5 out of 50 files I actually changed. And now that I see these 5 filenames, I can recognize what the colleague named that file. I've quickly found it.
Why don't more VCS GUIs support code navigation? Let me search. Let me select. Heck, if you wanted to get really fancy you could show me the groups in the Xcode project that my files belong to. Analyze, correlate.
The one thing all GUIs for version control systems provide these days is what I'd call peripheral vision: They show a constant list of files in your repository and show which ones have changed, live.
You don't have to actively call git status. Whenever a file changes, it just shows up.
By having these updates show up on their own accord, I can be warned of external influences automatically. SmartSVN, for example, shows both the local and remote state of a file. So if a colleague modifies the Xcode project file on the server that Im currently editing locally, I immediately see in my peripheral vision that I have a pending conflict.
Each Version Control System an Island
Most of the version control GUIs Ive mentioned ignore one important fact of most people's work with version control: Sure, it is useful for single developers as unlimited undo, but most of the time it is used in collaborative environments.
If Im collaborating with someone, isn't the most important thing here to keep me abreast of what other developers are doing? Why do all the GUIs except SmartSVN with its horrible non-native Java grab-bag UI focus so much on making me see my working copy that is right here in front of me, and then come up surprised when something on the server changes and drop me into an external diff client without any hand-holding?
Apart from showing remote status, why don't they keep me informed of incoming changes? Why does Cornerstone only let me view the log history of individual files or folders, but doesnt constantly keep the list of commits in my peripheral vision? Why does no client offer to show me a notification whenever a new push happens on the server?
They just don't Learn from History
The commit history also seems to be an afterthought to most VCS GUI developers. The only human-curated part of the entire commit metadata is usually hidden on separate tabs, or at best fighting for space with the file list and lots of other UI. File names are short. Commit messages are long. Why should those two lists be forced to be the same width?
In Versions, the commit list can only be read. I can see the changes in it and the message, but can't select a commit in the list to roll back to that commit, or branch off from it. This is one of the basic tenets of UI design: Dont have the user type in something the program already knows. The commit hash is right there in front of me on the screen, why do I have to type it in to check out?
Moreover, the list of commits in Versions is not scannable. There are barely noticeable color differences in the date, name and commit message, and they're too close together and separated by lines.
Ever wonder why Finder uses alternating background colors to distinguish table rows? Because its easier to scan: Lines are read by the mind as glyphs, additional information to be processed, whereas the line where two different-colored surfaces meet is just accepted as a gap between things.
That's why so many lists use columns. That way, if you're looking for a commit from a particular colleague, you just scan down that column, able to completely ignore the commit messages.
The User doesn't make Mistakes
Users don't make mistakes. Bad GUI just leads them down the wrong path. When a user makes a mistake, be forgiving.
A contradiction? Yes. While most VCSes already under the hood have the policy of never losing data, GUIs can improve on that. Undo on text fields. Showing a big warning banner across the window when the user is on a detached head, which the user can see even if the window is half-hidden behind Xcode. Offering to stash changes for the user if they're switching branches and have unsaved changes.
If the user selects three unknown (aka new) files and asks you to commit them, don't just abort with Git's standard error saying that they aren't under version control! Try to anticipate what the user wanted. Show a window with a list of the offending files and offer to automatically stage them (with checkboxes next to them to turn off ones they might not have wanted to commit).
If a user tries to commit a binary file that has its executable bit set, maybe ask for confirmation in case theyre accidentally checking in the build products, and offer to add the file or one of its enclosing folders to the .gitignore file.
If the user tries to amend a commit, be smart and warn them from changing history that's already been pushed. But don't warn them needlessly. Can you check if any remote is ahead of this commit to detect whether the user has already pushed the commit to be rewritten? If not, it's safe, just let them do it.
Remote Possibility of Supporting a Workflow
I've mentioned how we need to try to support the user's workflow more and how the server is under-served. This also applies to setup. One of SourceTree's standout features is that it lets you not only enter your Github or Bitbucket URL, but also shows you lists of your remote repositories.
You can set a default folder where your programming stuff goes, and then just select one of your remote repositories and click clone, and poof, it checks it out, adds a bookmark for it, and opens it in a window and you're good to go. Heck, Git Tower even lets you specify the address of an image file in your repository to represent it in the list for quicker scanning.
Why does no VCS GUI add a Coda-style project list and automatically looks for project files and their application icons in a checkout to pre-populate the icon?
Re-open the repositories (yes, users may want to open several at once, deal with it!) the user had open when your app was quit. And for heaven's sake, why are there VCS developers who don't know how to make their application accept a folder via drag & drop on its application icon in Finder or the dock so I can quickly open a working copy thats right there in front of me without having to wait for an open panel to open up?
Promise to be Better
Im sorry, this has turned into a rant there. But the fact is, there are so many VCS applications, yet most simply expose the commands of their command line equivalents. Why do so few protect me from commonly made mistakes and focus on what me and my colleagues want to achieve instead and support us in that?
How can products connected to servers be so asocial?