(no title)
Tyriar | 2 months ago
On the roll out side, this is what we observed:
- It was enabled in Insiders for several months, generally only very positive reactions - It was surprising to me that we shipped this to 25% of our stable users and basically no one complained for 2 weeks before we rolled out to 100% - After hitting 100% of users we did see some backlash like this comment - Of course telemetry doesn't show the whole story, but we try to determine both whether the completion was modified and whether the command was successful after using it and both numbers stayed relatively stable since shipping in Insiders at what we consider pretty good numbers (both accept without editing and command success rate is ~80%).
Neywiny|2 months ago
I think you're doing a disservice to newcomers by creating a new method of autocompletion. And I say that as somebody who has mentored a lot of newcomers in high school, University, and now professionally. Very often, including just yesterday, I'll hear something like "I don't really know how to use [very standard thing], we had [esoteric helper] instead." Yesterday it was for makefiles. Their school just abstracted it away to make it easier for them, so they don't know how to make a simple makefile to compile a few source files together. Or literally any other build system, including cmake. So, Lord have mercy on my soul if I have a new hire tell me "I don't know how to use the regular terminals. All I can use is VSCode's terminal." I think sometimes things should be hard, but I don't think terminal autocomplete is very hard. Just hit tab a few times and it'll do its thing or -h.
Where it might come in handy, and I haven't tested this, is programs that haven't registered their completions. For example, I'm often cross compiling, and it would be nice if it knew that ...-objcopy had the same completion as the host objcopy. But I am not going to take the hit of the bad pathing just for that.
I'll conclude with a lesson in biases: your insiders are biased. You need to recognize that only egregious errors might be statistically significant. Not only are they more power users, they're new feature hunters, and more than that, they want new VSCode features. Also, that's very creepy y'all are looking at my command success rate even though I'm not an insider. And if you look at the issue ticket, you'll see that a lot of the issues wouldn't cause failure. `Git add` on the wrong file isn't a negative return code, and they might just muscle memory press enter before seeing they need to edit. A possibly better metric is how many times did the user run the same command up to the completion point. But please don't collect that data, that's creepy. I'm going to have to look through my settings to try and turn that all off.
Tyriar|2 months ago
Thanks for the insights. Something I've learned here is that the vast majority of users don't change their defaults or seek out features they may find very useful. Discoverability vs simplicity/bloat is a hard problem and that's essentially the issue here.
I made a note on the issue that with the planned changes to make it easier to configure, we should consider not overriding tab by default anymore. That would mean that only down arrow is bound by default which would then put focus into the widget.
> I'm going to have to look through my settings to try and turn that all off.
Full details at https://code.visualstudio.com/docs/configure/telemetry, but setting `"telemetry.telemetryLevel": "off"` will disable usage/crash/error telemetry for the VS Code core. Just keep in mind extensions may or may not respect that.
Here's that specific event if you're interested: https://github.com/microsoft/vscode/blob/b0e9dce905d12646801...
digitalPhonix|2 months ago
Or a feature to lock users into their tools?
dobin|2 months ago
I, and probably most uses, just hoped this going away as soon as possible again.
Tyriar|2 months ago
For that WSL one specifically we'll get it fixed in https://github.com/microsoft/vscode/issues/285037
laserbeam|2 months ago
itopaloglu83|2 months ago
The feedback you receive is from a selection of people who’re trying new features, not people with existing patterns that is broken one of a sudden with an update while they’re trying to get stuff done.
The_President|2 months ago
Certainly this may not even be intended gesture, but it will result in unknowable metric of users being insulted by the half-baked forced nature of these product changes.
nubg|2 months ago
GNyZhf6g|2 months ago
Also, speaking as an educator, I think there might be a misunderstanding about what makes things intimidating for new users. Systems that make specific decisions without being able to easily control them makes things more intimidating, not less. And if I'm reading your post correctly, it sounds like you are trying to introduce a feature on newcomers, but your internal testing was done on insiders and stable users -- a different population.
Frankly, at this point I may strongly discourage all of my students from using VSCode.
teekert|2 months ago
I think that bar-lowering is not really something that Terminal users want, if they wanted simplicity they wouldn't be in a terminal in the first place, at least that holds true for a large portion of the Terminal users.
Sure there are always the new users, who may benefit from some hand-holding. But why don't you ask first if people want their hand held? Normal terminal users are looking for a way to control their computer in a more direct fashion, which makes them faster. They seek a more predictable interface, by moving closer to the true language of the computer itself, by learning a bit about how it works inside and subsequently adapting oneself to it.
You have chosen to alienate a large group of highly knowledgeable users for a user group that may be mostly a myth.
What would make more sense is to provide a switch for "noob mode", while leaving the core experience alone. I for one already hate the difference between my normal terminal when it comes to ctrl-c/ctrl-v and pasting with select/middle-click. This current change feels like a slap in my face.