Re: Cocoa et al as HCI usability problem
Re: Cocoa et al as HCI usability problem
- Subject: Re: Cocoa et al as HCI usability problem
- From: Alex Kac <email@hidden>
- Date: Mon, 19 May 2008 11:42:39 -0500
I have followed this discussion closely because as a veteran developer
who started on Mac OS back in the nineties and then gone to Win32 and
a bit with PHP, Tango, .NET (both web and mobile/desktop), Cocoa has
been very difficult to *get into*. Every technology I've been able to
get into easily because I could discover the tech in my own time.
Cocoa is not like that. You have to grok the whole foundation first
before you can do anything.
So I've got a business I'm running writing software for mobile
platforms and I do a lot of coding myself for WinMobile as well as
managing several project leads for BlackBerry and other platforms. I
want to get into Cocoa and *learn* it by trying simple useful things
first and then going forward in my spare time. With all other
languages and frameworks I've used you can do that and not feel
overwhelmed. The Cocoa docs are not conducive to that. I have
purchased Aaron's book and that helped a lot - except it was out of
date and didn't follow any of the new tools (which I have to use due
to the Cocoa platform I'm working with) - so while I could see it
being great for what I needed it was useless for now.
I'm not against hard work to learn a new platform/language. Its a
challenge and I love it. The problem I have is that the docs as
written do not work for learning Cocoa in your spare time even if you
plan to go full-time to Cocoa in the future (that's my goal - move my
WinMobile dev to my other engineers and then move myself to Cocoa full-
time, but I can't just drop my projects now). And I think this quote
from Peter Duniho explain exactly why:
MSDN is sprinkled with code samples. Everywhere. Granted, some of
them are kind of silly, and some of them are just plain wrong. But
on the whole, they are pretty good. More to the point, they exist
for pretty much _every_ documented API element. Class methods,
properties, events, fields. All have a dedicated doc page that
includes some sample code (in many cases, a single sample is shared
among multiple elements...but that's just efficient doc writing).
Contrast to the Cocoa docs, where a single class is documented in
just one web page, with practically no sample code at all and
incredibly brief descriptions of each element.
I agree with much of what Peter wrote in his post, though not his
conclusion that Cocoa can't be fun. I've watched one of my Cocoa devs
who is very fluent in Cocoa and it can be fun. Once you grok
everything and get that "Aha" moment, its fun to work with. But until
then its like pulling teeth.
Part of the issue I feel is that some people need examples along with
the reference. Sample code is great, but I don't want to have to open
sample project after sample project to just figure out a few things
that could've been shown in 5 lines of sample code in the docs. Its
also now separate from the docs which mentally makes it harder to
connect.
Just like some people are visual learners and some people are audial
learners, some of us do not do well with overly wasteful with
paragraphs of chit-chat. I don't want a seminar; I want to know what
the class is for, what its methods do, and give me some simple
examples on how one would use them. And explain WHY it works that way
and so on.
Again Peter wrote much of what I wanted to write:
As an example, I found myself wanting to exclude an area from my
clipping region. Nothing complicated: I had a rectangular area, and
I wanted to draw everywhere _except_ a specific sub-rectangle. The
docs were quite prideful as to how, since Cocoa clipping uses the
NSBezierPath, you have practically infinite control over clipped. No
doubt this boasting was reasonably accurate (*). And yet, even as it
hints tantalizingly at the idea that there's a way to do this (see
"Modifying the Current Graphics State"), it doesn't quite get you
there.
And finally, I think the issue Peter had with finding Cocoa non-fun
were not due to Cocoa itself. For one thing, I think XCode 3.0 makes a
huge difference in the "fun" of Cocoa - the tools are a huge deal and
make a big first impression to new developers and it sounds like he
used XCode 2.4 which I didn't care for much. Second, the doc issue and
the difficulty in getting started with those docs negatively colored
his feelings on Cocoa.
So my advice to Scott and the Apple docs team:
1) Be less verbose. Get to the point.
2) Provide a doc tree so we newbies can find our way around the docs
better while in XCode.
3) Provide simple sample code within each method. It doesn't have to
be production quality. Just give me an example so I can connect what
you're writing. You have the Research Assistant which is 90% of the
way there, but again it points me to a collection of sample projects
which I have to download, setup, find the code I'm looking for. I've
now spent 30 minutes looking for sample code that on MSDN would take
no extra time.
BTW - for those new to Cocoa - grab XCode 3 and use the new Research
Assistant as except for sample code, it really solves many issues I've
had with learning Cocoa.
Alex Kac - President and Founder
Web Information Solutions, Inc. - Central Texas Microsoft Certified
Partner
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden