@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.
by Scott Stevenson — Jun 27
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.