[…] what I'm thinking of is essentially: > > > - TiddlyWiki model (local copy of a project plan, as a single-file app. > running in a browser) > > - An interface that's more attuned to project management (checklist, > action item list, expandable fields for details, Q&A, other info associated > with each checklist) > > - Linked via a P2P protocol - update a local copy, updates propagate > automatically to other copies of the document > > Work flow comes down to: > 1. Generate an initial "checklist" in a browser > 2. Email to collaborators. > 3. Updates flow automagically rather than having 100s of follow-up emails > show up that have to be sorted through and reconciled. >
I'm interested in this (and as I'm home today looking after my sick kids, I have some time to reflect on it :)). In this situation, where you're trying to tie together multiple contributors, the success of the thing I think will boil down to how well it fits with each person's work flow. That's what will change it from a reporting obligation to a useful working tool. That's interesting because people working on the same thing can still have very different conceptions of it. For one person, week long sub-project A is the final expression of their last two months of work on a feature; for another, project A might be the middle of their six month UI revision project. My guess is that the difference will be in the high level data model — or perhaps 'object' model — that's imposed on the users. Having nothing imposed (which I guess would just be simple checklists, and plain wiki content) means people will want to define their own structures. That could work, if the project-runner sets up a good clear structure that suits the project, but might end up with each person defining their own preferred (and incompatible) structures. Having a rigid, more detailed structure imposed by the tool might suit person 1 but not work for person 2, or worse, not really suit anyone. So my first naive thoughts are that the big challenge is to distil out the right set of common elements across all projects, carefully name them so people use them the right way*, and implement support for those project elements so that each contributor can use it the way they need to get their job done. (* I always care a lot about the names of things, perhaps overly much.) Anyway the point here is - for anyone who made it this far - I'm looking forward to seeing what you come up with, with respect to the built-in structures. ;Daniel -- Daniel Baird I've tried going to the XHTML <bar /> a few times, but it's always closed. -- You received this message because you are subscribed to the Google Groups "TiddlyWiki" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/tiddlywiki?hl=en.
