On Monday 23 July 2007 14:15:04 Mimi Yin wrote: > Hi Davor, > > Thanks for taking a peak. > > It might make more sense to think of the vision document as a paper > on the wiki. Perhaps I should work on an intro paragraph that makes > that clearer.
I think having an intro paragraph that lays out the vision at a very high level would be even more useful to get people to read it. Kind of like an abstract for a paper. (Which is all that most people actually read in a typical academic paper. :-) Something like: Our goal with Chandler is to support the way people actually work. When collaborating in small groups and managing information, most tasks are solved iteratively [...] Existing productivity software tends to force the user into a much more rigid and static [...] Chandler's goal, on the other hand, is to support flexible workflows people employ to manage, process, and organize information. [note different channels of communication?] It's important that the first sentence be really punchy, I think. Not that what I have above is necessarily all that hot -- I primarily wanted to illustrate how much could be covered in just 100-200 words. Next, in the body of paper, I was somewhat disoriented by "context switches" between problems with the data flow, the lack of support for iterative information processing, and multi-faceted organization of information. Since there are multiple points, they should be enumerated right from the beginning, and be easily visible in the structure of the document. E.g.: Who - the user - the first half and the last two paragraphs of the current "preview target users" section (leave their problems for the next section) What - the problem - methodology (what's in the current "Design approach" section?) - pull together all problems, organized in say three main areas 1. 2. 3. How - the Chandler solution - hit every point from the previous secton and show how Chandler fixes/will fix what's wrong with present tools 1. 2. 3. (This is just an example, the most important thing is to have a strong structure that makes it easy to grasp the crucial points.) Another advantage of this organization is that Who-What-How sections can each go on a separate page. (While it would make sense to have them together in a downloadable PDF version linked somewhere visible here, I believe that it's nicer to read web pages in smaller, more self-contained and easily digestible chunks.) Also, I think it's great to have a few "reality checks" and note, as you do now, where Chandler is in the Preview wrt. the vision, vs. what's planned Post-Preview (but pre-1.0?), vs. longer-term horizon (asymptotically approaching the vision's goal :-). It would probably make sense to keep these piecemeal in the How section as a relevant feature comes up. (Maybe pulled out into sidebars?) Also, there would need to be a conclusion -- what's currently in "Chandler as a system" would probably work fine for that. > Our other alternative is to go with something list this: > http://chandlerproject.org/Projects/NutshellCartoons > Less concrete and less explicit, more a series of teasers that you can > dig into more if you want to. These are cool and contain a wealth of information, but it's much harder for an outsider to pull them into a coherent vision on first read when they're organized like that. Not that they don't have a place in the wiki, and at least some of them them could be linked to from the Vision page as further reading. (Either at strategic points in the text, or collectively at the end.) I hope this is helpful, Davor _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "General" mailing list http://lists.osafoundation.org/mailman/listinfo/general
