Real-World Background and Relevant Theory leading to problem statement:

There are a multitude of groupware solutions available. Some are Web based and some are not. But they are for the most part in support of communities which are paid to work together and meet physically.

Communities which do not meet and are not paid to work together (ie. not in the same company) are relegated to having 'community portals', chat, email and message boards/forums.

There is no integrated environment which supports people working on the same goal and who are maybe working in their spare time.

 
Problem Statement:

The problem, and project will be to gather a set of requirements from knowledge workers who work in the computer industry and have a need for and sense of distance collaboration, put together a spec and a prototype and further refine all three in a second major round.
 
Main Questions which will have to be answered include:

• What is the main problem we are trying to solve? "We have a tendency to focus on the solution, in large part because it is easier to notice a pattern in the systems that we build than it is to see the pattern in the problems we are solving that lead to the patterns in our solutions to them." (Ralph Johnson quoted in Software Requirements & Specifications, Michael Jackson 1995).
   
• What are we trying to augment? People in groups access information through the Internet, thinking, and communicating, using the Web as the main initial front end, also utilizing email via mailing lists,Web publishing, with provisions for future media and technologies, within an explicitly evolveable framework.
   
• What actions are we working to augment? See the Augmented Actions Overview document.
   
• What are the social and technical implications?
  • How can online collaborative work be kept on 'track'?
    • Relatedly, how can online collaboration change direction to become ever more fruitful to the purpose of the work?
  • How can information best be readily accessed later (recorded dialogue, intelligence etc.)
  • How do different components (email, newsgroups, forums, to do, authoring & reading, browsing and document repositories) add to and degrade group collaboration?
  • How is a sense of community fostered?
  • What do major thinkers feel?
    

 
Initial Main Tools will be:

Initial scope will basically be enhanced web browsing and mailing list:

• Email via Mailing List.
• Enhanced Web Browsing.
• Enhanced Web Publishing.

 
Future Main Tools will have to be able to include:

•  
• Collaborative, hierarchical To Do List.
• Document Repository (FTP, versioning control).
• Chat.
• Calendar sharing.
• Hypermedia Document Authoring. Tools to build your Core document.
• Hypermedia Browsing environment - All levels of documents/files etc.
• Hypermedia Browsing environment - Reading basically.
• Must be able to include future media types including voice, video and 3D.

 
Initial Requirements:

• Focus on augmentation, not on simplistic ease-of-use.
• Entirely Web based initially.
• Must be expandable in the future to include different kinds of data.
• Must be expandable to include full applications and environments.
• OpenSource.
• Complete OHS functionality and philosophy.
• Complete ZigZag integration.
• Vertical, highly encapsulated and explicitly documented code base.
• Emphasis on relationships, context and access from to anything through anything in any way..
  

 
Aims (what the project sets out to do):

The aim of this initial project (MSc paper) is to provide a solid foundation for implementing a cynapse.org environment.

The aim of the cynapse.org environment will be to provide the next generation of information environment for he end user as described in the www.liquid.org/manifesto and a developer environment with which will empower the programmer to work in a dynamic, cooperative environment unlike any seen today, while making the distinction between end user and programming smaller and smaller.

 
Objectives:

Understand what exists in the marketplace, what's available in the literature and what the real requirements are for a usable and utilized online communications environment are.

The Requirements Document will come from structured and un-structured interviews in person and via email primarily focusing on the Bootstrap community in California.

 
Method:

Interview the user community (requirements capture) while reviewing the literature and marketplace resulting in the issuing of 'Requirements Document V1' get feedback.

Issue 'Requirements Document V2' edited based on feedback.

Build and test prototype.

 
Intended design/method/analysis/Deliverables:

• Existing OHS Documentation
• Existing OHS Documentation
• Development Environment
• Available enabling technologies
• Literature Review
• Marketplace Summary
• Requirements Document V1 ~ Compiled
  Requirements Document V1 ~ Rec. By Person
• Requirements Document V2 ~ Compiled
  Requirements Document V2 ~ Rec. By Person
• Requirements Document V3 ~ Compiled
  Requirements Document V3 ~ Rec. By Person
• Initial Spec (not promised as this may cost programming time)
• Prototype Mock-ups
• Specific lessons learnt and specific recommendations
• Main questions covered
• Evaluation of mock-up
  
  All presented in a continuously evolveable hypertext document online, allowing for feedback while the project is ongoing as well as printed reports.
  

 
Schedule:

May
Organize Project.
Get initial opinions.
Conduct Marketplace Review.
Conduct Literature Review.

June
Conduct Requirements Capture.
Generate (user and data) walkthroughs and HTAs.
Build Requirements Document V1. Invite further comments.
Build visual prototype (split screen with notes and feedback form). Evaluate comments/test speed.

July
Continue with revised Requirements Capture document.
Build Initial Spec and invite further comments.
Build prototype in HTML & JavScript with some server-side Java. Evaluate comments/test speed.

August
Contingency time.

September
Complete Requirements Capture document.
Complete Spec.
Complete, polished prototype.
Write recommendations.