ICE Interdisciplinary Collaboration Environment

1
ICEInterdisciplinary Collaboration Environment

• Team Members
• Akram
• Patrick
• Maetee
• Phichet

2
Introduction

• Title
• Interdisciplinary Collaboration Environment ICE
• Description
• A research project collaboration tool for
  universities and colleges
• Need
• No dedicated solution to the problem exists
• Client
• MU-ACM and Chris Topinka

3
Project Background

• What is the problem?
• University and college research projects are
  currently maintained in scattered websites,
  e-mails and departmental newsletters
• Very limited awareness of research conducted by
  other departments
• The result is many opportunities are unseen

4
Project Background Cont.

• What exactly is ICE?
• A web-based system
• Maintains database of research material and
  project information
• Provides information sharing and collaboration
  opportunities
• Who uses ICE?
• Graduate Students working towards masters
  degrees or PhDs
• Professors working on research
• Undergraduates interested in working on projects
  or with professors

5
Project Background Cont.

• Are there any solutions currently?
• Open source or commercial Content Management
  Systems (CMS) such as Mambo, Drupal, Plone and
  Sharepoint
• Why not just use a CMS?
• CMSs are very general and need to be configured
  before they offer any real use
• Only a small amount of professors or researchers
  have the technical expertise to configure such
  systems
• Unless a system is adopted by a large entity such
  as a University or College, the problem of
  interdisciplinary collaboration is not solved

6
Plone
plone.org
7
Drupal
drupal.org
8
Mambo
mamboserver.com
9
Sharepoint
microsoft.com/windowsserver2003/technologies/share
point/default.mspx
10
Project Background Cont.

• How will ICE solve the current need?
• ICE will be built to specifically address the
  needs of the research community.
• ICE will be easy to deploy and will not require
  much expertise to configure or use
• Potential problems when building the system
• Additional requirements or change in requirements
  might occur during implementation
• Some desired requirements could be conflicting
• Different departments or colleges might have
  special requirements for maintaining data

11
Market Analysis

• Cost of Technology
• All software technology used in this project is
  open-source or freely available
• ICE can be deployed on any server that supports
  the software technology used
• ACM will be providing several software titles and
  server space
• Could ICE be sold?

12
Constraints

• Technological
• ICE will only function on servers. The server
  must be running the correct versions of MySQL and
  PHP.
• Performance can be affected by quality of server
  running ICE
• Social
• ICE is community driven software. Without a
  community of users, ICE performs only a portion
  of its functions.

13
Literature Review

• Advanced Indexing and Retrieval in Present-day
  Content Management Systems
• Metadata generation upon media acquisition
• Advanced editing of Metadata
• Splitting media into arbitrarily sized chunks
• Multilingual queries through translation engine

14
Literature Review Cont.

• DynG Enabling Structured Non-monolithic
  Electronic Collaboration
• Protocol geared toward dynamic groups of
  collaborators
• Defines rules for creating and answering
  questions, defining groups, performing user
  actions
• Can be implemented through many technologies

15
Literature Review Cont.

• A Knowledge Sharing and Collaboration System
  Model based on the Internet
• A protocol which would link many unrelated
  servers together for data sharing from knowledge
  bases
• Capable of converting data into XML so data can
  be used in a variety of environments
• Emphasis on speed and transparency to user

16
Literature Review Cont.

• Content Mismanagement Systems
• Argues that URLs generated by many CMSs are not
  human-readable
• Makes general argument of inconvenience to users,
  regarding book-marking, exchanging and following
  links
• Potential harms include hampering of
  viral-marketing, and willingness to follow,
  preserve links

17
Literature Review Cont.

• Plone and Content Management
• Describes in detail the merits of Plone as a CMS
• Designation of content as specific type,
  attributes
• Structured Text editing
• Customizable visual component
• Extend functionality through plugins
• Building ICE with Plone is very feasible

18
System Components

• Technology
• MySQL
• PHP
• Standard Web Technology (HTML, CSS, JavaScript)
• Recommended Possibilities
• Python
• CMS (Plone, Mambo, Drupal)

19
System Components Cont.

• Users
• User
• The basic user Can create and maintain projects,
  communication, collaboration requests
• Admin
• All the abilities of the User, control of all
  configurable options

20
System Components Cont.

• Components
• Project
• Stores all relevant information regarding
  research projects such as title, participants and
  departmental affiliation
• User
• Stores all relevant information regarding users
  such as name, title, additional biographic
  information, current projects

21
System Components Cont.

• Components
• Collaboration
• Stores all relevant information regarding job or
  assistance postings, such as referring Professor,
  job description, time frame
• External Users
• No information is stored regarding external
  users, but they are allowed to view certain
  portions of ICE

22
System Components Cont.

• Components
• Hierarchy
• Maintains the hierarchy of all the universities,
  colleges and departments affiliated with a
  particular installation of ICE
• Keyword
• Stores and maintains user specified keywords0

23
System Components Cont.

• Components
• User Interface
• Allows for use of the ICE system
• Communication
• Allows for sending and receiving messages to ICE
  users from within the system, and for leaving
  comments on projects

24
System Diagram
25
System Design

• Waterfall, Spiral Model hybrid
• Specifications are defined, hence waterfall
• Revisions and examination of current
  implementation will be needed occasionally
  throughout development, hence spiral

26
Goals and Objectives

• Initial Prototype
• Provide a useful tool for MU-ACM and the Computer
  Science department
• Ease of use
• Simplicity of system
• Easy to deploy and configure
• Future
• Expand to many colleges and departments within
  the University of Missouri
• Possibly expand to multiple universities

27
Advantages

• Designed for non-technical users so a wide
  audience can benefit from the system
• Provides unified environment for sharing data and
  collaboration between projects
• Increases communication between users
• Easily deployable

28
Disadvantages

• Specific application built for specific type of
  client and environment
• Some professors may not want to use the system at
  all, harming the collaboration element

29
Questions