Lots of vertical-app requirements We hope evaluations of systems and tools from developers will refer to elements of this template as a way of demonstrating how closely these systems approximate a true OHS. See especially the terse listings for "end-user systems". Also see this evaluation of the Web based on Engelbart's requirements.
draft project plan (Oct'00) http://www.bootstrap.org/a2h/BI/2120.html Phase1 = Hyper Scope (lightly modified web browser supported by an "Intermediary Processor" (IP) which operates between the browser and the files or data bases holding existing working knowledge of a collaborative community) to build OHS features on top of legacy systems. I'm not sure that's the right approach.
mailing list archives: http://www.bootstrap.org/lists/ba-ohs-talk/
Lots of WiKi people.
this message doesn't sound promising (Mar'02)
I can't find a good document describing how users will behave when using OHS in the course of targeted collaborative activities. Which makes it hard to think about the designed solution.
If I were doing the macro planning for OHS (pardon the hubris), I'd
document richly some potential behaviors, rooting them in useful business outcomes (User Scenarios) (e.g. this team has a vision for a new business, but they're refining their vision while trying to simultaneously execute on it, here's the kind of intellectual activities they're engaged in, and the resulting collaboration issues). I'd also hit some of the environment issues which constrain the design (some team members are contractors working offsite: they'll use the host-company's web-based tools for some things, but have their own email client and outside email account).
- now design some collaborative behaviors for that team based on the smallest possible set of new features wrapped around those base standards/tools.
- then plan how to build those features. This could be prioritized to deliver some benefits in a relatively short period of time, increasing incrementally.
Doug's model seems to come out of the BigCo pre-Web days of companies willing to spend dollars and man-hours on projects with no coherent process to lead to ROI. I think those days have passed, because (a) even the BigCos are too busy (in some senses) and financially focused for this kind of investment, and (b) since the Web they have lots of alternatives for tools (and their working teams are less willing to be forced into some big corporate process when such tools are available).
And I think the Hyper Scope (an app to layer OHS features on top of legacy systems/content) could be a huge distraction, esp. given the implicit need to deal with MsOffice files, which are undocumented and subject to format change.
I think the Bootstrap Institute should (maybe in addition to their current/core approach) provide more overall direction in terms of requirements (this is probably sufficiently documented already) and architecture/protocols (e.g. use RDF? what schema?). In other words, try to define an ecosystem in which groups could develop smaller apps meeting their highest-priority narrow needs, but with an eye toward later integration with other tools.
(Comment from someone else) I see some overlap with intentions and design of the Askemos project.