CS 350 - Computer/Human InteractionFall 2009 - Final Group Project: Chatting in a Social NetworkOut: October 22Mid-project Report Due: November 12Presentation Due: December 3Technical Report and Final Implementation due: December 8The final group project consists of four parts: a mid-project report, an implementation, a presentation demonstrating the final product, and a technical report describing the project. To reiterate the project overview handout, this group project is worth 40% of your final course grade and is broken down as follows: 5% Group project mid-project report10% Group project written report10% Group project presentation15% Group project implementationGroup WorkFor this project, you will work in groups as assigned by the instructor. Groups are expected to meet regularly and group members are expected to contribute in substantially equal measures. Each group member will receive the same grade unless extenuating circumstances are brought to the attention of the instructor. To help identify and prevent such circumstances, a mid-project report and peer review forms for both the mid-project report and the final report will be required. Students receiving lower than satisfactory ratings may have their final project grade adjusted accordingly.The Programming Task Your software company is creating a social network for your target users. This will allow users to communicate with other users elsewhere in the world, almost instantaneously. While there are many ways for users to communicate in a social network, we will concentrate on a chat interface that allows "real-time" communication. A user types a message into the chat interface, and the message is sent to the other user(s) currently on-line, who can then reply. Your task is to write the first fully working version of this piece of software. The features which should be supported by this version of the program are:● Each user must choose a login name that must be entered into the program before the user is allowed to send messages. ● Each message that is sent will carry identification of who sent that message. ● When a user successfully sends a message, the message should appear in another part of the interface as feedback. I.e., the chat window.● Error messages should occur if important information is omitted, or the user does the wrong thing. However, the interface also can prevent the wrong thing from happening in some cases. 10/21/09 Page 1 of 5● Your interface must support both one-to-one communication (like AOL Instant Messenger) and many-to-many communication (a chat room). This may be done with the same interface or two different interfaces that are related. To make your task simpler there are a few features which do not necessarily have to be implemented: ● The chat program must work, but it can use files to transfer the information. This is not a networks course. ● You do not need to check that login names are unique, or keep a database of login names. This is not a database course. ● There is no need to delete old messages, but you may choose to do so if you want. Or else you may choose to display only the last 10 messages, for instance. Do whatever you think makes the interface most usable. ● Messages do not have to be received automatically by the program. You can make the user press a Listen button, for instance. However, working out how to make messages appear instantly without the user explicitly doing anything would add to the usability of the interface. You may write your system using any of the following tools: ● HTML and CGI using PHP scripts ● Visual Basic .NET ● Java using the Swing graphics library ● Any combination of the above (dual systems) Some other notes: ● Everything you put in the interface must be implemented. No useless buttons, please. Unimplemented interface options will be considered negative features of the project. ● Your system will be assessed first on the user interface and the usability considerations, and secondly on the features. A system that provides the minimum features but an excellent interface with corresponding excellent report may well score better than a system that has many features, but a poor interface and/or poor report. ● You will have to demonstrate the program in KC-137 with at least two chatters on different machines (one projected from the instructor's station), so make sure it compiles and runs in that environment. Report LogisticsEach group is to produce a 10-20 page technical report. It must include a cover sheet that states the names of all members of your group, describe briefly the contributions of each group member, and contain the following declaration signed and dated by all members of the group: In accordance with the University of Evansville Honor Code, we attest that the project we are submitting is completely our own work, and that we have not received nor given any unauthorized aid on this project. 10/21/09 Page 2 of 5The report should consist of three sections: a requirement analysis, a design rationale, and a usability assessment. Requirements Analysis-Choose the Target Users You are to choose a specific set of target users who will use your program. Design your interface with those users in mind. The more carefully you think about the needs of that set of users, and the more your interface meets those needs, the better grade you will receive. Here are some suggestions about sets of users you might choose: ● Primary-school students ● High-school students for remote learning ● Computer-illiterate people ● Doctors and patients in remote locations ● Journalists traveling the world ● Music bands and their fans ● Antarctic explorers and their sponsors ● Visually-impaired users Other sets of users may be chosen, but they must be cleared with the instructor first. Brainstorm to develop a root concept as described in Chapter 2. This will have a strong influence on the rest of the project, so think carefully about this. ● Develop a list of stakeholder groups and at least two hypothetical stakeholder descriptions that introduce users with different characteristics and personal contexts. ● Develop at least two problem scenarios describing how the hypothetical stakeholders would communicate in the absence of your project or other similar technologies and accompanying problem claims analysis showing at least one positive and one negative feature. Design Rationale