2011/2/23 Yuval Levy <<a href="mailto:create07@sfina.com">create07@sfina.com</a>> <div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div class="im">On February 21, 2011 03:32:18 pm Gregory Pittman wrote: > > very interesting idea to write the manual first :) > > If we do this, it would be nice if some could show some prototype ideas > of what this might look like or how this might work. What would the > workflow be? How would documenters interact with coders? </div>this discussion about writing the manual first has been going on for a few days now... and nobody has mentioned things such as mock ups or functional specifications? Well written specs are like a very detailed manual but you don't want to unleash them on the user because of too much detail that is relevant to analysis and coding but not to usage. It's a chicken and egg problem. or a feedback loop. First there is a vision. It is analyzed, dissected, recomposed and fleshed out; articulated into specifications including screens mock ups and functional specs. Then it is implemented into code and manual. The processes are parallel and influence each other, with close/fast feedback loops. In an ideal world the initial analysis is so perfect; both coders and copywriters get it the first time so that when the software and the manual are delivered to the users, all they can say is wow! In reality nobody is perfect. The analysts are likely to miss something in the func specs; the coders are likely to interpret / implement different than intended; the tester are likely to find new ideas that would significantly influence the vision that the analyst had not thought of in the first place; and so the stage is set for the next cycle leading to v+1. Simply taking a user manual as a specification document is not enough. If it is, that manual is not user-friendly. There is no perfect workflow either, just put the people in the same room and get them to talk, talk, talk, until they understand each other, develop a common sense of purpose and leverage each other's skills. But it is not a user manual to drive the development. It is use cases, analyzed and articulated into mock ups and func specs. </blockquote><div> Thanks Yuv for putting this into words. I guess we can say that LGM is a good place for that. Put the people in one room and get them to understand eachother. Now, that's a plan ! Louis </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Yuv _______________________________________________ CREATE mailing list <a href="mailto:CREATE@lists.freedesktop.org">CREATE@lists.freedesktop.org</a> <a href="http://lists.freedesktop.org/mailman/listinfo/create" target="_blank">http://lists.freedesktop.org/mailman/listinfo/create</a> </blockquote></div>