Thinking Like a Cocoa Programmer
Being a great Mac or iPhone programmer means more than just knowing Objective-C and the Cocoa, it means thinking in a different way about designing and writing software. Understanding how experienced Cocoa programmers look at things will help you get closer to becoming an expert.First and most importantly, the Cocoa programmer's focus is always the end result for the user, not the academic sophistication of the code. Start with the simpler, lower-tech solution and switch to a more complex one only if there's a clear reason to do so. This ain't no science fair. The only person you need to impress is the user.
How To Make Great Software
Avoid overdesign — Don't sit down to design big, sweeping architectures that try to address every case that could ever exist. Instead, start by targeting scenarios that actually exist right now using the tools available now. Come up with a solution for one part of the equation, learn what you can, then move onto the next iteration.
Avoid underdesign — Don't blindly implement specs. See the spec as a starting point, and then continually ask the question "does it really make sense to do it this way?" We're making software for a human, after all, not a piece of paper.
Overdesigning for fun — Mac programmers experiment with over-engineering solutions for the sheer joy of doing so. In those cases, they're trying to impress each other, but only in the spirit of having fun and challenging each other to do better work, and only when it doesn't compromise the overall quality or ship date of the product.
Optimization — It's counter-productive to optimize before you know what you're actually building. Get something working, then rearrange it into a reasonably clean design, and optimize for performance after that. Do start with streamlined implementations of things you know you'll need, but the key is streamlined, not obsessively optimized.
Experts write less code — Experienced Cocoa programmers start by assuming the frameworks do the right thing, and look for ways to tweak the built-in classes before resorting to writing custom implementations from scratch. Custom code has to be maintained, so use built-in code whenever possible.
Frameworks and API — When creating a reusable framework, it's far better to solve a practical problem in an end-user application before trying to generalize the code into an API. If you try to create API by guessing, you'll probably end up with the wrong design.
Experience, Inside and Out
It's everywhere — Cocoa programmers think about user experience at every step. Novices think user experience is just on-screen graphics, but it includes things as subtle as the capitalization of text in a preferences window, the name and location of data files, and even the phrasing of messages in the console.
Users aren't stupid, they just have other things to do — Don't assume the user is an expert, but don't talk down to them either. Non-experts are usually intelligent people who don't spend as much time thinking about software as engineers do. Assist the novice user to whatever degree you can without making the software a chore to use for experts.
Code counts too — The developer's experience of reading the code is significant. The developer is you for the moment, but it may be a future version of you, another developer, or a mob of developers if the project is later open sourced. The need to ship software may override the desire for beautiful code, but at least try to arrange things so they can be cleaned up later.
How To Make Great Software Better
Be an advocate for the user — Experts vigorously scrutinize their software as a painter would scrutinize a painting, looking for any reasonable opportunity to improve it without holding up the project as a whole. You're not doing this to impress co-workers, you're doing it to be an advocate for the end user's experience.
See the forest — When scrutinizing software, true experts don't look at it purely as a collection of individual parts. The user sees the final result as a whole, and a great piece of software is as much art as it is science. The highest-level goal is satisfaction, and that may involve doing some really illogical, counter-intuitive things at times.
Feedback — Experienced developers don't let critical feedback get them down. Welcome and thank someone who volunteers insights about your software because it's incredibly valuable information. Don't take it personally because anyone who criticizes too harshly likely hasn't attempted the same kind of work.
Knowing what to not implement — Experts can identify well-intentioned feedback which doesn't really apply to what the software is trying to accomplish. It's not helpful to implement every feature that is requested. A big part of making a successful product is knowing which features to not implement so that the most important ones can shine.
We Make the Rules, We Can Break Them
Any of these rules above can be bent or broken in pursuit of the first rule — making something great for the user. Remember to enjoy what you do because it will reflect in your work.
Thinking Like a Cocoa Programmer
Posted Jun 27, 2008 — 30 comments below
Posted Jun 27, 2008 — 30 comments below
siancu — Jun 27, 08 6090
As a newbie to Cocoa, this has come at the exact right time!
DogThreeZero — Jun 27, 08 6091
It's interesting to hear the emphasis on the user. It does tend to suggest, though, that only a certain kind of person (empathetic, sympathetic, human) will ever become an export Cocoa developer. Maybe that's the point.
Good Cocoa software will be human.
Nobody — Jun 27, 08 6092
I guarantee, if you write the kind of program YOU would have fun using, chances are, others will like it too. Unless you're a really hardcore nerd in which case you should not be programming with Cocoa in the first place, go write a webserver in assembly or something.
ssp — Jun 27, 08 6093
This is about dealing with feedback by users. I am tempted to say that as I user I have experienced the whole range of developer reaction to user feedback. It ranged from an enthusiastic reaction along with a new beta version to test in my inbox a few hours later to being ignored to being told my idea was stupid to being told that they weren't interested in the idea at the moment.
I find the middle two reactions quite frustrating. While the last one is a good way of dealing with this. Unless it's a real bug that you report, a suggestion is just a suggestion, it would be nice to have but you don't expect it. Being told right away that the suggestion won't make it, leaves you with the impression that the developer cares and is honest about things, you also don't expect to see the feature in the software and you won't keep downloading updates hoping for it to appear some day. This prevents long-term disappointment with very little effort.
Tornique Tvalavadze — Jun 27, 08 6094
Unfortunately where I live, developers try to impress each other and, as you can imagine, final result is disgusting... yes, maybe it has lost of settings and can be tweaked in any ways, but no-one, even a power-user could use it out of the box without reading help files, which sadly, in most cases are not written at all...
Thanks for great article, those are one of the most critical things modern software developer should think about.
Kevin Walzer — Jun 27, 08 6095
Mike — Jun 27, 08 6096
While Cocoa programmers might not be the only ones to think about user experience, focused programs, and avoiding unnecessary code, they are usually the ones to get it right.
Sorry if that sounds like a typical "Apple Guy" statement, but a) I'm not an "Apple Guy", and b) it's true. Compare an OS X program with it's equivalent non-Cocoa implementation, and you'll usually find the OS X version to be more attractive and streamlined.
Kevin Walzer — Jun 27, 08 6097
Please don't make an entire paragraph bold--it's like using all caps. You come across as shouting to make your point.
To address your broader point:
A good user experience is incredibly important, and I agree that the Mac platform is better than other platforms in this respect--it provides a more consistent, comfortable, and elegant user experience. However, a good user experience is completely orthagonal to the technology used to implement it. A good user experience is one that provides the user's required functionality in a comfortable, pleasant, discoverable environment, and which facilitates rather than hinders the user's work.
Cocoa has no inherent superiority over other frameworks in terms of delivering a good user experience. It all depends on the skill of the developer.
Here's a small list of non-Cocoa applications that provide as good, if not better, user experience as their Cocoa counterparts, in terms of their functionality and design. I first note the non-Cocoa application, and then its closest Cocoa equivalent in parentheses:
Librarian Pro (Delicious Library); Fetch (Transmit); Dreamweaver (Coda); Lightspeed (Checkout); Word 2008 (Pages); Acrobat Pro (Preview); Macintosh Explorer (Path Finder); File Buddy (X-Ray).
Take a look at a few of these apps. You may or may not agree, but my list above reflects my purchasing decision or, at a minimum, evaluation of a demo. In every case, I judged the non-Cocoa application to meet my needs better, or at least as well, as the Cocoa equivalent. This reflects the skill, effort, and attention to detail shown by the developer.
charles — Jun 27, 08 6098
I think 'empathy' is a critical quality of a good UI designer. "The ability to understand and share the feelings of others", and in this case, I would make it more general "The ability to understand and share the feelings and mind processes of others". A good teacher would likely be a good UI designer.
Steven — Jun 27, 08 6099
It had built in options/change to the nth level. Problem was, it will never happen. It can never happen. This is an embedded system with a 15-30 year life span. In that time, it will change very little after development is complete. It will never have a wave soldered device removed while the power is applied. It will never get a second part (OK, there is a 0.1% chance). The DMA was not used for what DMA is good for, it was write and wait to complete in the higher level application code. Always will be.
The entire application is like this. Amazing functionality but it implements functionality never to be fully taken advantage of. As a result, we have 5X the number of files, it is 1/2 the speed it should be (and needs to be), 10X the number of functions.
I am glad you put over design at the top.
Brian Christensen — Jun 27, 08 6100
Do you really think that only Cocoa programmers think about these things
Where did Scott ever claim the above? You're putting words in his mouth.
Kevin Walzer — Jun 27, 08 6101
Read his introduction again. The strong implication is that Cocoa programmers have a special focus on the end user. The corresponding implication is that other kinds of developers don't. I take issue with that.
I wish he had packaged his advice in more general terms. It's good advice for developers of all stripes.
Daniel Jalkut — Jun 27, 08 6102
And, suffice to say that interface design and usability are subjective topics. But the list of comparisons you present is somewhat ironic considering some of the "close seconds" you cite in the Cocoa world have in fact received Apple Design Awards and are widely considered to exemplify careful design on the Mac.
The argument that Carbon applications can easily provide the expected user experience on Mac OS X is getting weaker and weaker every year.
Scott Stevenson — Jun 27, 08 6104
It depends on who you work with, I think. You can certainly write a networking stack for an application without necessarily understanding user experience. The other people on the team may request you make changes to your code to to support the user experience, though.
@Kevin Walzer: Do you really think that only Cocoa programmers think about these things
Absolutely not, but I can see how it might read that way. I phrased it as "Cocoa programmers do these things" because people ask me what they need to know to write Mac software. In other words, it's saying "this is what you need to know about if you want to be a Cocoa programmer," but it can apply to a lot of things.
@Mike:Please don't make an entire paragraph bold
I can see from his original comment markup that there were two open "b" tags. I think it was an accident, so I updated it.
However, a good user experience is completely orthagonal to the technology used to implement it. Cocoa has no inherent superiority over other frameworks in terms of delivering a good user experience. It all depends on the skill of the developer.
With respect, I completely disagree. If you just mean basic layout and workflow, you can absolutely do that well regardless of framework. But it's just one part of user experience.
Cocoa offers a mountain of subtle but invaluable elements to the user experience, including accessibility, resolution independence, the comprehensive text system, automatic undo/redo, and so on. It's true that a developer could theoretically go and recreate all of these manually -- but it's unlikely they'll have the resources to do so. Not to mention the potentially huge performance advantages of Core Animation.
I don't say this to convince you that you're wrong for choosing another framework, I just want to be clear to the new developers that you can't expect all frameworks to give you the same results. For example, Carbon (and any frameworks that sit on top of it) will not be making the 64-bit transition. The C-based QuickTime API is in the same spot. If you understand that and the other items above and still want to go that path, then by all means do so. I'm a firm believer in doing what works.
Sergej Andrejev — Jun 28, 08 6105
Rob Rix — Jun 28, 08 6106
Steve Weller — Jun 28, 08 6107
@Kevin: However, a good user experience is completely orthagonal (sic) to the technology used to implement it.
This is true but the availability, and particularly the commercial availability of such a user experience is not orthogonal to the technology used to implement it since the technology controls the economic equation. It is not enough to implement a great user experience, you've got to do it to time and to budget if you are to ever implement another one.
John C. Randolph — Jun 28, 08 6109
That one is the key. The biggest culture shock coming from the Mac to NeXTSTEP as I did, or from Carbon or Win32 to Cocoa as people would today, is getting used to how much code you don't have to write.
Several times a year, someone will pop up on Cocoa-Dev, and ask "How do I write a Cocoa app without using a Nib file?", and that's the surest sign of someone who hasn't gotten their head around it yet.
-jcr
Chris Hanson — Jun 28, 08 6110
Here's an example: If you're writing a desktop application for Mac OS X, it should also support a certain subset of the emacs navigation keys in its text fields. If you're using any framework other than Cocoa, you have to do quite a bit of work to get it right and match the behavior of all of the Cocoa applications on the user's system. You can do this work but you are unlikely to do so. Will many of your users notice? Probably not. Will some of them? Yes, and the ones who do will be frustrated daily trying to use your application.
lbaum — Jun 29, 08 6122
Michael Gorbach — Jul 01, 08 6127
Ken — Jul 01, 08 6128
I'm very new to Cocoa so maybe I'm missing something. I've wanted to implement something like iTunes Smart albums; adding and removing a set of controls on the fly. If I can do this via a Nib file please let me know.
Do I have an application that I'd like to do this in? I'm one of those curious types that sees something and wonders how they did it.
For the record, I'm still trying to get my head around it.
Jean-Louis — Jul 01, 08 6132
Like many new comer to the Mac platform, whom are used to "less pleasant" way of coding, I have to admit that I have yet to get my head around it as far as using Interface Builder. Mostly for the (likely incorrect) reason that I found the whole outlet/target linking clunky and possibly hard to maintain/revisit ... But since I'm new to this maybe I'll grow to like it? ... however I have to admit that since I do enjoy writing UI fully in code without UI builder of any kind, it may be hard for me to "convert" ...
@Scott
Great article, really enjoying your blog/site. Thanks a lot for both.
Chris Hanson — Jul 01, 08 6133
You can create an NSRuleEditor or NSPredicateEditor in a nib file. If you want to create a control of your own like those, you can lay out your "row" view in a nib file and just instantiate it multiple times using NSNib.
David — Aug 08, 08 6244
A different title might get (or "have gotten," maybe it's too late) more people to read it, as many who didn't probably should have, because "...Cocoa..." = "skip right past" for many who aren't in or near that environment.
bob — Aug 19, 08 6259
"If you're writing a desktop application for Mac OS X, it should also support a certain subset of the emacs navigation keys in its text fields."
You mean like the Finder from Mac OS X 10.0 to Mac OS X 10.4.11?
I find it hard to ask someone to support a feature that Apple started supporting only 6-7 years after the first OS release.
icloud — Feb 01, 09 6602
Many thanks for sharing this!
Benjamin Dobson — Feb 03, 09 6604
mkppk — May 13, 09 6734
I write a lot of Java code to create very large and complicated web-based apps, for tha man.. I have also written several iPhone apps within the past year using Cocoa, in my free time. My personal computers are all Macs and I use Cocoa for personal projects, and PCs/Java only at work.
YES - the Mac/iPhone Cocoa frameworks make it much easier to follow and succeed at the Rules in the article. Cocoa programmers are probably especially inclined to embrace the Rules since they are more likely to inherently care about user experience (they chose to program for Mac, and probably prefer them themselves!).
NO - none of the rules are specific to Cocoa.. any project, for any platform, on any OS, using any framework, written in any language will benefit from All of thes Rules in the article. I love the article and Cocoa, but it does come off as a bit Cocoa-elitist (not to say that such a thing is bad, we should be proud that we try to achieve a higher standard).
AmeliaWG — Jan 21, 10 7134