Sorry, another post to highlight something that’s been bothering me.
A year ago on Inside the Factory, a post discussed Modeless properties. One of the topics was that of User/Focus update. I thought that committing changes once the mouse is moved out of the properties palette was a brilliant idea. As I tested the new features in November, I thought it worked great. However now that I’ve been working with it for a while, I’ve changed my mind. Unlike Steve Stafford who is quite happy with the palette!
I’m finding that I keep losing focus when trying to edit a parameter. Usually once you click in a list box, you naturally move the mouse sideways to make sure the cursor doesn’t block what we’re about to type (at least I find myself doing that a lot when working in any software). Unfortunately if you move the cursor outside the palette’s boundaries, it commits changes immediately, and the input box you just clicked in, loses focus. At least when selecting something from a list box, you can pick the scroll, hold down the mouse button and move the cursor outside of the palette boundaries up and down, while still retaining focus until a selection is made.
At first I loved the above behavior, but now that I find myself losing focus constantly, it is growing to be very annoying. Sure I can adapt, but I think a better solution is to commit the changes once the focus is moved away from the palette, such as when clicking the next command on the ribbon, dropping your selection by picking other objects or clicking on an empty spot on the canvas. These are natural clicks that a user makes, so it wouldn’t increase the click count.
I know a lot of you like it the way it is but I just had to state my feelings as it’s not going away for me. I’ve held on posting about this for a while to see if I would get used to it and obviously I have not! Here is a summary of my thoughts together with some other possible solutions:
- Commit changes when a new selection is made or the current selection is dropped such as when clicking an empty spot on the canvas. Say you select a door and make changes to its parameters. Now you pick a wall; since the selection changed, the door parameter edits would be committed.
- Commit changes when a new command is invoked. This seems quite logical as now focus has moved away from the palette, as if saying “Hey Revit, as you can see I’m done editing parameters...commit my changes!”
- Define a distance in pixels that the cursor has to travel past the palette extents before changes are committed.
- To satisfy a wider audience, how about controls/settings to customize the commit behavior: current behavior or per my above suggestions?
Anyone else out there having similar thoughts or other ideas?
Posts
6 comments:
I guess I don't have the problem of the cursor obscuring data entry, so I'm happy with this functionality. We oughta poll the AUGIers!
Great idea! Just goes to show how difficult it is for the Factory to satisfy us all :)
I like the dialog and never had an issue, until someone else pointed this issue out to me and now it happens to me constantly.
today, the palette has a few shortcomings making it a bit confusing. for instance, hitting enter in the keyboard after having changed a value does not commit and it should.
my bet would be that fixing this problem could reduce the need to move the mouse over. the other interesting effect is that when the palette is docked on the right, this issue is also reduced.
That's an interesting point you just made regarding where the palette is located. I've tested and used 2011 on a dual screen setup and placed the palette on the rigt screen. This meant that most of my movements where naturaly right to left, meaning the cursor stayed within the palette boundary. Now I'm working on a larger single monitor and I place the palette at the left side with the Project Browser adjacent to it (I toggle the PB on and off with my shortcut ctrl + b to release screen space). Naturally, I find myself clicking in the list box and moving the cursor left to right this time, which constantly drops it outside the palette boundries, and thus the loss of focus. That would explain why I find myself having more issues now than I had before, and could explain why some people like the behavior as it is while others find it problematic.
Enter will commit the palette but the first Enter is probably committing the field. First the field is committed then the palette. This allows you to use Tab and Enter to move through the palette. Hitting Enter twice should always do the trick.
Post a Comment