The Birth of a Book: Part 18

The stylistic changes, grammar mistakes, and poor typography were relatively easy to detect and mark up. It took a lot of time, certainly, but it wasn’t difficult editing. What really blew my stack were the changes to my code.

As I mentioned in a previous post, I had actually been instructed not to format my manuscript. I was to mark sections of code, basically by saying [code starts here] and [code ends here]. That would have been really annoying. More importantly, I had very specific ideas about the way I wanted the code formatted in the book. I wanted to use color to enhance its readability. So, I ignored my instructions and formatted the code exactly the way I wanted utilizing color and a monospace font.

I have an entire chapter on formatting standards in the book. Within that chapter, I provide examples of poorly formatted code and then show what it looks like properly formatted. There was one such example that had been corrected! The text was explaining what was wrong with the indentation of the code block, but the code block’s indentation was just fine.

In the same chapter, I talk a bit about whitespace, explaining that rulesets should be separated by blank lines, but on that page and throughout the book, the whitespace had been completely bolluxed.

I had to comb through every line of code in the book searching for errors that had been introduced. After several iterations, I think I got everything fixed.

And with that, finally the book was ready to be sent to print

To be continued…

Read previous parts.

The Birth of a Book: Part 17

Now we’re to the beginning of April. I received email from my project manager—the person responsible for the production of my book—in which was outlined these steps:

  • A copyeditor will ensure for grammatical correctness, consistency, style, and mark for any changes in the manuscript.
  • The copyedited manuscript will then be typeset and the page proofs will be sent for your review from 11th Apr.
  • I request you to review the proofs, mark the corrections, answer any queries from the copyeditor/typesetter, and return the annotated proofs to me by 18th Apr.
  • The proofs will also be sent to proofreader and to an indexer to compose the index.
  • As we have tight production schedule for this title, we would provide only one round of proof for your review. I request you to send all intended corrections at this time as this will be your only opportunity to check the proofs. I will ensure all the changes are incorporated to the final proofs. 
  • The final files will be generated and sent to the printer by 20th May.
  • The manufacturing process requires 8 weeks and the books will be published on 15th Jul.

As promised, I received the PDF proofs on the 11th. My assumption was that the copyediting process would be a fairly simple thing. I write reasonably well, and I’m a capable proofreader, so my writing has very few errors in it. To my horror, I found that more errors had been introduced in my writing than had been corrected.

I was unimpressed with the typesetting. The entire book was justified, which resulted in really bad word spacing. Screenshots had been poorly cropped. Strange decisions were made, such as putting a period at the end of every figure caption, even if it was just a title, such as “Years of experience.” The introductory paragraph to Part 1 was completely left out.

The introductory paragraph to Part II was there, but it ended in a widow. The final sentence was, “Buckle your seatbelt; we’re going for a drive.” The word “drive” wrapped to the next line. So, I highlighted the word and entered the comment, “widow”. I assumed I was dealing with professionals. I must have been wrong, because when I received the corrected proofs, the sentence read, “Buckle your seatbelt; we’re going for a widow.” They had marked it with a question, “Should this be ‘window’?” As if that makes more sense.

Those problems were annoying, but they were easily noticed and corrected. What really ate up my time was having to proofread my writing all over again. So many changes had been made. There were stylistic changes that had been applied inconsistently, as if different editors were taking on different parts of the book. I asked that these be backed out completely. They had no business changing my voice, especially if they weren’t going to be thorough about it. And whoever it was, they weren’t up on pop culture. I wrote a sentence in Gollum-speak: “Nasty embedded CSS. We hates it, yes we do, my precious.” My editor tried to correct it: “Nasty embedded CSS—we hate it, yes we do.”

Then there were changes to technical terms that they obviously didn’t understand. For example, anyone who works with code knows what a “diff” is. If you are going to compare two files to find differences, you would say that you are going to do a diff. You would never say that you are going to do a differential. 

It was aggravating. I had to spend many hours marking up the PDFs and entering comments. But, these changes didn’t hold a candle to the mess that was made of my code.

To be continued…

Read previous parts.

Book Launch

To commemorate the launch of my book, which is now shipping from Amazon and Barnes & Noble, here is the Preface.

As tends to happen with experience, my convictions have morphed over the course of my career. As a graduate student studying interaction design at Carnegie Mellon University (CMU), I was of the opinion that designers shouldn’t need to know how to code. We should have tools that give us complete freedom to create without requiring knowledge of the technical bits that are necessary to realize our visions. Looking back at my younger self, it seems hypocritical. I had already learned the technical process of offset printing—not enough to set up and run a press, mind you, but enough to know the difference between process and spot colors, how to specify them, and how to design a brochure with only two colors to keep the cost down. I knew that I had to include an extra margin if I wanted an image to bleed off the edge of the page. As it turns out, I had to learn a lot about the production process to be an effective graphic designer. Why did I not expect to have to do the same to effectively design for the web?

I was quickly disabused of the notion once I took a job with a software development firm where I was expected to hand over HTML that developers could cut and paste into their Java server pages (JSPs). My screens may have looked fine, but the what-you-see-is-what-you-get (WYSIWYG) editor I was using generated terribly ugly code. So it was that I began down a path that resulted in the book you hold in your hands now. But it isn’t just a book about code. More important than learning how to write clean Cascading Style Sheets (CSS) is learning how to integrate with your development team.

You see, when I was first hired by that small software development firm, I was set to work on a complete, ground-up redesign of their flagship product. This was to happen in parallel with the development team rearchitecting the product. The company was young, and I was inexperienced. I was advised by another designer who had been with the company since its inception to not show my work to the developers until I had polished it to perfection. I’m sure you already sense the train wreck that was coming. Sure enough, after months of brainstorming new features and iterating over pixel-perfect screen mockups, I presented my work to the developers, only to be told, “Hey, that looks great, but our architecture assumed the same functionality and a similar interface to what we have now.” They were too far down their side of the tunnel to come back for me, so my fully designed and specified user interface (UI) was shelved. I learned a valuable lesson the hard way, and since then, I’ve worked diligently to integrate myself tightly as part of the development team. Doing so has paid great dividends, and I’d very much like to share them with you.

I’ve now been working for that same company over 13 years, during which time I’ve been able to merge my design process with that of the developers. I use many of the same tools they use for task assignment, issue tracking, version control, and documentation. Where once upon a time I would hand over my designs to the developers for implementation, I now participate in implementation, ensuring that every detail of the design is translated correctly by contributing directly to the production code base. And that brings us full circle. If you want total control of your design, from its first inspiration to the day the finished product ships (not to mention future revisions), you have to participate in the entire development process. That means you should be able to write production-ready HTML and CSS. That’s why I decided to write a book that is one part down-and-dirty code tutorial and the other part ideological process and collaboration. Both parts give practical advice, some of which you can put into action immediately, and some you can begin to plan and build toward.

One person who has the skills of a visual designer, an interaction designer, and front-end web developer is often referred to in our industry as a unicorn—a magical, mythical creature and the object of many a great hunt. If you look at natural history, you’ll find many plausible origins for the legend of the unicorn. You’ll also find a number of creatures that, while not matching our perfect envisioning of a unicorn, are nonetheless creatures with four legs and a single horn. I posit that there are actually quite a few designers in the workforce who meet the base-level description of a unicorn; they just don’t have the opportunity or direction necessary to meet their full potential. Perhaps you are one of them? My sincere hope is that this book will be the incentive that leads you to take that next pivotal step in your career.

The Birth of a Book: Part 16

Selecting a different layout that would fit fewer words per page just to get a higher page count seemed like cheating. I decided to go back through the book and find parts that I could expand upon. There were a few topics that my reviewers suggested including, and there were places that I had purposefully limited the number of figures I was inserting because I was afraid I might end up with too many pages. Then, there was the additional exercise I was thinking about adding to my workshop.

My editor supplied me with the copyedited chapters, and I added content to every chapter except 1 and 6 the first week of March. Then I started on chapter 9. This one took a bit more effort to write, as it was all new content. The rest of the book had come from my conference talk and workshop. I was researching information for the chapter as I was writing it. I decided to include information about CSS preprocessors, JavaScript libraries, and test harnesses. I finished off the chapter with a test harness exercise. Brian Cavalier agreed to review the chapter for me, even though he had already fulfilled his contract with my publisher. I’m extremely grateful to him for that, which reminds me, I still owe him lunch.

The final chapter was written, reviewed, and revised by the end of March. I again felt the weight lifted from my shoulders, but I had gotten a glimpse at the copyediting that had been done, and I had a nagging feeling that I wasn’t going to be happy with it. Little did I know how bad it actually was.

To be continued…

Read previous parts.

The Birth of a Book: Part 15

I was finally granted permission to start telling the world that I was writing a book. It was time for Interaction 14, a perfect time to toot my horn. On February 2nd, I submitted my revisions of all 8 chapters and the final figures. Then I headed to Amsterdam. I got to discuss the publishing process with Jeff Gothelf, who forewarned me about the issues I might face during production. The book was a great conversation topic, but I’m not sure how much good the publicity did. I didn’t realize it would take another 6 months, as long as it took me to write the book, to get it printed and on store shelves.

It was during the conference that I was informed that I had to recreate all of the screenshots in chapter 7. It has to be obvious that they are screenshots to avoid copyright issues. This became a real hassle. Before I started writing the book, the authoring guidelines I was given told me not to include my figures in my document. Rather, I should just put in the figure numbers and captions. That wasn’t a problem while I was writing, but when I had to go back in and change the figures, be it adding, removing, or just moving, I created a lot of errors. It’s really easy to get a figure labeled incorrectly when you never see it in context. There were multiple instances in which I had to renumber half the figures in a chapter. I wouldn’t catch my mistakes until I received proofs back from the typesetter. If I ever do this again, I’m going to insert placeholder figures in my manuscript.

In the middle of February, my editor dropped the bomb.

We also received a page count estimate back  from our typesetter and the manuscript is coming in at 176 pages, which is a bit under what we had proposed. This is cause for concern as a low page count can affect sales etc. We have several options here, such as choosing a different interior template, with a slightly lower page count, that may increase the page number, or adding content, maybe even another chapter.

I had thought I was done writing. I was happy to be done writing. I was ready to enjoy a little free time again. Instead, I had to write another 25 pages.

To be continued…

Read previous parts.

The Birth of a Book: Part 14

Over the Christmas holiday, I wrote the conclusion, acknowledgements, dedication, glossary, and references. I also got the GitHub repository up. It was time to finalize the cover. We also finalized the title of the book, going from the working title, “UX and Web Development: Better Results through Integration with Your Development Team,” to “Bridging UX and Web Development: Better Results through Team Integration.”

As I worked on the cover, I was also attempting to get somebody to write a foreword for the book. The point of a foreword, as far as I was concerned, was to lend credibility to my book by having a recognized member of the design community endorse it. And additional requirement was that it be somebody that I know personally and respect. The first person I asked never replied. The second person declined. My editor contacted a list of people that I had suggested might provide endorsements for the back cover, but none of them panned out either. That was a little disheartening, but I felt confident enough in the usefulness and quality of my writing that I wasn’t too concerned about it. Yes, I would have preferred to have the support of some “big name” UX professionals, but to tell the truth, I don’t mind not sharing the cover.

By the end of January, the cover design was done, front and back, and I had comments back from my technical reviewers on all the chapters. It was time to make revisions and learn some lessons… the hard way.

To be continued…

Read previous parts.

The Birth of a Book: Part 13

The next three weekends were productive ones. Chapters 4, 5, and 6 were churned out in rapid succession. By the end of the Thanksgiving holiday, I had finished the last two chapters. That didn’t mean the book was done—far from it—but it was a major milestone, and only two weeks late of the contractual deadline. I get the feeling that the publisher was used to writers delivering late. Every time I gave my editor a status update, she thanked me  for trying so hard to stick to the schedule.

So, what was left to do? Well, a lot of the figures I included with my writing were placeholders. I wanted to create graphs that Tufte would approve of, and I wanted all of the screenshots to be sized appropriately. There was a diagram that I had only sketched out. Then there was the dedication and acknowledgements, the conclusion, a references section, a glossary, and the book cover. I was also required to provide abstracts and keywords for each of the chapters. And, of course, there were the reviews. I already had comments back on chapters 1-3 and 4 was being reviewed.

Now, one of the exercises uses the Amazon homepage as an example, so the book includes screenshots. These were the only figures that there was some question as to whether or not permission was needed. I was asked to contact Amazon about them. I contacted their customer service and was directed to send a draft to an Amazon Permissions email address. I did that and never received a response. Eventually, my editor told me that we could use them, but they would all have to include the web browser. I had cropped them all down to only show the content, so I was going to have to redo all of them from scratch.

Another exercise, which I pulled straight from my workshop, involves a layout for an address book, including contacts’ photos. For fun, I had used the fighter pilots from Star Wars: Biggs Darklighter, Jek Porkins, Dak Ralter, John “Dutch” Vander, Tiree, etc. I couldn’t have those copyrighted images in the book, of course, so I decided to acknowledge my coworkers—the developers and designers that have helped me to reach the point in my career at which I could write the book. I invited them to provide photos for my mock address book, which you’ll be able to work with in chapter 8. Those people are:

  • Rob Veltre
  • Jeff Christensen
  • Doug Fellner
  • Will Ross
  • Steven Schwab
  • Kelly Dolan
  • Joe D’Alessandro
  • Henry Burke

They’ve all been outstanding collaborators from whom I’ve learned much. Including them in the book is the least I can do to thank them for their contributions to it.

To be continued…

Read previous parts.

You might be interested in…

Amazon’s suggestions leave a lot to be desired. The past couple weeks, we’ve had ants raiding our kitchen, so I ordered ant bait that has worked well in the past. Now I have an entire row of ant killer on my page. I don’t need anymore. This past winter, I ordered a new pair of leather driving gloves. For months, my Amazon homepage was displaying pictures of male models wearing leather gloves. Just this past weekend, I received email from Amazon:

No, I really don’t need to order my own book, thanks anyway. Actually, to be perfectly honest, it gave me a little thrill to see it there, but I realize it’s just because I’ve looked at it several times of late.

Speaking of which, I’m now the proud owner of my own author pages on Amazon and Good Reads.

The Birth of a Book: Part 12

I was behind on my writing, but my editor wanted me to think about the book cover. The first time she had mentioned it, I had floated the possibility of designing it myself. They liked the idea. Of course, that meant that I had to find time to design the cover in addition to writing the content. The cover design probably suffered due to that fact. I went with my first idea, which we all know you should almost never do—not without exploring other possibilities. I already had the title slide from my Working with Developers talk—a photo I had taken of the New River Gorge Bridge in West Virginia. It’s a not-so-subtle metaphor for building a bridge between your designers and developers. Remember, at this point, we only had a generic working title for the book—“bridging” wasn’t in it. The cover would later inspire the title that stuck.

Having sent them an idea for the cover, I finished chapter 3 mid-October. Then I received three samples of interior layouts from my editor. To be honest, I didn’t care much for any of the designs. I was tempted to ask if I could design the interior as well, but I knew I wouldn’t have the time. I picked the one that I felt was the strongest. On the 30th, I had a PDF of my first chapter using the template I selected. I was asked to review it and provide feedback. At the same time, I was given the notes from my two technical reviewers on the first two chapters. I was beginning to feel like I couldn’t write the book for all the other things I had to do for it.

I was in the middle of chapter 4 with two weeks until the entire book—8 chapters—was to be done, and I was seeing a lot of issues with the way that first chapter had been produced. I decided it was probably hastily thrown together as a mockup, not intended to be production quality. Little did I know that it was foreshadowing the editing process to come.

To be continued…

Read previous parts.