I am knee-deep in my first home renovation. My latest project was to replace all of the trim—around the doors, floors, and windows—which, while labor intensive, sounded to me like a simple enough project. After ripping out the old stuff, I found that my seemingly well-installed floors were anything but. The floor was inches away from the wall, and none of our doorjambs were actually connected to anything. I thought I had one big job ahead of me, but it turned out I had three. Whoever did the work the first time took the easy route, leaving me with extra work.
Making a website is more complicated than it used to be. We have to work around unanswerable questions, like at what dimensions the site will be viewed or how many pages it will have. As websites evolve and their list of variables and technical requirements grow, they become harder to define. Static wireframes and site maps can’t always capture this necessary level of detail without mountains of paper or endless annotations. Enter—stage left, waving like Miss America—the HTML prototype.
Last week, Greg Storey and I attended the Senior Exit Review at Texas State University. We were both blown away by the quality of work and were incredibly jealous that these students got to learn so much about the web in college. It made me think back to when I graduated and how confused I felt about, well, everything. Looking back at what I’ve learned since then, I came up with the following list of what I wish someone had told me at the time:
The process of making a website used to be like an assembly line. It was a series of hand-offs with each team member contributing his/her part before giving it up to the next person. Like a game of telephone, the same content was passed from person to person, and, at each step, it took a slightly new form. What started as a glimmer in a client’s eye became a sitemap, then a wireframe, then a Photoshop file, and eventually it became code that went to live in its final resting place, the browser.