Moving on with our series on productivity. This time around I want to talk about how I organize my windows and monitors. This goes back into what I said at some point: using Windows and any application running on it just as-is out-of-the-box is kind of like buying a car and driving it around without ever adjusting the rear-view mirrors, the driver’s seat, etc. When we’re driving a car, we have to adjust those things so to make sure we can see everything that’s important, while still concentrating on the road ahead of us.
I’ve been working with dual monitors for about 7 years now, and I simply can’t work on a single monitor setup without cursing the living hell out of me. Working with a single monitor feels very claustrophobic to me, and I hate it (even though I always run at 1600×1200 pixels). But it can get worse; for instance, when I’m doing presentations and have to not only run a single monitor, but also drop the resolution to 1024×768. I guess that’d be the same feeling of driving one of those gigantic trucks people drive in Texas in any of those cities in Europe that have some really narrow streets (I’ve never done it, but I could bet it feels the same). 🙂
Working with Visual Studio and Dual Monitors
So part of effectively using two monitors is to make sure we configure the applications to take advantage of it. I’ll concentrate on Visual Studio, since that’s where most of us developer hang out. By default, developer usually run VS something like this (even if running dual monitors!):
Have I said before how much I feel that is claustrophobic? 🙂
In such setup, one can’t really see the full form, and may be seeing windows that really aren’t relevant for the task to be accomplished (in the snapshot, that is to lay out a form). Then, the developer switches to "View Code" mode, and then sees something like this:
Great… now the toolbox doesn’t show anything useful, and so it doesn’t the Properties window. And, we can’t barely see the code, which is really what we’re currently interested in. Just for the record, if you press Shift+Alt+Enter, VS switches to "Full Screen" mode, which gets rid of all the windows in VS, and displays mostly the code editor window (I use this feature a LOT when I absolutely have to work with a single monitor – like when doing presentations).
How about we use that second monitor that’s hanging in there? Except for the code editor, most windows in VS are "dockable", such as the Solution Explorer, Properties, Output, etc. So why not move those out of the way, but still keeping them close for when you need them? The following snapshot shows how I set up my environment here:
On the left monitor, I keep the code/form editor and the toolbox (since I’m always going to the toolbox to drag and drop controls onto the form, right?). On the right monitor, I keep the "accessory" windows I use a frequently. This set up allows me to have as much focus as I can on the most important thing, which is whatever I’m working on the monitor to the left, but I still have a pretty easy access to stuff I use frequently, which I move to the monitor on the right.
Let’s expand a little that monitor on the right so that you can see what I normally hang in there:
- Items 1 (Solution Explorer) and 2 (Class View) show what I use for navigation. Most of the time I use the Solution Explorer, but I quite often use the Class View as well, so I keep them tabbed there;
- Item 3 is the Properties window, which I use not only to set properties on visual controls, but also to see properties on the item that’s currently selected on the Solution Explorer, such as the full path to the selected file, for example;
- Item 4 shows the Metrics window. This window is part of DevExpress’ Refactor! Pro. It shows Code Metrics for the file currently being edited. I like this window being there because it helps me keeping an eye on the quality of the source code I’m sitting on, and if I see any visual indication of "code smells" (for instance, methods that are too long and/or too complex) I can consider refactoring it (or at least to make a note and come back to it later);
- Item 5 is the Server Explorer. I use that one instead of going back and forth to SQL Management Studio. For instance, for simple things like checking out the structure of a table (columns, data types, etc.), the source code of a Stored Procedure, or even to just see the data within a table, the Server Explorer is much better than using the full-blown SQL Management Studio;
- Item 6 shows the bottom part of the screen, where I put things such as the Output window, Task List, and Error List.
Switching Windows Layouts
There are cases when I want to run VS only in one monitor, even though I’m on a dual monitor setup. For instance, if I’m connecting remotely to my computer, dual monitors aren’t supported, so I want to switch my VS windows configuration to only fit one monitor (for the records, Windows Vista does support dual monitor through remote connection).
Another scenario is when I want to see both VS and, say, the web browser (because I’m looking up some info); in such scenario I don’t want the browser going away when I activate VS, so fitting VS in a single monitor is more appropriate.
In order to have a handy way of switching screen layouts, I’ve been using the hint described in this article. In a few words, it uses macros to restore windows layout settings, therefore, rearranging all the windows in VS as you’ve pre-defined. I’m going to exploring the same technique and set up some more optimized settings for a few more scenarios such as "working with WinForms", "working with source code", "working in test-driven development mode", "working in debugging mode", etc., and for each of those, have support for both single and dual monitor setups.
The Ultimate Hardware Setup!!
Even better than working with dual monitor, is to work with three monitors: one 30-inch widescreen in the middle, plus one screen on each side in "vertical mode":
THAT is what I’m talking about!!! 🙂
Claudio Lassala's Blog 