Monday, March 03, 2008
Following on from the tips on how to setup your laptop for demos (with some great ones from you in the comments!), I thought I'd follow up with how to setup Visual Studio specifically.
Whilst the language I use below is prescriptive as always, please note that I am far from an authority so all I am doing here is sharing my views. I'll start with 2 that I know are controversial and then move on to a mixture of mainstream points with a couple tips that I suspect most of you have not come across before.
A) Don't change colours; don't use "themes". Use the default settings.
I've been in presentations where the presenter puts a lamp of code on the screen and I am trying to compile it in my head except all the stuff I am familiar with has changed: default colours of types, keywords, comments, strings and even code editor background! "Why would you ever do that to the audience? Why do you hate them so much?". To be clear, it is fine for you to "pimp your IDE" for working purposes. However, when showing dozens (if not hundreds or thousands) of other people a demo using Visual Studio, what is the lowest common denominator that you can assume about them? Answer: that they are familiar with the default settings of Visual Studio. Unless your goal is to prove how smart/artistic you are, instead of trying to make it as easy as possible for them to follow your code, please take heed.
B) Leave the 3rd party productivity addins at home.
In case you are not familiar with them, there are 3rd party enhancements to Visual Studio (such as resharper, coderush, codesmith, visualassist, [insert your favourite here], etc) that can truly increase your productivity multi-fold. However, recall from point A above that the majority of your audience will not be familiar with them. When we show code during a demo, all effort from the audience should be concentrated on understanding the API/pattern that you are explaining and not be distracted by seeing menus they are not familiar with and being confused by how you managed to accomplish something with a shortcut that they never heard of before. Unless, of course, you are actually an evangelist for those products and/or you need the productivity boost during your demo because you are coding it for the first time instead of having rehearsed what you are showing. Do you really want your attendees coming out of your session and talking about how they enjoyed learning about one of the said products, instead of walking out with the intended take away that you had in mind?
C) Use large enough fonts everywhere.
Don't wait for the audience member to shout out to you to enlarge your fonts. Go to Tools->Options->Fonts and Colors and change the "Text Editor" font to at least 14 (and for some rooms 16). In fact, when you reach the room you are presenting in, launch Visual Studio and go seat on the last row of chairs starring at the projector; can you read your code? Furthermore, change the font for things like Tooltips, the intellisense window and all the other "Tool Windows" (hint: look at the top combobox with the label of "Show settings for:").
D) Change your highlight colour for selected text.
This is my only rule that goes against A above. Simply put, if you leave your "highlight" as the automatic default of "Blue", your text is not visible to the audience – not sure why people don't get that. You are having the opposite effect of your goal when you highlighted that piece of code. So, as per the instructions of C above, find the "Selected Text" and change the "Item Background" to "Yellow". FYI in the past I used "Lime" but I have found that some projectors show lime darker than what it is on my screen, so I have switched back to yellow.
E) One docked tool window.
I've seen demos where the presenter had multiple docked windows on all sides. How much of the code in the editor is viewable at any given time at 1024x768 resolution at 120 DPI? Every demo you do will have different windowing requirements, but in my experience I have never needed more than one side for docked tool windows (for me that is on the right, but right or left is a mute point IMO). Of course, I'll bring out a tool window from the other side (on the left for me) and also from the bottom but they are set to auto hide so they get used quickly and then disappear. You may also be tempted to autohide all tool windows but in most demos I find it useful to have solution explorer always visible because attendees can easily glance at it during the demo to remind themselves of the big picture (instead of viewing just a single code file). Regardless, windows that are set to autohide but are never used during a demo should be closed/exited instead – what is the point of having tool window tabs(=clutter) in the IDE if they are not going to be used? TIP: for prebaked demos, you can layout all the tool windows (dock/autohide/close) and then save/close the solution and the next time you open it you'll find them all in the right place!
F) Two toolbar rows; for all documents.
Again, this has to do with space-saving and with clutter removal. You may be tempted to get rid of the toolbars completely but, not only that looks weird (recall the point on familiarity), but I actually use the toolbar for some actions instead of using keyboard shortcuts so I can make very obvious to the audience what it is I am doing. I doubt there is any demo that requires more than 1 row of toolbars, but in the interest of familiarity I leave the first toolbar appear as it does with default Visual Studio settings and then customise the 2nd row to match whatever my demo(s) require – so I always have 2, no more no less. You may find that when you switch between document types the toolbars "dance" around so you must make sure you preserve the height (i.e. the 2 toolbar rows). For example, you open a Windows Form in code view and you have 2 toolbars showing but when you switch to design view then one of them (annoyingly) disappears – it is down to you to enable another toolbar for design view too, so as to preserve the overall toolbar height when switching between documents.
G) Tab Size = Indent Size = 2 spaces.
There are religious arguments between developers as to whether the editor should be using spaces or tabs (for indentation). There are also disagreements on whether the correct number of spaces (or tab size) for an indent is 2 or 4. I have little interest in opening that debate and when you are developing at home, do as you please. For presentation purposes though, you must eliminate horizontal scrolling (I hope that is an axiom and hence I don't need to prove it) and given that you are running with large font at 1024x768 at 120 DPI, guess what is a low hanging fruit? That's right, make the Indent = 2 spaces and you've just saved yourself a ton of white space and with it unnecessary h-scrolling. You can make this change from Tools->Options->Text Editor->[Your language]->Tabs.
H) Remove namespace declarations.
This one is along similar lines to the previous item – saving horizontal scrolling and unnecessary white space. For most prebaked demos, there really is no reason to have a namespace (which gets generated by default in C# code files). So simply go and remove them all and save yourself another 2 horizontal columns per file e.g.
I) Maximise, in more ways than one.
I kid you not; I have been in a session where the presenter did the whole show without ever maximising Visual Studio! I was this close (imagine me holding my thumb and index finger close together) to getting up on stage and hitting the maximise button of Visual Studio to occupy the whole screen. Besides that obvious advice, what helps with some of the goals of some of the items above is to maximise the code editor (Shift+Alt+Enter) at opportune moments, especially if you are going to spend a lot of time in one code file.
Epilogue
There are other things that I do in Visual Studio but I don't want to go through the entire alphabet here ;-). For example, I am such a strong believer in "including" as much of the audience as possible and not appearing biased, that when I first run up Visual Studio after installation, I select General Settings (instead of C# or Visual Basic).
Do you agree with all of the above? Do you vehemently disagree with some of it? How do you utilise Visual Studio for demos? I look forward to reading your comments below...
Whilst the language I use below is prescriptive as always, please note that I am far from an authority so all I am doing here is sharing my views. I'll start with 2 that I know are controversial and then move on to a mixture of mainstream points with a couple tips that I suspect most of you have not come across before.
A) Don't change colours; don't use "themes". Use the default settings.
I've been in presentations where the presenter puts a lamp of code on the screen and I am trying to compile it in my head except all the stuff I am familiar with has changed: default colours of types, keywords, comments, strings and even code editor background! "Why would you ever do that to the audience? Why do you hate them so much?". To be clear, it is fine for you to "pimp your IDE" for working purposes. However, when showing dozens (if not hundreds or thousands) of other people a demo using Visual Studio, what is the lowest common denominator that you can assume about them? Answer: that they are familiar with the default settings of Visual Studio. Unless your goal is to prove how smart/artistic you are, instead of trying to make it as easy as possible for them to follow your code, please take heed.
B) Leave the 3rd party productivity addins at home.
In case you are not familiar with them, there are 3rd party enhancements to Visual Studio (such as resharper, coderush, codesmith, visualassist, [insert your favourite here], etc) that can truly increase your productivity multi-fold. However, recall from point A above that the majority of your audience will not be familiar with them. When we show code during a demo, all effort from the audience should be concentrated on understanding the API/pattern that you are explaining and not be distracted by seeing menus they are not familiar with and being confused by how you managed to accomplish something with a shortcut that they never heard of before. Unless, of course, you are actually an evangelist for those products and/or you need the productivity boost during your demo because you are coding it for the first time instead of having rehearsed what you are showing. Do you really want your attendees coming out of your session and talking about how they enjoyed learning about one of the said products, instead of walking out with the intended take away that you had in mind?
C) Use large enough fonts everywhere.
Don't wait for the audience member to shout out to you to enlarge your fonts. Go to Tools->Options->Fonts and Colors and change the "Text Editor" font to at least 14 (and for some rooms 16). In fact, when you reach the room you are presenting in, launch Visual Studio and go seat on the last row of chairs starring at the projector; can you read your code? Furthermore, change the font for things like Tooltips, the intellisense window and all the other "Tool Windows" (hint: look at the top combobox with the label of "Show settings for:").
D) Change your highlight colour for selected text.
This is my only rule that goes against A above. Simply put, if you leave your "highlight" as the automatic default of "Blue", your text is not visible to the audience – not sure why people don't get that. You are having the opposite effect of your goal when you highlighted that piece of code. So, as per the instructions of C above, find the "Selected Text" and change the "Item Background" to "Yellow". FYI in the past I used "Lime" but I have found that some projectors show lime darker than what it is on my screen, so I have switched back to yellow.
E) One docked tool window.
I've seen demos where the presenter had multiple docked windows on all sides. How much of the code in the editor is viewable at any given time at 1024x768 resolution at 120 DPI? Every demo you do will have different windowing requirements, but in my experience I have never needed more than one side for docked tool windows (for me that is on the right, but right or left is a mute point IMO). Of course, I'll bring out a tool window from the other side (on the left for me) and also from the bottom but they are set to auto hide so they get used quickly and then disappear. You may also be tempted to autohide all tool windows but in most demos I find it useful to have solution explorer always visible because attendees can easily glance at it during the demo to remind themselves of the big picture (instead of viewing just a single code file). Regardless, windows that are set to autohide but are never used during a demo should be closed/exited instead – what is the point of having tool window tabs(=clutter) in the IDE if they are not going to be used? TIP: for prebaked demos, you can layout all the tool windows (dock/autohide/close) and then save/close the solution and the next time you open it you'll find them all in the right place!
F) Two toolbar rows; for all documents.
Again, this has to do with space-saving and with clutter removal. You may be tempted to get rid of the toolbars completely but, not only that looks weird (recall the point on familiarity), but I actually use the toolbar for some actions instead of using keyboard shortcuts so I can make very obvious to the audience what it is I am doing. I doubt there is any demo that requires more than 1 row of toolbars, but in the interest of familiarity I leave the first toolbar appear as it does with default Visual Studio settings and then customise the 2nd row to match whatever my demo(s) require – so I always have 2, no more no less. You may find that when you switch between document types the toolbars "dance" around so you must make sure you preserve the height (i.e. the 2 toolbar rows). For example, you open a Windows Form in code view and you have 2 toolbars showing but when you switch to design view then one of them (annoyingly) disappears – it is down to you to enable another toolbar for design view too, so as to preserve the overall toolbar height when switching between documents.
G) Tab Size = Indent Size = 2 spaces.
There are religious arguments between developers as to whether the editor should be using spaces or tabs (for indentation). There are also disagreements on whether the correct number of spaces (or tab size) for an indent is 2 or 4. I have little interest in opening that debate and when you are developing at home, do as you please. For presentation purposes though, you must eliminate horizontal scrolling (I hope that is an axiom and hence I don't need to prove it) and given that you are running with large font at 1024x768 at 120 DPI, guess what is a low hanging fruit? That's right, make the Indent = 2 spaces and you've just saved yourself a ton of white space and with it unnecessary h-scrolling. You can make this change from Tools->Options->Text Editor->[Your language]->Tabs.
H) Remove namespace declarations.
This one is along similar lines to the previous item – saving horizontal scrolling and unnecessary white space. For most prebaked demos, there really is no reason to have a namespace (which gets generated by default in C# code files). So simply go and remove them all and save yourself another 2 horizontal columns per file e.g.
namespace MyNamespace // delete this...and then hit Ctrl+K,Ctrl+D to reformat it all nicely.
{ // delete this
class MyClass
{
}
} // delete this
I) Maximise, in more ways than one.
I kid you not; I have been in a session where the presenter did the whole show without ever maximising Visual Studio! I was this close (imagine me holding my thumb and index finger close together) to getting up on stage and hitting the maximise button of Visual Studio to occupy the whole screen. Besides that obvious advice, what helps with some of the goals of some of the items above is to maximise the code editor (Shift+Alt+Enter) at opportune moments, especially if you are going to spend a lot of time in one code file.
Epilogue
There are other things that I do in Visual Studio but I don't want to go through the entire alphabet here ;-). For example, I am such a strong believer in "including" as much of the audience as possible and not appearing biased, that when I first run up Visual Studio after installation, I select General Settings (instead of C# or Visual Basic).
Do you agree with all of the above? Do you vehemently disagree with some of it? How do you utilise Visual Studio for demos? I look forward to reading your comments below...
Labels: AboutPresenting
Sunday, February 17, 2008
I've been meaning to post something like this for a while and having just spent 8 (eight) days of training (DPE summit + TechReady 6 + Deep Dive on XYZ), I need no more incentives ;)
I am assuming that we've all been to sessions/events where the presenter switched from PowerPoint to their machine for a demo and immediately our brain goes in overdrive to take in all the colourful input and icons that have just been unleashed on it (completely ignoring the presenter's voice which just fades in the distance, of course). Or maybe that just happens to me ;-)
Well, I am no expert, but here is some advice anyway for those of you giving demos in presentations:
1. Run at 1024x768 resolution during the session/demo.
2. Run at (120) High DPI. I cannot stress this enough. If you are on Vista this requires a reboot but give it a try now and you'll never look back (all icons suddenly come alive).
3. Your Task Bar should only show applications running that are being used in the demo (and the session overall). Any unnecessary application should be closed.
4. Your Task bar should be as small as possible (i.e. only one row). Doesn't matter what size it is when you are working on your machine; taking away pixels from the audience has no excuse when there is absolutely no use for it being larger during a demo.
5. Your taskbar should be at the bottom where most people expect it to be and it should not auto-hide (very distracting).
6. You know those icons on the right of the taskbar (commonly referred to as the systray or just "tray")? If you are not using them for the demo, then kill them. Right click on each one and "Exit". If any don't offer an Exit option, open task manager and kill the offending processes. If there is an icon that cannot be closed for whatever reason and is not used in the demo, hide it (Taskbar Properties->Notification Area). This includes hiding icons such as the volume icon, network activity etc, if they are not used in the demo. For most of my demos I just have the clock (cause I like glancing at it) and the power meter (because I am paranoid that someone will pull the plug and my laptop will die ;-)) – nothing else.
7. You know all those toolbars on the task bar (e.g. Desktop, Address etc)? Get rid of them unless they are used in the demo. The special toolbar is Quick Launch: This is where you may choose to have the shortcuts to your demos (or even just a shortcut to Visual Studio). In that case make sure that all other shortcuts are out of view by resizing the quick launch bar.
8. Hide all the icons on your desktop (right click->View->Show Desktop Icons). The exception to this is when you place the shortcuts to your demos on the desktop. In that case, hide all the remainder icons by moving them into some other temporary folder (and go back to step 7 and hide your quick launch toolbar since you have just opted out of that approach).
9. Choose a standard Windows Wallpaper for your desktop background (the default if possible) – unless you are using your current one as a prop for a laugh etc. You can change it back to a picture of your kids when the session is over. Remember, this isn't about you; it is about what you are there to show.
10. Turn off your screen saver (and don't rely on battery power alone – always plug in your laptop. And change the laptop_lid_close_action to do nothing).
11. BONUS non-visual tip for demos: A side effect of steps 3 and 6 will be that your machine is slightly faster during the demo (where any kind of visible slow down is amplified by the presence of an audience). Open task manager and make your machine even more responsive by killing unnecessary processes (or even stopping services) that you are not going to use in this particular demo. But don't take it to the extreme.
Feel free to add your own tips below if you think I missed any...
I am assuming that we've all been to sessions/events where the presenter switched from PowerPoint to their machine for a demo and immediately our brain goes in overdrive to take in all the colourful input and icons that have just been unleashed on it (completely ignoring the presenter's voice which just fades in the distance, of course). Or maybe that just happens to me ;-)
Well, I am no expert, but here is some advice anyway for those of you giving demos in presentations:
1. Run at 1024x768 resolution during the session/demo.
2. Run at (120) High DPI. I cannot stress this enough. If you are on Vista this requires a reboot but give it a try now and you'll never look back (all icons suddenly come alive).
3. Your Task Bar should only show applications running that are being used in the demo (and the session overall). Any unnecessary application should be closed.
4. Your Task bar should be as small as possible (i.e. only one row). Doesn't matter what size it is when you are working on your machine; taking away pixels from the audience has no excuse when there is absolutely no use for it being larger during a demo.
5. Your taskbar should be at the bottom where most people expect it to be and it should not auto-hide (very distracting).
6. You know those icons on the right of the taskbar (commonly referred to as the systray or just "tray")? If you are not using them for the demo, then kill them. Right click on each one and "Exit". If any don't offer an Exit option, open task manager and kill the offending processes. If there is an icon that cannot be closed for whatever reason and is not used in the demo, hide it (Taskbar Properties->Notification Area). This includes hiding icons such as the volume icon, network activity etc, if they are not used in the demo. For most of my demos I just have the clock (cause I like glancing at it) and the power meter (because I am paranoid that someone will pull the plug and my laptop will die ;-)) – nothing else.
7. You know all those toolbars on the task bar (e.g. Desktop, Address etc)? Get rid of them unless they are used in the demo. The special toolbar is Quick Launch: This is where you may choose to have the shortcuts to your demos (or even just a shortcut to Visual Studio). In that case make sure that all other shortcuts are out of view by resizing the quick launch bar.
8. Hide all the icons on your desktop (right click->View->Show Desktop Icons). The exception to this is when you place the shortcuts to your demos on the desktop. In that case, hide all the remainder icons by moving them into some other temporary folder (and go back to step 7 and hide your quick launch toolbar since you have just opted out of that approach).
9. Choose a standard Windows Wallpaper for your desktop background (the default if possible) – unless you are using your current one as a prop for a laugh etc. You can change it back to a picture of your kids when the session is over. Remember, this isn't about you; it is about what you are there to show.
10. Turn off your screen saver (and don't rely on battery power alone – always plug in your laptop. And change the laptop_lid_close_action to do nothing).
11. BONUS non-visual tip for demos: A side effect of steps 3 and 6 will be that your machine is slightly faster during the demo (where any kind of visible slow down is amplified by the presence of an audience). Open task manager and make your machine even more responsive by killing unnecessary processes (or even stopping services) that you are not going to use in this particular demo. But don't take it to the extreme.
Feel free to add your own tips below if you think I missed any...
Labels: AboutPresenting
Monday, January 28, 2008
I recently received (as a gift) the "Microsoft Office Powerpoint 2007 Step-by-step". I was scanning thought it to see if I am missing any tricks and came across page 232 where it advises on how to use Presenter view when using two monitors. That reminded me of how I had evaluated and discarded this feature before the 2007 version so, after looking at it again, my reasons still holds true:
3. Presentation View does not show animations. So when I go to a slide that has animations, on my screen I will see the entire slide while the audience is seeing a different one.
- I don't like looking back on the large screen because I find it distracting.
- I like to see on my screen what my audience is seeing.
- Clicking (on my clicker/mouse/keyboard) in order for the animation to appear on the large screen while nothing happens on my screen makes me uncomfortable.
2. Presentation view is useful for slide notes, but I'd rather not read anything while the audience is expecting me to be speaking instead.
1. It encourages the presenter to be in front of the laptop screen for the duration of the presentation, which whilst the only option in some venues, is not my preferred place to be.
There you have it, instead of telling you what features I do use in powerpoint, I am sharing the one that I don't... oh well, maybe you have some powerpoint tips to share?
3. Presentation View does not show animations. So when I go to a slide that has animations, on my screen I will see the entire slide while the audience is seeing a different one.
- I don't like looking back on the large screen because I find it distracting.
- I like to see on my screen what my audience is seeing.
- Clicking (on my clicker/mouse/keyboard) in order for the animation to appear on the large screen while nothing happens on my screen makes me uncomfortable.
2. Presentation view is useful for slide notes, but I'd rather not read anything while the audience is expecting me to be speaking instead.
1. It encourages the presenter to be in front of the laptop screen for the duration of the presentation, which whilst the only option in some venues, is not my preferred place to be.
There you have it, instead of telling you what features I do use in powerpoint, I am sharing the one that I don't... oh well, maybe you have some powerpoint tips to share?
Labels: AboutPresenting
Copyright © Daniel Moth
