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: Mark Roseman <email@hidden>
- Date: Tue, 20 May 2008 12:41:32 -0400
I wanted to throw in another set of experiences and opinions, as
someone who has recently been (re)learning Cocoa for a new application.
Background... programming since mid-80's, MSc in HCI/CSCW, worked on a
number of significant Mac programs off and on since the "phone book"
edition of Inside Mac (Lightspeed/Think Pascal&C, Object Pascal, MPW,
TCL, Powerplant...), plus a large variety of other technology,
including C, C++, Java, various scripting languages, etc. Have done
very little Mac-only work in recent years (mostly cross-platform
stuff), but as I said, that's changing for a new project.
I've found learning Cocoa has been a very steep, slow, but manageable
learning curve, which has left me overwhelmed and frustrated more than
once for considerable periods of time - more so than any other
technology I've had to learn in recent years. And again, that's with a
lot of relevant experience; I can imagine what people who don't have a
formal comp sci background, just done Java or something similar would
be facing.
A few reasons, and hopefully I can tie some of this back to HCI... ;-)
1. Too many choices. Hard-coded models, or Core Data? Views or
layers? ObjC-classic or 2.0? Garbage collection or not? NSRect or
CGRect? Bindings or ...? I understand perfectly well why all the
different choices exist, how things have evolved, etc. but it means
everytime you encounter a problem in those kind of areas, you have to
figure out the right approach for your situation, and those aren't
trivial decisions, and they do require a lot of background knowledge.
We don't want our app users to be forced into making decisions when
they don't have to be, why should we? Yes, maybe that can't be
avoided, but it still is a significant factor slowing down learning.
2. Too many concepts. As the discussions here highlight, there are a
lot of concepts you need to keep in mind while developing; no need to
enumerate. Going back to the short term memory "7+-2" limits, you can
see why people get bogged down, because they get ten levels down into
concepts and then have to reorient themselves to what they were doing
higher up. Experts deal with those limits by "chunking", so that
several concepts can be effectively collapsed into one. That takes
experience and learning, which perhaps explains why some experts have
difficulty understanding why newbies don't get it. It takes a lot of
rote following "click this and type this here" examples before you
even start along that road.
3. Too much housekeeping. This is another instance of too many things
you have to hold in your head at once... to perform this operation,
you need to create this class, add this method, declare, alloc and
init this mutable whatzit, pass it this type which you get by calling
this function passing this other thing that you retrieved from this
method of... etc. Because ObjC/Cocoa are quite dynamic, they are
nowhere near as bad as Java, C++ and others in this regard, but
they're also not nearly as dynamic as dynamic languages like Ruby,
Python and Tcl. (Think creating lists for example). The tradeoffs
are there for a reason of course, but the extra steps do add to
learning curve.
4. Doesn't support everything. I'm being slightly facetious here, but
what I really mean is that there are some things you might think are
(should be) easy, that you have to create for yourself. If anyone has
used Tk, you know about its canvas widget, which provides a very rich
structured graphics framework which takes care of redraws, most event
handling, and does it in a very concise and self-contained way.
Programmers can use that facility for a surprisingly wide range of
common tasks. In Cocoa you need to handle that yourself. With tools
like the canvas, I've taught experienced programmers enough Tcl/Tk to
put together some useful tools in a matter of a couple of hours, and
non-programmers in a couple of days. Couldn't do that with ObjC and
Cocoa. It doesn't take long in Cocoa before you're at the "custom
view" level.
5. Too much hype. Or to put it another way, expectations are set very
high by many Cocoa experts, which it's difficult to live up to. Cocoa
is great, but it doesn't do everything the best way possible, is not
the right tool for every job, it's not for everyone, and there are a
lot of things to learn before you can do things well. That's not a
bad thing. But it's the old story that I'd rather under-promise and
over-deliver.
I really like Cocoa, and I'm getting more and more proficient, but
it's still slow going. And I am really thankful that the 3rd edition
of the Hillegass book came out on O'Reilly's Safari not too long after
I started working on this current project!
Mark
_______________________________________________
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