Inkwell: Authors and Artists

    
 Who do you find to be the ideal readers of the book?  Is it best
received by people who are new to software engineering or more
experienced programmers?

 I don't know that I would have appreciated the book as much had I not
seen many of the problems the patterns solved tackled in other ways.
 
  

    
We specifically targeted readers who have just a few years of
experience (say 1-4?).  Why? Because we thought that most of the design
patterns books already out there were pretty advanced, and likely to
be very difficult for those reasonably new to software engineering. 
You're right - the big "ah-ha" moments with design patterns tend to
come with experience, but we're hoping that with a little head start in
OO principles and design, newer programmers will be able to approach
difficult problems a little differently than they might otherwise.  As
you point out, they won't have the same appreciation for design
patterns in terms of their previous problems that a more experienced
designer would, but hopefully it will help them create better designs
from the start, rather than struggling through a few bad design
iterations first.

But certainly, the book is also appropriate for experienced
programmers who are new to design patterns as well.
  

    
I'm a little late to this discussion, but... hello!  Welcome to both
of you.

I'm currently working as a programmer *and* as a teacher, so I'm
finding both the pedagogical approach and the content are giving me
food for thought.

I mostly work in Python now, but have played with Java enough to
follow along so far in the first few chapters. I'm curious why the
title of the book doesn't have the word "Java" in it. When I first
cracked it open I was a little surprised at the Java-centric content
(until I saw what your previous book was!).

Would you ever consider doing a version specific to another language,
like Python or Ruby or C++ -- or perhaps even offering downloadable
appendices with the examples done in other languages? Or do you feel
that's not necessary?

(I apologize if these questions are answered in the book itself -- I'm
home sick and the book is at work!)
  

    
Or, offering code written in those other languages on the website, for 
those of us who would be more comfortable following along in, say, python 
or PHP.
  

    
In the book you teach each concept more than once, in different ways.
How did you decide how many ways was enough?
  

    
Sorry for the slow response, we were out of town the last couple of
days.

To answer the last couple of questions:

Yes - we would definitely like to make the code available in other
languages.  We currently have someone working on C#.  So far, the
feedback has been very good - most people have not had trouble
translating most of the Java code into their language of choice (mostly
that's been C# from the emails I've received from readers).  We tried
to keep the examples as simple as possible and yet still somewhat real
so that the overhead of the language and the example itself would be
minimal, and I think that worked pretty well in most cases.

(and anyone who feels like translating the examples into another
language and submitting them for us to post would be most welcome to do
so!!)

To answer your question Loren: we have a "Head First" formula.  :-) 
It's three parts: Why? So what? Who cares?

So, first we explain the topic.  Then we imagine someone going, ok,
but WHY would I want to do that? (or do it that way, or whatever).  So
then we explain why.  Then, we imagine the reader saying, ok, but SO
WHAT?  So we have to go another level deeper.  Finally, we imagine the
reader saying, ok... but WHO CARES?  So we have to take it to that
third level!  Now, some simple topics don't warrent all three levels,
and we do our best to judge that so we don't do simple things to death.
 But many do need the entire 3 levels in order to make it perfectly
clear.  We don't want the reader to be saying at the end "I still don't
get it," and we try to take it all the way so that at the end the
reader understands not only 1) the idea but also, 2) why they'd want to
do it 3) the deeper implications for doing it that way (or not doing
it that way) and 4) why it matters *personally* TO THEM (ie., if you
don't do this you will a) get fired or b) have no sex).  

If we can explain the Why? So what? Who cares? in different ways, then
it helps the whole thing sink in a bit too.

Obviously, we don't always succeed, but this is our goal.
  

    
Could you talk a little bit about how you chose the order of the patterns in
the book?  I was surprised that you covered Observer so early on, for
example.
  

    
Another part of the explanation is HOW? One thing I liked is that, in
some chapters you demonstrate that the HOW part (and the WHY part for
that matter) is mostly an application of basic object design
principles. I say "mostly" because in some cases there is an "aha!"
aspect to the solution that makes it not completely obvious. As I
recall sometimes (but not always) you pointed out the "aha" part.
  

    
Well, we started by choosing the list of patterns to cover in-depth
from the original patterns book (Design Patterns by Gamma, Richard
Helm, Johnson, and Vlissides) by how often those patterns are used. 
The patterns we cover in depth are the most used patterns according to
a survey we found.  They are also the patterns we use the most (which
happened to correspond closely to the survey we used).

I think putting Observer near the front of the book was driven by two
factors: one, it's a very commonly used pattern, and two, it's
reasonably easy to understand both from the point of view of
understanding the pattern itself, and also understanding the benefits
of using it.

One of the interesting things about writing a Head First book is
getting the challenge level right to keep the reader engaged,
interested, and wanting more.  Just like a game, you need to give just
enough of a challenge that they feel like they've accomplished
something, yet not so hard that they get stuck or don't feel like
they're getting it.  So we tried to arrange the patterns so that the
reader could make some early gains in understanding without getting too
overwhelmed, so they want to move on to more.  And remember, this is a
learning book, so we wrote it to read from front to back.  Most
technical authors do not assume this, and do not write for this.  But
because our books are story and challenge driven, it's important that
we write this way.

In addition, some of the order was driven by the programming
principles. We found that explaining certain principles worked well
with certain patterns.  And the order of the principles also helped
shaped the stories and vice versa.  

So in conclusion, I'd say it was an organic thing that was driven by
many factors.
  

    
I was about to ask the same question until <jbrewer> put it first and 
better. 

Until this book, the only design pattern that I am aware of working with 
is MVC, which made perfect sense when I learned it a couple of years ago 
and resolved a lot of issues that had kept me from progressing farther on 
learning to program.
  

    
I read a little bit of Head First Design Patterns at the bookstore and
I'm impressed.  Even though I mostly know this stuff already, even the
opening example got me to reconsider a few things.  (In retrospect, I
probably missed a few opportunities where a Strategy pattern would have
come in handy.)

However, the clip art thing still bugs me a little, and I'm trying to
figure out why.  One of my favorite books is Scott McCloud's
Understanding Comics, so I think the issue is not just that your book
has lots of pictures of people in it, but that they're photos.  I keep
thinking that these people are just models who probably don't know the
first thing about programming and the words in the bubbles don't fit
them.  In a way, it deconstructs the use of clip art, which is an
interesting thing to do, but a distraction from the goal of the book. 
So I was wondering whether you folks considered other artistic
approaches.  Would hiring an artist to draw some cartoon characters
have worked as well?
  

    
37 messages later and I am a bit less enthused than I was. When I
started the Topic, I stopped, and emailed my wife. She is a programmer,
and out of town on a project.  I am a technical writer.  I thought
this was a high-level, language independent concept, this "Head First"
design idea.  

What I read here seems to be about menu buttons.  (I mean, you do know
that Engaged is mostly a convenient text editor, right?  Anything
serious you need to do to your account or in a conference on The Well,
you do in Unix on the command line.  Put two spoons of that in your
Java.)

On the other hand, when I go back and read some of our classic books
on programming from the 1970s and 1980s, I find ideas that work in any
environment.  My career as a technical writer has been a learning
curve.  I learned C by documenting a set of extensions that were being
sold; I created learning examples for the books.  Eventually, it came
time to work in Java, so I did.  

(I just thought of an analogy between software design and the
architecture of houses, but I'll that go for now.) 

Flowcharts, Warnier-Orr, Nassi-Schneiderman, Action Diagrams,
Entities, Fishbones, ... functions, subroutines, libraries of linkable
programs, classes, objects, modules ...  LEDs, CRTs, ... punched cards
or palm pilots ... the principles of good software design are the same.


I am impressed by the Disney credentials.  The graphic.jpg links were
interesting and insightful.  So, based on the first ten entries, even
though there are four inches of snow here in Ann Arbor, I will go out
to Borders tomorrow and buy the book.

Thanks to Elisabeth and Eric and their colleagues.
  

    
18 of 37: Dave (drsmith)
I'm asking because of documentation issues, really.
In documentation and training materials, it might be nice to
mention to the reader ... 

Arrrrghgh!!!  NEVER NEVER NEVER NEVER NEVER NEVER NEVER let the
programmers write the documentation and training materials.  Did I say
NEVER?  I meant NEVER!!

Aside from the fact that that's _my_ job, I like to think that I offer
the service because I can do what the programmers cannot.  I come in
and LEARN the system from the user's viewpoint.  Then, I explain it to
the users in terms that the users understand.  It is _not_ (as
programmers think) because they users are deficient or stupid or lazy
or immoral, but because they have different vocabularies, different
needs, different expectations, and different backgrounds.  

I offer a classic case.  I started on a project that was under way. 
Menu item 1. was "File Maintenance."  How often do the users perform
file maintenance?  Monthly.  Why was it menu item 1?  Because that's
how the programmers saw the system.  So, I recommended a change. 

 Remember "Press any key to continue."  The standard quip was, "Which
is the 'any' key."  The programmer were not stopped by that.  So, I
walked up to a programmer and hit the Alt a bunch of times, then the
Ctrl, then the Shift.  "See?  Alt and Ctrl are just another kind of
Shift.  It goes back to teletypes.  You ever use one?"  No.  "I have.
Press those keys all you want, nothing will happen." My suggestion was
to have the user press "Enter" or "Space" and let it be so.

I speak several languages. I took two classes in Japanese in college.
I worked for two Japanese companies.  I taught myself to read classical
Greek and published two articles on using the language. The point of
all that is I see a computer as a mode of communication.  I know that
words have different meanings among different English speaking people. 
More people in India consider English their primary language than in
the UK, US, Canada, and Australia combined.  Yet, you cannot expect
North American users to rely on manuals created in India, China, or
Japan, even though, people in those places, do, indeed, get
documentation from us.  Those problems keep me awake at night. 
Programmers do not understand the question.

Sometimes a project manager will try to save money by having the
manual in "electronic format" (ahem) via Adobe PDF.  Is a screen a
piece of paper?  They are not even the same size and shape.  

It has been said there that "I learn more by hacking than by reading a
book." We _all_ do.  That is why I work with programmers to make sure
that those screen prompts, messages, pop-ups, dialogs, and do-dads are
meaningful, direct, and helpful to the users -- and those users may be
another generation of programmers.  

Field (Address) "Enter Address:" On_cursor_popup "Enter Address" 
On_cursor_popup user asks, "Do I put the apartment number on the same
line?"

We are _all_ users.  You _use_ Java. You did not write it.  You _use_
a keyboard you did not build as interface to a computer that you did --
and probably could not -- not buildn -- and I don't mean plugging in
stuff from boxes, I mean BUILD.

Personally, I am pretty happy at the hex level myself, and I think the
IBM-PC reached its zenith with the PC-XT, a color monitor, a 20 meg
hard drive, two floppies, 640K RAM, and a 1200-baud modem.  Last night,
I watched MAX HEADROOM.  The night before, I watched THE MATRIX.  You
would be surprised how little progress has been made in computering.  

(I like Java. I like C. I like Laurel and she likes me. Oh, yeah,
speaking of Laurel and "Head First Design"... oh, better not...)
  

    
Brian, we have had lots of feedback on the clip art and quite a few
people feel the same way you do about it.  One reason we use photos of
people is so that the reader can identify with the character's
expression better, for reasons I outlined earlier.  Although, I have
not seen studies as to whether responses to facial expressions on hand
drawn people are worse.  Another reason we use stock photography and do
not hire someone to draw the characters is that we do not have a big
budget for producting these books.  Eric, myself, Kathy and Bert do
*all* the design and layout for these books - when we hand them to the
publisher they are camera ready.  We have two choices: either we do the
layout ourselves, or we write in Microsoft Word and submit our "text"
as part of a template with pointers to images.  Obviously the latter
will not work for a Head First book. 

We have definitely considered other approaches to implementing the
Head First learning principles.  The way it was done in the four books
that are out now is clearly only one approach.  When Kathy and Bert
started the series, it was a big gamble and they didn't know if it
would work!  As I write, we are attempting to refine the way we
implement the learning principles... so keep an eye out for new things
to come :-)
  

    
Michael, I'm not sure what you mean.  "What I read here seems to be
about menu buttons."  In what way?

Is it that you believe that OO principles and Design Patterns do not
add anything to the art of programming?

Or rather that you think Head First does not add anything to the art
of learning?

Or something else entirely and I'm missing your point?
  

    

> NEVER let the programmer write the documentation <

That's excellent advice in general, to be sure.  I could debate
you on some of the particulars -- for example, I feel that my degree
in technical communication and my years of experience at writing API
docs have some bearing on the question of whether I should be allowed
to write documentation.  But, really, this is all off topic, so let's
try not to sidetrack the Head First discussion.


I found it interesting, reading someone's (Beth's?) comment earlier,
about how this is a learning book so it's meant to be read front to
back.  I started out that way, and was making steady progress.  Then
a specific issue came up at work, and I started jumping around the book,
which really did not seem as productive at all.  First of all, when I
had a specific work goal in mind, I found myself hurrying more.  So
I think I had less patience for the humor, and I wasn't as diligent at
doing all the exercies; instead, I found myself skipping ahead, looking
for the answer.  Then there were also references to patterns I 
didn't know yet, so of course that slowed me down. 

No epic point to make here; I'm just agreeing with the observation
that this is a book that should be read front to back, and given time
to sink in.  Now if I could just find more leisurely reading time...
  

    
I don't have any scientific studies to back me up, but personally I
have no doubt that a talented artist can do better than clip art in
representing all the human emotions.  I mean, look at what Charles
Schulz did in a tiny space with just a few lines.  Comics have all
sorts of conventions for showing how people feel that aren't available
in realistic photography.  And as Scott McCloud argued, they can also
strip out the irrelevant and alienating detail in a picture so that
more people can relate to them.

However, it's certainly labor-intensive, and I think you've
accomplished many of the things McCloud was writing about, using a
different technique.  And who's to say that, in an alternate universe,
other people wouldn't be complaining about how the people were drawn in
The Cartoon Guide to Design Patterns?

So, how did you go about designing the book, anyway?  I'm imagining
paging through hundreds of clip art collections to find just the right
pictures.
  

    
Brian, you are imagining right!  We have stock photo disks that we use
for both the 50's pictures at the front of each chapter and the
characters within the chapters.  Many of the drawings that support the
code we hand draw ourselves.  It's definitely a labor intensive
creation... but fun too.
  

    

I'm particularly fond of the stock photo on p. 169.
"Look at the lines, the curves, the body, the headlights!"

And just now I noticed a nice little thing I'd missed before -- the
Indiana Jones-inspired item on the menu bar on the screenshot on p. 263.
Wonder how many people miss that one altogether...
Good lord, there's a different one on every screenshot!
How'd I miss that?
  

    
heh heh - yes, we love those easter eggs :-)
  

    
Dave, regarding your comment before about reading front to back vs.
jumping around, and the effectiveness (and your patience for the
various aspects of the book).  This is a perfect example of the
difference between a learning book and a reference book.  A reference
book is designed (or should be) precisely so you can jump around and
find the thing you need, right then.  You can't really do this with a
learning book and still make it a really effective learning tool.  They
really are very different.  The trouble with many technical books
today is that they try to be both and you can't really do both and
still be great at either.
  

    
Have you seen shouting matches between people about whether a certain
design expressed this pattern or that one? Was that the inspiration for
the Fireside Chats?
  

    

Hmm.  I see your point about reference books, but I don't think that
I was trying to use the Head First book as a reference, exactly,
even when I was jumping around.  I mean, yes I jumped around somewhat--
I looked in the index for MVC and then went to that page and started
reading.  But then I tried to sit down and take my time and soak the
info in, so I wouldn't quite say that I expected an answer "right then."

In hindsight, I guess I just had different goals when I was reading
front-to-back vs jumping around.  When reading front-to-back, my goal
was just to learn the material because it would come in useful someday
soon.  When I was jumping around, it was because I had a specific
question in mind, and once I reached a point in the MVC discussion
when I felt like I had an answer to that question, I felt my job
pulling me back.  I think my mood was probably, "ooh, must apply this
info to that thing we've been discussing in email, and do it NOW, before
I forget."   So I never finished that chapter.

Kinda reminds me of the classic design principle, "Never go
grocery shopping when you're really hungy."
  

    
Loren, something like that... we've definitely seen a lot of confusion
about patterns - the right way to implement them, and yes, whether or
not a design expressed a particular pattern.  So the inspiration behind
Fireside chats was mainly to help address the confusion about patterns
and give the reader a fun & interesting way to compare aspects of
similar patterns, or to explore more detail about a pattern than we
covered in the text.  
  

    

Now that there are several Head First books out, have you seen any
signs that the Head First style is being copied by other publishers?
And how would you feel about it if another publisher did mimic the style?