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: Mike Abdullah <email@hidden>
- Date: Thu, 22 May 2008 00:05:55 +0100
On 21 May 2008, at 23:58, Rua Haszard Morris wrote:
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)
In my experience Backspace or Command-{ does this pretty well.
- 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
_______________________________________________
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