The Coolest Class

Tonight began a new semester. I’m once again teaching game design for 16 seniors in Graphic Design at WVU. I’m happy to say that I am optimistic about this group. They seemed engaged and excited about the topic. Of course, that could have something to do with the fact that we kicked off class by playing games.

My family went on a mini-vacation to see my Aunt and Uncle at Capon Springs as a last hurrah before school starts. We drove home today, but timed it so we could stop in Morgantown for my class. Since I had my family with me anyway, I decided to put them to good use. I broke my class into 4 groups of 4 and assigned each group to one of 4 games: Munchkin, Gloom, Takenoko, and Betrayal at House on the Hill. I selected these games because each one has distinctly different mechanics and gameplay. My wife and daughters each took one of the games and taught my students how to play. After an hour and 15 minutes, two of the games were over, and two were still going, but I had to call time.

Not only was this a really fun way to start the semester, but it gives me examples that I can reference when talking about game mechanics, narrative, experience, themes, etc. throughout the semester. The exercise showed my students what truly great game design can do, broadening their awareness from the shallow pool of Monopoly, Uno, and Taboo.

Because I only have one classroom available to me, I ended up leading Betrayal at House on the Hill in the middle of a hallway. I was interrupted a few times by passersby who were intrigued, and ultimately jealous, that we were actually playing games in class. My students think it’s pretty cool too. I hope they retain their enthusiasm as they find that game design, while all fun and games, is also a lot of work.

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.

Stupid Form

I often encounter stupid forms with annoying validation. It’s rare that I encounter a form that does something I’ve never seen before. This one is a real treat.

I’ve never encountered an online form that breaks a street address into three fields. I can’t imagine why they felt they had to do so, but there it is.

Not only did they want me to split the name of the street into two parts, they made the “street type” required! What if the name of the street is just “Centennial”? You would be forced to add something. If they were then mailing something to you, would the address end up being “Centennial N/A”? This is just dumb.

Then I got to the phone fields. Check out the validation on this sucker.

It will only accept the phone number with the parens, space, and dash, just as it is shown above the field. If you put in something else, you get the message below. Notice that the format displayed in red does not match the required format at all. Idiotic.

Curriculum – Part 1

Carnegie Mellon University, my alma mater, has announced its new program framework, which has caused a bit of a stir, especially among those of us that are/were educators.

Way back when I was in high school, my art teacher told me I should look into commercial art. I soon learned that what I really wanted was called graphic design. When I was an undergrad, studying graphic design at West Virginia University, interaction design was the hot new thing. Multimedia CD-ROMs were garnering awards from the Communication Arts jury, and CMU had just founded the first masters program in the burgeoning field. Until then, a design generalist was a graphic designer that also made furniture. A design specialist was one that focussed on corporate identities or annual reports.

If you had asked me what I was doing when I applied to CMU’s masters program, I probably would have told you that I was specializing in interaction design. From my perspective, I had a general design education. I had taken studio classes in which we designed posters, logos, banners, stationery, and brochures. I took a couple semesters of photography. I had a class in letterpress and book binding. I learned how to use Photoshop, Freehand, and QuarkXpress. I learned about color theory, typography, and design history. This was all building on an even broader foundation of visual art: drawing, painting, printmaking, and sculpture. Against that canvass, adding some knowledge about how to make my graphic design effective on a computer screen seemed like a relatively small addition to my skill set.

Nobody was talking about user experience or information architecture. I hadn’t heard mention of service design or organizational change. Social innovation wasn’t part of my vocabulary. Design for good would have referred to doing a little pro bono work for a non-profit.

My perspective would change during my time at CMU.

To be continued…

In the Details: Load Missing Tweets

In the Tweetbot app, when you have missed a lot of tweets—say, after being on vacation for a week without cell coverage—the oldest ones are hidden. A bar is displayed where they would appear in the stream that says “Load Missing Tweets”. If you scroll the list so that the bar is in the top half of the screen, the arrow points up, indicating that if you tap the bar, all of the missing tweets will be inserted upwards, above the current scroll position. If you scroll the bar into the lower half of the screen, the arrow flips, and the messages will be inserted downwards, below the current scroll position.

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.