TimSull's Blog

re: Steven's VsSettings comments

2004-04-07T21:49:00Z

Thanks to Steven for his great comments about VS Settings.

The upcoming Import/Export feature actually does allow you to import from a vssettings file that lives out on the web. So you should be able to post your favorite vssettings file on a website and then load it onto any machine with VS Whidbey.

One thing we haven't enabled is setting a file on the web as your auto-sync file. This would definitely be a cool feature, especially if it was fully integrated through the use of a Microsoft-supplied web service. And, as you point out, there would be tremendous opportunity for datamining to determine what our default settings should be in the future. Unfortunately I don't think we'll be able to provide this functionality in Whidbey, though. I know there would be lots of security/privacy concerns, even if it was an opt-in feature. And building a feature that involves interaction with a web service is probably too expensive to do at this point in the product cycle. It's actually not terribly complicated from a development perspective, but there is a significant test cost associated with it as well. I'm going to think about this a little bit though; I'd like to ensure that some interface hooks exist that would let a 3rd party create a package and some web services to enable this scenario.

VS Settings (finally)

2004-04-01T22:48:00Z

Ah, VS Settings. I've been meaning to post on this topic for ... oh ... about 4 months now. I guess it's about time.

If you've ever used Visual Studio and you've ever ventured onto the Tools.Options dialog, you've discovered the dizzying array of customizable settings offered by the IDE. You've also undoubtably discovered (possibly by accident) that the positions of the IDE's tool windows are fully customizable. And you may have discovered that, like Office, the menus and toolbars of VS are fully customizable. In fact, VS is so customizable that you can easily spend many hours customizing the IDE to make it look and behave the optimal way for your individual work style. For multiple versions now, customers have requested some way of capturing all this work they've done in setting up the IDE, so they can quickly and easily recreate their personal settings at a later time or on another machine. I'm happy to say that we'll be providing a feature in VS Whidbey to enable this scenario.

The Import/Export Settings dialog/wizard will be available from the Tools menu in VS. It allows you to choose categories of settings to export to a .vssettings file, and it allows you to point to an existing .vsettings file and choose categories of settings to import from that file. So what is a settings 'category'? In general, a category of settings is a logical grouping of settings for a toolwindow, a tools.options page, or an IDE feature. Examples of categories are:

Each individual Tools.Options page (e.g. Environment.General, Text Editor.C#.Tabs, etc.)
Window Layouts (tool window positions in design, debug, and fullscreen modes)
Commands and Menus customizations
Toolbox customizations
External Tools, etc.

Courtesy of our PM, James, I've posted some preliminary screenshots of the UI from the Import/Export Settings feature spec so you can provide feedback on the design. Follow these links to find pictures of the welcome screen to the wizard, export screen one, two, and three, and import screen one, two, and three. The Import/Export wizard is intended to smoothly guide you through the process of choosing which settings to export/import and where to save them to/load them from. The last screen of the wizard is actually incomplete in these images. We'll be providing a log of some sort describing any errors that have occured during the export/import process, such as settings categories that failed to export, or invalid settings in the file that could not be applied during import.

Note: If you receive a copy of the VS Beta or play with one of the Visual Studio Technology Previews, you'll actually find a different UI when you access the Tools.Import/Export Settings command. Those releases contain a preliminary UI that we've been using internally during the development of the Import/Export feature. It's functionally equivalent to the wizard UI in the images above, but our usability tests and UI walkthroughs have determined unanimously that it's too nonstandard, too difficult to use, and involves a rather annoying number of popup messages and other dialogs. If you've used this preliminary version, I certainly wouldn't mind to hear your comments about it, but I won't bother posting screenshots here since it's going away soon.

In addition to the manual import/export UI, we'll also be supplying a sub-feature that's designed to make it easier for a single developer to work on multiple machines at once. Found on the Environment.Import/Export Settings options page, under the heading 'Automatically load and save settings', this feature enables you to specify a vssettings file that will be kept up to date with your current settings (on each close of VS). On VS startup, if this file is newer than last remembered, we will import all the settings from this file. That enables a scenario where you have two machines, each with VS installed, where you want VS to look and behave the same on both machines. If you point both machines at the same auto-save file and you change a setting on one machine, it will automatically show up on the other machine.

Another sub-feature, called 'Team settings' is designed to make it easier for a team of developers to maintain similar settings in certain categories. With this feature you can point the IDE at a particular vssettings file (typically on a intranet share), and the IDE will check that file on each startup to see if it is newer than remembered; if so, the IDE will import all settings from that file. To see how this would be useful, consider an example where you have a team of people who should all be using the same indenting/formatting options for C++ files. The manager of that team can open VS, change the formatting options to the team's defaults, export just the C++ formatting settings category to a vssettings file on a network share, then ask everyone on the team to point VS at that team settings file. The whole team will then automatically stay in sync wrt C++ file formatting. If the team should ever decide to change the defaults, or perhaps additionally set defaults for C#, the can simply export new settings to that same file, and everyone on the team will automatically have the new settings next time they start the IDE.

Another feature that customers have been requesting for quite some time is the ability to easily reset the IDE to it's default settings. Having such a customizable IDE is great at times, but it also has the downside of providing the opportunity for people to shoot themselves in the foot. Customers commonly do this by accidently removing important features from their Menus, or accidently customizing their tool windows into an unusable layout. In VS 2002 and 2003, there were individual places you could go to reset portions of the IDE, (e.g. the Window.ResetWindowLayout command, or the 'Reset Toolbar' button on the Tools.Customize dialog) but these reset features were very difficult to find, and only encompassed a small subset of the IDE settings.

Earlier on, you may have noticed the 'Reset all Settings' option on the wizard's welcome screen image. The idea behind this Reset option is to allow you to go back to the environment defaults for all your settings. If you know that you only want to reset certain settings categories, then you can do that via the normal Import option on this same dialog. Conversely, if your settings have gotten into such a bad state that they're preventing you from using the IDE at all, or preventing you from accessing the Import/Export Settings feature, you can use the new 'devenv /resetsettings' command line switch to restart the IDE with default settings applied.

You may have noticed in the Reset image that you have the option to reset to several different 'default' settings; you can choose between VB, VC, C#, Web, and J#. Let me go into more detail about what those are, along with some history as to why we have them.

In VS 2002, we finally got the VB, C++ and Web development products into a single IDE. This was good in that you could use all of these products while really only having to learn to use a single product. It was also bad in that each product had to compromise in some areas in order to fit nicely with the other products. For instance, VB developers don't typically want to use the Disassembly window when debugging and C++ developers don't typically like to have the Toolbox window taking up their precious coding real estate. But in VS 2002 and 2003, both types of developers had to put up with these annoying (to them) default settings because they were important to other VS customers.

We plan to address this problem in VS Whidbey by defining default settings for each major developer type, generally aligned around the developer's language of choice. These default settings will focus on enabling the particular workstyle we've found each developer type to exhibit. When each customer starts VS for the first time, they will be asked to classify themselves according to their 'primary development activity', and the IDE will startup pre-configured for that activity. Obviously most people will want to go through and make further customizations according to their own personal tastes, but our hope is that this will provide a starting point that is closer to what each VS developer expects from their IDE. Also, the Reset option on the Import/Export Settings wizard allows people to easily switch between different defaults to experiment and see which ones most closely match their individual workstyle.

If you have feedback about about how you customize your IDE settings for your particular development activity, I'd love to hear it and I'll pass it on to the people responsible for defining these defaults.

I'd also like to hear feedback around the general design above as well as around which settings you like to customize in VS 2002 and 2003, and how you think you'd make use of this feature in VS Whidbey.

Also, if you'd like me to drill in more on anything about this feature let me know. E.g. I can talk about some of our design decisions, or about how 3rd party packages can plug into the VS Settings infrastructure.

Moving to ASP.Net

2003-12-24T06:07:00Z

Thanks for all the great comments on my intro Help post. I'll soon be posting about the new VS Settings feature in VS Whidbey. But that post will be at my new blog on ASP.Net.

New to asp.net

2003-12-24T03:02:00Z

I've just moved to ASP.Net. My previous blog was on gotdotnet. More entries to follow... -Tim

The lowdown on Help in VS Whidbey

2003-11-11T12:26:00Z

Hello world, my name is Tim--though I also respond to TimSull, Timmy, and Timmaaayyy--I'm a developer on the Visual Studio IDE team...welcome to my blog. I work on a number of different features of VS including Help Integration, Community Integration, Commands and Menus, Side-by-Side Versioning, and Import/Export Settings. My plan for this blog is mostly to talk about some of the cool stuff we're doing for the Whidbey release and to provide a forum for developers out there to give us feedback about our plans. I'll try to go through my features one by one and tell what I can about our plans. If people respond and want to know more about a particular area, I'll go into the gory details. I must say, given that I'm still new to the whole blogging fad, I'm a bit skeptical that anybody is actually going to read my blog. But what the heck, I'll just throw this one out there and see what happens.

IDE Help and Community Integration for Whidbey:

Help and Community are getting a lot of attention in Whidbey. We've received an enormous amount of feedback from customers expressing their disdain for the Help that shipped in VS 2002 and 2003. Developers consistently complain that the help interface makes it too hard to find the help content they're looking for. And they complain that when they finally do find 'the right topic' it's often lacking in some fundamental way. We're trying to address these problems in a few different ways.

Improved content:

This isn't actually something that my team works on, but it's obviously really important, so I want to mention it. The editors that are responsible for writing the docs have heard your feedback and are working hard to improve the quality of the help content. For instance, C++ developers have made it clear that they don't like seeing API reference that says only 'The FooBarEx() api takes parameters int x and void *y and returns 0 if successful', with no further discussion. If documentation barely says anything more than the SDK header file, it's obviously ...umm... lacking. VB developers have told us they don't want docs that seem to be written for or by C++ developers . For the VB developers , higher level content and task based help are clearly the way to go. And virtually every developer we've ever talked to, regardless of their language of choice, has requested more and better quality code samples in topics. All the people that are working on the help content are aware of this feedback and are working to address it in the Whidbey release. Unfortunately, due to the sheer number of help topics in MSDN and a few scheduling and organizational issues, I can pretty much guarantee that a number of help topics will still be sub-par when we ship Whidbey. But hopefully the most important topics will have been rev'd and will be much improved. If you've got a rant about the help content, or if you have particular topics you'd like to see fixed in Whidbey, let me know and I'll make sure the documentation teams hear your feedback. Also, make sure to use the 'send feedback' links whenever you find an MSDN topic that's not to your liking; those bits of feedback are all read by actual people and they result in bug entries that someone will be responsible for fixing.

Improved access to content:

In VS 2002 & 2003 you have 5 ways of getting help:

F1 -- Completely hit or miss, sometimes it works remarkably well, sometimes it shows the Dynamic Help window which is always trying to give you help on the 'Code and Text Editor', which is never what you're looking for.
Table of Contents -- I don't know anyone who has successfully found a specific topic they were looking for by navigating down the TOC tree. The TOC is most useful for finding topics that are similar or related to the current topic, using the 'Sync Contents' button on the Web toolbar.
Index -- If you already know the API or class name you're looking for then the Index works well, otherwise you're out of luck since this window is virtually useless for finding conceptual topics.
Search -- 500 results in nearly random order, choose the topic you want based on its Title and Location--unfortunately the titles are really tough to differentiate since there are lots of duplicates and similarly named topics.
Forgo the integrated help experience and search using the web -- Has mixed results depending on your search engine of choice, forces you to leave the IDE, which implies a mental context-switch and usually a loss in productivity.

In Whidbey we're making improvements to F1 and Search and we're adding some completely new interfaces to access help content.

F1 -- Better metadata on help topics will make F1 work more consistently even if you're not in the context of a project, or if you're writing code in native C++ where we usually don't have fully namespaced keywords to lookup. Better disambiguation UI will show topics that are more targeted to your selection; you won't see the same topics all the time. You'll also have the option of going online for F1. This will have 2 beneficial effects: First, you'll get the very newest help topics. And second, if you're not satisfied with your F1 results, you'll be able to let MS know so we can try to fix whatever bug is causing F1 to be broken.
Search -- Filtering will be more easily adjustable than it was in VS2002 and 2003, and will do a better job of filtering away many of the topics you'll never have an interest in. (Topics on DirectX, the Speech SDK, Commerce Server 2002, etc. might be great, but not when they show up at the top of the search results list when you're trying to learn about a TreeView control for C#.) Also, the search results will show a dynamically generated abstract based on the text of the topic to go along with the Title and Location. We hope this will make it much easier to tell if a topic will be worthwhile before you click on it and wait for the fancy script and graphics to render in the web browser window.
How do I... -- This is an entirely new view into the help system. It's a hierarchical organization of common tasks a developer is likely to encounter. Each developer segment (VB, C#, Web, etc.) will have its own hierarchy containing roughly 200-400 tasks. Each task will contain carefully reviewed editorial text along with sample code that can be copied and pasted into the VS editor. The documentation teams have been collecting user feedback to help determine which tasks to include in the hierarchies. If you have ideas for tasks you'd like to see in a How do I... page, let me know and I'll pass them along to the right people. You can think of How Do I... as a hand-picked, carefully designed subset of the Table of Contents. Check out these screen shots from live builds: How Do I... hierarchy page, WinForms Controls category page.
Help Favorites -- previous versions of VS and MSDN contained an integrated favorites tool window, but it was just the IE favorites window, not help-specific favorites. Our initial surveys and focus groups have indicated that developers think help-specific favorites will be really useful. People have also shown a lot of interest in the ability to save favorite search queries so they can easily go back to interesting sets of search results.

Inclusion of online content:

There are numerous things that online help can provide above and beyond what you already get with local help:

Smaller install size: MSDN is on the order of 2 GB when installed locally, online help has the ability to forgo that use of hard disk space.
Newest content: if content gets updated, the only way to get that with local help is to acquire and install one of the MSDN Quarterly updates (very heavyweight process). With online help, you get the newest content automatically.
Ability to provide feedback to MS: Online help makes it easy to tell MS that a particular help topic is insufficient.

Inclusion of Community content:

Going online to access MSDN content has its benefits, but the biggest win in searching online is really the ability to access living content. If you look at some of the fantastic work that Community-based web sites like .Net247, CodeProject, ASP.Net, and others have done, it's clear that static content published to the web can never be as rich as content that is provided by members of the developer community. Don't get me wrong, MSDN's API reference is obviously important. But if you open that content up to be annotated and extended by people in the community, then it becomes a much more powerful resource. It's really a complementary relationship: MSDN content provides breadth of coverage while the Community fills in depth in the areas that are most important to developers in the real world. Community content also helps address the need for more code snippets. If I need help using a DataGrid control, I definitely prefer to look for code snippets at .Net 247's DataGrid page than at MSDN's static DataGrid class topic. MSDN's code snippet looks very comprehensive, but .Net 247's page provides so much more variety, and it's directly linked to a forum where I can ask questions about the code and interact with the code authors or other forum members. The experience at the Community-based site is much richer because the content is far more dynamic and because I can interact instead of just reading.

So how does this apply to VS? In Whidbey we have partnered with a number of Community sites that will allow MS to aggregate and search their content from the VS client. This means that when you search for DataGrid from Visual Studio Whidbey, you'll see a list of local help MSDN topics, a list of MSDN online topics, and a list of links to pages on CodeWise web sites. So developers will have simple, direct access to the newest and most popular code samples and technical articles in the community. You'll see living content alongside the comprehensive static content from MSDN.

In our focus groups, we've found that many of the more savvy developers out there currently do a 2-stage search for help content. First they search in local help or MSDN Online, and then they search Google. The goal of integrating community content into the VS client is two-fold: First, we want to help our not-so-savvy customers get access to all the great community content out there. Second, we want to make finding help content a seamless experience where you only have to learn and use one UI, and you never have to leave the IDE. The main outstanding question is: Will the quality of integrated VS search results be comparable or better than the search results from today's 2-stage search. Because of our highly customized filtering and scoping, we think that they will, and when you combine that with having a single search entry point and a unified search results interface, our solution should be a big productivity win.

But what does it all mean (to you)?

When I look at the full list of changes we're making to improve Help in Whidbey I think they'll add up to a big productivity win for our customers. But I'd love to hear what the developers out there think of our plans. Are you psyched about what we're bringing to the table in Whidbey? Do you wish we were focusing our efforts in different places? Let us know what you think!