Welcome, Designers
My head has been reeling all weekend after watching the iPhone SDK presentation. The excitement I felt the first time I saw an iPhone has returned full-force after it was crushed by Steve Jobs during last year’s WWDC keynote address. I still think he owes all of us an apology for trying to pass off Ajax techniques as an SDK like we’re stupid. Anyway, I’m super happy and optimistic about all the new technology we get to play with and like many others, I can’t help but think about the future. There’s one thing in particular that I can’t get off my mind.
There are going to be lots of new Cocoa developers and many of them will come from the field of design, not software development. Some will have never programmed before in their life. This happened with HTML and CSS when the web became popular. It’s going to happen in the world of iPhone development and Mac desktop application development will naturally follow.
This influx of new developers means that the usability of the Cocoa’s APIs are going to be put to the test like never before. Bugs like NSView’s autoresizing not working as advertised or the fact that the methods to customize the drag and drop highlights of an NSTableView are private and not legally accessible to developers are not going to sit well with this new generation of Mac devs, who will demand control over every aspect of their visual design.
It should be possible for the Cocoa engineers to give developers complete control over the visual properties and interactive behaviors of their classes. I don’t mean in that convoluted creating a custom cell way, it should be easy — HTML and CSS easy (in fact, why don’t we use style sheets?). If there are points where this is technically impossible, it’s a design flaw of the framework and should be fixed. If it means writing a new NSTableView, so be it.
Sorry, you’re screwed
I keep thinking of an article I read about the history of CSS and this part in particular:
Meanwhile, writers of Web pages were complaining that they didn’t have enough influence over how their pages looked. One of the first questions from an author new to the Web was how to change fonts and colors of elements. HTML at that time did not provide this functionality - and rightfully so. This excerpt from a message sent to the www-talk mailing list early in 1994, gives a sense of the tensions between authors and implementors:
In fact, it has been a constant source of delight for me over the past year to get to continually tell hordes (literally) of people who want to — strap yourselves in, here it comes — control what their documents look like in ways that would be trivial in TeX, Microsoft Word, and every other common text processing environment: “Sorry, you’re screwed.”
The author of the message was Marc Andreessen, one of the programmers behind NCSA Mosaic. He later became a co-founder of Netscape and by then his views - if they ever were his views - on formatting had changed.
I doubt that any Cocoa engineer has such a flippant attitude towards designers. After all, this is OS X — the best looking operating system on the market. I just hope that they will take these types of issues into more serious consideration when mapping out their priorities. Sure, advertising “New Table Views!” in Cocoa isn’t as sexy a feature as Core Animation, but it’ll make everyone’s life easier in the long run. Imagine this question popping up on the Cocoa-dev list: “How do I customize the background color of a column in an NSTableView”. Now think of the answer…
March 10th, 2008 at 11:40 pm
Uh oh, now you’ve made me very worried about a wash of apps using marquee and blink tags, or early Web-2.0-style buggy “features”! Developing for the Mac has made me a lot more conscious of good design and UI…
Apart from this, it’s nice to see a good new Cocoa blog on the Internet; keep it up!
March 11th, 2008 at 2:08 am
I want to be one of those people you talk about who are going to be Cocoa developers.
I just finished my first class: C++. I started reading the Apple documentation on Objective C. It is very helpful, but I feel like I am missing something. I am reading a couple blogs, yours, cocoa is my girlfriend, some posts on the cocoa development central page, but what about some kind of text for learning objective C. That seems to be where the meat is, and most people talk about Cocoa. Can you give me some direction?
Thanks…!
March 11th, 2008 at 3:52 am
I like the stuff you’ve been writing about, and I particularly like this topic. Please keep it up. I personally love to read Cocoa and Mac topics written by an interaction designer.
I understand the appeal of visual customization, and it’s hard to deny the value. But there are two main factors for new API:
1. How many developers will this help?
2. How clear are the use cases?
Providing “complete control over the visual properties and interactive behaviors” is quite a bit. I think of “complete” as “everything” — which asks where you draw the line. Every single pixel at every resolution? Control over every conceivable mouse or keyboard event?
Even if it could be technically done on the framework side, the resulting markup would likely be so complex that you’d just wish for a way to do it with normal code (speaking from experience! :).
But there’s probably some middle ground. The key is to articulate exactly how you would expect this to work and how it would specifically help you make great software, then file it as a radar.
You might have also seen this:
http://mattgemmell.com/2008/02/24/skinnable-cocoa-ui-with-webkit-and-css
March 11th, 2008 at 6:03 am
Jeff: Most people recommend “Cocoa Programming for Mac OS X”. I haven’t read it, myself, so that’s all I can say about it. (Note that there is a different book titled simply “Cocoa Programming”. I haven’t read that one, either.)
BTW, C++ is not a strict superset of C—there are some differences. Objective-C is a strict superset of C, so those same differences exist between C++ and Obj-C. You would do well to read the New Testament or Practical C Programming in order to get used to plain C, before you dive into Objective-C.
Cathy: A year or so ago, I observed that one’s blog has matured when its author can refer to previous posts from new ones. I’d first noticed this in Coding Horror, and made that observation when I noticed that I was doing it, too.
Your blog has matured really fast. Good job, and thank you, and please keep it up. ☺
March 11th, 2008 at 11:14 am
Jeff:
Definitely check out Peter’s suggestions and I really have to recommend Aaron Hillegass’s “Cocoa Programming for Mac OS X”. I’m not sure if the new version is out yet. Aaaron Hillegass is a wonderful teacher and that’s where I started. Other than that, I think you just have to get your hands dirty. There is a huge community around Cocoa and tons of example projects and documentation available at the Apple Developer Connection.
Scott:
I don’t mean control over every pixel, but over the stroke, fill colors and position, width and height of every visible rectangle in the window, the same control you have over a div tag in html. I think that this is what alot of people are going to expect when they come to Cocoa for the first time, especially the many that will come with experience in web design.
We can’t give everyone what they want, of course, but a lot of people struggle with these issues even now. So I sometimes wonder - how could this be easier?
I can imagine the view heirarchy + layer hierachy of a window being represented in mark-up, and then being able to apply a style sheet to that. For the controls, it’s a matter of asking - how configurable are they and how easy are they to subclass if the standard configuration options don’t meet people’s needs? I pick on the table view because it’s the worst offender and it’s the one people are always trying to customize.
I know I’m over-simplifying the problem but sometimes there’s no other way to start looking at it. And I really don’t know if CSS + markup is a good model to follow for destop apps. I’m really just thinking out loud : )
Peter:
Yeahh…that was sooo Jeff Atwood of me ; ) hahaha. Thanks a lot of your encouragement, it really does mean a lot.
March 11th, 2008 at 11:21 am
Jeff:
Also, use the mailing lists. The official Cocoa-dev mailing list is archived and easilly searchable at this site:
http://www.cocoabuilder.com/archive/bydate
Seriously, anytime you have a problem, search for it on the site and you’ll find that someone has asked your question already and someone else has answered it and often with some example code. This site was invaluable to me as a beginner and I still use it every day.
March 11th, 2008 at 1:53 pm
Thanks very much, people. I just bought Aaron’s book, even though I will probably buy it again in June when the next edition comes out.
Thanks for answering! I am amazed at how I can feel that people care and support me even though they don’t know me.
March 12th, 2008 at 12:24 am
NSCell in Leopard has something called “multipart image drawing” which uses the NSDrawThreePartImage and NSDrawNinePartImage constants. For a nine-part image, you provide images for the four corners and four edges, and an image for to be tiled in the center. The three-part version is the same idea but it’s only resizable in one direction.
Also, Core Animation layers have a “style” property which allows you to feed in all of the display attributes you describe (fill, stroke, shadow, size, and so on) as a dictionary.
I fully support the idea of figuring out how common needs can be made easier — that’s the whole point of Cocoa. The important thing for all of this, though, is to condense it into into a description of how specifically you’d like the API/markup to work, then submit it as a bug report. That stuff gets read by real people. Markup is one option, but I think Interface Builder is probably even better. This is what it was designed for.
March 12th, 2008 at 12:51 am
Yeah, I think CALayers are definately headed in the right direction and I’m *guessing* that the new UI APIs for Cocoa Touch are also an improvement.
I think maybe the problem I see in the Cocoa API is that there isn’t really a consistancy in how view objects are configurable in terms of their visual properties. Sometimes you can do it in IB, sometimes you have to subclass and do the drawing yourself, sometimes you have to implement a delegate for the object and hand over the information that way and sometimes you have to do some combination of all three…it’s kind of awkward.
IB would be the most intuitive place to do this. It would be great for there to be some sort of style protocol that all view and view-like (Cells, Layers) objects would conform to so that IB could configure at least the most basic style properties…again thinking out loud.
I will condense these thoughts and submit them as you’ve suggested.