Designing GitHub for Mac

What a f'ing fantastic article. Thank you so much for writing this.<p>I spent a decent chunk of time last year building up a somewhat large Cocoa application (a telling synecdoche of how ambitious the app is: it integrates libevent with the Cocoa loop and involved writing a whole new evented Redis-backed HTTPS cache in ObjC).<p>But unfortunately, I got to the UI part of this project ("UI part", heh) thinking "this is going to be so much easier than webdev, look at all these tools!, and that was a crushing disappointment; getting <i>anything</i> reasonable on the screen has been intensely painful, and is if anything much harder than CSS3+JQ is on modern web apps.<p>I'm thrilled to hear that at least to some extent, it isn't just me, and making a good-looking Cocoa app (especially your first) is just very hard.

&#62; Death of the SSH key. People should be able to connect to GitHub with their GitHub username and password.<p>This sounds like a wrong design decision. I wish nobody could log into my github account using anything but my SSH keys.<p>This is also true of my AWS account: my ec2 instances are protected by SSH keypairs, but if anyone gets my AWS password, he has full control over everything.<p>I'm not a security expert, but SSH keys feel way safer than passwords, especially with all those recents article showing how easy it can be to bruteforce passwords.

Without going into whether I agree with his assertions on Cocoa, if it seemed so much easier to do with web technologies, why didn't he just do it with web technologies?<p>Cocoa is probably the framework best suited for incorporating web views, and tons of apps do this: Mail.app, iTunes, Aperture, Colloquy, etc. etc. Use the right tool for the right job, if you have something that is going to have a lot of flow-based layout, then by all means use WebView.<p>It's kind of like refusing to use an NSTextView, then complaining about having to lay out text yourself.

Great article for sure, but I take issue with these bits:<p>&#62; Unfortunately for everyone involved, every OS X application that’s showed up over the years gave up and tried to turn CLI commands into buttons.<p>It's my understanding that for a really long time there was no linkable library for interacting with Git. So unless these devs wanted to first write said library they were pretty much left with putting buttons on the CLI.<p>You might say "Well they should have written one, then!" but that is quite a risky capital expense on a piece of software that could easily flop. GitHub did it (with Summer of Code's help), but they have umpteen uses of such a library even if nobody uses GitHub for Mac.<p>&#62; It blows my mind that no one tried to do anything special. Git (and its DVCS cousins like Mercurial &#38; Bazaar) provide an amazing platform to build next generation clients — and it’s like the entire OS X ecosystem left their imagination at home.<p>I dunno, I think GitX (especially its forks) does some pretty special things, including making it dead simple to stage/unstage/discard single lines of files.

<i>There is no layout engine for Cocoa. If you want two elements to rest side to side, you’ll need to calculate the pixel size of the text, padding, borders, margins — then manually position the next element.</i><p>This is getting a lot better in Lion. If you browse the WWDC 2011 videos, look for Session 103 "Cocoa Autolayout".

As an aside, I really feel like Apple is losing the plot with their latest batch of UIs. Wooden end panels, birch bookshelves, the glossy reflective dock, leather-bound notebooks etc, all smack of a lack of imagination and an timid need to convey value in outmoded terms.

&#62; Eventually, I (well, many of us) decided that better native clients (OSX, Windows, Linux, Eclipse, Visual Studio, etc) was the best way to grow GitHub.<p>I hope that means they plan to build a git GUI client for Windows, the poor bastard child of git support.

&#62; Simplify the git fetch, pull (--rebase), push interaction. Synchronize — don’t make the user figure out what they need to do to get their local commits remote and remote commits local.<p>What about conflict resolution? That's one of the hairiest, least-user-friendly scenarios in my experience.

He makes great points about MacRuby. I started tooling around with it for an app a few months ago, and though it was a great interface, it didn't make working in Cocoa any easier, and I still had to learn a lot of weird technology choices in Cocoa.<p>Though, I think the difficulty of making a complex GUI in Cocoa shines in the OS X world. It's a lot harder to make a working UI, so you want to get the design right the first time, so you don't have to go back and re-do.

I really like what GitHub do, though in this case I would say that the GitX client (forked one) is way more productive and overview:aböe IMO. I even managed to teach my MBA partner how to use it - this one is actually a bit more confusing than GitX interface. Abstraction is not always for the good, but a very good try at least.

Dear github: clicking "published" on a project deletes it from github. That was a surprise!

Has anyone been using this client, is it worth using as far as GUI's go?

Smartgit is an awesome client for mac and I love the diffs view. Git is complicated so does a simple client help or hurt? I think that's up for debate and different users are going to have different requirements but for me I feel Smartgit is simplistic, useful, and functional where as I think of the Github client as more of an RSS type application where I check the latest stuff that has been committed.

Just wanted to say thank you so very much! I'm just getting started on trying to build an iOS/Mac application system and while it's fairly straightforward to build it, the design of the user interface is what gets me. Going from ok to 'wow' is what really sets Mac applications apart from most PC applications.

On a related note, i've built a simple github browser for ipad that will never get approved on the AppStore due to paid accounts. If someone wants to play with it here's the link <a href="https://github.com/oscardelben/GithubBrowser" rel="nofollow">https://github.com/oscardelben/GithubBrowser</a>

I'd love to see a good comparison from someone with a good bit of WPF/Silverlight/Xaml and Cocoa experience.

This is so unfair. I finally mastered the GIT console pushing and pulling stuff around. And this awesome product comes and the console is now obsolete. Jokes apart, this is super tool that will bring new users that are still not familiar with the console. Great job guys!

I use SourceTree. It's not free, it's definitely not cheap, but it's badass. <a href="http://www.sourcetreeapp.com/" rel="nofollow">http://www.sourcetreeapp.com/</a> (I have no affiliation, just a happy customer)

I've been enjoying the app these last few days. Nice job! It's a great add-on to an already killer service. I'm quite happy to send the folks at Github some of my money each month, because they really earn it.

On the images/code drawing points: are there any benchmarks for this? I've been writing meticulous CGGradient type stuff recently, should I just make a gradient in Photoshop and call it a day instead?

Could someone elaborate on the difficulties encountered managing branches of an iOS project in XCode using git?

Auto Save and Versions <a href="http://www.apple.com/macosx/whats-new/auto-save.html" rel="nofollow">http://www.apple.com/macosx/whats-new/auto-save.html</a>

The bit about the NDA is a little ridiculous.<p>Apple wouldn't be able to politely ask people not to blog about their stuff.

It's amazing, I thought I would come here to learn things, but instead I am teaching.<p>Branching projects is hard in XCode? Zip up the project files and back up the revision... in I don't know, a source code repository? LOL!<p>None of the re-writing is required in Xcode for your app. Design the app, then make it in Xcode. If you have to make revisions to the design of your app, go back to designing it. Most of the code can be re-used, but clearly you haven't finished designing the app yet...<p>Interesting take on the initial experience. But instead of casting about for blame, it might be better to ask why your processes are going wrong.

Super interesting article