Instead of debating the book's structure first, why don't we start out by just breaking it down into the various topics and subtopics (excluding introductions, tutorials, and "prolonged examples") and working on them? From my perspective, the priority should be first on compiling and organizing information, and then later on creating the narrative structure that ties those individual topics together.
I'd think that, towards the end of the process, we'd have a select few editors polishing the book. At some point we have to give someone that responsibility or else it'll remain a wiki (essentially) forever, with lots of people and lots of opinions on what direction the book should go. The way I see it, we're responsible for providing the raw materials, and once that snowball of information reaches critical mass, we elect the best contributors to the job of creating the final product. We're the researchers, providing the detailed information and fact-checking, while the role of editor is reserved for the people who shine the most during that researching process. Very much an "IMO", but I believe it offers the best chance for creating a cohesive and coherent end product. Timothy On Wed, Sep 3, 2008 at 3:01 PM, Patrick Moore <[EMAIL PROTECTED]> wrote: > I would suggest that you get a way from the linear, single path flow of > writing book. > > I have stopped reading most technical books because they assume that I am a > beginner and am going to read the book in a strictly serial manner. > > I would suggest that rather than be chapter focused that you be concept > focused (1-2 pages) and provide different paths through the text. So someone > who is on the "beginner" path will be lead through the book differently than > someone who is an intermediate. > > -pat > > On Wed, Sep 3, 2008 at 11:55 AM, Thiago H. de Paula Figueiredo < > [EMAIL PROTECTED]> wrote: > >> Em Wed, 03 Sep 2008 15:31:05 -0300, ProAdmin Dariusz Dwornikowski < >> [EMAIL PROTECTED]> escreveu: >> >> Tapestry alone is no use if you do not have DB. >>> >> >> As a instructor of Java, Hibernate, Spring and other frameworks, my >> experience says that people learn way better when they're learning just one >> thing, one concept, one feature at a time. Therefore, I think the book must >> focus in Tapestry and abstract away the persistence layer. In a later >> chapter, the book would show how to integrate Tapestry and Hibernate. In >> another chapter, the book would show a complete example of Tapestry + >> Hibernate + Spring. >> >> >> Thiago >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
