Redesigning the New Project Dialog

Pratik

Last week, we released Visual Studio 2019 version 16.1 Preview 2. If you have the latest update – awesome and thank you. If not, you can download it from the link above. Or, if you already have the Preview, just click the notification bell inside Visual Studio to update. This post discusses one of the most visible interface changes we’ve made in Visual Studio 2019 – the New Project Dialog.

Motivation

In Visual Studio 2019, one of our main objectives was to help you (both new and experienced developers) get to your code faster. You can read more about this journey in the blog post that discussed the new start window. One of the most common ways to start coding in Visual Studio is to create a new project.

The dialog hadn’t changed much since 2010, and the interaction model between folders and items has been in place since Visual Studio .NET back in 2002. We hadn’t put much time into the New Project Dialog because we believed it largely served its purpose. Until recently, we didn’t have the telemetry in place to be able to analyze how this dialog was used. Our initial hypothesis was that most of you interacted with the dialog rarely. And instead you spend much more time modifying projects you had previously created. After a bit of user research and analysis, we found that the latter holds true. But we were quite mistaken about the former. Many of you use the dialog to create new projects to try out new things or add on functionality to existing solutions a lot more often than we thought.

User research

We then dove deeper into the data, particularly looking at the usage patterns from new users of Visual Studio. We found that there was a surprisingly large drop-off in usage after launching Visual Studio to opening a project to start coding. That led us to the hypothesis that the New Project Dialog might be somehow inhibiting success with the tool. So, we expanded our user research and gathered that this dialog was presenting you with too many concepts, choices, and decisions. The process of getting started with your code wasn’t straightforward enough. The hierarchy of the nodes wasn’t consistent. When you installed several workloads you would see too many languages and technologies presented at the top level. Further down into the second and third level of nodes, the taxonomy became quite unmanageable with differences in naming conventions of categories.

When we asked participants in our usability studies to search for code scaffolding to get started with certain types of projects. We saw them click around through the top level nodes, and not click through the hierarchy. Sometimes they completely ignored the structure on the left and focused just on the default list of templates in front of them. What surprised us was that even for experienced developers, some of the options weren’t intuitive. Most couldn’t pinpoint the link to ‘Open Visual Studio Installer’ when the templates they were looking for weren’t available. They glazed over the search box without interacting with it. They seemed to completely ignore the recent templates list. And when they finally selected a template, they lacked confidence in their choice.

In addition, we learned that most of you think about your app type first but there are some who think about languages first when finding templates to start coding. It became clear that this mixed structure wasn’t intuitive for either use case. The barrier to the first actions within Visual Studio was too high. And this was a problem that small UI tweaks weren’t going to solve.

Design principles

During the design and development of Visual Studio 2019, we looked at usage across different areas of the project creation process and honed down on a core design goal –

“Get to code quickly with the minimum necessary scaffolding and help developers configure their application with the right settings”

Remove unnecessary choices

There were several options in the dialog box that we sought to remove as a way of simplifying the set of decisions you had to make. We first cleared out the rarely used toggles to sort templates and change icon size. The checkbox to create a git repository provided little value when creating a project. Our research told us that the right step for git init was either before project creation when you create the local folder or after project creation when you know you want to move ahead with the project. You can now do this in one click through the ‘Add to Source Control’ button in the bottom right of the status bar.

The last option to go was the ability to view and download online extension templates through the dialog. You can also do this through the Manage Extensions dialog in the Extensions menu. So, we eliminated the duplicate behavior to reduce cognitive load while looking for templates. After all that, our design looked something like this:

Search-first

But through design studies we found that this still wouldn’t lead to success. The node structure was still too convoluted to be understandable in early usage. We initially wanted to flatten the tree so that there was less digging and clicking to do. But we soon realized that with the overabundance of supported project types, it was an exercise in futility coming up with a single taxonomy that supported every single template. So, we decided to fundamentally shift the way users could discover templates. The search box had low usage in the old dialog box because its position made it a secondary function. But search is a prominent discoverability mechanism across the industry. So, we wanted to improve the way Visual Studio utilized search to help find what you need.

Our early studies saw participants gravitating towards the search box when we changed its position. But there was still a slight hesitation before typing something in – “what do I search for?”. This led to the realization that search cannot be a catch all, and there needs to be a little more guidance. We took the values we knew from the old dialog’s node structure and saw that they roughly fell into three categories – ‘languages’, ‘platforms’, and the more vague ‘project types’. So we introduced filters and tags as secondary mechanisms to support search. Browsing through the tags in the template list will help you discover the different capabilities of Visual Studio based on the tool-sets installed in your instance. Setting filters will allow you to narrow down the list to your preferred choices when starting with a new project.

One decision at a time

We also broke up the process into two separate screens. There is a single decision point on the first screen – select a template. And all the interface elements direct you to make that choice. The second screen is all about providing details about the project type you’ve selected. You can modify the values here or move through the project configuration screen without changing anything since all the recommended defaults are set for you. Some of the more complex project templates then open a third screen which has custom options specific to that project type.

Looking at the template list itself, we made a point to sort this list by our most recommended project templates for the workloads you have installed. So, the template that you should select if you aren’t exactly sure what to do would be the one placed higher in the list. We found that most of you don’t use more than 10 different types of templates, so we’ve made the recent templates list even more prominent than it was in Visual Studio 2017, so that you can get to your most common templates without having to search for them.

Looking forward

This is the first iteration of a new design paradigm we’re trying to adopt for Visual Studio. We’ve been measuring adoption and engagement since the launch of Visual Studio 2019 earlier this month and we’re happy to see a significant increase in success rate through the get to code journey. But at the same time, we acknowledge that the evolution of the experience isn’t over just yet. We’re continuing to listen to your feedback and learning from you to ensure success. We’re on the path to make improvements to search and filtering as they are now the key functionality to finding the right templates. In addition, we recently built in the ability to add tags to your own custom templates. If you’re a template author, find out more on how to update your templates in this blog post. We released this functionality as the result of your direct feedback, and we thank you for it. But we are looking to do better and could use more of your help. Please continue to share your feedback through the Visual Studio Developer Community.

119 comments

Comments are closed. Login to edit/delete your existing comments

  • Jon Davis

    I’m fine with a modal dialogue in response to a user action (File -> New Project, etc) but it is NOT OKAY to shove a modal dialogue in the user’s face at launch and after closing a solution. First time I saw this and the menus in the main window weren’t responsive I thought VS was glitched and used Task Manager to force VS to exit.
    As a sanity measure, I have created an extension called VSStart to open the Start Page (File.StartPage command) at VS launch and when a solution is closed. Couple it with Tools -> Options…-> Environment -> Startup -> “Empty environment”, and VS 2019 behaves more like VS 2017. Unfortunately I have not managed to get the developer news feed to run, if it’s even still baked in there.

  • Anthony Cool

    I actually like the new New Project dialog box.  Yeah, it may take a few clicks the very first time you go to use the template you are accustomed to using, but then it’s in the recently used pick list after.  So, that basically solves a lot of the complaints here.The one thing that DOES need to happen though is:- Upon app startup, you see a “Continue without code ->” option under the “Get Started” listing.  When I go to close my solution, and the Start screen appears again, the “Continue without code ->” option should still be present as something we can choose from.  It is missing at this point in the UX.
    – Also, if you are going to show the Start screen after close of solution, close out the main IDE application behind it when it is to appear.
    – Also, if you choose to leave the main IDE application open after close of solution, ensure the solution’s you just closed local git repo information isn’t visible or accessible after you’ve already closed the solution and the Start screen appears atop the main application.  VERY VERY tacky and incomplete looking and feeling.

  • Peyman M.

    I think speeding up startup with a new dialog was a good decision and Get started items are handy but Create new project should have been first item don’t you think? for me Search-first approach is very painful and I’m not comfortable with it at all. That prototype looks very good and mix these the new one with prototype might make it better.

  • Neal Culiner

    User Research? Really? I absolutely DESPISE the startup screen in both Windows and even more so VS for Mac. Count me in on wanting an option to revert please. 

  • Jerry Greening

    So far in my expierience with VS22019 I have to agree with several other here and say that the new Project Dialog is the absolute worst and most confusing thing about about VS2019. The old dialog was, for me at least, by far faster in picking a new project type. Now instead of wasting time on the filters or searching through the convoluted an unorganized mess of project type icon with vague descriptions that is contained below it, I find myself just using the recent template list to select what project type I want.

  • James Alexander

    All the people complaining about the new dialog are likely the same people that get upset when the menu changes at Applebee’s. Took a few days to get used to it but now I’m digging it. I especially love that it brings to focus the types of projects I’ve recently used. One request though, please add project searching to the ‘Open Recent’ dialog that shows when you start VS 2019. I thought for sure I saw an early build where this was there but it’ll hands down be my favorite thing if it makes it in.

    • Dean Jackson

      Looks like you didn’t actually read the other people’s reasoning for liking the older way better.  They gave actual reasons.

  • Emran Hussain

    The new dialog is a disgrace to the legend of Visual Studio. In a Tree structure, we could easily see what are my options under what platform. Now I need to ‘KNOW’ what project I need to create. Totally disappointing. As others have already expressed the frustration, I don’t have much to add. Please count me to the group who wants the old dialog back.

    • André Ziegler

      “In a Tree structure, we could easily see what are my options under what platform. Now I need to ‘KNOW’ what project I need to create.”
      +1000
      that’t the issue with the new dialog.

  • Soft Works

    I rarely comment on any blog posts. But that dialog is an incredible disaster and one of the worst changes I’ve ever seen since VS 6.0.
    This decision making the same mistake as MSDN docs did a few years ago, thinking that a navigational tree would no longer be needed and could be dropped – first completely, later replaced by some crippled “tree” showing only parent nodes but no siblings. A few years later, and now we’re back to having tree navigation again – because when reading structured documentation, it’s just naturally the right way to visualize the structure and the content’s position inside the structure.
    Similar applies to the “new project” dialog: With the hierarchical structure in previous VS versions, you always had a great overview about what’s even available. For example, when you wanted to create some kind of web application, you navigated to the right node in the hierarchy and you could see all options that are available (installed). When using search, you never know – you never can be sure that you have seen all possible options, because you might just haven’t entered the right search term.
    You are talking about the level of confidence that users would have about making the right choice. With the new dialog users will never be confident about their choices because there’s always a chance that there could have been a better choice that hasn’t been among the search results.
    I bet, this dialog has made a great appearance in internal presentations where the presenter tells about how they analyzed user behavior and enters selected search terms from which he knows exactly about the results that they are producing. But in practical use – when you don’t know what exact search term you would need to enter – it’s a totally different situation.
    With regards to some other comments, I don’t think that this is a matter of taste or of different kinds of users like some prefer this and some prefer that. This is just about different approaches: Sometimes a search is the more appropriated method for accessing certain content, but in other situations it is required to access that content by structural navigation.
    You may have improved search, but taking away the structural way of accessing new project templates was a very wrong decision.
    Please revert that. It doesn’t have to be the ‘old’ dialog, but it should include the navigational way of accessing project templates like it was possible over the last 2 decades.