Archive for UI design

On XCode 4…

The only thing worse than managing multiple windows is managing multiple panes… Brent Simmons

I feel like this all the time in Xcode 4. I have been using XCode 4 for quite a while now and while I love the fact that Clang and all the back end smarts are much nicer, the interface has really taken a retro-grade step in my opinion. I recently had to go back to XCode 3 to do some stuff and wow it was soooo much faster to get around and do stuff. There is now so much pane management in XCode 4.

For instance lets consider doing a find across your project. In XCode 4 you hit cmd-shift-F, enter your find text and hit return. Then you have to go drag the find results sub-pane bigger… then look through all your results. Then when you find something interesting you have to double click on a result to look at the find instance (being very careful not to single click it or else the main bit of code you were looking at to provide context to your find disappears). Then when you finally found what you want you have to dismiss the new windows you created, then resize the find column back to something you use for eg a stack trace / build results / whatever (Debug Navigator / Log Navigator) and then go on your way.

In XCode 3 you just hit cmd-shift-F, enter the find and hit return, look through the results, and then close the window. Sooo much quicker and simpler. Its things like this which just made XCode 3 so much smoother…

Apple please, please, please, also allow a more windowed approach like there used to be which was so much more flexible and quicker…

Leave a Comment

MacHg 0.9.15 released!

I am pleased to announce the release of MacHg 0.9.15!

Downloads at:
ReleaseNotes at:
Sources at:

Release 0.9.15 significantly revamps and improves the push, pull, incoming and outgoing sheets; significantly revamps and improves the server configuration sheet; now always stores passwords in the system keychain; adds support for handling of google code respositories and svn repositories; has “under the hood” improvements in the way disclosures are handled; and fixes or addresses many smaller issues including: #98, #116, #170, #184, #193, #200, #202, and many other unreported issues.

Others who contributed patches to this release (Thank you all!):

  • Kim Hunter
  • Matthew Watson
  • Eugene Golushkov

I really like the changes I added in MacHg 0.9.15. Nothing was critical but there were lots of details and polish that just make things better and more intuitive now. It’s one of the nice things about UI design that sometimes after you implement something and play with it, it’s just really obvious that the new way is better / worse than the old way. And the new changes to 0.9.15 are quite nice if I do say so myself…

Actually I probably could have gone 1.0.0 with 0.9.14, but I still might add some basic sub-repository handling before going 1.0.0. Or, maybe if there are no major bugs with 0.9.15 I will just basically use that to go 1.0.0.

I also wanted to say thank you to all users of MacHg for your excellent comments and feedback!

Cheers, Jason

Comments (1)

Unified diffs and GUI clients

Recently a user of MacHg asked how to display the differences in a file inside MacHg.

I personally have an opinion on this which differs somewhat from the established dogma. Thus I will outline my position here so I don’t have to elaborate it elsewhere, and hopefully it will make other GUI designers at least think about this issue.

The situation right now is that almost all GUI clients for Revision Control Systems (RCS’s) show differences “in application” through unified diffs. This is done because unified diffs are rather short and compact. But unified diffs don’t show all the surrounding code; and really in a large section of code with several changes, it is very difficult to immediately see what changes are occurring.

In fact, every single external GUI diffing program that I have seen has as default a side-by-side diff. (Some programs allow as an option, unified diffs, but it’s definitely something which is not the main thrust of the program.)

So, why does every single program that is dedicated to showing differences, display differences in a way different to that used inside almost all RCS GUI clients?

The reason is that most people sooner or later are forced into being able to recognize unified diffs. And after much exposure they begin to expect to see unified diffs, even though they are a very suboptimal way to view diffs.

Why do people get used to unified diffs? The reason is that since unified diffs are the raw format for diffs and are plain ASCII, they can be easily emailed around and inspected by people using tools which have nothing to do with diffing (eg email clients, text editors, displaying text on a web page, etc). In fact in some lists, sending unified diffs is the default way to exchange information, since in email ASCII is the lowest common denominator. (For instance, the mercurial development mailing list uses unified diffs as an interchange means of publicly discussing proposed changes.)

Of course, email is a very convenient interchange system, so developers are reading these unified diffs all day. Thus when some developer goes to create an RCS GUI client, they naturally put in the stuff they are working with all day, eg unified diffs.

But let’s take a look at what happens here in a screen shot from another RCS GUI client. (Note: I am not singling out this client amongst others, since many other clients do exactly the same thing.) However, of the overall window size (892 pixels x 689 pixels) the part which shows this unified diff is quite small (624 pixels x 192 pixels). Thus, just 19.5% of the window size is dedicated to showing the differences from one version of a file to the next in a semi-obfiscated patch interchange format.

I think its just sub-optimal.

(Of course for some die hard developers who eat, sleep, and breath unified diffs, maybe having some in program unified diff display is semi-convenient. However, to a large degree such people tend to use the command line in any case, so dedicating GUI features for them is futile.)

In this day and age of 32 inch LCD monitors, I think GUI RCS client programs need to live a little and somehow encourage the showing of diffs in the format that well… all dedicated GUI diffing programs use. Ie right now, use a very fast dedicated client or in-application code which shows the diff in a side-by-side format with full context in a large window.

(That said I have had more than a few requests for this feature in MacHg. And I try and do what users want… So maybe later I will have to toe the line and add these unified diffs into MacHG… But I am resisting for now…)

Comments (1)

MacHg 0.9.13 released!

MacHg 0.9.13 adds QuickLook support, error disclosures, .hgignore event handling, UI improvements, and fixes a number of issues.

In particular one can now use QuickLook to get a snapshot of the historical state of a file in the History View or the Differences View. This facet of QuickLook support is quite nice. In fact the general QuickLook support does all the things it should in the right mac ways, etc.

I also like the new error disclosures. They are much snazzier than the previous versions. (I even find myself every so often repeatedly typing in purposely wrong paths and names just so I can see them smoothly animate out in MacHg and think to myself “ohh, that really looks nice…” Then again I guess it’s only ever GUI designers who think such things, and normal people will just think “Oh… yes, I guess you are right, that does look nice.” But never really notice it otherwise… Still it’s details like this which make Mac applications, well Mac like…

Also a really nice change in MacHg 0.9.13 is that I can now get from Mercurial the regular expression representing all the files Mercurial will ignore. Before, whenever I auto-detected that something changed inside some directory (via FSEvents), I had to send through to Mercurial a request to see what had changed. However, if that directory was ignored by Mercurial, I would still have to go through the whole rigmarole of checking via Mercurial that indeed nothing had changed. Now I can just check against the regular expression, which is much faster. Eg a typical example of this is having an ignored build directory in your programming project. Typically though, when you are compiling the files inside in your project, often the files within the build directory are changing like mad.  Thus previously a flood of checks would have to go out from MacHg to Mercurial to see if anything changed, and this could in fact cause your build to go some 2 times slower than without MacHg running… Anyway happily this is now fixed.

Also I have gone with the new status icons provided by David Keegan. I think they are better than the ones I had. Also David sent along some new toolbar items and revamped the icons for the preferences items. (Thanks David!)

There are also a number of other UI fixes. See the full [release notes]:

In more general terms of the overall MacHg timeline, the change to stable graph drawing in 0.9.12 has gone very well. There has been only one reported issue against this massive refactor, and moreover that issue is now fixed in 0.9.13.  So all in all the huge refactor and speed up in 0.9.12 went very smoothly.

MacHg 0.9.13 is definitely a candidate for MacHg 1.0.0. (In fact MacHg 0.9.12 was also a candidate, but I just wanted to see that everything was ok with the stable graph drawing change.)

Beyond the 1.0.0 release I plan to add a super Annotation View, an improved history editing interface, handling for git and svn through their respective extensions, improved discovery and other issues.

Cheers, Jason

Leave a Comment

Interesting take on Linux and UI design

I stumbled over an interesting article the other day when trying to figure out how to turn BBEdit TextFactories into droplets.

Recently I have struggled a with several characters in the Mercurial development scene. Interestingly this article about UI design and Linux mindset thinking although old, was so on the money its eerily scary. (at least with some of the characters I have encountered…) Things haven’t changed. Tellingly from the article was the quote:

The list of fantastic open source developer software is long. The list of fantastic open source GUI software is short. This is not a function of chance.

Comments (1)