Presentations Demonstrations GUI Design intro

1
PresentationsDemonstrationsGUI Design intro

• CS351 Fall04

2
Never Demonstrate Anything

• Obviously, you cant avoid demonstrating software
  to potential customers, clients, bosses, peers,
  family, friends, and other important people!
• What I mean may be illustrated by the color
  card story

3
The Color Card Story

• CS351 project used to be part of a year long
  course divided into three quarters.
• Quarter 1 Project Requirements written.
• Quarter 2 Project prototype developed.
• Quarter 3 Project modest version written.
• Typically, these projects were rather limited in
  scope so that three people working normal hours
  could finish.

4
Normal Hours?

• These projects usually counted for ½ the credit
  for the course.
• In quarter 3, the implementation usually took
  about 60 hours total. (Three people working 20
  hours each specifically on the implementation)
• The all-time record was one student who worked
  alone and put in 375 hours!
• (he also flunked three of his other courses)

5
On to the story!

• A single team was doing a form entry package with
  lots of screen/kb/mouse activity in its gui.
• Teams normally worked in student labs on campus.
• This team had one member who worked in the
  microlab (basement of the library)
• Identical hardware!

6
Just to be sure

• They ran a screen display test on the machines in
  Reid, and the machine in the microlab. Identical
  results.
• Since it was more convenient to work in the
  microlab, the team worked there.
• Two weeks prior to running their DEMO (a big
  thing in those days!) they reran the screen test
  in the Reid lab(regressively after my demo story)
  Still O.K.!

7
Last Two Weeks!

• As it often is, 80 of the work was completed in
  the last two weeks.
• Demo time came!
• They actually were making changes, editing source
  code, recompiling and testing the morning of the
  demo. (Lets say the demo was scheduled for 2pm)
• Worked fine at the 145pm run, so they rushed
  over to Reid to meet me by 2pm.

8
The Demo!

• In those days, the demo was almost ¼ of the
  project grade.
• All members had to be present and answer
  questions.
• I often started by sweeping my hand across the
  keyboard (not hitting ctl-alt-del) as a first
  test.
• So, happy with that I started their project.

9
WHAT APPEARED!
Just a Brief Example
CANCEL
OK
10
Different Colors

• Clashing
• Apparent movement
• Nausia
• Couldnt focus.

11
Team Reaction

• To a person they all had open mouths and
  incredulous looks!
• BUT, but, it worked in the microlab ???
• I asked if this was what they had designed and
  they quickly showed me the functional spec.
• But, I said, this is what you are demonstrating,
  and I cant pay for it!

12
So, what happened?

• One week before the demos, in their infinite
  wisdom, computing services (as it was called in
  those days) decided to swap out the graphics
  boards in all the Reid lab machines.
• But since, the microlab was only used by
  Computing Services people they decided to leave
  these machines alone.
• Their program wasnt designed for the new boards!

13
What does NDA really mean?

• Double check everything.
• Tripple check the double checks.
• Dont make last minute changes.
• Regressively test any last week changes.
• Keep one working older version (just in case).
• Learn your package well.
• Learn how to speak and practice often.

14
NDA cont.

• Cart the hardware or prepare the demo on a
  specific machine and lock it down.
• Watch environment changes
• OS, Drivers, network links active
• Hardware cpu, drivers, keyboard, mouse, disk
  space, power backup.
• Remember! If it can go wrong, it will
• And, If it just cant go wrong, it will

15
A Different Perspective

• Montana Power company was doing a simulation of
  the west coast doughnut on a time share system
  in Salt Lake City.

16
A Pr1me Proposal

• Substitute their time sharing service with a
  purchase of the software and running it on their
  own machine.
• Software 80,000.
• Hardware 275,000.
• Pay off the cost in 1-1/2 years! (IF it worked)

17
What I did

• Took a copy of the source code, and converted it
  from the large computer it was working on to the
  Pr1me system.
• Wrote a script to read and write source code.
• Recompiled the whole system.
• Demonstrated it on a Pr1me system.
• They had an 80MB virtual address space, so it
  worked with a mini running 1 M of ram or so.

18
Results

• They purchased the computer from me and the
  software from the other folks.
• Sent me a 275,000. check.
• Hardware arrived, and I went to Butte to install.
  
• Took almost a week to elevator up, unpack, and
  cable all the racks.
• Turned it on, and it ran first try!!!!!

19
Software Install

• A fellow arrived with a little thin briefcase,
  loaded a single reel of magnetic tape on the tape
  stand, collected his check for 80,000 and went
  back to the airport.
• It was at that moment that I decided, Id rather
  work with software than hardware!
• The simulator worked fine, and as far as I know,
  they are still using it.

20
Installation Presentation

• Make it a production!
• Dont just load it and run.
• Now, however, there was a team that went
  overboard
• Full dress outfits, gowns and tuxes.
• Silver service for coffee and coookies.
• Music Playing.
• Low lights, and an easy chair to sit in.

21
Presentations

• Learn some graphics art!
• Many helpful presentation tools.
• Examples of both good and bad presentations have
  been at the annual SIGGRAPH conference.
• (Special Interest Group computer GRAPHics)
• Record attendance 50,000 (currently 25,000)
• Premier conference for CG papers.

22
The Good

• Clear speaker.
• Three or more screens.
• One shows speaker large.
• One shows main slides.
• One shows auxilliary slides.
• Limited Mathematics (one obligatory slide)
• Lots of examples cleanly integrated.
• Multi-media (sound, text, animations)

23
The Bad

• Little font.
• Too many entries on one slide.
• Lots of obscure mathematics.
• Not clear speaker (heavy accent or terrified)
• Not figuring out how to run the buttons on the
  podium
• Slides out of order or up-side-down!

24
And the Ugly

• Although ugly is often in the eye of the
  beholder, there have been many ugly presentations
  at Siggraph.
• Bad Colors and Poor Audio.
• Poor ordering.
• Every bad habit you have seen in your academic
  career shows up at conferences.