Re: Visualizing Cocoa
Re: Visualizing Cocoa
- Subject: Re: Visualizing Cocoa
- From: jgo <email@hidden>
- Date: Mon, 18 Jun 2001 13:43:55 -0700
>
Bob Savage <email@hidden> Sun, 2001-06-10 00:56:05 -0700
>
> Sat, 2001-06-09 19:46:00 -0400 Brian Howard <email@hidden>
>
> Listen up Apple: you should hire this guy, and fast. I will
>
> slog and slog as needed, because the app I have in mind needs
>
> Quartz, but I resent the hell out of having to learn a bunch
>
> of stuff I know will be worthless. Besides, in the long run
>
> you will be much better off if you teach us right, from the start.
>
>
the people who know enough to write the documentation are the
>
guys frantically fixing bugs and implementing requested
>
features and writing the demo apps. In the end you have to
>
ask yourself what you prefer these guys to be working on.
>
Clearly getting the bugs fixed, and the missing features
>
implemented before writing the documentation and sample code
>
is the only way to get it "right, from the start"...
>
Really the problem is we need to get over a critical mass
>
threshold. At some point enough people will have figured
>
out enough stuff that books will be coming out left and right.
>
I predict that by the time everyone currently on the list has
>
learned enough to not really need a book there will be dozens
>
from which to choose. :^)
Exactly. Many of us have been through analogous situations
a few times. Many of us are going through it right now.
Even in-house, the doc writers & QA testers & ... need to get
enough info from the developers to do their jobs. It just
needs to be scheduled in. Don't promise more than what can be
delivered at any point. That doesn't mean "never make promises".
Fix the bugs first. Fix the critical bugs first, then the urgent
and on down the line as you can. The docs should be progressing
in parallel with a little bit of lag. Example code can be done
in conjunction with the docs or later. I think I'd rather see
examples worked into the docs more, for the most part, but YMMV.
But take an hour a day for the debuggers & designers & developers
to meet with the doc guys & the tech support guys (virtual or
real meeting). Don't waste a lot of time on it, just "this is
what I got done; this is what I think needs to be done next;
this is something I don't know; this is something that's got me
stumped", just the 3 or 4 things hot on the plate at the moment.
And someone to say, "OK George can pick up that; Henry knows this;
Ian can supply that.". Keep the long range goals in mind but
focus close and leave out the accusations and such that are just
distractions. It can be very formal or informal, but it gets
things done... if you've got a critical mass of people, and I
think Apple does.
I also think that many of them already know all this.
We are part of this very processon these e-mail lists.
"This is what works; this is broken; I'm stumped how to do that;
who knows..." and some of us are saying we need better docs before
being able to create good apps. The trouble with that is that
it's apparently a longer-range sort of thing rather than the daily
back & forth, and many of us are swamped anyway, so it creates
much more frustration.
John G. Otto Nisus Software, Engineering
www.infoclick.com www.mathhelp.com www.nisus.com software4usa.com
EasyAlarms PowerSleuth NisusEMail NisusWriter MailKeeper QUED/M
My opinions are probably not those of Nisus Software, Inc.