Skip to content

Latest commit

 

History

History
136 lines (102 loc) · 6.02 KB

client-project-presentations.md

File metadata and controls

136 lines (102 loc) · 6.02 KB
Raw

Group Project Presentations

Overview

Group project presentations should take around 10-12 minutes.

Everyone will talk. So that's about 2 minutes a piece, which isn't much :)

This is a software demonstration. Your goal is to make it feel like it's NOT a software demonstration.

Your target audience is not your team, your instructor, nor your cohort. It's not even your client. Your target audience is someone who has never even heard of your client and what they do and what problems they have.

Pro Tips

  1. You need a story.
  2. You need accurate and believable data.
  3. Watching people fill out forms is boring.
  4. Watching people register/login is boring.
  5. It must be clear WHY you are doing any particular thing in your application.
  6. Smoke and mirrors are a-okay.
  7. Have a backup plan (keep talking)

Outline

  • Who is on the team?
    • Introduce your group members
    • First and last name
  • Who is your client?
    • Introduce them and why what they are doing is exciting and important.
  • What problem are you solving?
    • Tell the story of the current state (problem)
      • Make the audience understand the struggle that exists today
      • Why is this a struggle for the client?
      • Why is it so important that they reached out for help?
    • Example:

      Paper Fighters are out to save trees from becoming paper. Their current process involves a lot of paper and is inefficient because of all of the paper! Notes can get lost in the shuffle.

    • Be especially careful not to insult your client during this section. Do not imply that they are unintelligent because their process is outdated. It can be a fine line between explaining why the process is bad without implying that the client is bad.
  • What is the solution?
    • Continue telling your story
    • Walk through your new application.
      • This is NOT just a feature demo. You are telling the story of how your application will solve the problem for the people it is built for.
      • Example:

        We developed an application for tracking the Paper Fighters' battles against paper and has made their process completely paperless! I'm going to be taking on the role of Ms. Piper McFightington, the founder of Paper Fighters as she goes through her typical day on the new application we have developed.

      • Every feature included in the demo should be a part of the story. WHY is someone doing this.
        • Bad Example:

          This is where Piper can edit a tree form, including changing its status.

        • Good Example:

          A tree is about to be chopped down and turned into paper! To save the tree, Piper can edit the status of a tree to "Rescued".

  • Thanks
    • Thank your clients
    • Thank your instructors/cohort
    • Thank your audience
  • End with who is on the team?
    • Introduce your group members
    • First and last name
    • Pictures and names on the screen

Expectations

First Pass (Friday)

This is your first pass where you will get feedback. If you've hit the above stuff, it should go fairly well. We do not expect you to have memorized any of your parts.

2nd Pass (Monday)

This is the final dress rehersal. We expect it pretty polished at this point.

  • Honed/logical story. It might feel contrived, we can work on it.
  • Note cards (minimal reading)
  • Solid deck that
    • introduces your team (with pictures)
    • introduces your client
    • outlines the problem/opportunity
    • supports your "story"
    • leads into demo
    • outro/closing with your team members and pictures of them (can be the exact same slide as above)
  • Solid test data with life-like data. Needs to support your story and actions.

Preparing a computer to demo the app

One person and one computer should “drive” (share the screen and navigate the slideshow/app) the whole time. Below are things to do to prepare the computer.

Ahead of presentation time

  • App data is sensical
    • passwords look secure
    • values make sense and look realistic
      • usernames, email addresses, names, etc.
      • phone numbers can be all 5s
      • data that's stored and displayed, and data you enter during the demo
  • Add secret onClick()s to populate forms
    • see section below - "Filling Out Long Forms?"
  • Chrome autofill off:
    • Chrome Preferences/Settings -> Autofill and passwords
      • -> Google Password Manager -> Settings
        • Under ‘Declined sites and apps’ add localhost:3000
      • (if your app has address data) -> Addresses and more
        • Toggle ‘Save and fill addresses’ to off
  • (if exporting files from app) clear recent downloads from Chrome
  • (if uploading files to app) only necessary files are in the folder that’s opened for uploading

At presentation time

  • Hide Dock from screen:
    • System Preferences -> Dock & Menu Bar
      • size is smallest possible
      • check ‘Automatically hide and show the Dock’
  • Minimize all computer apps except those that are necessary
  • Hide Chrome bookmarks and search bar
    • maximize the Chrome window so it's in fullscreen app mode
    • control + command + F

Filling Out Long Forms?

Typing out long forms is error-prone and tiresome to do and watch. Consider handling this with code.

The easiest way to populate forms is to add some code your Component to fill out a form with onClick events. Pick an element on the DOM, usually a heading or something on the same page as the form you want to fill. Recall that you can add onClick to almost anything.

That click event just sets the state tied to the forms. Easy-peasy.

Otherwise:

If you would like to fill in space automatically for your presentation or for testing: https://chrome.google.com/webstore/detail/form-filler/bnjjngeaknajbdcgpfkgnonkmififhfo?hl=en