Roslyn: Developer mode design document

Created on 7 Aug 2018  ·  18Comments  ·  Source: dotnet/roslyn

🚧 This is a work-in-progress design document for the "developer mode" feature.

Summary

The "developer mode" feature involves the addition of three distinct modes to the IDE (names subject to change):

  1. Focus mode: Intended for writing new code
  2. Developer mode: Intended for day-to-day development
  3. Review mode: Intended for reviewing code as part of team development

| | Focus | Developer | Review |
| --- | --- | --- | --- |
| Compiler errors | ✔️ | ✔️ | ✔️ |
| Compiler warnings | | ✔️ | ✔️ |
| Follow "treat warnings as errors" | | | ✔️ |
| Run analyzers | Forced Hidden ("refactoring only") | ✔️ | ✔️ |
| Scroll bar indicators | Errors only | Warnings and Errors only | ✔️ |

Changing modes

I do not have a specific proposal for changing modes. However, it's important to keep in mind that some users will prefer to always work in one specific mode.

Area-IDE Design Notes

Most helpful comment

Note: this feels worthwhile to have a dedicated status bar button to trivially enable focus mode and/or these sub options. Specifically i do not feel like this shoudl go into tools|options, but should rather be a flyout on the status bar you can click to really quickly enable/disable any of these options with just two-clicks (one to open the flyout, one to enable/disable the feature).

Having to jump to/from these different contexts if the very poster child of focus-disrupting :)

All 18 comments

The platform team recently created a prototype to display a streamlined UI that maximizes the files that the user is working in and minimizes distractions. The feature will be available as a command in the View Menu near Full Screen or via the Shift + Alt + f keyboard shortcut.

The default values for Focus Mode’s options are:

• Error, Warning, Suggestion underlines suppressed
• QuickInfo suppressed
• Quick Actions margin suppressed
• Completion List suppressed
• Focused debugging will be disabled
• All of the panels besides the editor will be hidden

image

Customization:

image

image

I don't like the terminology "and boost productivity". That feels very biased towards a certain type of development mentality. It also is effectively flat out stating that our featureset negatively hampers productivity. I would just phrase this in terms of allowing users to pick the set of features they prefer to have as part of their default workflow.

  1. I'm ok with most of hte things that will be hidden. However, i do want clarification on if every single one of those things will have a way to enable if that's what works best for a particular user.

  2. image

This seems odd. I feel like if users take an explicit action (like hovering over something), then showing them information is appropriate.

  1. Having the error list and squiggles not be shown seems like a very strong direction to go in. Do we have indications that customers want things suppressed to that extent?

  2. Should code-lens be here as somethign easy to disable?

  3. What is 'focused debugging'?

I don't like the terminology "and boost productivity". That feels very biased towards a certain type of development mentality. It also is effectively flat out stating that our featureset negatively hampers productivity. I would just phrase this in terms of allowing users to pick the set of features they prefer to have as part of their default workflow.

I agree and can create a ticket for platform team to change.

  1. I'm ok with most of hte things that will be hidden. However, i do want clarification on if every single one of those things will have a way to enable if that's what works best for a particular user.

Currently there isnt a way to configure some of these while other editors such as VS Code allows you to and think the platform team should offer that option to as well.

Configurable options:

  • activity bar
  • status bars
  • tabs
  • notifications
  • toolbars
  • tool window bars
  • navigation bar
  • main menu
  1. image

This seems odd. I feel like if users take an explicit action (like hovering over something), then showing them information is appropriate.

There is an option to enable this if you select QuickInfo tooltips then tooltips will be shown during focus mode.

  1. Having the error list _and_ squiggles not be shown seems like a very strong direction to go in. Do we have indications that customers want things suppressed to that extent?

We can change that and use Sam's proposal to show compiler errors at the very least. The indicator drop down lets you customize the diagnostics being shown. There is data from the platform team on the customization story to determine the default state of their feature. I have received feedback on Quick Info Tool Tips, Signature Help, Lightbulbs, and Screwdriver being distractions but not for compiler errors.

  1. Should code-lens be here as somethign easy to disable?

That would be a good option even though they have their own settings option.

  1. What is 'focused debugging'?

Not sure what focused debugging is either.

There is an option to enable this if you select QuickInfo tooltips then tooltips will be shown during focus mode.

I guess my point is: this is already a feature you do not see by default. so why does it need to be 'disabled'. I think the only things that should be disable-able would be things that present UI to the users as part of the default editing experience.

Configurable options:

That sounds good. The UI doesn't seem to reflect that, but i'm glad to have the clarification.

Note: this feels worthwhile to have a dedicated status bar button to trivially enable focus mode and/or these sub options. Specifically i do not feel like this shoudl go into tools|options, but should rather be a flyout on the status bar you can click to really quickly enable/disable any of these options with just two-clicks (one to open the flyout, one to enable/disable the feature).

Having to jump to/from these different contexts if the very poster child of focus-disrupting :)

Currently there isnt a way to configure some of these

IMO, that's just broken. Focus-mode shoudl not be someone else telling me: here's how you focus. It should be me telling teh product "here is what i find relevant enough to my effectiveness to be visible by default".

We can change that and use Sam's proposal to show compiler errors at the very least.

I think that's sensible. It can always be someone can turn the knob one dial further on if they don't even want squiggles.

Note: this feels worthwhile to have a dedicated status bar button to trivially enable focus mode and/or these sub options. Specifically i do _not_ feel like this shoudl go into tools|options, but should rather be a flyout on the status bar you can click to _really_ quickly enable/disable any of these options with just two-clicks (one to open the flyout, one to enable/disable the feature).

Having to jump to/from these different contexts if the very poster child of focus-disrupting :)

There is a keyboard shortcut to enable/disable focus mode and you can enable it by searching for focus mode in Ctrl+Q search and select focus mode. If we create a status bar option it can have a flyout to enable/disable and to configure.

image

Currently there isnt a way to configure some of these

IMO, that's just broken. Focus-mode shoudl not be someone else telling me: here's how you focus. It should be me telling teh product "here is what i find relevant enough to my effectiveness to be visible by default".

I agree!

@CyrusNajmabadi Below are updates to the configuration page and the default behavior should show compiler errors:

image

Also, shouldnt the behavior be the opposite? so whatever I check off I would expect it to be hidden and not vice versa?

The feature will be available as a command in the View Menu near Full Screen or via the Shift + Alt + f keyboard shortcut.

One thing to clarify is that the current prototype exists just as an extension. Before settling on anything that's already built I'd like to see us iterate a bit more on the Developer Mode(s) concept.

I think 'Developer Mode(s)' proposal above offers quite a bit more value and nuance on top of the existing Focus Mode prototype. Instead of tailoring to just minimizing distractions, you have fit-to-purpose modes that emphasize certain important features while de-emphasizing others.

At least from my perspective as a VS user, they seem particularly compelling if done right.

Some things that could use more research:

  • Minimal set of initial modes/profiles.
  • Default settings for each mode/profile.
  • Customization story (Tools > Options is well known to be hard to discover).
  • More convenient entry/exit points.
  • A way to temporarily re-enable features while in focus mode. e.g.: I can hold down Ctrl+Shift and see all of my indicators re-appear.

If we create a status bar option it can have a flyout to enable/disable and to configure.

👍

I think whatever we have in tools|options should just show up in the flyout. :)

Also, shouldnt the behavior be the opposite? so whatever I check off I would expect it to be hidden and not vice versa?

Sure :) we should probably wordsmith things then so it would be like:

  • [ ] Hide quickinfo tooltips
  • [ ] Hide codelens

That way you know if it's checked that the thing is hidden.

I'd like to see us iterate a bit more on the Developer Mode(s) concept.

What are "developer modes"?

What are "developer modes"?

It's in the description of the issue :)

Focus | Developer | Review

The idea is there's a bigger set of problems to solve here than just Focus Mode.

Was this page helpful?
0 / 5 - 0 ratings