Defining the Scope of the Project

In studio today we defined the scope of our project. We explained the idea to Mark and he didn't have any problems with it. I drew this as a map of our ideas:


This is my understanding of the scope of our project:
A user creates, or is invited to be a group member of, a project. The number of users working on a project is not limited. The number of projects a user can be involved in is limited to 3, or unlimited for paying users. Users can leave projects if they no longer want to be involved. If all of the users involved in a project leave the project, the project is deleted. Projects have a name and a last update time.

When a user has write permissions on a project he/she can do the following:

• Invite other users to a project. They are automatically added to the project (no approval required).
  
• Add an item to the to-do list of that project.
• To-do list items have a name, a due date (optional) and person/s responsible (required for group projects, and automatically set for individual projects).
• Users can set items to be either in progress or completed.
  
• Add a document to the project (could be an image, word file, PDF, etc)
• Documents must have a name. The name should be editable by any user with write access (using AJAX - similar to the status change feature on Facebook).
  
• Documents must have at least one version, but possibly many versions uploaded by different users. Versions must have a system date. Old versions are still accessible, but can be deleted by any user with write access.
• Write a comment in one of two places - on the main page of a project (where the to-do list is located), or on a document page (i.e. "I like that version you just uploaded Fred").
• Comments have a time and a body. They are not sorted into threads.

When a user has read permissions on a project he/she can do the following:

• View the to-do list, documents and all comments. Nothing is hidden from them, they just can't change anything or write any comments.

When a user is a member of a project (with either write access or read access), here's the added benefits they get:

• They will be notified in a 'news feed' whenever a new version of a document is uploaded. The notification will remain in their 'news feed' until they open the document page.
• New to-do list items will have a star next to them the first time the user sees them.
• They will be notified in a 'news feed' whenever a to-do list item is assigned to them as the person responsible.
• They will be notified in a 'news feed' whenever a new comment is added to a document or to the project.
• New comments will have a star next to them the first time the user sees them.

Users might have a number of projects on the go at the same time, so when they log in they see a 'dashboard' page with recent info from all their projects. This is what users can do on the 'dashboard':

• Create new projects or remove themselves from old projects.
• View their 'news feed' containing all notifications.
• See a to-do list of items they are responsible for, across all of their projects.
• See a visual representation of due dates (i.e. a calendar)

We also brainstormed for names of the project. Here are some of the ideas: projector (or projectr), project now!, chalkboard and tabletop. Some other words that are related to our project that could make up part of a title are: student, schedule, learning, books, time, calendar, project, planner, desk, web, lab and table.

Over the next week I am going to design the database, Justin is going to make a Gantt chart to illustrate our project schedule, and Long is going to work on the project plan documentation.