 Finding code is so fun that we split up this episode of Visual Studio Toolbox into two parts. So join us for part one when we talk about the find and files feature. Hey, everybody. Welcome to Visual Studio Toolbox. I'm your host, Leslie Richardson, and today I'm here with two of my colleagues. This is Dante Gagne and Andrew Chung, who are going to talk about finding code in Visual Studio. Welcome, y'all. Hey, thanks, Leslie. Yeah, thanks. So we all love to search for things, not just in the IDE, of course, but just everywhere, save you a lot of time, and you don't have to scroll through until you find what you're looking for, and searching for things within code that you're writing is no exception, right? Yeah. When it comes to code search, finding the code that you're looking for, it's one of the most basic operations we're going to do when it comes to developing. And find and files is one of those features that our telemetry shows is very frequently used. We've got literally tens to hundreds of thousand developers using it every day, and it's an area that hasn't gotten a lot of love lately. But until recently, we've finally managed to get in there and make some real improvements to it, and I appreciate you giving me a chance to come on and talk a little bit about what we've been doing. Absolutely. The people need to know what they're missing out on. So with that, do you want to show us what's new with finding files? Sure. So just a little bit of background. Like I said, finding files, it's been around for over 15 years now. It's in Visual Studio, it's Control Shift F for those folks who don't already know that keyboard shortcut. It's one of the ones I use a lot, and it allows you to specify a code string or specify any arbitrary string, and it will look over all the files in a single file, in a directory, in a project, in a solution, whatever scope you want to do. The original implementation was native code done 15 years ago, and it was powerful then. It's still powerful, but over time, the architecture of Visual Studio has changed. It's kind of gotten left behind, and it frequently shows up as a contributor to a lot of performance issues, a lot of memory issues, and the more you use it, unfortunately it can cause Visual Studio to just keep slowing down. And it's an area that we finally decided we need to get in and rewrite it. We need to redesign this one. We've been patching it, we've been trying to improve on it, but there's only so far we can go. We were hitting the wall of diminishing returns, so we decided, okay, let's rewrite it. Part of that gave us the opportunity to take a step back, look at the old UI, and say, you know, it looks kind of dated. It doesn't fit with the rest of the user experience that Visual Studio has moved forward with, so we took it as an opportunity to, we could have made the UI look identical to what it did before, but we wanted to bring that forward and incorporate some of the improvements that our customers have been telling us, our developers have been saying, hey, you could make it better if you did that. So I believe it was Update 3 for Visual Studio 2019 where we, in the preview channel, we released the first new version of find and files. We released it in the preview channel, we took all of 16.3, and I want to say a good chunk of 16.4, getting that feedback from folks to figure out how could we make this better? And with 16.5, it was enabled for everybody, and we're seeing great adoption. We're seeing a lot of folks are using it, and it's faster. Even among small searches, we're seeing shaving 20 to 30% of the search time off. On big searches, like large 1000 plus file repos with regular expressions, it's dropping 90% of the search time is getting cut off by. It's a lot faster, it doesn't take as much memory and things like that, and now we can start making some of the improvements we want to make. Just a preview of one of the things we constantly get requests for, let me exclude directories or let me exclude file types. We couldn't do that with the old implementation. We tried a couple of times, but every time we put something in, we cause regression in some other unrelated piece of code just because of how everything was connected in the ways that they shouldn't be. So we had the opportunity to start doing some improvements on the overall experience, and that's what I'm really glad to show you today. So Dante, it's really cool to see that you've taken all of your customer feedback to heart and have essentially overhauled the find and file features we know it. So can we see a demo? Great, yeah, I'd love to show you where it is. So what I've got running here is Visual Studio. This is our internal preview channel, but everything I'm gonna show you at least is in the release channel. So if you've got the latest update of Visual Studio or realistically anything after about update five, you should have everything I'm gonna show. So I'm gonna hit Control Shift F. It's also available in the edit menu or you can use Control Q search for it. And this is the new find and files experience. So folks who have used find and files are probably gonna see most of this to be pretty familiar. We did make a few changes. Like for one over here, we've broken external items and miscellaneous files out. Those used to only be available if you had a C++ project, but over time we discovered that there were other scenarios that we wanted to enable those. So we made those check boxes for everybody. External items are items that are maybe part of an SDK or a header file or something like that that's referenced in your solution but isn't necessarily part of it. And miscellaneous files are any file that you use file open to open that isn't part of your solution. You can explicitly say whether or not you want that searched. Like for instance, while I was working in here in my project, I opened the program.cs from another project so I could reference it. I can decide with that checkbox whether I want that included or not. So. Oh, that's so great. You know, it's one of those I didn't realize what that did until we started implementing it. And then it's like, wow, that's actually more useful than I thought it was. And that's gotten some confusion from our folks so I wanna make sure that people understood what it was since I find it useful anyway. So I've got find and files here and this is a project that Andrew and I have been kind of playing with. And I'm just gonna search for animal. I'm gonna do a find all and here is my results. The results table has actually been around, I believe since Visual Studio 2017. But what I've got here is the ability it just sorts it for me based on what path it's in all the way down to what file. It tells me how many at each scope. A lot of people have been playing with this for a while. But one of the things that not a lot of people know is I can right click these columns and change the grouping. So right now it's grouping by path and file. Well, if I don't really care about the path, I just wanna move it all the way down to the file. I can change that and now it's just each individual file. This is handy if you have kind of a streamlined project that doesn't have a lot of redundant file names in it. But if you want to do the file names, you can just change that grouping very easily. You also got the ability to add or remove different columns and the columns are actually language specific. So for instance, you'll have a different set of columns available in a C++ project than you do in a C-Sharp because the C++ team has determined that there's other columns that are more useful for C++ developers that C-Sharp developers don't find quite as useful. So there's a little bit more that you can do there to specify, just get a little bit more refinement out of your searches. That is so nifty. Like I use finding files a lot personally and I had no idea you could even just group them by like either a path or just by an individual file and stuff that would save me a lot of time. You're not the only one. We hear a lot of developers find those and that we are looking for ways to make some of these experiences a little bit more discoverable. That's definitely one of the things that we need to find. Another example of discoverability is keep results. The feature that allows you, I can turn that on and if I do another search, like let's say I wanna look for the word card. When I do a find all now, you'll see at the bottom here's my old find with find animal and here's the new find with find card. So I can store up to five different searches now instead of only two. And if I realize, okay, animal is not the one I want anymore, I can turn its keep results off and the next search it will recycle that one for me. So I've got a lot more granular control over which finds I want and which ones I don't want. That is fantastic. That's kind of like, you know, when you're using a basic calculator and you wanna save the value and you have to use like the recall button on there. But yeah, it's so nice to have. Yeah, it was a change from, you had to remember beforehand where you wanted it to go and we moved it into the results. It's had some interesting feedback, but what I actually kind of like is that we're getting feedback going, keep results is so useful, can we make that the default? Assume I always wanna keep it and not otherwise. So that's like one example of the customer feedback that we're investigating and we wanna make improvements on. One of the other pieces of feedback that we got was not everybody's a big fan of the table view. Some people want the old view where it was just results one right after the other. Some people have got post-processing that they wanna use to be able to, after the search is done, be able to iterate on it and be able to extract information for other processes. Well, we didn't originally have the list view, but we directly took, we listened to our community on this one and said, you guys want that? People have a use for that, we need to bring that back. We went ahead and implemented the list view to try to get back exactly the same text that we had previously so that if you have existing scripts that do post-processing, this output should give you what you need. So we didn't wanna break those workflows, we did. And we discovered where we kind of got that one wrong and we've taken that feedback and been able to bring that particular functionality back. That is great. So you've mentioned before that you've been doing a lot of customer research regarding how to make this tool what it is today. Can you talk a little bit about like, what was that experience like and how did you get started on some of that research? Cause as PMs, as project, as program managers, we have to do this all the time whenever we're developing new features. Absolutely. And this is one that we got a lot of feedback both before and after. We get a lot of feedback after anytime we make a speech. This was one example of it. And I could point to developer community with very long threads. But the after has been kind of interesting for me because we've gotten a lot of people who've come back and said, oh my God, this is terrible. What did you do here? And when we started talking to the folks and started saying, help me understand what you don't like about it. There's some people who are like, oh, it's big. I don't like big. Okay, well, there's not a lot. Well, there are things we can do about that. But then we got to people who said, the new version, I can't run my post processing scripts on it or the new version, I can't just change a value or something like that. I have a hard time tweaking my find to do exactly what I want. We started getting down and we started finding out the functional things that we had inadvertently or thought we safely could change and discovered, you know, maybe we made the wrong calls on those. So the after has been really valuable for us. So that's why we released this into the preview channel. We had a couple of blog posts talking about what we did here. And we really, I really worked hard to try to engage with the community to find out where our changes are on the money and where they're not. And in some cases, we definitely started engaging with the community to figure out how can we make things better? Like, for instance, let me go over to find card here and I'm gonna click the repeat find button, which is what I was kind of talking about before. This one will go back to any search that I've done and repopulate all the parameters into the find and files dialogue. So even though I'm working with a bunch of different searches, I can use the repeat find and go back and tweak any particular search. Like, let me show you an example here in the card. This is actually looking in my editor config. And I see it's looking at discard variable suggestions. That's not what I want. So what I can do here is in the file types box, I can say not dot editor config. And if I search now, I'm gonna take it out of list view and I think I'd forgotten the per, yep, I had turned the keep results off on the animal so I decided to override that. But in this case now, it's only searching in the files other than editor config. Well, I've got a CSS script. I can remove that one. I can keep tweaking this, repeat find. And you know, in addition to editor config, let's take out my CSS files. So not star.css and find those ones. And I can keep refining that search down to what I want just by click repeat find, modify the way I want and be able to go in. That was a workflow that it worked in the old find in files, but there were some quirks. You had to have it docked. It had to always be up there taking up your space. The new repeat find makes it a lot easier. And then for keyboard users, what I find is I hit repeat find and just press enter. And that will repeat the find exactly as it was. So if I'm making changes to my code, it's easy to just hit control shift F, or I'm sorry, just hit repeat find, press enter, and I can update that search as I'm going along to always have the latest set of data. That is great. So I mean, it sounds like this kind of does everything me and so many other people have wanted it to do now. So like, what's the catch? Are there any limitations that we currently have? There are some limitations. And we're kind of doing some of the extra. So for instance, one of the limitations is in the Visual Studio Codespaces, the find acts a little bit quirky if you're working with entire folder, as opposed to entire solution or entire project. And we're looking into trying to get those things refined. One of the areas this look in, so right now it's saying look in the entire solution. I can click these three dots and I can find another folder. So let me just look here, say select folder. All right, great. What if I also wanted to go into the test folder? So let me go back a couple, add the test folder, select, and it adds it on. So I can keep hitting that to keep adding directory after director after directory, but this string up here, this is really not the best way to be presenting a handful of independent directories. If I wanted to remove one of these, I'd have to find the right place to click. I'd have to, this is an area that we want to do a better job on. And that better job, what that experience is gonna be, we're gonna be talking to customers who are using this and saying, hey, here's a prototype on a different way we could approach this. What do you think? And just engaging with folks, finding out ways that it would work better in their workflow. That's the kind of feedback loop that we're gonna use to make finding files better. And for those folks who have got to integrate in their workflow, we're just gonna be able to make it smoother, make it more useful for you every day. But yeah, we're not done. We've got more places that we can do a better job on this one. And it kind of leads into one of the other things, kind of leads into a different feature that I'd love to chat about. But this is only limiting me to files in my existing solution or my existing project or on my machine and things like that. What if you want to search a little bit wider than that? I don't want to talk too far about this one because I don't want to steal Andrew's thunder, but it leads into a good segue to talk about what happens when what you want to find is beyond the scope of the project that you're in. So I'll- You're keeping me in suspense. Yeah, so I am, but I'll let Andrew take up on that one in the next part. Awesome. Thank you so much for sharing finding files. This has been great. And I have one last question for you. So for those who don't know, Dante is like one of our resident accessibility experts on the team. So you're very familiar with what some of the best accessibility related practices are like. So can you tell us what the experience was like when you were redesigning this feature from an accessibility perspective? Like what were some of the challenges that you ran into? So this feature, a lot of the accessibility features. So Visual Studio took on a new project with roughly October of I want to say 2017. We started taking a step back and looking at the accessibility of Visual Studio all up and discovering that there were a lot of places that screen reader users were really having a hard time just because of simple things that we got wrong. Behind the scenes, every control that you, a sighted person like myself, I know what these fields do. I've got labels and things like that that connect everything but to a screen reader user, we have to expose all those properties so that the screen reader knows what to call it. Like if you notice this box up here at the top doesn't actually have a label but I can see and understand from a visual standpoint what that means. For the screen reader, we need to make sure that those had meaningful names and the European Union and the United States put out a series of documents that said what does it mean for software to be accessible, to be compatible with assistive technologies. So we just did a pass on this to make sure that screen readers and magnifiers and speech recognition systems would all be able to work with these. And at the same time, we started talking to our community. We started talking to the blind developers and the motion impaired developers and ask them how can we make this experience better? And it's been really gratifying for me to be able to reach out to a community that we didn't engage with as well as we could have or should have but now we're bringing more of them into the loop and getting a lot more feedback on making the experience better. And I'm proud to say that recently Visual Studio as far as our internal testing is concerned is much more compliant with the EN501, EN301 laws in the European Union as well as Section 508 in the US to be more compliant for folks who use assistive technologies with software. We've gotten a lot better but we've still got more room to go there and it works through the same feedback loop. We're talking to developers who are using Visual Studio every day and asking how can we make it better? For the sighted user, how can we rearrange things? How can we help the flow go better with the assistive technology users? How can we make sure that that flow that we're designing is going to work just as well if not better for folks who use a screen reader or any assistive technology? So it's been really interesting to be able to engage with that community, get that feedback, bring it back and that loop, it doesn't just extend to the editor. It's all throughout Visual Studio. We've got a lot more developers using screen readers on a frequent basis not just to see does it look right but does it sound right? Does it interact right? It takes a little bit longer to do some of these things but in reality it's better for everybody and I'm proud to be a part of it. Yeah, that's great. Even in the time that I've been on the team just seeing the greater importance that's being put on talking accessibility in the design phase not just when you start writing the new tool is really nice. Absolutely. So with that, how can people get in touch with you in order to get that critical feedback in order to make this tool and all of our other tools even better than they already are? So the easiest way is developer community. I monitor developer community on at least a weekly basis sometimes more frequently. Everything that goes up there that has anything to do with Find Editor or anything like that, I will see it. I'm also moderately active on Twitter probably not as much as I could be but I do have a Twitter presence. It's just Dante Gagnier up there and I'm always paying attention there. Generally all the channels that we use for getting feedback from Visual Studio if it has to do with the editor it's gonna come across my plate. So developer community and the reporter problem inside Visual Studio or reporter suggestion in Visual Studio those are easily the best ways to get a hold of me. Awesome. So thank you so much once again, Dante for sharing all about the new and improved find and files. Definitely try that out everybody. And you've kept me in suspense regarding the ability to search and other places outside of our solutions. So we're actually gonna stop it here to keep the suspense going. So tune in next time for part two when we talk about how we can do that. Thank you. Thank you.