Well, There are methodologies that are already being used. Basically, the whole field of information architecture and the whole process of wireframing/prototyping/testing is all about documenting strategy. Coding (should) happens only after that.
We need open tools for interface prototyping. If possible, they should be web based & DVCS (as in Git) enabled. This is something I discussed with Dave Crossland last summer at Debconf. Dave has some cool ideas in this subject. So yes, I would say the pre-manual should be prototype based. Should we start thinking of focused prototype-sprints? This is short but has a nice example: http://www.azarask.in/blog/post/write-the-manual-first/ Mushon Zer-Aviv Mushon.com | Shual.com | @Mushon On Feb 21, 2011, at 7:41, "[email protected]" <[email protected]> wrote: > I totally agree Mushon. Totally. Manuals are dead. Atrophied. Even > worse when they get printed. > > Yes, totally, make future manuals, then fill in the blanks to them. > > That is totally the approach I took in participating in the open web book: > > http://openweb.flossmanuals.net/ > > There is a book sprint in Toronto by adam on the web from the 7 - > 12...should talk with adam to see if possible to do one at LGM before > or after. > > So what would the future manual look like? Ideas for that? > > Jon > > On Sun, Feb 20, 2011 at 11:30 PM, Mushon Zer-Aviv <[email protected]> wrote: >> >> >> On Feb 21, 2011, at 4:17, Gregory Pittman <[email protected]> wrote: >> >> All fodder for discussion at LGM. Certainly we need to get out of the dark >> ages of documentation as an afterthought. >> >> Greg >> >> This is actually a huge issue I recently discussed with Adam Hyde of Floss >> Manuals. FM was initially established to address a blind-spot for Floss — >> documentation. It developed the book sprint documentation methodology which >> I am sure you guys are familiar with. >> Last year I participated in "Collaborative Futures" the first book initiated >> by FM that was not documenting a procedure but describing the past, present >> and future of open networked collaboration. It was much much harder, but >> there was something there that really clicked. And after a second sprint on >> the book I actually think it's a quite recommended read. (and it is always >> available for further editing) >> What I proposed to Adam is that FM could start experimenting in writing >> manuals for software that was not developed yet. Basically asking "how would >> we like it to work?" before we say "this is how do you need to use it." This >> would actually be addressing another blind-spot for Floss which is >> strategy. >> I know Adam is really excited about this idea and maybe LGM could be the >> first place to try it out. Do consider it would probably not work the first >> time and would need some iterations but it could be a much needed >> intervention into a process that we all agree needs some challenging. >> The infrequent lurker, >> Mushon Zer-Aviv >> Mushon.com | Shual.com | @Mushon >> _______________________________________________ >> CREATE mailing list >> [email protected] >> http://lists.freedesktop.org/mailman/listinfo/create >> >> > > > > -- > Jon Phillips > http://rejon.org/ | http://fabricatorz.com/ > chat/skype: kidproto | irc: rejon > +1.415.830.3884 (global) | +1-510-499-0894 (sf) _______________________________________________ CREATE mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/create
