Skip to Content
Course ProjectPresentationPresentation Logistics

Presentation Logistics

This page outlines how the in-class project presentations will be conducted. Please read carefully to ensure a smooth and fair experience for all teams.

Presentation schedules: To be posted by November 2, 2026.

Arrival and Seating

  • Class begins promptly at 13:10.
  • All presenting teams should arrive by 13:00 to test display connections and get seated.
  • At any time, the next three teams should be seated in the front row, ready to present.

Time Allocation (Strictly Enforced)

Each team has:

  • 6 minutes for the project presentation
  • 2 minutes for Q&A
  • 1 minute to transition to the next team

To ensure fairness to all teams and to respect classroom booking times, the 6-minute limit will be strictly enforced.

  • At 1 minute remaining in the presentation, the instructor will give a hand signal.
  • At 6 minutes, the presentation MUST stop immediately, regardless of completion.
  • The Q&A will then begin and will last approximately 2 minutes.

We strongly recommend practicing timed rehearsals in advance.

Required Written Introduction (Due November 25)

Each team must submit a short written introduction (70–100 words) to Quercus  by November 25, 2026, 11:59 PM.

Important: This written introduction is not a replacement for speaking during your presentation.

It is used for the following purposes only:

  1. To populate Microsoft Forms for peer-review submissions
  2. To be published on the course website, allowing students to preview their classmates’ projects before presentations

During your presentation, your team should introduce the project yourselves, as part of your 6-minute time slot.

Your written introduction should include:

  1. Project name and one-sentence purpose
  2. Target users or use case
  3. 1–2 core features (what the system does)
  4. Key web technologies used (e.g., Next.js or React + Express, database choice)

Word Limit: 70–100 words

Example

“Team 8 developed CourseFlow, a full-stack web application that helps instructors manage assignments and track student submissions efficiently. The system supports authenticated users who can create assignments, upload supporting files, and monitor submission status through a responsive web interface. CourseFlow is built using Next.js with TypeScript, PostgreSQL for persistent relational data, and cloud storage for file uploads. The frontend is styled with Tailwind CSS and reusable components, while the backend handles data validation and access control. Our goal is to streamline common instructional workflows in course management.”

Presentation Setup

To minimize transition time and ensure a smooth presentation:

  • Use one single laptop for the entire presentation.
  • Decide before class which laptop will be used.
  • Have all slides, browser tabs, demo windows, and backup materials open and ready before your turn.
  • Check your display settings in advance. Some laptops default to “extended display” or disable the laptop screen when connected to HDMI/USB-C. Please ensure your laptop is mirroring correctly so that both the projector and your laptop screen display the same content.
  • Teams should arrive by 13:00 to verify that the projector connection works and that the display is visible on both screens.
Note

The classroom supports USB-C and HDMI. If your laptop requires an adapter, please bring your own.

Live Demo Expectations

The presentation should provide direct evidence that your project’s core technical requirements are implemented and functional.

Live Demo Requirement

Each team must include a live demonstration of at least one meaningful part of the working system.

The live portion should demonstrate genuine application functionality and should ideally provide evidence of one or more core technical requirements, such as:

  • running the application and interacting with a meaningful user flow;
  • demonstrating frontend functionality implemented with React or Next.js;
  • showing frontend-backend interaction, such as data retrieval, form submission, or other state-changing operations;
  • demonstrating persistent data stored in SQLite or PostgreSQL;
  • uploading, retrieving, or otherwise using files through the application’s cloud storage integration.

A presentation consisting entirely of pre-recorded demonstrations is not permitted.

Recorded Backup Material

We recognize that some features depend on stable network conditions, including cloud storage, external APIs or services, authentication providers, or deployed applications.

Short pre-recorded clips may therefore be used:

  • as a backup if a live network-dependent demonstration fails;
  • to show behavior that would be difficult or unreliable to reproduce within the presentation time; or
  • to supplement the required live demonstration.

Recorded clips should cover only the relevant portion of the application rather than replacing the live demonstration entirely.

You should still explain what is happening while a recorded clip plays — what the feature does, why it matters, and what the demonstration provides evidence of.

Examples

Feature TypeRecommended Demo FormatNotes
Running the application and demonstrating a meaningful user flowLiveGood candidate for the required live demo
Demonstrating frontend–backend interactionLiveShow data retrieval, submission, updates, or another meaningful end-to-end interaction
Demonstrating database persistenceLiveShow that application data is stored and remains available across appropriate interactions or restarts
Uploading or retrieving files through cloud storageLive or Short RecordingPrepare a recording if access to the storage service or network reliability is a concern
Using an external API or third-party serviceLive or Short RecordingRecording may be useful if the external service is slow or unreliable
Demonstrating authentication or authorization flowsLiveGood candidate when authentication is an important project feature
Demonstrating real-time functionalityLive or Short RecordingA short recording may be useful if reproducing the required multi-user interaction is difficult within the presentation time

Professional Communication

Clear and concise technical communication is part of the presentation assessment.

Presenters should explain the project in their own words rather than read from a full prepared script. Slides and brief notes may be used as prompts.

For detailed guidance on presentation structure, slide design, delivery, rehearsal, and Q&A, see the Project Presentation Guidelines.

Q&A

Each presentation will be followed by approximately 2 minutes of Q&A with the instructor and TAs.

The Q&A will typically consist of one main question, with a brief follow-up where appropriate.

Questions may address topics such as:

  • application architecture or technology choices;
  • frontend–backend integration and data flow;
  • database or state management;
  • cloud storage and file handling;
  • advanced feature design;
  • technical tradeoffs or limitations; or
  • remaining work before the final project deadline.

Who May Be Asked?

Teams may designate one or two members to deliver the 6-minute presentation, but all team members should be prepared to participate in Q&A.

You are not expected to memorize every configuration detail. However, every team member should understand the major technical aspects of the project and be able to explain the team’s work at an appropriate level.

Answering Questions

Listen carefully to the question and answer it directly and concisely before adding additional explanation where useful.

The purpose of Q&A is not to test memorization. It is an opportunity to demonstrate your understanding of the project and practice communicating technical ideas in a dynamic setting.

Q&A performance is considered primarily under Clarity & Communication in the Presentation Rubric. Technically incorrect or unsupported answers may also inform the instructor & TA assessment of Technical Progress & Demonstration.

Peer Evaluation

All students must attend both presentation sessions and provide peer evaluations for teams other than their own.

Peer reviewers should evaluate only what is clearly demonstrated or explained during the presentation and Q&A. You are not expected to verify underlying implementation details beyond the evidence shown.

The peer-evaluation form requires only three scores:

  • Clarity & Communication
  • Technical Progress & Demonstration
  • Advanced Features & Completion Plan

Evaluation links will be posted via Quercus before the presentation sessions.

Summary

  • Arrive by 13:00; class starts at 13:10.
  • Next three teams sit in the front row.
  • Submit the 70–100 word introduction to Quercus by November 25.
  • Each team has 6 minutes presenting + 2 minutes Q&A + 1 minute switching.
  • Use one laptop, fully prepared before your turn.
  • A meaningful live demo is required.
  • Short recordings may supplement the live demo or serve as backup for network-dependent components.
  • Present clearly and concisely; do not read from a full script.
  • All team members should be prepared for Q&A.
  • All members attend both days and complete peer evaluations.