Architecting the Doc Solution

[Judy Perry]

Which, of course, really goes back to the  Hypercard model of pre-built
widgets ala the Buttons and Fields stacks (don't recall their exact names
at the moment) that many of us have requested since Day 1.

And, while it's wonderful that individuals such as Marielle and others
wish to 'fill the gap', the ideal approach, especially for inventive
users/hobbyists/edu folks/non or novice programmers, is to have these
things shipped WITH THE PRODUCT because this target audience is least
likely to have the confidence to look for third-party resources, search
the list archives, or even ask the use-list three or more times how to use
and script tabs (e.g., eliminate the gap instead of filling it). (And, if
you search the use-list archives, you will see that the tabs example is
one that comes up _repeatedly_).

Think about it:  what percentage of that target population do you really
think will just walk away if these things aren't part of the out-of-box
experience?  Is 50% too generous? (I think it is; I'm betting it's more
like 75% or higher).

Does the company want to lose that many potential users?

I hope not.

Judy

On Sun, 15 Jan 2006, Charles Hartman wrote:

> I really like the "cookbook" model of mutual help at, for example,
> 	http://aspn.activestate.com/ASPN/Cookbook/Python
>
> In various languages, I've found that after the initial bootstrapping
> phase (Dan Shafer's book can help people through that), the cookbook
> approach is very efficient: I know enough to know what it is I don't
> know, I formulate it as a how-do-I-do-this problem, and look up the
> keywords that percolate into consciousness in the process. On a big
> site like the ASPN one, most problems have dozens of solutions, and
> choosing one, even in a rush, always teaches me something.