• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Cocoa et al as HCI usability problem
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Cocoa et al as HCI usability problem


  • Subject: Re: Cocoa et al as HCI usability problem
  • From: Stuart Malin <email@hidden>
  • Date: Sun, 18 May 2008 17:13:00 -1000


On May 18, 2008, at 3:56 PM, email@hidden wrote:

On Sun, May 18, 2008 at 8:41 PM, Julius Guzy
<email@hidden> wrote:
Well, there is a problems with the documentation and if it does not get
resolved then people will end up unable to write the code. I mean what is
the point in loosing people who actually want to program this machine and
are willing to put oodles of effort into doing it?

There's been a lot of discussion on the list lately about how Cocoa has been so hard for people to learn, but not a lot of useful specifics or follow-up. People haven said "the API is bad because it refers to all these terms you're already supposed to know and I don't know them!", and then when someone says "Did you read the conceptual documentation?" the response is a resounding... silence. I think this is part of why those veteran Cocoa developers are often less than sympathetic.

I would self-describe myself as a newbie, and feel compelled to chime in on this discussion. The odd thing is, one can read the conceptual docs and not see what is obvious to others, In my own experience, in the very beginning, I would wend my way through the conceptual docs dull eyed - yes, I was reading words, but the concepts escaped me. For me, much of the learning comes in the pursuit of making code work. Eventually the wonderful AHA moments happen. After which, when I go back and read the conceptual docs again I smile - in a proud and embarrassed way -- for suddenly parts make complete sense. And so, I find I need to revisit the docs, over and over. In this regard, addressing the discussion here regarding the quality of the docs is quite a bit influenced by how much one already knows.


I have for the past few days been struggling to find a way to append an attributed string to the end of text view. I resisted the temptation to ask the list. I did look all through the docs. I read loads of conceptual material about the text system (architecture, layout, containers, storage, and many of the class references). I did find an example in the text architecture document (Simple Tasks) for using replaceCharactersInRange:withString: to append a string to the end of the text view. I actually had trouble finding info on this method (it is a part of NSText, which I had developed a notion of that it was better to use its subclasses rather than itself directly). That aside, there was no replaceCharactersInRange:withAttributedString: But then it struck me -- inheritance. What else does an NSTextView inherit from? What about its storage? And by pursuing that, the answer became clear and the solution utterly trivial. In fact, the way to do this is so painfully obvious now that I am embarrassed to mention here that I spent the better part of two days trying to figure this out. But this is the plight of the programmer new (or relatively) to Cocoa. Hopefully I will retain some humility from this experience.

The key to learning is to have fundamental ideas fall into place. Before enough of that happens, even easy problems loom large. The gap between the accomplished Cocoa programmer and the newcomer is the context of their respective knowledge -- a context that makes problem solving either more or less difficult, and that makes the docs either useful or not.

My point in writing is that veteran Cocoa developers do need to have some sympathy and compassion -- that we aspiring developers don't have the patterns, and so what is obvious to you isn't obvious to us, even if the docs say so.

On the other hand, aspiring developers need to understand that learning involves struggle. And that having read the docs once or twice isn't good enough. And also to understand that learning is sometimes circular -- one needs to go round and round because so much of the system is inter-related My advice: experiment! I must also admit that I read and read about a Nib's File's Owner, but it wasn't until I made a bunch of small apps that did nothing but display a window (all done in various ways) that the idea finally sunk in.

That said, one of the huge barriers to climbing the Cocoa/Objective-C/ CF app development learning curve is that there is so very much to learn. The deeper I get into it, the bigger the sea seems to become (I am now trying to use Security Framework to manage passwords on a keychain -- no small mountain here!).

BTW: I download PDFs of the Apple docs (from developer.apple.com) ... and access those quite often. Using Preview, it is easy to search for a term. I find I often have several open all at the same time, and need to cross-reference what I am reading in order for solutions to problems to appear.

Anyway, not sure if I have added anything meaningful...just sharing my experience.

_______________________________________________

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


  • Follow-Ups:
    • Re: Cocoa et al as HCI usability problem
      • From: Nathan Kinsinger <email@hidden>
  • Prev by Date: Re: validateMenuItem() not always being called
  • Next by Date: Re: validateMenuItem() not always being called
  • Previous by thread: Re: Cocoa et al as HCI usability problem
  • Next by thread: Re: Cocoa et al as HCI usability problem
  • Index(es):
    • Date
    • Thread