Presentation Format

Given the remote learning situation, we want to continue to provide flexibility in this final presentation while providing some structure to the process so that community partners and campus supporters can participate.

You are allowed to submit either:

• a recorded presentation (MP4 format is best) or
• schedule a time to stream your presentation.

We will invite your community partner and CLS staff to attend these if they are able, as we do for in-person final presentations. Every team member should contribute to creation and delivery of this final presentation. For either option, you should take your presentation seriously and think of it as a final public presentation with the professionalism and polish that goes along with that.

I will also share the recordings or times of presentations through PWeb so that you can see what other groups accomplished this semester. You should plan to “attend” presentations or watch recordings to see what your colleagues have produced this term.

Presentation Times

Since we are not doing both the technical presentation and the public presentation this term, we have two presentation time slots available for teams that prefer doing a live WebEx presentation.  You may present during our last scheduled class period: May 8th between 10:00 am and 11:50 am.  or the afternoon of our scheduled final: May 13th between 2:00 pm and 5:00 pm.

Sign up for a half-hour time slot on the document sent to you on April 30th.

If you are doing a recording, you should submit your presentation in PioneerWeb by May 13th at 5 pm.

Presentation Content

Above all, keep in mind that these are non-technical presentations and therefore should not go into the technical detail that you have in your demos and should avoid all jargon.  If you must use a technical term, you should be prepared to explain it.

Your team has a great deal of flexibility in how you want to present the current state of the software that you have been developing this term. We offer these ideas as suggestions for what to consider including in your presentation.

These presentations should take about 20 to 25 minutes each – MAXIMUM. We need to leave time between each group for switching laptops and movement.

Your audience will include your classmates and instructor, Susan Sanning from CLS, the community partners for all of the teams (some may not be able to attend, but they are invited).

• These presentations often work best if you prepare a Power Point (or similar) slideshow with screen captures of the most important parts of your program.  Computer programs frustratingly often do not work properly when you are in front of an audience!! This should be more of a poster session than an actual walkthrough demo.  You certainly may try to show the working application, but I highly recommend having screenshots in a presentation format as a backup.
• Since many of the people who may be attending do not know anything about your project, it will be helpful to briefly describe what the purpose of the software is: what is its major function and how does it help your community partner fulfill their mission?
• It is helpful for everyone to have a brief narrative of what features or changes or improvements were requested by the community partner. You might go back to your initial notes from the first meeting with your community partner and review the user stories or feature list. In some cases, you might need to explain that many important improvements are not visible but essential to the security of the program’s operation. Most of our users will understand and appreciate the care we are taking to protect their users and their data.
• Since a good portion of the audience will be made up of our community partners, be careful to avoid computer science jargon. This is good practice for both industry and research!!  
• Talk about – and possibly have slides showing images of – the current state of deployment of your project. If it is in progress, just let us know that there are still issues to work out next term. If you are (almost) done – mention that too.
• Aim to show us how major features or the new improvements function, but you do not have to demonstrate everything that the program does.