aaron's weblog : UI Design and Usability

Feedback Requested: Visual Studio 2005's Look and Feel

aaronbrethorst — Thu, 16 Feb 2006 01:24:00 GMT

As you may be able to discern from the contents of this weblog, I'm the Program Manager who is responsible for a lot of the overall look-and-feel of the Visual Studio product line. Specifically, I drive User Experience, Shell UI, and Accessibility across Visual Studio.

You've all probably had a chance to work with Visual Studio 2005 a fair amount now that it's been generally available for a few months. I've been spending a great deal of time lately thinking about how we can improve Visual Studio's user experience in a number of areas, and I wanted to get feedback from everyone in the community on this.

Feel free to post a comment on any thoughts you may have, but here's a rough framework you can work from if you feel inclined:

Do you use Windows XP, 2003, or Vista with visual styles (themes) enabled?
If so, which OS and theme do you use?
If not, why not?
Regardless of your answers to questions 1-3, do you think Visual Studio 2005 looks better than VS 2002 or 2003? Why, or why not?
Do you think VS 2005 is easier to use than VS 2002 or 2003? Why or why not?
What is your least favorite part of VS 2005's UI?
What is your favorite part of VS 2005's UI?

Thanks, everyone! I look forward to reading your comments on this :-)

Feedback Requested: Visual Studio 2005 Tab Design Iteration 2

aaronbrethorst — Wed, 16 Mar 2005 22:41:00 GMT

I want to thank everyone for all of the terrific feedback we received on our first pair of tool window tab designs for Visual Studio 2005. As of right now, we've gotten 124 comments, which is really outstanding!

I've been working with our designer, Corrina, to modify the tab designs we showed before in response to your feedback. The general consensus we received centered around a few key points:

It was hard to tell which tab had focus based upon colors in design 1.
Tab design 2 had a "Windows 2000" appearance, as opposed to a more WinXP-inspired design.
Tab design 2 made determining the active tab a no-brainer.

So, with this in mind we'd like to get some feedback on the following matchups.

First, we will present two new tab designs (Design 3 and Design 4). Please rate these two designs in the comments just like before. Second, please compare your favorite of the two new designs to Design 2 from the last blog entry and include this information in your comment as well.

Design 3:
Please rate Design #3 on a scale of 1-7 (strongly disagree to strongly agree):
1. It is very easy to see which tab is active.
2. The tabs are aesthetically pleasing.

Design 4:
Please rate Design #4 on a scale of 1-7 (strongly disagree to strongly agree):
1. It is very easy to see which tab is active.
2. The tabs are aesthetically pleasing.

Compare the Two Groups:
Finally, of the design above that you preferred (#3 or #4), do you like it more or less than Design #2 from the previous entry?

Please let us know what you think! We'd love to get just as much feedback on this as we did before :)

Feedback Requested: Visual Studio 2005 Tab Design

aaronbrethorst — Thu, 03 Mar 2005 21:45:00 GMT

//Update 2

I have posted a new set of designs for this at http://blogs.msdn.com/aaronbrethorst/archive/2005/03/16/397107.aspx. Please leave feedback on there. Thanks! :)

//End:Update 2

//Update

Corrina, the designer I have been working with on our new tabs posted this in the comments below. I wanted to make sure that everyone saw it:

Hi, I'm one of the designers on Visual Studio and I want to throw one more question into the mix...
Design #1 allows for slightly less tab text, so truncation may occur more often with this design (imagine 3 or more tabs docked together). Would that affect your tab preference?

//End:Update

Hi everyone – The Visual Studio Design team is currently going back and forth over a few different designs for the tool window tabs in Visual Studio 2005, and we wanted to elicit feedback from the community on what all of you prefer. With the tabs in Visual Studio 2005 Beta 1 it can be difficult to determine at a glance which ones are active and which are inactive, which is how we ended up with the designs that we’re prototyping.

The first design style that we’re considering is to move to overlapping tabs, so that the active tab is always visually on top of all other tabs in a group.

Please rate Design #1 on a scale of 1-7 (strongly disagree to strongly agree):
1. It is very easy to see which tab is active.
2. The tabs are aesthetically pleasing.

The second design style that we’re considering is more reminiscent of the tool window tabs in Visual Studio 2003. Inactive tabs will blend into their tool window tab channel, and only the active tab will have a tab-like appearance.

Please rate Design #2 on a scale of 1-7 (strongly disagree to strongly agree):
1. It is very easy to see which tab is active.
2. The tabs are aesthetically pleasing.

Visual Studio Setup Changes

aaronbrethorst — Sat, 07 Aug 2004 01:40:00 GMT

If you've played with Visual Studio 2005 Beta 1, you've probably noticed a fair number of changes to the user interface of our setup application. It's become quite a bit easier to use, but we still have some changes planned for it. I was asked by Brian Strully and Jason Lee of the Setup/Release team to elicit feedback from all of you guys on what direction you think we should take this part of Setup.

When you install Visual Studio, do you opt not to install certain languages, or do you usually confine yourself strictly to your deployment platform of Windows/Smart Devices/Web App? Do you tend to stick to the advanced installation options, or are you usually comfortable with the default settings?

Which of the three options pages shown below is the most helpful and intuitive to you? Also, please post any other comments and recommendations you may have.

Option 1:

Option 2:

Option 3:

Those Little '?' Buttons

aaronbrethorst — Thu, 22 Jul 2004 18:19:00 GMT

Thanks to everyone who has logged bugs in the MSDN Product Feedback Center on inconsistencies in the use of dialog help buttons (those little '?' buttons) in Visual Studio 2005 Beta 1! I really appreciate all the help everyone has provided so far; you guys rock!

I Need Your Help

aaronbrethorst — Sun, 18 Jul 2004 06:31:00 GMT

Let me be totally straightforward and honest: I need your help. For those of you who are just tuning in, I am the Program Manager responsible for User Experience and User Interface Consistency for Visual Studio.

Visual Studio 2005 is becoming consistent with Office 2003 in how we display our help buttons. We are moving them from within dialogs to their window's title bar (check out the Display control panel for an easy-to-find example of this).

According to our specs, the expected behavior should be that clicking on the '?' button in window title bars will launch F1 help immediately. Unfortunately, we still have a ton of bugs where clicking this button gives you a “What's This” cursor (this is a cursor with a little question mark attached to it).

Here's what I need you to do. If you see a dialog anywhere in Visual Studio 2005 Beta 1 (Express or otherwise) where a dialog still has an old-fashioned help button, or where the dialog's help button gives you a “What's This” cursor I need you to log a bug against it in the MSDN Product Feedback Center. Your assistance will be invaluable in making sure that Visual Studio 2005 is our best-looking, most-consistent developer tool suite ever.

I look at every single bug that comes in from the MSDN Product Feedback Center in order to correctly tag our user experience bugs, so I will definitely see every one of these that you log.

Thanks again to everyone who has logged user experience bugs against Visual Studio! You have my eternal gratitude!

Web Apps, Turbo C, and the like

aaronbrethorst — Wed, 28 Apr 2004 00:14:00 GMT

Let me tell a little story. Once upon a time (read: 2002-2003) while I was a senior in college I had to do an Advanced Project Laboratory, or, as the rest of the world refers to them, a senior design project. Somehow, I came upon the bright idea of porting a 12,000 LOC Turbo C application for DOS to a managed code environment and wrapping a C#/ASP.Net web application around that nastiness.

The 12,000 line C application had been doing quite well, thank you very much, on its own as a scary throwback to a time when men were men and Wordstar ruled all. Then three of my Computer Science buddies and I came along thinking we knew something about UI Design and HCI. Naturally, we needed to prove that we were just as tough as this application and its Entomology professorship-holding creator, Dr. Richard C. Axtell.

FMS, Dr. Axtell's creation, did some crazy stuff that didn't necessarily play nicely in the land of Visual Studio 2003 and C++/Managed Extensions. It threw out notions like arrays starting with index 0. It's a testament to the amount and quality of work done by the C++ team here in DevDiv that we could get this to work through the IJW feature-set. Nevertheless, I and my partners in crime stayed the course, and were able to develop a fairly cogent, interactive Web application around the batch-processing FMS application. Our web application received its appropriate grade, and then disappeared. You can actually still download it and its source code, but I won't provide a link at this moment.

Anyway, I made a promise to myself after finishing the project that I would never again work on a decent-sized web application; “Only rich client apps for me,” I boldly declared to any who would listen. Hah, like that worked out...

For the past few months I have been working on the Whidbey UI Design and Implementation Guidelines. This is a large corpus of information that grows larger with every passing day. Initially, this was a document composed entirely in Word. Unfortunately, Word wasn't the most suitable tool for exactly what we wanted to do. Realistically speaking, we needed a very lightweight content management system that could store this information, spit it back in a variety of formats, allow a potentially large and diverse team to work on content, and be extremely easy to add content to. So I built it in C# and ASP.Net even after I had said never again. To be perfectly honest, It's been a great experience. I had forgotten how easy it was to build web apps in Visual Studio. The application does most everything our designers need it to do today, and it's just continuing to get better.

We want to make sure that every team building functionality into Visual Studio uses a consistent user interface. We're not perfect yet, but we're getting better. Creating a consistent user experience across all of Visual Studio is a daunting process, but we're going to get there. I'll be posting more tips here over time, but I thought that everyone deserved to know what we're doing in Whidbey to make developing Windows applications a more enjoyable experience. Cheers :-).

UI Consistency: Title Bar Help Buttons

aaronbrethorst — Tue, 20 Apr 2004 05:40:00 GMT

Have you ever noticed how Office 2003, and a wide variety of modal dialogs throughout Windows XP and Windows 2003 Server use that little question mark button in the title bar to launch their F1 help system? It's rather neat, unobtrusive, and it allows you to get rid of a clunky-looking button on your forms that say “Help.”

Ok great, so you have seen it. Or maybe you're looking right now. No worries; I'll wait. Anyway, perhaps you're wondering now how to do this. It's a little more tricky to set up than you might think. The default behavior of the Help button in a window title bar is to launch a “what's this?” cursor. Hmm, not very useful. I honestly don't remember the last time I used the “what's this” help for anything, quite frankly.

The trick to solving this problem is to override the WndProc() method on your Form subclasses. When the title bar help button is clicked, it sends a message to your Form with a WParam value of SC_CONTEXTHELP. SC_CONTEXTHELP is defined in some native Windows header file or another, you're welcome to search for it on MSDN if you really want. By looking for, and then acting upon, this WParam value, you can launch your F1 help topics just like Office (I wonder if that's a trademarked term somewhere...).

Just one more tiny step towards consistent UI across Windows apps ;-).

/** Added WM_SYSCOMMAND check. **/

using System;
using System.Windows.Forms;

public class HelpForm : Form
{
    private const int SC_CONTEXTHELP = 0xF180;
    private const int WM_SYSCOMMAND = 0x0112;

    public HelpForm()
    {
        this.ClientSize = new System.Drawing.Size(300,250);
        this.HelpButton = true;
        this.MaximizeBox = false;
        this.MinimizeBox = false;
        this.Name = "HelpForm";
        this.Text = "Help Form";
    }

    protected override void WndProc(ref Message m)
    {
        if (m.Msg == WM_SYSCOMMAND && SC_CONTEXTHELP == (int)m.WParam)
            ShowHelp();
        else
            base.WndProc(ref m);
    }

    private void ShowHelp()
    {
        MessageBox.Show("F1 Help goes here.");
    }

    [STAThread]
    static void Main()
    {
        Application.EnableVisualStyles();
        Application.Run(new HelpForm());
    }
}

Accessibility is not a feature

aaronbrethorst — Sat, 03 Apr 2004 23:42:00 GMT

I moderated a talk yesterday on accessibility at Microsoft. I think it went over pretty well. In any case, one of the central points I made during the talk bears repeating in a more public forum.

Accessibility is not a feature.

“Whoa, wait, what?” I hear you saying. So, let me clarify this. Accessibility is part and parcel to an application's overall usability. It cannot and should never be thought of as a work item to do during the next coding milestone, or (and this is the worst) something to hopefully incorporate during the next product release. Whenever you're thinking about the usability of your application it is vital to take some time and ponder how your user model will work for users with cognitive, sensory, or physical impairments.

By designing software in such a way that it is usable for everyone, usability will be enhanced for all of your users. This may seem tautological or self-evident, but I don't think it really is. You may discover some interesting synergistic effects on overall usability by making your application accessible to users with an impairment

Warning: Contrived Example Below!

As a demonstration, let's go over a scenario: An application monitors the health of a network. It has a status indicator that is colored either green or red, depending on current conditions. The status indicator has no text associated with it. Most users will have no problem differentiating between a healthy system and dangerous conditions, but a color-blind user may, very well, be completely unable to to tell the difference between the two states. Additionally, a user who relies upon a screen-reader software package will also have no idea that there could be an adverse situation underway without additional cues. For starters, adding a label with a textual description of the current system state will help a lot. However, there's still more that can be done.

What happens if your sysadmin has turned off the monitor plugged into that computer, or if they're using a KVM switch, or... Well, you get the idea. In fact, the solution I gave above of just introducing a textual indicator will not solve all scenarios. Perhaps an audio cue could be introduced as well. Whenever the network status goes to red, a text label could state this, and the system could start beeping on one or two second intervals until the problem is solved.

Anyway, I think it's worth taking some time to think about the usability of your application for everyone. How would you use your app if you couldn't manipulate the mouse, or if you couldn't differentiate between two certain colors? Would it impact how you design it?

Tips on making a great-looking Windows XP app

aaronbrethorst — Fri, 19 Mar 2004 00:54:00 GMT

I've been thinking a lot lately about some best practices in making sure applications look and feel like 'real' Windows XP apps. This is one of those areas that is, in my opinion, undervalued at times, despite the fact that it really can make a huge difference in the overall perception of your work.

Include a manifest file with your application. This is a very straightforward process, which is well documented on MSDN.
Make sure your buttons, radio buttons, group boxes, and check boxes use the 'System' FlatStyle.
Use 24-bit or 32-bit images throughout your application. This can have a suprisingly big effect on how inviting an application appears. For example, take a look at the differences in artwork between Internet Explorer 5 and Internet Explorer 6.
Experiment with adding some task-based UI. Windows XP does this quite effectively, and I think it's something that's worth considering.
Follow standard font guidelines. ~~For managed applications, this should mean MS Sans Serif, 8.25pt, regular.~~ (thanks for catching my mistake, Pavel)
When in doubt, refer to the Windows User Experience Guidelines.

VSIP Partner Summit

aaronbrethorst — Tue, 24 Feb 2004 05:37:00 GMT

I just got to have dinner with a ton of our VSIP Partners in Bellevue this evening. To everyone I talked to tonight: thanks a lot for telling me about what you've been up to, and for offering your thoughts on what we can do better (and for those of you who have yet to, please do. I'd love to hear what we can improve). I got some great feedback on UI Consistency across Whidbey (one of the primary areas I work on), frustrating accessibility bugs, and usability as it relates to performance. Thanks again, everyone! It was a pleasure to meet all of you :-).

iTunes 4.2

aaronbrethorst — Mon, 09 Feb 2004 03:23:00 GMT

Wow, Apple just completely redeemed themselves in my eyes with iTunes 4.2 on Windows. I've been trying to avoid reinstalling iTunes for a while now just because it makes me into a borderline psychotic to see a company that prides itself on design (Apple) violate another set of UX guidelines (Microsoft's) so completely. I finally broke down and reinstalled it tonight because my iPod is sitting at home recharging through my iBook (I feel like I have a right to rip on Apple occasionally, given that I do own several of their products).

So, back when Apple first released “the best looking Windows app ever” the damned thing refused to maximize. Instead of maximizing, it would kind-of sort-of maximize, which drove me (and tons of others) nuts. In any case, they finally fixed that problem. iTunes finally maximizes correctly!!!

Design from the other side of the pond

aaronbrethorst — Fri, 06 Feb 2004 22:37:00 GMT

I got to hear a former Sony designer (also a veteran of Apple's HIG) talk at MS Research today. He had a lot of interesting things to say, and he had a few interesting anecdotes about verbal jousting with Ken Kutaragi, the guy who came up with PlayStation (and I'm sure most of you are familiar with that :-) ). In any case, my favorite line from the presentation was: “technology is nothing without man: technology is a mirror of man.” You can find out more about Eduardo Sciammarella if you feel so inclined. Hmm, he seems to own a hiptop, and there's a moblog of his out there somewhere too.

Import/Export Settings in Whidbey PDC Build

aaronbrethorst — Mon, 19 Jan 2004 05:55:00 GMT

I just ran across a blog entry from David Hunter, who has been playing around with the PDC build of Whidbey. David was trying to create a web service after reading about Indigo, but discovered that his New Project menu item had completely disappeared! It was only after a lot of hunting and poking around that he discovered our cool new Import/Export Settings feature, which tailors Whidbey for different sets of users. When he had first installed Whidbey, he had selected the Web Developer settings file without giving the other options a second thought. Resetting the IDE solved his problem, but as he put it: “this amount of specialization caught me by surprise.”

Hmm, food for thought for the group I work on. Has anyone else run into this problem?