Two Person Presentations - Revision history

Checker at 21:43, 1 April 2007

2007-04-01T21:43:20Z

← Older revision		Revision as of 21:43, 1 April 2007
Line 1:		Line 1:
	[[Image:Migs06maxis.jpg\|right]]		[[Image:Migs06maxis.jpg\|right]]
	One of the goals for [http://slackworks.com/~cog Chaim Gingold's] and my [[Advanced Prototyping\|2006 GDC lecture]] ~~with~~ to try learn how to do really a good two-person talk. I'd seen a bunch of mediocre two-person talks at the GDC over the years—talks that would have been better if they were given by either one of the speakers as a solo talk—and I was curious to know what it would take to make a truly good two-person lecture, a talk that was better than either person could give alone.		One of the goals for [http://slackworks.com/~cog Chaim Gingold's] and my [[Advanced Prototyping\|2006 GDC lecture]] was to try learn how to do really a good two-person talk. I'd seen a bunch of mediocre two-person talks at the GDC over the years—talks that would have been better if they were given by either one of the speakers as a solo talk—and I was curious to know what it would take to make a truly good two-person lecture, a talk that was better than either person could give alone.

	I think we accomplished this goal. The lecture was the highest rated lecture in the Game Design track that year, and a lot of the feedback form comments mentioned how the natural back-and-forth we achieved on stage helped communicate the material and was fun to listen to, as a bonus.		I think we accomplished this goal. The lecture was the highest rated lecture in the Game Design track that year, and a lot of the feedback form comments mentioned how the natural back-and-forth we achieved on stage helped communicate the material and was fun to listen to, as a bonus.

Checker at 21:43, 1 April 2007

2007-04-01T21:43:02Z

← Older revision		Revision as of 21:43, 1 April 2007
Line 1:		Line 1:
	[[Image:Migs06maxis.jpg\|right]]		[[Image:Migs06maxis.jpg\|right]]
	One of ~~my personal~~ goals for ~~my [[Advanced Prototyping\|2006 GDC lecture]] with~~ [http://slackworks.com/~cog Chaim Gingold] ~~was~~ to try learn how to do really a good two-person talk. I'd seen a bunch of mediocre two-person talks at the GDC over the years—talks that would have been better if they were given by either one of the speakers as a solo talk—and I was curious to know what it would take to make a truly good two-person lecture, a talk that was better than either person could give alone.		One of the goals for [http://slackworks.com/~cog Chaim Gingold's] and my [[Advanced Prototyping\|2006 GDC lecture]] with to try learn how to do really a good two-person talk. I'd seen a bunch of mediocre two-person talks at the GDC over the years—talks that would have been better if they were given by either one of the speakers as a solo talk—and I was curious to know what it would take to make a truly good two-person lecture, a talk that was better than either person could give alone.

	I think we accomplished this goal. The lecture was the highest rated lecture in the Game Design track that year, and a lot of the feedback form comments mentioned how the natural back-and-forth we achieved on stage helped communicate the material and was fun to listen to, as a bonus.		I think we accomplished this goal. The lecture was the highest rated lecture in the Game Design track that year, and a lot of the feedback form comments mentioned how the natural back-and-forth we achieved on stage helped communicate the material and was fun to listen to, as a bonus.

Checker at 21:38, 1 April 2007

2007-04-01T21:38:52Z

← Older revision		Revision as of 21:38, 1 April 2007
Line 1:		Line 1:
	[[Image:Migs06maxis.jpg\|right]]		[[Image:Migs06maxis.jpg\|right]]
	One of my personal goals for my [[Advanced Prototyping\|2006 GDC lecture with Chaim Gingold]] was to try learn how to do really a good two-person talk. I'd seen a bunch of mediocre two-person talks at the GDC over the years—talks that would have been better if they were given by either one of the speakers as a solo talk—and I was curious to know what it would take to make a truly good two-person lecture, a talk that was better than either person could give alone.		One of my personal goals for my [[Advanced Prototyping\|2006 GDC lecture]] with [http://slackworks.com/~cog Chaim Gingold] was to try learn how to do really a good two-person talk. I'd seen a bunch of mediocre two-person talks at the GDC over the years—talks that would have been better if they were given by either one of the speakers as a solo talk—and I was curious to know what it would take to make a truly good two-person lecture, a talk that was better than either person could give alone.

	I think we accomplished this goal. The lecture was the highest rated lecture in the Game Design track that year, and a lot of the feedback form comments mentioned how the natural back-and-forth we achieved on stage helped communicate the material and was fun to listen to, as a bonus.		I think we accomplished this goal. The lecture was the highest rated lecture in the Game Design track that year, and a lot of the feedback form comments mentioned how the natural back-and-forth we achieved on stage helped communicate the material and was fun to listen to, as a bonus.

Checker at 21:32, 1 April 2007

2007-04-01T21:32:01Z

← Older revision		Revision as of 21:32, 1 April 2007
Line 11:		Line 11:

	* It's like backup and solo in jazz, maybe?		* It's like backup and solo in jazz, maybe?
			[[Image:Migs06maxis04.jpg\|right]]
	* The slides often want to have phrasing such that there's a cue to jump in at the end for the other person if they feel like they want to expand on any points. One thing we found useful was that the current speaker's hand as it moves towards the spacebar to advance the slides is a great non-verbal signaling device to let the non-speaker know when they should jump in on the current slide if they want to.		* The slides often want to have phrasing such that there's a cue to jump in at the end for the other person if they feel like they want to expand on any points. One thing we found useful was that the current speaker's hand as it moves towards the spacebar to advance the slides is a great non-verbal signaling device to let the non-speaker know when they should jump in on the current slide if they want to.

Checker at 21:29, 1 April 2007

2007-04-01T21:29:58Z

← Older revision		Revision as of 21:29, 1 April 2007
Line 1:		Line 1:
			[[Image:Migs06maxis.jpg\|right]]
	One of my personal goals for my [[Advanced Prototyping\|2006 GDC lecture with Chaim Gingold]] was to try learn how to do really a good two-person talk. I'd seen a bunch of mediocre two-person talks at the GDC over the years—talks that would have been better if they were given by either one of the speakers as a solo talk—and I was curious to know what it would take to make a truly good two-person lecture, a talk that was better than either person could give alone.		One of my personal goals for my [[Advanced Prototyping\|2006 GDC lecture with Chaim Gingold]] was to try learn how to do really a good two-person talk. I'd seen a bunch of mediocre two-person talks at the GDC over the years—talks that would have been better if they were given by either one of the speakers as a solo talk—and I was curious to know what it would take to make a truly good two-person lecture, a talk that was better than either person could give alone.

Line 22:		Line 23:

	* Once it starts coming together, it is a lot of fun to do!		* Once it starts coming together, it is a lot of fun to do!

			<center>[[Image:Migs06maxis06.jpg]]</center>

	[[Category:Lectures]]		[[Category:Lectures]]
	[[Category:Opinions]]		[[Category:Opinions]]

Checker at 10:34, 1 April 2007

2007-04-01T10:34:33Z

← Older revision		Revision as of 10:34, 1 April 2007
Line 15:		Line 15:
	* Two talks enter, one talk leaves. Both Chaim and I had different ideas of what we thought the talk would be about, even while we were developing the material together. But, to end up with a coherent whole, we had to destroy our individual talks and build the shared talk.		* Two talks enter, one talk leaves. Both Chaim and I had different ideas of what we thought the talk would be about, even while we were developing the material together. But, to end up with a coherent whole, we had to destroy our individual talks and build the shared talk.

	* Rehearse, rehearse, rehearse. I have a [[~~Rehearsing Presentations~~\|bunch of advice on rehearsing]], and it's even more important for two-person talks, especially in front of your peers. The good thing about testing a two-person talk is that it depersonalizes the feedback since it comes from an unbiased 3rd party, so cutting material becomes easier and is about the talk as opposed to the individual.		* Rehearse, rehearse, rehearse. I have a [[How to Give a Good Presentation\|bunch of advice on rehearsing]], and it's even more important for two-person talks, especially in front of your peers. The good thing about testing a two-person talk is that it depersonalizes the feedback since it comes from an unbiased 3rd party, so cutting material becomes easier and is about the talk as opposed to the individual.

	* It's vital to build trust during development, so you have the ability to edit and cut up each other's work without defensiveness. This is true collaboration.		* It's vital to build trust during development, so you have the ability to edit and cut up each other's work without defensiveness. This is true collaboration.

Checker at 10:29, 1 April 2007

2007-04-01T10:29:38Z

← Older revision		Revision as of 10:29, 1 April 2007
Line 1:		Line 1:
	One of my personal goals for my [[Advanced Prototyping\|2006 GDC lecture with Chaim Gingold]] was to try learn how to do really a good two-person talk. I'd seen a bunch of mediocre two-person talks at the GDC over the years—talks that would have been better if they were given by either one of the speakers as a solo talk—and I was curious to know what it would take to make a truly good two-person lecture, a talk that was better than either person could give alone.		One of my personal goals for my [[Advanced Prototyping\|2006 GDC lecture with Chaim Gingold]] was to try learn how to do really a good two-person talk. I'd seen a bunch of mediocre two-person talks at the GDC over the years—talks that would have been better if they were given by either one of the speakers as a solo talk—and I was curious to know what it would take to make a truly good two-person lecture, a talk that was better than either person could give alone.

	I think we accomplished this goal. The lecture was the highest rated lecture in the Game Design track that year, and a lot of the feedback form comments mentioned how the natural back-and-forth we ~~acheived~~ on stage helped communicate the material and was fun to listen to, as a bonus.		I think we accomplished this goal. The lecture was the highest rated lecture in the Game Design track that year, and a lot of the feedback form comments mentioned how the natural back-and-forth we achieved on stage helped communicate the material and was fun to listen to, as a bonus.

	You should probably listen to the [[Advanced Prototyping\|talk]] if you want to judge how we did for yourself.		You should probably listen to the [[Advanced Prototyping\|talk]] if you want to judge how we did for yourself.

	We took some loose notes as a sort of ~~post-mortem~~ on what we learned. Here they are:		We took some loose notes as a sort of postmortem on what we learned. Here they are:

	* It is lots of work, much ~~moreso~~ than a solo talk, and you have to know the other person's material inside and out, and be able to switch off and deliver their stuff fluidly, and fill in if they miss something, without missing a beat.		* It is lots of work, much more so than a solo talk, and you have to know the other person's material inside and out, and be able to switch off and deliver their stuff fluidly, and fill in if they miss something, without missing a beat.

	* It's like backup and solo in jazz, maybe?		* It's like backup and solo in jazz, maybe?

Checker: New page: One of my personal goals for my 2006 GDC lecture with Chaim Gingold was to try learn how to do really a good two-person talk. I'd seen a bunch of mediocre two-per...

2007-04-01T10:28:39Z

New page: One of my personal goals for my 2006 GDC lecture with Chaim Gingold was to try learn how to do really a good two-person talk. I'd seen a bunch of mediocre two-per...

New page

One of my personal goals for my [[Advanced Prototyping|2006 GDC lecture with Chaim Gingold]] was to try learn how to do really a good two-person talk. I'd seen a bunch of mediocre two-person talks at the GDC over the years—talks that would have been better if they were given by either one of the speakers as a solo talk—and I was curious to know what it would take to make a truly good two-person lecture, a talk that was better than either person could give alone.

I think we accomplished this goal. The lecture was the highest rated lecture in the Game Design track that year, and a lot of the feedback form comments mentioned how the natural back-and-forth we acheived on stage helped communicate the material and was fun to listen to, as a bonus.

You should probably listen to the [[Advanced Prototyping|talk]] if you want to judge how we did for yourself.

We took some loose notes as a sort of post-mortem on what we learned. Here they are:

* It is lots of work, much moreso than a solo talk, and you have to know the other person's material inside and out, and be able to switch off and deliver their stuff fluidly, and fill in if they miss something, without missing a beat.

* It's like backup and solo in jazz, maybe?

* The slides often want to have phrasing such that there's a cue to jump in at the end for the other person if they feel like they want to expand on any points. One thing we found useful was that the current speaker's hand as it moves towards the spacebar to advance the slides is a great non-verbal signaling device to let the non-speaker know when they should jump in on the current slide if they want to.

* Two talks enter, one talk leaves. Both Chaim and I had different ideas of what we thought the talk would be about, even while we were developing the material together. But, to end up with a coherent whole, we had to destroy our individual talks and build the shared talk.

* Rehearse, rehearse, rehearse. I have a [[Rehearsing Presentations|bunch of advice on rehearsing]], and it's even more important for two-person talks, especially in front of your peers. The good thing about testing a two-person talk is that it depersonalizes the feedback since it comes from an unbiased 3rd party, so cutting material becomes easier and is about the talk as opposed to the individual.

* It's vital to build trust during development, so you have the ability to edit and cut up each other's work without defensiveness. This is true collaboration.

* Ironically, the shared difficulty of giving a bad rehearsal bonds the speakers, and removes a lot of defensiveness and preconceived notions. We gave at least 2 dreadfully bad rehearsals before we chopped the talk to pieces and rebuilt it completely collaboratively.

* Once it starts coming together, it is a lot of fun to do!

[[Category:Lectures]]
[[Category:Opinions]]