Scrapbox Failures

  • Publishers are asked to submit a draft table of contents (as is usually the case everywhere).

  • Create a large number of sticky notes and summarize them using the KJ method to create a draft table of contents.

  • Writing chapter by chapter

    • Consider putting in place a parallel review period.
    • Thinking that it would be a good idea to do it in Scrapbox.
  • After writing 0 chapters, place the manuscript in Scrapbox and start reviewing.

  • Unfortunately, Scrapbox was not very well suited for this use.

    • The manuscript is written in Markdown and versioned in Git.
    • The changes are to be communicated by e-mail.
      • Worried about not being aware of the change because there was no Stream at the time.
        • The theory that I should have just done a quick Slack notification.
      • In the first place, review comments should not be visible to one reviewer’s comments to another reviewer, since it is useful for several people to do so independently.
    • About halfway between the first and second rounds, I asked the reviewers if they wanted to co-edit. I asked the reviewers if they wanted to co-edit, and since there were not many who wanted to, I decided not to co-edit.
    • One page per chapter is preferred because some people print and put red in PDF, etc.
      • The amount of work is considerably larger than what Scrapbox expects, or performance problems may occur.
      • I think you’re right about cutting off the entry where you separate it with a heading.

        • https://bitjourney.kibe.la/shared/entries/259e827b-934b-4a24-b034-7ee6033c2fee
        • I really think that’s true, but after running a chapter and a page, “I’m going to chop it up into smaller pieces, you’ll have to look at all the pages…” is a bit…
        • I did some experimental chopping, but after reading a fragment, I don’t know which fragment to read next.
        • I could do it if I worked hard and wrote a link to the next fragment at the end of every fragment…
        • Reviewers commented that it is difficult to understand the whole picture. Book readers don’t want to read a wiki that is fragmented and networked, they want to read a “clean text” that is properly serialized and properly considered so that there are no undefined words when read from the beginning.
    • It’s hard to see long sentences in the first place.
  • Would you have preferred to use Scrapbox in the phase before you start making the draft table of contents, when you are writing ideas on sticky notes?

    • But I’m used to the KJ method with sticky notes, and Scrapbox asks for titles and is too granular in its assumptions.
    • It would be nice to be able to use title-only, no text, but I can’t use the link notation in the title.
    • If someone says, “We’ve decided on a book project, here’s the manuscript, please review it,” there are a certain number of people who will review it, but if someone says, “We don’t have a specific project or table of contents in mind, but we’re hoping that if we all ply our hands together we can come up with a draft table of contents, so please help us ply our hands together…”, you’d think, “What? Wouldn’t you say, “What?

This page is auto-translated from /nishio/intellitech執筆の過程 using DeepL. If you looks something interesting but the auto-translated English is not good enough to understand it, feel free to let me know at @nishio_en. I’m very happy to spread my thought to non-Japanese readers.