Presentations Demonstrations GUI Design intro - PowerPoint PPT Presentation


PPT – Presentations Demonstrations GUI Design intro PowerPoint presentation | free to download - id: 11b117-MzJiN


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation

Presentations Demonstrations GUI Design intro


Obviously, you can't avoid demonstrating software to potential customers, ... a little thin briefcase, loaded a single reel of magnetic tape on the tape stand, ... – PowerPoint PPT presentation

Number of Views:30
Avg rating:3.0/5.0
Slides: 25
Provided by: csMon


Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Presentations Demonstrations GUI Design intro

PresentationsDemonstrationsGUI Design intro
  • CS351 Fall04

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

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.

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!
  • 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
  • They ran a screen display test on the machines in
    Reid, and the machine in the microlab. Identical
  • 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!
  • 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.

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

Just a Brief Example
Different Colors
  • Clashing
  • Apparent movement
  • Nausia
  • Couldnt focus.

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!

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!

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.

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

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

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

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

  • 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 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 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
  • Slides out of order or up-side-down!

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.