create new tag
view all tags

Project 3 - Team Project

Interactive Web Page Project
Web Chat or multi user web game (Tic Tac Toe, Pong)

UI Design: February 13 - 11:55 pm
Arch Design: February 17 - 11:55 pm
Risk Mitigation and Demo: February 22 - 1:00pm
Final Project: March 1 - 1:00 pm

Moodle Link

Chat.jpeg TTT.png pong.png


The goal is to create a web based program that allows two people to interact live through a web page. The idea is to have the web page talk to a server program (much as in project 2), but have two connected web pages, such that the web pages interact with each other.

The project is open to a varity of applications, but you will need to work very quickly if you want to choose, and get approved, something not in the list above.

For text chating or Tic Tac Toe you will not to do anything with animated graphic. This is the suggested route unless you have a real interest, and some back ground, in animation. If you want to do animation I am suggesting the KineticJS platform Some examples are given here for graphical programs using KineticJS: link Also see the Tutorials.

The basic idea is to design a program to allow two users to interact through the web server program. However, normally a web page is not automatically updated. However, a script can be written to call the server on a regular basis to get updated information. An example of a web pages with a simple function that gets called every second is here. There is also a project that displays processes dynamically on the cslab server. Try it here: https://cslab.kenyon.edu/class/softdev/skon/active.html. The project is in github here: https://github.com/jimskon/processList.git

You are to keep this version of the system simple - focus on basic functionality. Only two users should be supported, with no extra features. Extra features will be added in project 4.

You will be required to use GIT for all files in this project. This will be introduced in class.


  1. Project selection, user interface design, system features and use scenario: (Due Feb 10) Your team will need to decide what kind of project to do, design a good user interface, and list the major user features (requirements from the users perspective). This should include a visual mockup. If you are doing anything that requires interactive graphics (like pong) you will need to prove that you are able to do this by turning in a simple mockup that does runs on a single page on Feb 10 as well. You can use LucidChart for your drawings. Turn in:
    • The User interface mock up (from LucidChart)
    • A bulleted list of user requirements (should be short, 2-5 features)
    • A user story (scenario) - a paragraph describing what steps a user will go through as they use the system.

  2. Architectural Design and Communication Protocol: (Due Feb 17) You will design the archtecture of your program. Below is a sample architecture created with Lucid Chart:
    The goal here is to think trough ALL components, and create a drawing showing the components. Then write a short narrative that describes the purpose and fuctions of each component, and the data or control that the lines between the components means.

    Communications protocol: The second goal is to design the form and syntax of how the components talk to each other. You will need to explain how messages are formatted to be unambigous, and how they will provide the necessay information to allow the system to work. More about protocol design here: Communication Protocols

  3. Risk Mitigation and Demo: (Due Feb. 22) The goal of this step is to make good progress by discovering major risks to the projects success, and then creating some prototype code to solve or mitogate the risk.

  4. Complete Project and Demo: ( Due Mar. 1) You will turn in and demonstrate your working program. The program should be fully functional, with well designed, formatted, and commented code. All files should be turned in.


Don't forget to put in the following line as the first cout in your CGI program:

cout << "Content-Type: text/plain\n\n";


The examples below can be used as a starting point.

A Self Chat Examples:

Github Project: https://github.com/jimskon/WebChat

Pong Example:


Tic Tac Toe Example:


Project 3 Team Assignments

Team Name Team Members Project and Link
Team 1 Solorio, Christian
Iduma, Elizabeth
Wilhelm, John
Tic Tac Toe
Team 2 Coire Gavin-Hanner
Seaver, Alexander
Team 3 Fukuyama, Miku
Vance, Spalding
Chat System
Team 4 Olivier, Daniel
Juviand Rivera
Murphy, Aidan
Chat System
Team 5 Schutz, Joey
Twitchell, Natalie
Basting, Preston
Chat System
Team 6 Yanqi Xu
Ogilvie-Thompson, Harold
Alperin, Jessie
Grigull, Bennett
Chat System
Team 7 Neau Tess
Khan, Malik Ahmed
Ghada Bokbauk
Chat System
Your team may submit a name of you own.

Grading Rubric

Criteria Excellent Acceptable Unacceptable
Documented & Maintainable
(The program is well-documented with appropriate names and comments making it easy to understand.)
  • all naming conventions are followed
  • both in-line and header comments are included and clearly explain the what the code accomplishes and how
  • white space is used well
  • most naming conventions are followed
  • some comments are confusing or missing
  • white space is used well in most places
  • poor or no use of naming conventions
  • too few or too many comments are used and they are unclear or inaccurate
  • poor use of white space
Adaptable & Reusable
(The program is modular, using abstraction well and any limitations are clearly specified.)
  • all interfaces between objects are clear
  • appropriate utility functions are used and well-documented
  • most code can be reused
  • most object interfaces are clear
  • some appropriate utility functions are used and documented
  • some code can be reused
  • poor object interface definitions
  • few or no utility functions
  • no code can be reused
Robust & Correct
(The program provides the correct output for all possible input.)
  • the program works completely as expected
  • the output is displayed to specification for all valid input
  • the program responds appropriately for all invalid input
  • the program works as expected for most input
  • there may be minor errors in output formatting for valid input
  • not all invalid input is handled reasonably
  • the program does not produce correct output for even the sample input
  • the program fails to handle invalid input
  • exceptions are not caught
Efficient & Elegant
(The program uses both time and space on the computer effectively, without losing source code clarity.)
  • no extra variables or definitions are used
  • the code is small, efficient yet still easily understood
  • extra variables do not make the code harder to understand
  • brute-force problem solving approach
  • extra variables are pervasive and confusing
  • the code is unnecessarily long and patched together
  25-20% 19-11% 10-0%

Grading Results

Criteria Comments Grade (25-0)
Documented & Maintainable    
Adaptable & Reusable    
Robust & Correct    
Efficient & Elegant    
Topic attachments
I Attachment History Action Size Date Who Comment
JPEGjpeg Chat.jpeg r1 manage 8.9 K 2017-02-06 - 15:23 JimSkon  
PNGpng NamesWebArchtecture.png r1 manage 57.9 K 2017-02-06 - 16:55 JimSkon  
PNGpng TTT.png r1 manage 9.8 K 2017-02-06 - 15:23 JimSkon  
PNGpng pong.png r1 manage 1.7 K 2017-02-06 - 17:01 JimSkon  
Edit | Attach | Watch | Print version | History: r22 < r21 < r20 < r19 < r18 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r22 - 2017-03-20 - JimSkon
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback