Hi - I've been lurking here, but this is too good a discussion to pass up. One audience for documentation that hasn't been mentioned is the QA group. As much as the developers, they need enough detail to develop test plans and make sure the app works as designed.
I agree with the comments that mostly developers focus on the pictures, so if there's a tricky bit I'll usually highlight it with some close-ups of that portion of the screen. Usually the developers are on a tight deadline, so an overly long document just isn't going to be read. For one of my longer term clients, I've taken to providing static HTML pages and accompanying CSS, with some JS libraries plugged in to show parts that animate. The skill level among the developers when it comes to CSS is pretty variable, so many of them appreciate not having to tackle the layout and styling issues. It also means that the colors and fonts don't need to be in the spec - they are available in the prototype. Obviously, the developers don't use my JS code, and they replace the static items with Java calls, but the process has been working well for everybody. I'm curious though - for things that animate, appear and disappear, are people detailing these behaviors in a document, and if so, how? ________________________________________________________________ Welcome to the Interaction Design Association (IxDA)! To post to this list ....... [EMAIL PROTECTED] Unsubscribe ................ http://www.ixda.org/unsubscribe List Guidelines ............ http://www.ixda.org/guidelines List Help .................. http://www.ixda.org/help
