rmurphey

Lessons Learned from Taking On a Project in Crisis

Posted

I just got done with an emergency project for an agency developing a public-facing application for a mutinational technology client you've most certainly heard of. I developed the entire front-end -- HTML, CSS, and JavaScript -- for a non-trivial application with a limited spec in just seven days. The experience was so eye-opening that I feel the need to write down some of the things I've learned, in hopes that I can benefit from my experience in the future.

• Demand all technical source material up front, such as functional specs, mockups, work that's been done to date, etc. Give the client a fixed amount of time to deliver that source material, and don't make a decision about taking on the project until you've seen it. What the client can deliver in that fixed amount of time will shed a lot of light on the state of the project and whether their expectations are realistic.
• Set clear time expectations. Am I willing to work 16 hours a day? Am I expected to? Are there hours during which I'll be expected to be available? Am I willing to work on the weekend?
• Find out whether the client expects me to be available after the imminent deadline, and to what extent. The last thing I want is to snatch defeat from the jaws of victory by being unable to support the code I've written.
• Do not accept responsibility for commitments made on my behalf. The recruiter said I'd be available six hours a day when I told him four? Not my problem. The client committed to having a feature ready for review without consulting me? They probably won't make that mistake again.
• Ascertain the rest of the team's commitment to the project. If I'm expected to work long hours, will they be there during those long hours to get me what I need? Are there any constraints on their availability?
• Establish a single point of contact at the client, and make clear I'll be depending on them to get me any information I need and I'll be treating their decisions as final. Insist that they participate in all calls I'm expected to participate in.
• Limit the amount of work I do before I have access to all client systems I'll need access to: version control, testing environments, ticketing systems, etc.
• Insist on a ticketing system. I'm new to the project and I have a lot to get up to speed on. I don't want emails flying at me from all directions -- decisions and technical requirements need to be documented in a single place that everyone can see. This is my only insurance when someone wants to know why something isn't done, or why it wasn't done the way they expected.
• Insist on version control, even if it's something crappy like CVS. I'll need a way to make sure the rest of the team has access to my latest and greatest. FTP blows, especially when I'm FTPing to a server where another developer is constantly deploying a new build, overwriting my work.

What other advice do you have?

Notes on handing off a design to a front-end developer

Posted

I've been spending a lot of time lately turning other people's designs into working websites, and often there are a few rounds of back-and-forth before I have everything I need. Some notes on must-have pieces before I can begin work: Design

• Custom fonts. If the design includes fonts that aren't on this list, then either the designer needs to provide a PSD that has all instances of the font being used in the design, or else I'm going to need the font file in order to create them. (There may be licensing issues here, which I leave as an exercise for the reader. In print land, we were allowed to provide the print shop with the fonts required to produce a printed piece, and the print shop was not supposed to retain them once the print run was complete. I imagine something similar applies to web production.)
• Navigation state information. What should navigation elements look like in the up, over, and current states? Ideally I'd like to see all of the buttons in each state, but if the variations are simple then I can probably make them myself.
• Link state information. What color should links be? Should they be underlined all the time, or only on hover? What color should they be when they are hovered? When they've already been visited?
• Form treatment. If the site has any forms on it, what should form elements -- text inputs, submit buttons and input labels -- look like?
• Typography specifications. Decisions about these can dramatically affect the feel of the site, and you may not want to leave them up to me. Specifically:
  • How big should body copy be?
  • How much space should there be between body copy lines? (Normally the "line-height" is set at 1.2 times the size of the font; increasing this can make body copy more legible.)
  • How much space should there be between body copy paragraphs?
  • How should headings be styled? How big should primary and secondary headlines be relative to the body copy?
  • How should lists (ordered and bulleted) be styled?
• Imagery specifications. Like typography specifications, these considerations should be made carefully, as they affect the feel of the site. Specifically:
  • How should text wrap around an image? Should the image float to the left, with copy wrapping around the right? Float to the right, copy on the left? Leave it up to the user?
  • If an image is floated to the left or right, how much space should be between it and the text?

Documentation

• Approved content documents. Personally I prefer a single content document per static page that needs to be created, and a content sample for any dynamic pages that will need to be created. If there are any repeating elements in the design that require content, I'd enjoy getting a document that contains their text as well. Lastly, if there are any dynamically generated content items -- for example, a list of latest posts -- I'd like a document that shows me how these should be formatted. This will help me:
  • Make sure I've accounted for the pieces of the content and how they fit together.
  • Know that all content has been considered, reviewed and approved, so there shouldn't be too many surprises later.
  • Reconcile the content documents with any other documentation I've received.
• Functional spec document. Let me know what should happen when someone fills out a form. Let me know how the items in the sidebar should be gathered. Let me know where that video's going to come from. Basically, anytime I ask "Where does that come from?" or "What does this do?", the functional spec should answer that question. While a functional spec should be initiated long before the design is complete, it is good to review the design and make sure those questions are answered. A functional spec should also include a sitemap.