Naming Controls in Cider

Brian in Cider | 22 Comments September 13, 2006

Since the dawn of time (OK, since Visual Basic 1, but that was a long time ago in computer time) designers have been automatically assigning names to controls. Plop a button on a form and it was given a wonderful name like "Button1". But at least it got a name. You had no control over this in Visual Basic. Controls all had to have names, so even if you had a form that contained nothing but lots of static labels your code still had access to Label1 through Label200.

Windows Forms in VS.NET 2005 changed that a bit. We still required names on controls because too many things broke if we didn't name all the controls with unique names. However, we allowed you to flip a bit that would cause the code generator to generate the variable as a local rather than as a member variable. Now all your labels and static images could stay the heck out of your Intellisense drop downs. There was much rejoicing, except by the QA team whose test matrix doubled in size.

Names on controls in WPF are optional. If a control isn't named, you can't write code against it without searching for it in the visual tree. This is a good thing because in WPF forms and pages may have a ton of elements and only a few of those are directly programmed against. You may have noticed that Cider supports empty names, so if you clear the name field we don't generate an error. We're pretty happy with that part.

What we're not clear on is when we should actually provide a name for controls. Conventional thinking says that we should give everything the idiotic but familar "Button1" style names whenever a control is dropped on the designer. The challenge with this is that names in WPF have a runtime cost, so if you have lots of controls that have names you're not using you're paying a runtime penalty. The power of XAML means that you will probably have a lot less code to handle events in a WPF application, so the need to have programmatic variables to access controls is less.

Here are some of the ideas we've been throwing around:

Name Everything

This is exactly what Windows Forms does today. Everybody gets a name, and if you don't want it you need to clear it out of the property window yourself. Each name has an associated runtime cost for WPF to wire the control to a member variable. This will be familar for existing Windows Forms and VB 6 customers, but it takes additional work to write a well optimized WPF application. Also, if you have many elements on your page UI that lists those elements, such as the property window and Intellisense, become more cluttered.

Name Nothing

The zen opposite of naming everything is to just name nothing. Nothing gets a name when you drop it on the page. If you want to program against it, you first give it a name. We could be smart here and if you wired an event through either the property window or through by double clicking on the control we could generate a name for you on the fly. This breaks the usability of the event drop-down windows in the code editor, however, because unnamed elements won't show up there.

Name Nothing and Prompt

If you drop a button on a page and it doesn't get a name, then you double click and we automatically give it a name, what name do we give? That's right, "Button1". Sure, you can rename it later, but the event method we wire to the control will be named something like "Button1_Click". Yuck. Yes, we have thought about allowing the rename refactoring code to rename event methods too, but that's an inexact science we don't know if we can get right in all cases. One option here is to interrupt the flow with a modal dialog and ask you what name you want. We would then name the control with the value you provided and use that name when generating the event handler method. Clean, but that modal dialog is going to get old fast.

So, what do you think? Should we name automatically like we've always done? Should we name opportunistically? Should we stick a big fat modal dialog in your face and ask you what you want things to be named?

Comments (22) -

gesharptes, Wednesday, September 13, 2006 at 11:29 PM

Name Nothing!
I LOVE this idea! For me it's OK have controls without names, and give an appropriate name when i need to reference it in the code.

Erno, Thursday, September 14, 2006 at 3:23 AM

Do what VS should have have been doing for ages:
Allow developers to set a mask for the naming e.g.: txt_# or #TextBox so when the name property is selected ONLY the # part is selected to be modified.
For Cider: add a setting "Automatic control naming" that can be turned on or off. When on generates a name based on the mask, replacing the # with a number.

Ian Griffiths, Thursday, September 14, 2006 at 4:16 AM

My vote would be to name nothing by default. However, I would also like it to be easy for me to name the things I want to name. One of the things that has always frustrated me a little about the Windows Forms designer is that it's a bit cumbersome to set names. I always want to choose my own names, so this crops up a lot, and it is a process that I feel could do with streamlining. (Or, if there's a streamlined way to do this, it needs to be more discoverable. Smile )
I'm not sure how well this would work in practice, but there's an approach I've often felt would be useful: some sort of non-modal pop-up that appears when you drop a new control onto a form that gives you the opportunity to enter a name without bugging you or forcing the issue. Maybe as part of the popup Tasks lists that certain controls offer, perhaps? Although I find the miniature click target of that a bit easy to miss - really I'd just like a nice big textbox. So perhaps you could do something more akin to the 'Floaties' in Office 2007? (So when you drop a control, it offers a floating place to type the name, but this fades away if you move the mouse elsewhere.)
I realise that this very vague proposal raises more questions than it answers, and introduces a raft of potential useability pitfalls. But I think control naming is definitely an area that is cumbersome today in Windows Forms, and I'd like to see done better in Cider. (Plus, I think the typical structure of a UI in WPF is sufficiently different from in Windows Forms that it positively requires a different approach.)
As for situations where you need to provide a name...I certainly wouldn't want a modal dialog. I guess auto-naming is the way to go, but ideally, I'd like some kind of visual cue that lets me know I'm about to commit to a silly name that's awkward to rename with today's refactorings. I'm thinking something more like a warning sign rather than a road-block of a modal dialog.
Unfortunately, we don't have any good stock interaction patterns for this kind of scenario. E.g. Explorer has pretty poor handling for 'you are about to do something that may well be intentional but could equally be a big mistake' cases. For deletion, it throws up an annoying modal dialog. For folder moves performed by dragging folders around in the folder view (an operation which I almost never do on purpose but often do by mistake) it doesn't even offer very obvious feedback that its done anything, much less ask me if I meant to do it. Neither of these is very helpful. This is a UI area sorely in need of innovation. I'm not quite sure what the answer is...  Maybe something should glow bright red as I'm about to perform an action, to make me think "is this what I mean to do". That'd be easily ignored if you did mean to do it - you'd soon learn to expect the light. And yet it would be a clear sign that something was up if you hadn't actually intended to perform the operation. (Whether the operation is moving items, deleting them, or committing to a default name.)
On the other hand, I can see how frightening red lights as part of the first experience new users have might not be desirable... But I think the idea may have potential - perhaps something informative rather than alarming could be used.
As for the problem of the event drop-down combo, is that really a problem? I think the current model is slightly outmoded: it's still rooted in the old old days of User32, when most forms were pretty flat. A big list of controls makes sense for that model, but doesn't make sense in the more structured world we have with WPF. (And arguably it's on the margins of making sense for Windows Forms, which supports nesting.) In my opinion, that idiom needs some work regardless of what you do on the naming front.
So I'm thinking that the document outline view needs to be brought into play here. (I'm looking forward to the day when the document outline starts working in Cider by the way. When will that be?) Given such a hierarchical view, it shouldn't need to matter greatly whether or not my elements are named when presenting potential event raisers. And if I select an item in the document outline, the event drop-down can then be populated based on the currently selected element. (Then you auto-name if necessary as handlers are added.)
You could still provide an old-style drop-down of items. My vote would be to have this populated with the items that you've given names to, but have an extra final entry in this list that's a hyperlink labelled something like "Unnamed elements", and when the user clicks on that, take them to the document outline. (The goals here are to make the document outline (a) easy to discover, and (b) easy to get to even if you were already aware of its existence.)
I'm conscious that I might be in a minority here in that I never want to use the auto-generated names. Also, being more of a C# guy than a VB guy, I'm not a big user of the event drop down combos... If there's a significant proportion of people who think it's a Bad Idea for *all* items to be unnamed by default, how about a compromise: name some items automatically. I guess you'd need some kind of attribute to let classes declare whether they are typically named by default. But thinks like labels and groupboxes probably wouldn't be, while things like buttons and textboxes probably would, for example. (Obviously this requires someone to do the homework of working out which items should fall into which categories. And since I've not actually done that work, it's quite possible there are problem examples lurking in there that I've not thought of.)
If you were to do this, I'd appreciate the ability to turn the feature off... (Although I'd be happier still not to have this auto-name feature at all. It was just a suggestion based on guesswork as to how I think other people like to use the drop-down controls... Interaction design based on guesswork about other people doesn't often work that well, so I'd be happier if items were only ever named automatically once they positively need names. And I always feel that optional features are a bit of a copout... If you need to provide users with the ability to turn something off, that suggests it may not be designed well enough.)
BTW, if I had $100 to spend on Cider features, I'd spend $0 (zero dollars) on Erno's suggestion. Sorry Erno, but that doesn't strike me as a very valuable feature. Not everyone names their controls with such a pattern. If you're going to make this user-configurable, that's a lot of config going on, because you'd need a pattern for every single control type! (And if it's not user-configurable, that'd be hellish - I don't want to be stuck with naming conventions limited enough that they can be captured with such patterns.) Even if I my $100 was purely going on features designed to streamline the handling of control naming, I'd still allocate $0 to this idea. The auto-generated name is still always something I'm going to want to change. And the cumbersome part of naming isn't typing in the name, it's getting to the point where you can type in the name.

wekempf, Thursday, September 14, 2006 at 4:19 AM

Name NOTHING!
If you must, prompt, but please, don't prompt for everything dropped on the page.
(Thankfully, I'll probably code most of this by hand and not use the designer, so you're decision won't effect me as much, but still, naming nothing is the only logical choice.)

Anthony Mills, Thursday, September 14, 2006 at 8:51 AM

Name nothing.
I like Ian's suggestion of the floating palette, too. I'd like the nice flow of dropping a control on a page (or dragging a box for the control to fit in as in Delphi), typing the caption (for buttons or labels at least), typing the name (perhaps with an ugly Button1 suggestion), hitting Enter. Repeat for the next control.

Anthony Mills, Thursday, September 14, 2006 at 8:57 AM

Oh, here's an idea ... maybe doable now, maybe in the future. Using Bayesian methods and the caption, the IDE should offer better suggestions than "Button1". So if I generally call buttons with caption "OK" OKButton, the IDE should suggest the name OKButton if I create another button with that caption.

Steve Binney, Thursday, September 14, 2006 at 9:19 AM

I think that it is better to do nothing.  I think that the auto naming in Win Forms is annoying.
However, it is important for Cider to have a Visual Tree view for easily locating control if the user wishes to name them.  The Visual Tree needs to be in sync for highlighting controls on the design surface.  
If you are going to provide a naming utility, the floating non-modal box is OK or you can use the tasks arrow that .Net 2.0 forms controls have.

Bryant Likes, Thursday, September 14, 2006 at 10:13 AM

+1 for Nothing. I think the auto naming in ASP.NET is annoying since I end up either not using the name or renaming it to something useful when I do need to reference the control. So the only benefit is for quick and dirty demos where you just leave everything with the default names.
I think the effort for auto-naming would be better spent on other things.

Alex Stockton, Thursday, September 14, 2006 at 10:13 AM

Please don't have a modal prompt. If someone double-clicks to add an event handler for an item that isn't named, just add a code snippet to their code instead of dead text. Make the control name and part of the event handler name use the same $variable in the snippet then users can easily tab and type one place to update the code.

Drew Marsh, Thursday, September 14, 2006 at 10:41 AM

Name nothing, auto name if needed by something like adding an event handler *and* add the name as the first thing on the smart tag panel in the designer for WPF controls so people don't have to go hunting for it in the properties list.
Just my 2¢,
Drew

Kevin Daly, Thursday, September 14, 2006 at 11:20 AM

I think I like "name nothing and prompt".

Roman Hnatiuk, Thursday, September 14, 2006 at 12:41 PM

Do nothing by default. In addition, Name property should be the first property in the list of properties and it should be "sticky" - no matter where you scroll the list, Name always remains in the first row.

Aelij Arbel, Thursday, September 14, 2006 at 12:44 PM

I'd go for "name nothing and prompt". When I need to wire an event, I already know what the element is used for, so it's quite reasonable I'd have a proper name for it. A modal is not so bad at this stage, either. You're ready to type in some code. So type a name as well, press enter, and you're on your merry way.

Corrado Cavalli, Thursday, September 14, 2006 at 2:04 PM

Name nothing and disable all features (e.g events) that require a name, it would be nice to have a quick way to set the name (e.g: CTRL+? a float textbox appears, set the name then features are now active)
Absolutely no model window after each control drop or automatic naming.

Brian, Thursday, September 14, 2006 at 5:30 PM

Great feedback, everyone.  I'm not going to pick and choose just yet -- keep things coming.  I'll get together with the design folks next week and see if we can hash out something that fits around everyones thoughts.  I promise to share here before we commit it to code...

Ryan Baker, Thursday, September 14, 2006 at 10:42 PM

Given only those three I'd go for No Naming, with autonaming when GUI demands.
That said, I was initially thinking of something similar to IanG's suggestion.
I'm thinking, when controls are dropped, they have no name.  When copied you should go with CopyOf_{oldname}, so it's easy to find and change that.
Secondly, when you do something like event creation, autoname but put a little squiggly under the event name, and use one of the smart tags to offer a “name object” option.  To be a bit more clear, you’d see Button1_Click, with a red underline, followed by smart tag that would present a dialog to change the name of the object (and would of course rename the method at the same time).
Since the object was just autonamed, you don’t have all the messy refactoring issues to worry about so it’s a pretty cheap feature because all the UI elements are already in place.  I suspect it might be a little more cost to let the user edit the event name and then renamed the object off that since they might do some wacky things like rename it to MashMouse_Button1 instead of being nice and just changing the object part of the name.
What might work, and I actually like this one best, is to initially drop the cursor with “Button1” highlighted (or even have that blank, thus your event is named _Click), and thus suggest the user type in a name, which becomes the object name.  There are a few messy pieces here though, but from a user perspective that is what “I” would want.

Thomas Krause, Friday, September 15, 2006 at 2:51 AM

First of all you should make these options available in VS, maybe with different default for VB and C#.
As for my personal opinion, I have 2:
1. Don't name any control if not necessary or
2. like Ian suggested: name only some items automatically. Specifically you could name all "interactive items", like Buttons, TextBoxes, ListViews, TreeViews...
In the case that you need a name for event wiring, etc.: I don't want auto-naming, but I also don't want to have a modal dialog. So when I double click on a Control, the code editor should open directly with the event-method-stub and an auto-generated name, but the name should be highlighted in some way (e.g. like the code snippet placeholders) and there should be a small smart-tag like "toolbar" floating over the editor, with a TextBox to quickly rename the control (maybe even in a rename-as-you-type style). Just to be clear: I don't want a smart tag to take me to some extra rename-dialog. I want to type the name directly "in" the code editor in a quick-and-dirty way (whether this means a textbox embedded into the "smart-tag" or some kind of placeholder that I can change directly in the code itself).
This method would also allow me to write the event handler first (when I'm in the "flow") and then name the control.
Just to give you a short vs05-naming-profile of me: I never use auto generated names except for items that I use in code. For controls that I don't use directly in code (e.g. labels) I am often too lazy to name them, so I leave the auto generated name. From this perspective a modal dialog would be better than nothing, however I believe this would still be disruptive, because when I double click an item in the designer I "expect" the code-editor to pop up and the naming dialog is therefore disruptive.
Thank you very much for listening to us!

Brian, Friday, September 15, 2006 at 8:22 AM

Thanks!  The idea of some sort of modeless way of updating an automatically generated name, either by a smart tag or by a code snippet, seems to resonate here -- and Thomas, I totally get that you don't want the smart tag to pop some modal UI; that breaks the flow.  It's a good compromise between never naming and always naming and doesn't get in your way like a modal dialog.
Ian's proposal is really good too, but it sounds like it could be complicated to give it enough options to make everyone happy.

Brian, Friday, September 15, 2006 at 9:12 AM

Ian --
You had a question about when we'd see the document outline.  Never fear; it will be in there.  We're actually in the process of rethinking the doc outline so it is easier to find and provides more useful information.  I don't have an ETA -- we're still prototyping ideas.

Keith Hill, Friday, September 15, 2006 at 2:10 PM

Auto-name nothing unless the environment knows that it has to be named (event handler).  Then provide an easy way to locate and name an element (smart tag?).

Jeremy Hannon, Monday, September 18, 2006 at 6:03 PM

I am not sure how much work it would be, but since we are talking about the Orcas version VS, could you do an in-line prompt similar to the way word acts when you paste text in that would allow us to rename it on the spot (and, thereby, the function name)?  
You wouldn't need to worry about poor refactoring of events, since it is obvious you are only dealing with the function just created.  Additionally, you get all of the other benefits without the problem of a modal dialog box.
Having this in-line tool might be useful for other areas of code editing as well.  There are those times when I wish visual studio would ask me before it does something, but more often, I know the reason it doesn't do something automatically is that it can't be sure what you are doing.  Having the in-line dialog ability could then give visual studio the option of giving you a selection of auto-complete items.
Just a thought, and there are probably better ideas out there, but this is a wish list, right?
Of the three options, though, I would prefer the modal dialog.  I hate spending the extra time to remove nonsense that a designer puts in just to optimize my code (and, a lot of developers won't do it at all).  Secondly, the modal dialog is not too bad.  Just click OK or hit enter if you want to accept the default name
So, in summary, my vote is for Name Nothing And Prompt, but if we could avoid the modal dialog, it would be preferred.
P.S.  Definitely allow us to set a mask for the auto-name or, at least, give us a couple of different "standard" choices.  VB's classic convention should be left to nostalgia.

Luke, Monday, October 9, 2006 at 12:04 PM

I vote for name nothing but make changing/managing names much easier than the current Windows Forms designer.
Comments are closed