PresentationsPresentationsDemonstrationsDemonstrationsGUI Design introGUI Design intro

CS351 – Fall’04CS351 – Fall’04

““Never Demonstrate Anything”Never Demonstrate Anything”

• Obviously, you can’t 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

The Color Card StoryThe 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.

Normal Hours?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)

On to the story!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!

Just to be sure: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.!

Last Two Weeks!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. (Let’s say the demo was scheduled for 2pm)

– Worked fine at the 1:45pm run, so they rushed over to Reid to meet me by 2pm.

The Demo!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.

WHAT APPEARED!WHAT APPEARED!

Just a Brief Example

OKCANCEL

Different ColorsDifferent Colors

• Clashing

• Apparent movement

• Nausia

• Couldn’t focus.

Team ReactionTeam 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 can’t pay for it!

So, what happened?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 wasn’t designed for the new boards!

What does NDA really mean?What does NDA really mean?

• Double check everything.• Tripple check the double checks.• Don’t 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.

NDA cont.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 can’t go wrong, it will”

A Different PerspectiveA Different Perspective

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

A Pr1me ProposalA 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)

What I didWhat 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.

ResultsResults

• 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!!!!!

Software InstallSoftware 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, “I’d rather work with software than hardware!”

• The simulator worked fine, and as far as I know, they are still using it.

Installation PresentationInstallation Presentation

• Make it a production!

• Don’t 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.

PresentationsPresentations

• 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.

The GoodThe 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)

The BadThe 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!

And the UglyAnd 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.