Intelligent Intellisense (part 1/?)
Scott brought up an interesting idea for how completion lists could work:
He says:
"ArrayList someList = new
I would expect "ArrayList" to pop-up in a list, already highlighted, and any other known sub/supertypes of ArrayList to be close to the highlighted "ArrayList" option, instead of having to scroll through the entire list or type the first N keys to find my class. I'd expect a little more intelligence there."
I must say that:
- That seems like a great idea
- We don't do enough work to make the completion list that we pop up much more useful to the user.
One thing we've discussed is the new VB 2005 model. In that model you actually get a tabbed completion list. One tab shows all valid intellisense members and one tab shows all common members. A place where this would be useful would be the following:
throw new
You might expect that we just show Types that derive from System.Exception, however that wouldn't be correct. For example you could type
throw new MyClass().GetSharedException()
While unlikely, it could happen, and we don't want to aggravate power users who are typing correct C#. However, you could imagine that in the 'all' tab we would place newable types, and in the 'common' tab we would place things that derive from System.Exception. Another option that we've been debating is to throw away the concept of a completion 'List'. Scott's problem above is that we are taking a rich tree/graph of information and we're dumbly reducing it to a list. Scott mentions intelligent reduction to a list, however, what about intelligent reduction to a tree?
What if we could select ArrayList in the list with a + next to the name. If you then expanded that you'd see the types that directly derived from ArrayList with +'s next to them as well
The issue with all UI presentation is that we provide useful information while not showing obtrusive unhelpful UI. So one could easily argue that the +'s would be obtrusive UI. It might take far too much effort to think about that and expand it. In fact, one could argue that things like completion lists should work in a google-like manner. In an ideal world the item you wanted would be the one that was preselected. Of course, that won't happen until we ship a version of VS that comes with a electrodes. (also, if we could preselect the correct item, then we really wouldn't need to pop up the list). So, like google, we should try to get the best item first and then have the next most likely following afterwards. That way with a single glance of 10 items you have a 90+% chance of getting what you want. The problem then is: what if we don't show you the item you need. What if it's in that 10% that we screw up. The benefit of sorting the list alphabetically is that one could scan through the list with some idea where the item might be. Without sorting, it could be incredibly confusing for the user.
Another idea is if we were to group items. For example, in a completion list that comes up to show you the members of an object, we could group by fields/methods/properties/accessibility/etc. We could also trim down the list as you type. What do you think of those ideas? Do you have any more that you would be interested in?
Comments
- Anonymous
May 25, 2004
How about do it Microsoft Word style for it's font drop down.
Put the items that the user is likely to choose at the top of the list (say 5 or 6 items), and then put the rest alphabetically.
ie
If I typed:
ArrayList = new
Then the following order would popup:
ArrayList
MyArrayList
MyOtherArrayList
-------------------
Activator
AppDomain
AppDomainSetup
AppDomainUnloadedException - Anonymous
May 25, 2004
I think I agree with David but I'm not sure what should be displayed if I type something like
ICollection c = new
There could be dozens of types that implement ICollection - should they all be at the top of the list? Or only some of them? Or may be none?
In any case, it definitely makes sense to at least pre-select ArrayList.
Grouping by item type (method/field/property) might be useful, as well as trimming down the list based on what the user typed. I don't like the other suggestions (tabbed lists and trees) because they seem to be too complicated and different from the way things work now. - Anonymous
May 25, 2004
> In any case, it definitely makes sense to at least pre-select ArrayList.
This, of course, applies to the case where user has typed "ArrayList a = new ", not "ICollection c = new ". - Anonymous
May 25, 2004
An important thing to note is that say you have the following:
class MyClassCollection : ArrayList {
}
class MyClass {
ArrayList GetCollection();
}
and you wrote:
ArrayList a = new
In that model we would have:
ArrayList
MyClassCollection
OtherThingThatSubclassesArrayList
-----------------------------------
Alphabetical list of all types.
Now say you have written 'MyClas'. At that point we'll have selected 'MyClassCollection' which seems reasonable. however what if you hit the last 's' making 'MyClass'. Are we going to continue to selection 'MyClassCollection'? In the old model this isn't a problem because MyClass and MyClassCollection are next to eachother in the list, so it's trivial to hit up/down to get to the right one. In this case (which is not as uncommon as you might think) you are suddenly very very far away from your type and it's very difficult to get to.
This doesn't happen much in the word case because names of fonts are usually quite different. You also don't tend to use the drop down that much. However in code you often have extremely similar names and you're using the drop down every second. So it must be easy to get to the type that is close to what you are typing.
Of course, this just furthers the argument that we should filter as we type. However, Rick (http://weblogs.asp.net/ricksp/) has a lot of data that says that people don't like filtering. - Anonymous
May 25, 2004
Pavel: a) We definitely as least preselect ArrayList.
b)
"There could be dozens of types that implement ICollection - should they all be at the top of the list? Or only some of them? Or may be none? "
Exactly. At what point does filtering and organization end up being an inconvenience.
Clearly Scott thinks complete alphabetic ordering with single selection is inconvenient.
You think that showing the entire derivation tree would be inconvenient.
I think trees might be inconvenient. However, judging by how much people love debugger tooltips, I'm not so sure.
How do we strike a good/google balance between what might be relevant, and what needs to be there. - Anonymous
May 25, 2004
"You might expect that we just show Types that derive from System.Exception, however that wouldn't be correct. For example you could type
throw new MyClass().GetSharedException()"
Does it matter? I'm pretty sure that most of the time you will be typing SomethingException, so listing all the types that derive from Exception seems like a really good idea. In the case when you do want to type something like "throw new MyClass().GetSharedException()" you'll still be able too, you just wont get any intellisense help until you hit the "." which seems fair enough to me.
I think the biggest potential problem with trying to use things more advanced that a list is that'll take too long to make it do what you want. The reason (I think) complete lists work so well at the moment is because they are simple lists and take almost no effort to use. As soon as you increases the effort needed, even a little, they become a lot less useful and you might as well just type the whole name out manually.
Have a tabbed list sounds like it could work well though, as long as you can easily switch between pages with keys (maybe with the left and right arrow keys) - it just seems like that's about as complicated as you can make it before it stops being useful (it'll be great if I'm wrong though :))
- Wilka - Anonymous
May 25, 2004
The comment has been removed - Anonymous
May 26, 2004
The comment has been removed - Anonymous
May 26, 2004
Wilka: "Does it matter?"
It matters to us. We have tried to filter lists down to things that we believe are relevant for 99% of all times and people did not like it. It interfered with their ability to write the code they wanted to write.
Remember that if we filter the list it means that it's possible for you to be typing exactly what you want to type and we will inject other code into the editor. i.e.
you type: new MyClass()
and you get: new MyClassCollection()
Depending on the circumstances, you might no even notice and you'll end up with a bug.
This is why we were discussing ordering techniques or a All/Common tab system. Coders never follow a set of rules that we can expect on. They do all sorts of completely legal things. If we are going to optimize for the 99% case then we still need a way to not hamper the user in the 1% case. This is quite difficult and can't be brushed away casually.
What if we started looking at your methods and started saying "you know, those seem a little too complicated, he probably doesn't want to call those, we'll trim down the list to what we think is common". I would imagine a fair bit of outrage! "Who are you to think that you understnd my code and what I am trying to do" etc. etc. :-) - Anonymous
May 26, 2004
Andrew: I mentioned that there are some pretty severe interaction issues with not sorting the list alphabetically. Do you have any ideas on how to solve that?
I too miss the class view from eclipse. And we've been thinking a lot about the class view and the role it plays when people are writing code. Much of it has been pretty critical. I'm not sure we're going to make you happier (but we might). One thing you might like is that we've split the view in the class view so that members show up underneath the type hierarchy. I.e. you can navigate types in the tree, and then any time the type is selected you'll see all it's members in a list below it, not just in the tree itself.
However, we've been thinking a lot about "code focused" development. Which has led us to want to do as much as possible in the editor space. This is what led us to create the "code definition" window (see my post on Dynamic Help). Why force a person to go to external help or a class view if we can just show it in the editor itself. - Anonymous
May 26, 2004
After reading all the messages until now, I would vote for the tabbed edition, but with very easy navigation between tabs (the suggestion about using the left and right arrows would work, I think). - Anonymous
May 26, 2004
I haven't read all the posts and I don't really want to spend an hour doing so, so I just wanted to say a few things:
1. Try not to break compatability. If you go and make people use more keys than the usual up/down or letter/number keys, you're making it harder for past users to use the program. Of course they will get used to it, but it's not a very nice thing to do.
2. If you haven't done so already, please remove abstract types, interfaces, types that haven't got a constructor that can be used, etc. from the list, or move them to the bottom or something. I don't like going through the types in my 'new' list, then finding out I can't create an instance of them.
3. I would suggest that you keep the filtered list alphebatised and let the user click on a little 'down' option that lets you see all types, unfiltered, like it's done in menus with commonly selected options. - Anonymous
May 26, 2004
Omer:
1. Agreed. Compatibility is incredibly important.
2. We filter out types that are 'not newable'
3. Sounds like a great idea. - Anonymous
May 26, 2004
Omer and Cyrus, as a user of both Visual Studio and Office (which introduced those two-phases menus), I think that 3) is a very good ideea indeed.
However, the clickable "down" option should not get "virtually clicked" causing the list to be expaned after a [small] idle time, as the menus do.
Also, I would like to be able to "click" on the "down" option and cause the expansion of the list with the keys too (without using the mouse). I'm not sure which would be a good, usable, and simple shortcut for it, but that key must be easy enough to type it, and it shouldn't do anything else in the same context. Mayble the left arrow key would be good enough. - Anonymous
May 27, 2004
I would suggest that when 'walking the list' below the last option, the list would expand.
'Walking the list' above the first option would go to the last filtered option.
This way, to expand the list when pressing the space after the 'new' keyword, you could press the up key and then the down key.
Cyrus, I would love to hear (maybe in a post) what was accepted as the solution. - Anonymous
May 27, 2004
Omer: could you clarify that a bit? What is the "last filtered option". It seems rather painful to force a person to go to the up/down arrows to get to elements they used to be able to get to just through typing.
How are we sure that things we are filtering out of the list really are something that is unlikely for a user to use. - Anonymous
May 27, 2004
Sorin: Why don't you like the "virtual click" idea? I also agree that everything should be key driven.
However, I'm slightly worried that we might break '1'. Right now people get to all options simply by typeing. If we add another way to interact to find the things you want then we potentially ruin the experience for people who are used to the old model.
However, if the new model does significantly improve the experience in a majority of cases, then it is something we could do. - Anonymous
May 27, 2004
Hi all,
I'm a usability engineer that's been working on Visual Studio for the six years, so I've seen hundreds of people using Intellisense in the lab and their offices. As a result I have strong opinions about the feature. One thing that I always remind people to keep in mind is that people use intellisense for two things:
1. Speeding up code that they know they are going to write.
2. Browsing libraries and objects.
One interesting thing to watch is how people switch quickly from one to other, often every few seconds when they are really in the zone. Any changes that impede one of these uses at the expense of the other is going to be very frustrating.
Take, for example, the idea of filtering the list down to match substrings. This would work well for times when you are pretty sure you know what you are going to type. However, if you realize that what you thought you were going to type isn't actually in the list, you can't just use the arrow keys to scroll down through the list, you have to delete what you already typed to let the list expand back. At this point you are now thinking about how to use your tool instead of your program, and you get frustrated.
As people on the C# team know, I am very skittish about altering Intellisense because it seems easy to do more harm then good, especially when the feature works so well so much of the time due to it's simplicity and predictability.
Cheers, Rick - Anonymous
May 27, 2004
Cyrus,
Just to clarify on what I said:
You have a filtered list of items. Pressing up or down will move you through the list as it does today with intellisense lists. If you press up in the list when you are at the top, you will get to the last item in that filtered list. If you press down in the list when you are at the bottom, you will expand the list back to the unfiltrered list of new-able items.
I just pointed out that pressing up and then down removes the filtering quickly.
You could also click on the little arrow at the bottom (like in menus), but I wouldn't do it. Keyboard buff, you see. ;) - Anonymous
May 27, 2004
Forgot to mention that you have to be able to disable this. Easily.
Some people might not like the idea. - Anonymous
May 28, 2004
Omer: Thanks for the clarification :-)
I like your ideas. However, i do think we need to be careful with this. As Rick said, intellisense serves a dual purpose and we must be careful to not detract from one experience too much while improving the other. - Anonymous
May 28, 2004
Sorin: Why don't you like the "virtual click" idea?
Well I think that the "virtual click" idea is great in menus because allows the user to see a choice that he or she may be looking for and it doesn't exist in the smaller menu, and this has no other negative effect.
However, I feeld that when the Intellisense list is shown and I will look for some property in the "short list", if it would automatically expand to the "full list" after a definite period of time, that would make me lose the view point. Maybe I has just visually found the item, and when I was about to select it, boom, the list got full with other items, and now I have to find the item again.
Anyway, now that you have asked, I don't know if what I thought above is going to happen. If i'm looking for an item I'll probably scroll down the list and therefore won't be idle, and the "virtual click" won't happen unless I'm idle for a longer period of time... - Anonymous
May 28, 2004
Sorin: Thanks for the explanation. - Anonymous
September 02, 2005
nice to be seen