- Code (May 23, 2005)
- Debug (June 6, 2005)
Click here to view the article with full size images.
Like a concept car strutting its stuff, the Visual Studio 2010 Concept IDE is packed with over-the-top features and weird ideas. Tame as it may look, this UI designed for one thing: jamming out code. Save the bizarre Windows Media-esque skins for the punks, we’ve got work to do.
Here it is:
Concept One: The Solution Explorer (green box)
The green box at top left clearly identifies the name of the solution and provides two nice summary stats: total type count and total source line count.
Click the green arrow to slide out a panel providing full configuration options for the solution.
Concept Two: Assembler (yellow box)
Add, remove or build assemblies from the Assembler. Display assemblies in alphabetical or build order. Build individual assemblies by clicking the build number on the right. The shaded circles indicate the number of code files in the assembly - with darker colors indicating a greater number of files.
Click the yellow arrow to slide out a panel replete with assembly configuration dream tools.
Concept Three: CodeFile Crawler (blue box)
You’ve got exactly one jillion code files in your assembly, right? Use the Crawler to find the one you need to work on next. Search by type, type name, namespace or use the root feature to select a root type - the Crawler will then find all referenced types down to level zero. If that’s too many types, use the Level Cutter to limit the results to a given level.
Concept Four: Head (color-coded area above the editor)
After you select a type in the Crawler, the type name and relevant stats are displayed in the Head. Of course, the stats update as you code.
Concept Five: Remoting Eye (large circular icon in the head)
Of course you’re pair programming – the eye tells you so. Whenever the eye is displayed, your programming partner’s computer is connected to the session. Click the eye and select “Pass The Baton” to send a current copy, the diffs, or checkout the same files from your partner's computer (whatever your version control system wants to do) and then switch your UI into remote mode.
Concept Six: Click Strip (directly above of the editor)
All types referenced by the currently selected type are displayed in the strip, just click them to view the code file for that type.
Concept Seven: Ashes (gray box)
On the right, the code files which have been selected in the past, along with summary stats indicating the amount of work done on each are listed. Enter the first few letters of a code file into the Filter box at the top to jump to an entry.
Concept Eight: Floating Run Button
Vertically centered to the right of the method in which the caret is currently positioned is the floating run button. It builds and runs the application (just like F5).
Concept Nine: Floating Search and Replace
The giant magnifying glass at the top corner of the editor indicates that the poor man’s refactoring tool is within easy reach. Yes it does all the standard search and replace stuff.
Concept Ten: Greenboard
The Greenboard is a popup window displayed when the floating run button is clicked. Each assembly to be built is accompanied by a bar graph, proportionally sized based on the amount of source in the assembly. Error messages are collected at the bottom of the board. If an assembly fails to build, the Greenboard automatically closes and the Error Trap is displayed.
Concept Eleven: Error Trap
The ErrorTrap appears when compilation fails. It makes for clear, quick identification of errors.
Click here to view the article with full size images.
In this second part of the Visual Studio 2010 Concept IDE article, we address debugging. Before we get started, let’s first use the shuttering system in the Concept IDE to make code king. Here all shutters have been collapsed, maximizing the code editor:
Concept Twelve: Visual Breakpoint Conditions
Breakpoint conditions can now be entered directly into the editor, just click the small red arrow labeled “Condition” to slide out a panel below the breakpoint and code away. Conditions are persistent, that is, as long as the line of source where the breakpoint is defined exists, the condition for that line is remembered thereafter.
Concept Thirteen: Stepper
Hovering over the all-important line of code currently executing is the Stepper. This little navigator makes it easy to Step Into, Step Over or Step Out. It also enumerates the various property getters poised for resolution as of the current line. You can easily skip over these on your way into the method of interest, or step into them by clicking in the Stepper. Getters which contain anything beyond a simple return of a field value are marked with a special icon.
These generated diagrams form a map of the running application. See which objects are instantiated, which methods have been called and easily inspect object values. Minis, and the standards by which they are generated are discussed in detail here.
Concept Fifteen: Visual Stack
Minis give us the opportunity to present the stack as a diagram, with certain methods, property getters/setters or interface implementations “lit up” to show that they are currently receiving attention from the CPU. Click anywhere in the Mini and the source for that member is displayed in the Code Editor. Create Watch values by dragging from the Mini to the Watch window.
Concept Sixteen: Object Dash
Click the small orange square at the top left of a Mini to display the Object Dash. This small watch window defaults to the field values in the object, but can be customized with code-based watches. The default values can be quickly removed by clicking the checkboxes on the left. Once you customize an Object Dash, those customizations are remembered per type. Object Dashes can also be launched from anywhere in the Debug UI where an object reference is displayed (for example the Call Stack, the Watch window, or the Code Editor itself) by placing your mouse over the reference and clicking Ctrl-Shift-O.
Concept Seventeen: LiveObjects
When the debugger hits a breakpoint, use the LiveObjects panel to view the currently existing objects.
Concept Eighteen: The Barge
The Barge is a list of all objects which have been garbage collected, including the amount of memory reclaimed. Reduce the noise in this list by right-clicking and filtering out delegates, attributes, collections or the descendants of any type.
Concept Nineteen: Origins
It’s definitely great to know which objects currently exist (LiveObjects) or have existed (the Barge). When the object counts look wrong and you need to know the methods where these objects were created, check the Origins panel. Double-click the method to display the source in the code editor.
Concept Twenty: Trax
From the moment you hit the floating run button, to the moment you shut down the application, the lines of code executed and the amount of CPU time consumed by each is tracked. Use the Trax Summary to locate the most time intensive or noisy methods. Select a method in the Summary and the SubTracker will show all time-intensive calls in that method. Click one of these calls in the SubTracker or the “bullet” in the Code Editor to continue drilling down. Trax also highlights each line of source that executed during the last run, making it easy to differentiate which lines executed from those lines which did not.
And that’s it. What about the Visual Forms Designer, Refactoring, UML, Tests, and that AI Buddy who codes everything for me? Won’t these gizmos be in there by 2010? Well, that’s where you come in. Suggest ways of bringing this UI forward even further, and we will incorporate the best in revisions of this article!
The Concepts Behind The Concept IDE
Edward R. Tuft-esque ideas in this IDE are:
The “look” of this IDE was inspired by the works of Edward R. Tufte. The editing area is white, drawing your attention to the focus of your work: the code. Color coding on the left divides the major areas, and clearly identifies them in the Head when they are selected (i.e. when the giant arrow is clicked.) Any name created by you is displayed in black. Any name which is part of the IDE is deemphasized. “Hard” separator lines have been avoided.
Alan Cooper-esque ideas in this IDE are:
Everything is saved, including the undo stacks of all code files, the last type selected, the ashes list, etc. Whether you unplug your computer from the wall, or orchestrate a nice agreeable Start | Turn Off sequence, the IDE looks exactly the same the next time you launch it.
Designed to be maximized and used for hours at a time, this UI has understated controls and provides no distracting 3-D effects, save hot controls, which draw in an XP style when the mouse is over them. Affordance is provided through cursor hinting and hot control effects; expert users can “discover” functions as they go.
Putting Will Over Might
The jillion things a developer might want to do in the IDE have been relegated to dialogs and the menu. The few things that a developer will definitely need to do every day (or every minute) have been placed front center.
About Face: Alan Cooper
The Visual Display of Quantitative Information: Edward R. Tufte
Before you say “Not another diagramming standard!” please note that the DebugDiagrammer in the Concept IDE is pluggable and can be replaced with UML or your own custom diagrammer. The intent here is to visualize objects, not classes. Mini is short for Miniature, and the diagram is just that, literally a thumbnail showing the working internals of an object.
The heart of the Mini diagram is a rectangle representing the object.
Properties are represented by an ellipse.
If a property implements a value type, it contains a tiny rectangle.
If a property implements a reference type, it contains a circle.
The getter for a property is indicated by a shape on the left side of the ellipse.
The setter for a property is indicated by a shape on the right side of the ellipse.
When a getter or setter contains any code beyond a simple return or assignment of the field value, a line is drawn from the enclosed shape to the edge of the ellipse. Here is an example of a read/write property with code in the getter.
Methods are indicated by rounded rectangles.
Tiny squares are used to represent the parameters of the method.
Methods with more than three parameters use an ellipsis in place of the third square.
Interfaces are shown at the top left via a prong-like symbol.
Events are displayed at the bottom via an outlet-like shape. The down arrow inside the shape represents the delegate used to implement the event.
Fields containing value types are represented by tiny rectangles – these look almost like a hyphen.
Fields containing objects (reference types) are displayed as circles.
Constructors appear at the top left. Like methods, these shapes contain tiny squares representing any parameters.
A Destructor, if declared, is displayed as a grey rectangle immediately below the last constructor.
The scope and visibility of the various object parts is indicated by the location in the Mini. Public properties appear on the left, with the left tip of the ellipse protruding.
Public methods appear on the right, with the right edge of the rectangle protruding.
Public events appear at the bottom, with the “outlet” protruding.
To display a watch window specific to the Mini, click the orange button.
Static, private and protected members are displayed in special regions inside the Mini. Here we have a Mini with a static region, a private region and a protected region. The static region at the top contains fields. The private region in the middle contains fields and methods. The protected region near the bottom contains methods and properties.
Where the implementation of an object is split between a class and its ancestor, a Mini is drawn above with an inheritance triangle at its base. Here you can see the stack arcing through the ancestor to the descendent implementation.
Click here to return to the article.