Cocoa and Objective-C: Up and Running (by me) is now available from O'Reilly.

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.
Design Element
Thinking Like a Cocoa Programmer
Posted Jun 27, 2008 — 30 comments below




 

siancu — Jun 27, 08 6090

This is an excellent article, thank you very much!

As a newbie to Cocoa, this has come at the exact right time!

DogThreeZero — Jun 27, 08 6091

Thanks for that.

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

Forget all this superfluous nonsense. Listen to your inner instincts, Cocoa Developers. Stop making software and start making artwork. Have *fun* with your software. Your software's function/purpose is not separate or merely 'connected' to your User Interface, they are one and the same. Make your program appealing, make it interesting, make it useful, make it *easy* to use.

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

I'd like to focus on your last point 'Knowing what to not implement'.

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

This is a very, very good article showing a real purpose of writing software, and it work not with an Cocoa developers, it works everywhere in any ways.

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

Do you really think that only Cocoa programmers think about these things--the user experience, keeping your programs focused, avoiding unnecessary code? If you really believe that only Cocoa programmers think about these things, or think about these things in a deeper or more profound way than developers who use other frameworks, then I suggest you broaden your perspective.

Mike — Jun 27, 08 6096

Kevin Walzer:

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

@Mike:

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 — Oct 21, 05 6098

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.

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 — Oct 21, 62 6099

I love the "Avoid over design". I am working on the most over designed product ever. This applies to any programming and I am glad you put it first. There was an driver in the program I am currently working on that I just replaced because we moved to a new part (that will stay stable for about 30 years now). The old driver supported the device being removed and being replaced while the software was running. It was quite cool how all the hot swapping of the device was handled. It had every hardware resource available to it in use. DMA, interrupts, clock speed changes, multiple address. The driver implemented the kitchen sink.

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

@Kevin Walzer:

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

@Brian:

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

Kevin: I think it's best to just take Scott's points for what they are: a celebration of the good mood and care for customer experience that exists on the Mac, in general. The tone of Scott's article is largely prescriptive, and while it's true that some other programmers on other platforms may meet these same criteria, Cocoa is the dominant development framework for the Mac in 2008, so naturally his comments would be in the context of Cocoa.

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 Scotty the Leopard

@DogThreeZero: 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

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 27, 08 6105

These are all good practices. Don't you think that what you wrote applies to all good programmers in general?

Rob Rix — Jun 28, 08 6106

Couldn’t agree more. Some of these points highlighted bad habits that I know I have, for a certainty!

Steve Weller — Jun 28, 08 6107

Scott almost took the words out of my mouth above.

@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

Experts write less code

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

I think these qualities are more common in developers working with Cocoa, WebObjects and similar technologies. If you have the qualities that Scott is talking about, or want to develop them, you will use technologies that support you by giving you a lot of great infrastructure and taking care of many of the fiddly little details that you need to get right to truly fit in to the platform.

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

@Kevin Walzer: When you talk about user experience regarding Word and Acrobat, I hope you mean "developers experimenting on their users". Because the common meaning of user experience is what it feels like to use the application, not feature count. While Word and Acrobat have many more features than Pages and Preview, they both provide a terrible user experience, both on Windows and on the Mac, and I know many, many people will agree with me.

Michael Gorbach — Jul 01, 08 6127

Agree with almost everything in there. Just to add my experience, as I get deeper into Cocoa (and I probably have less experience than some posting here), I find myself removing code. It is a wonderful feeling when you realize that an entire subsystem in your app has been working against the frameworks, and then rewrite the thing to be much smaller, sometimes even realizing the entire component has almost no need to exist.

Ken — Jul 01, 08 6128

@jcr -

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

@jcr

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

@Ken said: 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.

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

Aha! They tried to convince me I was crazy all this time, but I see that somebody somewhere actually remembers for whom software is written. Nice article.
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

@Chris Hanson:

"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

Great insight I've ever read on design philosophy. Do you mind if I translate this to Japanese and introduce your blog to the Japanese blogosphere?

Many thanks for sharing this!

Benjamin Dobson — Feb 03, 09 6604

I have to say. I totally agree with this article. The comments from Nobody and lbaum are spot on as well.

mkppk — May 13, 09 6734

Nice, all the rules I follow, some without even realizing it.. but seeing them in print I immediately recognize that it is what I am trying to accomplish.

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 20, 10 7134

You seem to be so professional and your release just about this good topic supposes to be nice. Should you continue your investigation? I will buy some doctoral thesis or just <a href="http://www.exclusivethesis.com">dissertation writing</a> from you.




 

Comments Temporarily Disabled

I had to temporarily disable comments due to spam. I'll re-enable them soon.




Technorati Profile
Copyright © Scott Stevenson 2004-2008