🚧 This is a work-in-progress design document for the "developer mode" feature.
The "developer mode" feature involves the addition of three distinct modes to the IDE (names subject to change):
| | 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 | ✔️ |
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.
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
Customization:
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'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.
This seems odd. I feel like if users take an explicit action (like hovering over something), then showing them information is appropriate.
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?
Should code-lens be here as somethign easy to disable?
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.
- 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:
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.
- 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.
- Should code-lens be here as somethign easy to disable?
That would be a good option even though they have their own settings option.
- 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.
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:
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:
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:
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.
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 :)