ITEC 325 2016fall ibarland

home—lects—hws
D2L—breeze (snow day)

project
Project
requirements

For this course, teams of four students will design a web application. Some examples of the sorts of things that can be done are:

• A reservation system: Enter room-requests, have them approved, show all reservations for a given room, show all reservations for a given client, udpate a room's details. Include a calendar view.
• A specific variant of the above:
  A scheduling tool for RU students to make (advising) appointments w/ a faculty member. For example, spend an hour trying out a site like checkappointments.com and doodle.com (setting up your schedule and having a friend arrange an “appointment” with you), and see if you can make a site which is better for the specific task of RU student advising.
• mp3 shop: Browse inventory, search for albums/artists/songs, release files upon payment, update inventory.
• sports-team database: Look up information about players and about teams; administrators can to update such info; users can have a list of favorites teams or players and log in to see summaries. Allow users to either make changes to data, or suggest changes to be reviewed by an administrator.

---

Live projects

• A site to track student progress in Elites program, for the College of Science and Technology. idea-elites-tracking.txt.
• An on-line version of a study skills inventory: students in 120 (or Univ100) would take the quiz, and then receive their score. Quiz info would be stored in a database for later analysis. An administrator can create new questions, or edit existing ones. Contact: as brennemrad ford. edu.

• Help a professor track and award “badges” for programming courses — e.g. badges for “completed a homework 24hrs before due” or “awesome function and parameter names” (as determined by prof) or “corrected the prof on a technical point, during lecture” or “provided a function with more than 10 unit tests (all testing different edge cases)”?

  This involves coming up with interesting/fun/measurable badges; making it easy to enter/verify that a badge is earned; ways to export badges to D2L gradebook (or, a spreadsheet); coming up with a library of fun icons; let students and prof easily view their (and, others'??) progress.

• A web-site to maintain a friendly betting pool: On superbowl sunday, friends come over and watch the game together, and might have a small betting pool based on an elegant parimutuel system. A web-site would track the tickets issued, and when the game finishes it would show how to distribute the pot. See ibarland@ for details.
• An entry for a startup-proposal, via the COBE BB&T Business Innovation Contest. (Requires working with a COBE student; cash prizes available; plus, winners may get COBE to help seed their crowdfunding effort.)
• If you know of a local organization, charity, or business that would like a web project, and are interested in helping them, see me right away.
• A page for a (campus) club, that you seek out. Perhaps one with events that people can sign up for; or perhaps one with a bio sketch for each member; …

You encouraged to suggest your own projects, perhaps inspired by the suggestions above. However, your project must include the following features:

• Your pages are reachable via https://php.radford.edu/projn, where n is your team-number (in {1,…,4}).
  I will likely require access via git as well (presumably bitbucket.org or github.com).
• User authentification, either as a client or a manager/administrator.
• A back-end database to store information.
• Pages for clients to enter new records, and view all their own records (possibly modifying/updating parts of them);
• Pages for administrators to modify any records (with safeguards), view appropriate groups of records (e.g. all reservations for next week), perhaps with a page for administrators to enter/modify any record, a way for a client to enter/modify parts of their own record, and ways for administrators to view summary of many records.
• Data validation performed (as appropriate) on the client-side, server-side, and database back-end.
• As appropriate, a unified appearance for all the pages.

• You may use tools like Visual Studio or dreamweaver, as well as libraries like Twitter Bootstrap (for CSS), Node.js (server-side javascript), or additional php PEAR packages you install. Be sure to cite code you get from elsewhere (e.g. a bunch of php/javascript for showing a clock/calendar), and during your presentations be up-front about what libraries and code you made use of. (Discussing the difficulties of integrating others' code certainly can be a worthy topic, as well.)
  If you feel unsure whether you're borrowing too much, just talk with me.

  Note that the individual homeworks are where the course ensures you know various specifics of coding; the project is intentionally there to help you expand your vision of what your sites can (or, should) do.

Checkpoints include:

1. (due Sep.23; one email per team, plus each member in D2L.)
   Choose teams and projects.

   Choose one team member as liaison, who I'll channel all communication through. The liaison should email me (subject "itec325 project team [team-name]") the team-name, the names of the team-members, and a 2-sentence description of their project.

   disclaimer: The liaison is not responsible for getting teammates to do their work, or show up for meetings, etc.. The team lead (who is often also the liaison) should schedule meetings and coordinate with all members to help keep the project on track, but should not do others' coding. One supporting role that can be useful is that of a sounding board: a team member might sit and code while another member is sitting next to them, and can bounce ideas, design decisions, and questions off of their teammate.

2. (due Sep.28) Submit a proposal (10%):
   • Team name,
   • members (with the liaison )
   • a list of pages that site will contain, along with:
     • A crude, hand-drawn mock-up of each page (each page has a short name; each links/forms to other pages are that target name, circled). You do not have to use crayons.
     • A crude, hand-drawn mockup of any standard header/footer/sidebar that will be on all other pages.
     • What input fields each page has (if any), annotated with what data/validation will allow a successful submit; (perhaps even the exact id/name attributes for each input field).
     • Example sentences of the page-specific content.
     • What successor page(s) each form can lead to (with a ~one-sentence description of the criteria)
   • A database schema/ERD: what tables, what columns they have, and one-to-two sample rows for each table. Show primary and foreign keys.
     (This can be hand-drawn, but neatly (using ruler etc). Or you can use a tool such as Visio, which might save time during updates and presenting later.)
   You aren't locked in by this proposal; it is intended to make sure you have thought through what you need to do, and that the entire group understands exactly what functions will be implemented.

3. (due Oct.03)
   Have a working git account for your project, with a Readme file, and every team-member having pushed at least one change. Add ibarland@radford.edu as a team-member to the git project.

   The Readme (presumably on bitbucket.org or github.com). Have a README file for the project, which includes the team name and their members (as well as usual README info: a quick overview of the project, what sub-directories include what major components of your project).

   And of course, Everybody should be pushing their changes to this repo regularly; I'll glance at the project's log.

4. (due Oct.17) Prototype (10%), with a class demonstration (10%):
   • A stub for each page, with input fields and links (validation not fully required).
   • An instantiated database, even if just done in Excel tables or written on paper, with the indicated tables, and at least four rows of sample (concocted) data in each (exercising the range of cardinalities in the ERD), and at least two sample SQL queries that might be eventually generated by the web form (but not necessarily connected to the web forms).
   • For the presentation: this is fairly informal — you don't need to dress up, nor have powerpoint slides (though you certainly may, if you like). But you do need each person to partake in the presentation, make eye contact with everybody in the room (not just the professor), and not have any misspellings on your web page or database samples.
   • The pages and database design you present are locked in at this point.
5. (due Nov.18, hardcopy) Progress report (5%):
   A short written summary of progress and problems-encountered (less than one page), including which team-members have been contributing to which component(s).
6. (due Dec.09) Final project (40%), with a class demonstration (15%):
   • Full data validation and database connectivity.
   • In your demo, include a few moments to talk about technical and managerial difficulties you encountered (expected or not). ('Confessing' any problems won't hurt your score; indeed it's often the most learning-useful part of a presentation.)
   • Be sure that your projects are accessible for everybody to see/use at the URL: https://php.radford.edu/~projN/.
     • If you're hosting your project elsewhere, that URL should have a link, or redirect.
     • Be sure others can use public (non-admin) features; if new users can't create their own account then be sure to write a login&password at the start of your presentation.

       You don't need to provide us with an admin account&password, but you might if you want to help your “prospective customers” try out the system they're evaluating. And it goes without saying: if you are using another team's admin account, don't do any potentially damaging operations, like delete a database-row you didn't add yourself, as an issue of the honor policy and basic human decency.

7. (due Dec.11 (Sun.) 23:59 17:00) Peer evaluation (10%):
   Evaluate both other groups' presentations, and your teammates. project-team-feedback—itec325 project feedback

Your grade will be mostly the same for all group members, with some variation based on the team feedback form. However: If the group concensus and/or git logs show that a member contributed very little (including not communicating clearly and professionally), that student's grade might be given a lower score (even 0), if warranted. The converse is not true: if one student implements far more than their share of the project, they will not necessarily get significantly more points that others. (I do not want students to feel like they must be martyrs, to complete their group's work.)

Archiving your project

The project-accounts will be cleared, a few weeks into the summer! If you want to keep a copy of your work…

• Grab all the code files. (If you've been using github or bitbucket, this is already done!)
• Grab the database! In myphpadmin, there is an “export” button which will create a .sql script which, when run, re-adds all the tables and populates them.
• Make a screencast?
  If you want to link to the project in your resume/portfolio, but don't want to keep the project hosted and live and updated-security, a screencast isn't as good as a live site, but is better than nothing.

home—lects—hws
D2L—breeze (snow day)

©2016, Ian Barland, Radford University Last modified 2016.Sep.28 (Wed)

Please mail any suggestions (incl. typos, broken links) to ibarlandradford.edu