VS2011 “Reimagined” – Class View

Note: The below is an attempt to contribute to the discussion around Visual Studio vNext and what I think personally should eventuate into features for future generations of Visual Studio. The objective behind this is not to declare the UI examples as “done” but more to provoke a discussion around ways in which the tool itself could become more intelligent and contextually relevant to not just developers but also those of us who can do both design and code. I plan on compiling this into a more comprehensive document post public feedback.


Today, the ClassView inside Visual Studio is pretty much useless for most parts, in that when you sit down inside the tool and begin stubbing out your codebase (initial file-new creation) you are probably in the “creative” mode of object composition. Visual Studio in its current and proposed form does not really aid you in a way that makes sense to your natural approach to writing classes. That is to say, all it really can do is echo back to you what you’ve done or more to the point give you a “at a glance view” only.


The class view itself should have a more intelligent by design visual representation. When you are stubbing or opening an existing class, the tool should reflect more specifics around not only what the class composition looks like (at a glance view) but also should enable developers to approach their class designs in a more interactive fashion. The approach should enable developer(s) to hide and show methods, properties and so on within the class itself, meaning “get out of my way, I need to focus on this method for a minute” which in turn keeps the developer(s) focused on the task. The ClassViewer should also make it quick to comment out large blocks of code, display visual issues relating to the large blocks of code whilst at the same time highlight which parts of the codes have and don’t have Attributes/Annotations attached. Furthermore, the ClassViewer should also allow developer(s) to integrate their source and task tracking solutions (TFS) via a finite way, that is to say enable both overall class level commentary and “TODO” allocation(s). At the same time have similar approaches at a finite level such as “property, method, or other” areas of interest – (i.e. “TODO: this method is not great code, need to come back refactor this later”).

Feature breakdown.

image The above is the overall fantasy user interface of what a class viewer could potential look like. Keeping in mind the UI itself isn’t accommodate every single use-case, but simply hints at the direction I am talking about.


image Inside the ClassView there are the following Navigational items that represent different states of usage.

Documentation TBA.

Stats TBA.

Usage by TBA.

Derived By

The “Derived By” view enables developers to gain a full understanding of how a class handles known inheritance chain by displaying a visual representation of how it relates to other interfaces and classes.


image This inheritance hierarchy will outline specifically how the classes’ relationship model would look like within a given solution (obviously only indexing classes known within an opened solution).
  • The end user is able to jump around inside the minimap view; to get an insight into what metadata (properties, methods etc.) is associated with each class without having to open the said class.
  • The end user is able to gain a satellite view what is inside each class via the Class Properties panel below the minimap.

Class Properties.


Interactive Elements.

  • The end user is able to double click on a minmap box (class file representation) and as such, the file will open directly into the code view area.
  • The end user is able to select each field, property, method etc. within the Class Properties data grid. Each time the user selects that specific area and If the file is opened, the code view will automatically position the cursor to the first character within that specific code block.
  • The end user is able to double click on the image first circle to indicate that this code block should be faded back to allow the developer to focus on other parts of the code base. When the circle turns red, the code block itself foreground colour will fade back to a passive state (i.e. all grey text) as whilst this code is still visible and compliable, it however visually isn’t displayed in a prominent state.
  • The end user is able to click on the image second circle to indicate that the code block itself should take on a breakpoint behaviour (when debugging please stop here). When the circle turns red, it will indicate that a debug breakpoint is in place. The circle itself right click context will also take on an as-is behavior found within Visual Studio we see today.
  • The end user is able to click on the image Tick icon (grey off, green on). If the Tick state is grey, this indicates that this code block has been commented out and is in a disabled state (meaning as per commenting code it will not show up at compile time).
  • The end user is able to click on the image Eye icon to switch the code block into either a private or public state (public is considered viewable outside the class itself, ie internal vs public are one in the same but will respect the specifics within the code itself).

Stateful Display.

  • Each row will indicate the name given to the property, its return or defined type, whether or not it is public or private and various tag elements attached to its composition.
  • When a row has a known error attached within its code block, the class view will display a red indication that this area needs the end users attention.
  • The image eye icon represents whether or not this class has been marked for public or private usage (i.e. public is considered whether the class is viewable from outside the class itself – ie internal is considered “viewable” etc.).
  • Tags associated to the row indicate elements of interest, in that the more additional per code block features built in, they will in turn display here (e.g.: Has Data Annotations, Codeblock is Read Only, Has notes attached etc.).


My thinking is that development teams can attach tabs to each code block whilst at the same time the code itself will reflect what I call “decorators” that have been attached (ie attributes). Example Tags.
  • image Attribute / Annotation. This tag will enable the developer to see at a glance as to what attributes or annotations are attached to this specific code block. This is mainly useful from a developer(s) perspective to ensure whether or not the class itself has the right amount of attributes (oops I forgot one?) whilst at the same time can provide an at-a-glance view as to what types of dependencies this class is likely to have (e.g use case Should EntityFramework Data Annotations be inside each POCO class? Or should it be handled in the DBContext itself?..before we answer that, lets see what code blocks have that dependency etc.).
  • image Locked. This ones a bit of a tricky concept, but initially the idea is to enable development teams to lock specific code blocks from other developer(s) manipulation, that is to say the idea is that when a developer is working on a specific set of code chunks and they don’t want other developer(s) to touch, they can insert code-locks in place. This in turn will empower other developer’s to still make minor modification(s) to the code whilst at the same time, check in the code itself but at the same time removing resolution conflicts at the end of the overall work stream (although code resolution is pretty simplified these days, this just adds an additional layer of protecting ones sandpit).
  • image Notes. When documenting issues within a task or bug, it’s at times helpful to leave traces behind that indicate or warn other developers to be careful of xyz issues within this code block (make sure you close out your while loop, make sure you clean-up your background threading etc.). The idea here is that developer(s) can leave both class and code-block specific notes of interest.
  • Insert Your idea here. These tag specific features outlined so far aren’t the exhausted list, they are simply thought provokers as to how far one can go within a specific code-block. The idea is to leverage the power Visual Studio to take on a context specific approach to the way you interact with a classes given composition. The tags themselves can be injected into the code base itself or they can simply reside in a database that surrounds the codebase (ie metdata attached outside of the physical file itself).

Discussion Points..

  • The idea behind this derived by and class properties view is that the way in which developer(s) code day in day out takes on a more helpful state, that is to say you are able to make at-a-glance decisions on what you see within the code file itself. At the same time providing a mini-map overarching view as to what the composition of your class looks like – given most complex classes can have a significant amount of code in place?
  • Tagging code-chunks is a way of attaching metadata to a given class without specifically having to pollute the class’s actual composition, these could be attachments that are project or solution specific or they can be actual code manipulation as well (private flipped to public etc.). The idea is simply to enable developer(s) to communicate with one another in a more direct and specific fashion whilst at the same time enable the developer(s) to shift their coding lense to enable them to zero in on what’s important to them at the time of coding (ie fading the less important code to a grey state).
Going forward, throw your ideas into the mix, how would you see this as being a positive or negative way forward?

Related Posts:

  • Craig

    One obvious issue is that solution/project/classview panels on the right are far too wide. I like to have them up all the time so I can easily click among files, but as narrow as possible not to waste screen real estate. Also the Error List, Debug tabs along the bottom, often I have 10 tabs open, will they fit.

  • @a57213474d99e1a4f59d73ec074c3f88:disqus  depends on the hardware and monitor setup. Most developers in a cubicle (non-laptop) form are actually making use of dual or more monitor setups, so in a sense your ability to scale horizontally can be quite large. That for me is my thinking about a wide screen composition but most importantly I’m thinking that the right areas of interest really are your map to your codebase, that is to say its your context zone… highly reactive UI.

    You can consolidate the UI into more chunkable views, but the obvious lose here is the smaller you get the less detail you have on display. 
    I am putting together another post around the idea of having Bento UI, that is to say you can pick and choose your own template view state and allocate stateful panels into these areas… the idea behind this thinking is nothing inside Visual Studio is concrete its in fact 100% customizable and each developer can position the composition to suite their needs, screen sizes and what they value or de-value.

    The current UI sketches don’t highlight this as for now i’m spending the energy on zeroing in on specific features and how they could work less about how the outer chrome clicks together as thats an entire blog post on its own! 🙂

  • Pete

    Pretty cool, but honestly I’d really prefer more information in the code editor itself- rather than putting the base classes in the class view, display them inline with the code, above the class declaration. Make the code editor as powerful as possible, more than just a text editor.

    If the point of the class view is to improve cognition or navigation of the file then I think there are better ways to do it.

    Also, order matters- the order that I have methods in my code are the order they are typically used, or grouped somehow. Very rarely are they just alphabetically. Any high-level display of the code should be able to maintain this so I don’t have to have two cognitive models of the class.

    An alternate version of class view would be an almost ‘collapsed’ view of the code- a tree view control that automatically expands to your location in the code (even showing for loops and if statements?), but only shows peers at the higher level. Keep everything organized in the same order as the code.

    Also- if class view is for navigation of the code file then it *cannot* be under the solution explorer- the solution explorer is always up and I’m never going to switch away just to see the class view. Make the class view super minimal and put it into the code file. See screenshot of Sublime Edit’s minimap. If it was behind the file tree then absolutely no one would use it. Where it is I find it useful. But if it was as intrusive as a standard VS pane, then it goes back to useless.

  • Orion Adrian

    Firstly, I want to state that rethinking visual studio is an incredibly ambitious project, even if you’re not rethinking every piece of it (which in itself would be a full-time job for multiple people — Visual Studio is one of the largest pieces of mass-use creation software in existence). I think discussion is good and in that spirit I have some comments. I like some of the ideas presented, but they really come off like a visual designer trying to figure out how to apply visual design concepts and metaphors to Visual Studio and that’s good in some cases, but in several I’ve felt like you’ve either gone too far, or haven’t really applied the concept well or tried to solve a problem that wasn’t there.

    I think the one of the places where things come off the rails is that a large number of architects and developers are language-first people, visual-second. There are some places where you’ve replaced existing natural symbols (//) with glyphs (checkmarks). I might have just dropped the circle afterwards in the class property pane and just left the (//) as signal of commented-ness (though understand that what you’re proposing may not mathematically be possible since comments are not required to be lexically valid.

    Another place where I find re-imaginings like this fail is that they don’t handle the actual scale of real projects well. For example the design doesn’t leave nearly enough space for class members in the lower right. Most classes in an enterprise app are going to be in the dozens of properties. A good item to test the usage of your scenario is how does it handle “System.Web.UI.Controls.GridView”. As for the derivation area, you’ll need zoom controls because the number of classes in a hierarchy chain can be in the hundreds (just in your own code).

    Now for some specific points.

    Documentation and note taking: This should always be in the code or project. The problem in writing and maintaining code more often than not is that people put comments places where you can’t get at them. Code comments are the only real comments you can rely on and encouraging people to put those elsewhere just means they’ll be even less useful.

    Breakpoints: Breakpoints can be used in a simple (break when entering this method), but it’s almost never that simple and I would never be satisfied with a breakpoint system like that. Ultimately because 90+% of my breakpoints are in-block and not start-of-block, then I would end up relying on the 90+% behavior for the remaining 10%.

    Privacy and the eye icon: Privacy isn’t even close to a binary state and the details of privacy are incredibly important. There’s public, private, protected, internal, and protected internal, and unspecified (public for struct, private for class) (and that’s just C#). Meaning that the eye icon is dangerously insufficient.

    Member representation (i.e. fields, methods, properties): For methods, signature is all important, otherwise you’ll just have a long list of methods with the exact same name over and over again. A good class to test your design against is System.Convert. If it doesn’t handle that well, then you’ll fail in most cases. As it stands the design doesn’t even seem to attempt to handle methods or fields, only properties. Handling these in the same space is critical.

    Error Representation: Issues around this one is something I see a lot in designs. Part of the problem is that errors are consumed either in a one-at-a-time post-compile way; or are-there-errors-in-this-file sort of way. Your mini-map indicates error state in the latter way, but doesn’t allow the user to see all the errors in the file at the same time. Additionally, which method an error is in isn’t as important as that there is one and making it easy to click. My favorite way these days is showing errors in the scroll-bar which always has a mapping of the entire file. I can quickly see warnings, errors, suggestions and such. ReSharper does a wonderful job here, even summing it all up up top with a green, yellow or red square indicating if there are any errors or warnings.

    Finally to address your specific discussion points.

    There are a number of good minimaps out there already and I think the idea is a good one, but ultimately there are standard, compact ways of representing various states and those should probably be respected for no other reason than that they’re already very well established. Tradition isn’t king, but coming up with a new representation of privacy and static/instance-ness that doesn’t further refine what’s already there doesn’t really improve things. The glyphs could probably be simplified, but it’s going to take something really great to justify the change.

    To your second point, polluting the .cs files is exactly what we want to do. Polluting the member implementations is the tricky part. Code commends, sand castle/xmldoc comments are good things. I find formatting comments like so to be preferrable though:

    // Comment that refers to specific points in code [1] and some other specific point [2] and maybe even a third point [3].
    // Continuing comments that explain what the code is trying to do.
    public void Method(int i, string s)
        statement; // [1]
        if (expression)
            statement; // [2]
        // .. and so on. (note that most one-line comments wouldn’t be in here).

    The idea being that you have comments describing in-higher detail what it’s doing referencing explicit points in the code for clarity. There is space within this kind of thinking for further refinement.

    Ultimately understand that the design languages for images and videos and for code are very different. Code isn’t visual and is processed by a part of the brain that must comprehend so a sloppy, conversational style actually helps. The Code First books while making me feel like I’m five actually do a very good job of communicating advanced concepts. They’re visually pleasing, but they understand that code is fundamentally a written medium and really the best form is a block of code annotated inline with all the thinking that goes into the process. It’s right there. Frankly I’d like more space to write stuff. I’d love a way to do ink there (with hot-links), but we’re not there. Remember code is always in DRAFT form. If you remove all the draft comments from code you’ve essentially ruined it. I think if you take that into consideration you can come up with some truly wonderful designs.

  • Jedeco3

    I found this piece incredibly boring and just very hard to read. Run on sentences and many other grammatic mistakes, along with misspellings (too, as in also, is not “to”) made this a lot of work to read. I’m not sure I’m going to take any advice from a designer who cannot, first of all, write in a pleasing manner.
    I also think the speculation about what the audience wants is a bit premature and coming from an IT guy, which is basically going against the logic you claimed made Apple successful. How does any interface not get boring? What has kept the iTouch/pad interface interesting? I see it as a modern, higher pixel count Windows 3.1 interface actually. The itouch bores the living hell out of me. Another icon driven interface, unchanged since the late 80s?  You’ve got to be kidding about this, right? 
    Oh well, it’s always en vougue to write negatively about Microsoft, that’s how you “prove” you have real IT chops isn’t it?  This is now a shameless prerequisite for people inside and outside of Microsoft who consider themselves “writers” and it has become untenable.