KATI

The iPhone and its SDK inspire our imaginations. But maybe the thing in our imaginations is not this device, but the next device. There seems to be a general mood of frustration among developers stemming from the restrictions Apple is placing on third-party iPhone applications. As John Gruber points out today in his post, One App at a Time, the restrictions aren’t unreasonable considering the hardware. So maybe the angst and frustration we feel is coming from the fact that we have the tools in our hands and we finally have a real sense for this new platform and the possibilities are so clear to us but we have the wrong device. Maybe the thing that we’re all hungry for is not the iPhone, but something else. Something that’s a little less of a phone and not quite a laptop. When you read though the CocoaTouch documentation, do your imaginings end with a phone?

It’s important for us to be patient with Apple and with ourselves right now. This is something totally new and we need to take small steps to make the transition a smooth one. As developers, we have to completely re-conceptualize our idea of how an application should behave and how to engage users without a keyboard or mouse. We’ve been using the same model for software design since windowed GUIs were first introduced in the 80’s. We don’t know any different and we shouldn’t underestimate the challenges we’ll inevitably encounter. I can’t blame Apple for being so protective of their new platform. We have a lot to learn and so do they. Small steps, patience, a little bit of trust and compromise from both sides is going to be key to their and our success in this new endeavor.

But it’s hard to be patient when we’re all feeling so passionate. I look at this beautiful device and I read the documentation of its SDK and it makes me feel restless. I know that this is much more than a phone. But for now, all it is is a phone. It’s the iPhone. It’s not the next device. That will come next and there will be another after that. In the mean time, we have plenty to explore and have fun with. If you think about it, they’re giving us a lot. We’ll find out their next move soon enough.

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…