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: Rua Haszard Morris <email@hidden>
- Date: Thu, 22 May 2008 10:58:32 +1200
I don't believe Peter Duniho's barking up the wrong tree - he sees
room for improvement, and wants to discuss what to do to make it
happen. I.e. he appears to care about making the platform better
(probably something we all share)...
These are the main valid issues from my point of view:
1 Apple's docs, particularly in relation to Objective-C & Cocoa, have
some room for improvement:
- e.g. navigation (can't go back to list of methods after clicking
a method name hyperlink for example)
- lack of and generally un-useful sample code
- too much "cocoa is wonderful" vs. not enough dry detail
2 Cocoa requires you when learning to implement things by clicking and
dragging, which makes learning harder for some people (this is a real
annoyance to me, why can we not see/edit these connections in a text
file? why is there so much other crap in the nib xml? etc).
3 There's a belief (among) that Cocoa is in some way special and these
documentation (or more general) shortcomings/issues are not relevant
or real or justified.
So, ignoring my usual cynicism (I don't believe there's much that us
developers can do to contribute to improving the documentation, or the
fact that dragging connections is necessary, though I do submit
feedback when I see a clearly-fixable issue), I think it is very valid
to raise such issues and discuss them on the mailing list.
thanks for a very interesting and enlightening discussion
Rua HM.
On May 22, 2008, at 5:30 AM, Peter Duniho wrote:
On May 21, 2008, at 1:42 AM, Hamish Allan wrote:
I'm getting lost as to whether your main objection is about Apple not
providing anything other than Objective-C / Cocoa to develop apps on
the Mac, or whether it's just that you think their documentation
could
be improved.
Sorry, that's fair. I have a number of concerns, and I admit that I
tend to hop around a little (we have one subject description but
really several side-topics related to it).
As far as your question goes, the answer is "neither". And "both".
My _main_ objection is how newcomers to Mac development are
treated. Please, when someone new to the current Mac development
environment brings up one or more of these points, don't say "well,
you're too inexperienced to see why [Obj-C|Cocoa|the documentation|
the tools] is/are so great". Don't say "you're riff-raff, it's
supposed to be hard, we _like_ that it's keeping you out". Don't
say "you must not have read the conceptual guides, otherwise all
this would be clear". Or any of the other condescending,
presumptuous things that I've seen said on a semi-regular basis.
The fact is, any of those _might_ be true with respect to a specific
person. But they aren't necessarily so, and whether it is true or
not, it's counter-productive.
Instead, say something like "your complaint is a common one, you
aren't alone, and [most importantly] it's legitimate to have these
concerns", acknowledging that even if someone's concern is somewhat
irrelevant (being regarding a fundamental design aspect of the
language or framework, for example), it does color their perception
and affect how they approach the development environment. And then
move directly to offering specific and constructive help with
specific problems. If someone has failed to state their own
concerns or problems in a way that allows for this kind of specific,
constructive help, just ask questions that will elicit the kind of
details that would allow for that.
There are in fact specific things about the development environment
that I think can be improved, and I'd start with the documentation.
Would making an authoritative text like Hillegaas's book available
free online be welcome? Sure. But ultimately, some thought needs
to be put into how to make the regular documentation better. More
code samples (if not embedded itself, then at least with prominent
links embedded within the relevant topic), links to relevant guides
where Cocoa concepts are referenced but not defined, fleshing out of
specific techniques, and most importantly: keeping the information
up-to-date (don't tell me to use a tool that's not even included
with the development environment any more, and make sure tool-
specific documentation refers to the version of the tool that is
current).
But mainly treating people's own impressions and feelings with more
respect would go a long way. I recognize that this isn't something
most programmers are naturally good at, but inasmuch as the Mac is
_supposed_ to be the more "human" platform, IMHO it makes sense that
the developer community could stand to observe the more "human"
aspects of interpersonal communication.
And by the way, as far as the "shareholder" part of your reply goes:
I don't hold Apple stock directly. But everyone who relies on
Apple's hardware and software as part of their business, or has any
vested interest in the success of the Mac, is in some way a
shareholder. In that sense I am a shareholder, and it does concern
me to see things that limit the potential success of the Mac. I
think it's great that Apple has been able to expand their market
share a bit, but it remains to be seen whether their momentum can
continue without some fundamental improvements in developer support
(why this is, is a whole other topic unto itself, so I won't get
into the specifics here).
Pete
_______________________________________________
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
_______________________________________________
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