
Designing GitHub for Mac - rtomayko
http://warpspire.com/posts/designing-github-mac/
======
tptacek
What a f'ing fantastic article. Thank you so much for writing this.

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).

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 _anything_ reasonable
on the screen has been intensely painful, and is if anything much harder than
CSS3+JQ is on modern web apps.

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.

~~~
pmjordan
I had the same experience with my first Cocoa Touch/UIKit project. The GUI
stuff _far_ eclipsed the rest of the app in terms of development effort, which
I did not expect. This hadn't been the case with previous GUI stuff I'd done
(Windows apps, game UIs and the web), and took me completely by surprise.

The "no layouting engine" issue mentioned in the article applies to Cocoa
Touch in the same way as it does to Cocoa, with the added wrinkle that if you
want to support autorotation, this bites you _even harder_. Yes, there's the
"struts & springs" system, but it's very limited - no equivalent to 'min-
width' or 'max-width', and yeah I can't believe I'm citing CSS as a good
example. It also doesn't help at all if you need to change the relative
placement due to autorotation, or if you need to adjust positioning depending
on content.

Styling is another issue - most UI elements can't even have custom colours.
(this will improve with iOS 5, but not until iOS4 compatibility is no longer
an issue) The default button looks _awful_. You have to come up with your own
table view cells for pretty much anything but the most bare bones of lists.

In the end, I actually built my own fully fledged layouting system, which is
content sensitive, has a fairly flexible elasticity system and supports a
"flow" layouting mode which is somewhat similar to the way display:inline-
block; HTML elements are laid out (but with grow-to-fit). I also built
styleable versions of some of the views. If only I wanted to be in the
business of building iOS apps, I'd be extremely well prepared at this stage.
:-)

My recent foray into Cocoa on the Mac actually has been easier, but that's
probably because you can get away with using the default widget styles. Apart
from table cells anyway.

~~~
cylo
Any interest in either open sourcing said layout system or perhaps even
selling it to those of us who struggle with these sort of problems (a la
Sensible TableView)?

~~~
pmjordan
We've put some of the styling-related components online on
<http://appuicomponents.com/> but the layouting engine isn't there yet, I do
feel it's valuable enough to productise eventually. The main problem is lack
of polish right now. Interface Builder isn't much use once you get to that
level of customisation - there's no way to set properties your subclasses
introduce, let alone previewing the automatic layouting. I'd like to fix that
at some point and have some ideas on how it could be done. Aside from that, I
also still need to document the system, and tidy up the code implementing the
layouting, as it's currently not the easiest to debug or find out why
something isn't being laid out as you were expecting, even if the layout
system itself isn't doing anything wrong.

Then of course there's the fact that I'm spending almost all my time on our
startup, which is completely unrelated to iOS. (but it has a Cocoa-based Mac
GUI, hence my recent Cocoa adventures)

Actually, if you're interested in the layout kit, go ahead and drop me a line
(email on the website I mentioned, or in my HN profile) with what you're
trying to do - if it does what you want, I'd be quite happy to progressively
tidy it up and document it if I've got one or two users who are willing to put
up with the rough edges initially, in exchange for some hand-holding.

------
gregschlom
> Death of the SSH key. People should be able to connect to GitHub with their
> GitHub username and password.

This sounds like a wrong design decision. I wish nobody could log into my
github account using anything but my SSH keys.

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.

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.

~~~
kneath
Since GitHub launched, you've been able to access your repositories via
username/password (and add/remove ssh keys via the web interface). But
remember — we're talking about _client_ security.

If someone steals/owns your personal machine it's actually much easier to gain
access to SSH Keys than find your username/password (since an alarming number
of people use passwordless ssh keys).

Aside from that though — SSH Keys are probably _the_ biggest barrier to people
being able to use and contribute with GitHub.

~~~
brendoncrawford
_> SSH Keys are probably the biggest barrier to people being able to use and
contribute with GitHub_

The barrier to entry of writing software doesn't need to be zero. If a person
is going to write code, they should also learn some of the basic tools of the
trade.

~~~
bonzoesc
And I'd claim that an SSH key isn't one of them. There is only one platform
(UNIX-based web applications with application servers) that actually benefits
from them, and plenty that don't (Android, iOS, Mac desktop, Win32, this
week's .NET desktop stuff, ASP-of-the-week, Windows Phone 7).

As a company that makes money from users, it's to GitHub's benefit to make it
easy to use their stuff.

~~~
sjs
I use SSH keys to log into Linux and OS X boxes all the time, servers and
otherwise. And boy have I wished there was an easy SSH server to run on
Windows.

You have to log into remote boxes these days and SSH keys are the best way to
do that.

(Until 1password gets iTerm2 integration anyway, but the 1password guys don't
seem receptive to that idea)

------
tolmasky
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?

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.

It's kind of like refusing to use an NSTextView, then complaining about having
to lay out text yourself.

~~~
nfarina
Completely agree. Cocoa is appropriate for creating minimalist, system-styled
UI. Not for rich flow-based content rendering. See Versions.app: native where
it makes sense (filesystem treeview), Webkit elsewhere (history browser).

------
sant0sk1
Great article for sure, but I take issue with these bits:

> 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.

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.

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.

> It blows my mind that no one tried to do anything special. Git (and its DVCS
> cousins like Mercurial & Bazaar) provide an amazing platform to build next
> generation clients — and it’s like the entire OS X ecosystem left their
> imagination at home.

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.

~~~
scott_s
His point was that the OS X applications he saw were just a thin layer over
the CLI program - they provided no new abstractions. Whether the OS X
application calls a library or calls the CLI program(s) is an implementation
detail not relevant to his point.

------
pohl
_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._

This is getting a lot better in Lion. If you browse the WWDC 2011 videos, look
for Session 103 "Cocoa Autolayout".

------
cageface
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.

~~~
andrewf
It's called skeumorphism. You're not the only one.

[http://speedbird.wordpress.com/2010/06/25/what-apple-
needs-t...](http://speedbird.wordpress.com/2010/06/25/what-apple-needs-to-do-
now/)

~~~
cageface
_What are these but misguided coddles, patronizing crutches, interactively
horseless carriages?_

Nailed it. Great article. Apple's hardware is as beautiful as ever but their
software UI seems to have gone right of the rails. I wish Google's wasn't
aping that dumb page curl effect in their own books app.

------
RyanMcGreal
> 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.

I hope that means they plan to build a git GUI client for Windows, the poor
bastard child of git support.

------
jkkramer
> 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.

What about conflict resolution? That's one of the hairiest, least-user-
friendly scenarios in my experience.

~~~
TylerE
What if there was something like a git deploy command? Basically, when you
don't actually care about git functionality on the remote (production/staging)
end, that would actually change the remote files. (Yes, I know it can be done
with a hook, but that's more of a power user solution, and it's still extra
work to setup)

------
cdcarter
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.

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.

~~~
lrz
Well, MacRuby is a language on top of Objective-C. You can use Cocoa with it,
but you should be able to use the Chameleon framework too, assuming it is GC-
friendly (otherwise, adding GC support shouldn't be hard). His points don't
make much sense to me.

------
grimen
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.

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

~~~
kenneth_reitz
<http://kreitz.co/1H092e0h3z3y1v190v3T>

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

~~~
sunchild
I've been using it. I like it a lot, but I can't figure out how to "git add ."
in it!

I don't know why people are trashing this app. It's not exactly hard to use
the command line if you don't like this app.

Using a GUI on git is just a convenience, and probably most useful for new git
users.

~~~
rchowe
What I think part of the problem people have with it is that it doesn't
necessarily do what a seasoned git user would expect when syncing remote
repositories, such as the fact that it pushes and pulls at the same time, and
the pulls aren't normal pulls, they're rebase pulls.

------
atomical
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.

------
gawker
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.

------
oscardelben
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 <https://github.com/oscardelben/GithubBrowser>

~~~
leviathan
You can still create an account and provide the Apple reviewers with
credentials to try it. This is what we did for an iPad project that uses
Facebook photos, we provided Apple with login credentials to a facebook
account with lots of photos in it so that they can test it, and the app was
approved from the first submission.

~~~
oscardelben
Tried that without success. Maybe it depends on the person examinating it. Btw
it took them two months to reject the app so there must have been something
going on.

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

------
vladocar
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!

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

------
peteysd
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.

------
natesm
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?

~~~
theatrus2
Depends on how you handle the gradients - CG has some neat tricks about
reusing gradient rendering if you don't instantiate the same one over and
over.

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

~~~
kneath
Xcode tracks files with an XML "project file." So if you add files in one
branch and remove files in another branch, it often puts this project file
into a conflicted state. Resolving conflicts in this file is really difficult
— lots of confusing paths and SHAs all mixed together. If you don't resolve
conflicts correctly, the entire project refuses to open.

~~~
dolinsky
Thanks, that makes sense. Is it often that these conflicts arise during
development on a team of 1-3 developers? I'm also assuming you're referring to
the package contents of the .xproj file (specifically project.pbxproj),
correct?

------
mmphosis
Auto Save and Versions <http://www.apple.com/macosx/whats-new/auto-save.html>

~~~
pornel
These APIs are not well-suited for git-like version control.

They're document-oriented, rather than project oriented (or if you present git
repository as bundle, you lose nifty per-document presentation).

iCloud may force creation of versions (commits?)

There's no branching. There's lots of locking and exclusive access.

------
rawsyntax
The bit about the NDA is a little ridiculous.

Apple wouldn't be able to politely ask people not to blog about their stuff.

------
PartyDawg
It's amazing, I thought I would come here to learn things, but instead I am
teaching.

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!

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...

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.

------
thelicx
Super interesting article

