presentations demonstrations gui design intro cs351 – fall’04

Download Presentations Demonstrations GUI Design intro CS351 – Fall’04

Post on 22-Dec-2015




0 download

Embed Size (px)


  • Slide 1
  • Presentations Demonstrations GUI Design intro CS351 Fall04
  • Slide 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
  • Slide 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.
  • Slide 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)
  • Slide 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!
  • Slide 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.!
  • Slide 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 1:45pm run, so they rushed over to Reid to meet me by 2pm.
  • Slide 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.
  • Slide 9
  • WHAT APPEARED! Just a Brief Example OK CANCEL
  • Slide 10
  • Different Colors Clashing Apparent movement Nausia Couldnt focus.
  • Slide 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!
  • Slide 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!
  • Slide 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.
  • Slide 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
  • Slide 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.
  • Slide 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)
  • Slide 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.
  • Slide 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!!!!!
  • Slide 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.
  • Slide 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.
  • Slide 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.
  • Slide 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)
  • Slide 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!
  • Slide 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.


View more >