Bugzilla – Full Text Bug Listing
| Summary: | Refactor -> Rename now has confusing/problematic workflow | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Kevin McGuire <Kevin_McGuire> |
| Component: | UI | Assignee: | Markus Keller <markus.kell.r> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | bpasero, daniel_megert, erich_gamma, markus.kell.r, martinae, susan, sxenos |
| Version: | 3.3 | ||
| Target Milestone: | 3.3 M7 | ||
| Hardware: | PC | ||
| OS: | All | ||
| Whiteboard: | |||
| Bug Depends on: | 184594, 184597 | ||
| Bug Blocks: | |||
| Attachments: | |||
|
Description
Kevin McGuire
The new rename is similar to the quick fix 'rename in file' by using the template mode (linked mode in editor) to let you rename. The difference to local renam is that we present a hover to show that you are in a special mode and we give hints about possible keyboard shortcuts. It is targeted for keyboard oriented users that don't like modal dialogs. Invoking the lightweight dialog from the context menu can be confusing. But this is a general problem that editor actions always refer on the cursor but not the mouse position. The light weight dialog should help you bring the focus to the input field. Until you enter a new name, Enter and Ctrl + Enter are disabled. If in step 3. this was not the case, please file a bug with steps. Setting to WORKSFORME, but of course we are interested in more opinions. Users that prefer the modal dialog over the light weight dialog can configure that on the preference page. >>Until you enter a new name, Enter and Ctrl + Enter are disabled. If in step 3.
>>this was not the case, please file a bug with steps.
Wow, I have to tell you, I didn't "get this" at all until you explained it. Maybe I was just used to seeing the dialog, but the lightweight menu was throwing me off since I kept expecting I'd have to do something in it to initiate the renaming sequence (including specifying new name). I kept clicking in it to no avail and the disable state of some entries only confused me more because nothing was suggesting what I needed to do to enable them.
I can understand the speed up of workflow you're trying to accomplish for keyboard users. I still feel there's problems with it with respect to expecation and feedback though. Its a good space for us to be exploring, just not sure its "working", but this is always the challenge of introducing new paradigms.
But I'm guessing that the main confusion is that the new workflow is also initiated from the menu, and at that point the paradigm breaks down. What I'd suggest is:
- For keyboard rename accelerator you get the inplace fast workflow you have now.
- For the menu Rename, I should get the dialog because that's the style of interaction I expect to result from a menu item (ie. in general, not just because I personally happen to be used to the old behaviour).
The idea suggested in comment 2 is a good one. We discussed about this here when implementing the feature, but then concluded that it would be unusual to get different results depending how the action is invoked. Theres no other example for this. Currently, we always show the dialog when the action is invoked on an element like in the package explorer. In the editor we show the lightweight dialog >>but then concluded that it would be unusual to
>>get different results depending how the action is invoked.
I understand, that was nagging at me too. Traditionally accelerators always map to menus.
Then again, its a new interaction paradigm you're pushing on which may require a different approach. And its not that one way you get rename and the other you don't, its that the style of interaction changes depending on how you initiated the action. I can kind of buy that (but only kind of).
Have you spoken to someone from UCD like say Jin Li or Julian Jones? Could provide a different data point.
Yes, the new UI was designed with comments with Julian. I've given more thought as to why I think this is throwing me off. 1. What I didn't get *at all* was that if I just typed over the selected text, it would act as the input to the rename. So I just sat there wondering what I was supposed to do. See also 175957 for a similar user stumble. By contrast if I do an inplace rename in say the XP file explorer or desktop, I *do* understand that what I type will be the new name. This is because the feedback is clear (ie. the inplace entry box). In our rename case though, I can't tell that my selection now has a blue outline around it and that that means "type here for the new name". So stronger feedback would help a lot. Maybe if the mini-dialog encompased the selected text more it might be more understandable. I'll attach a mockup along these lines. 2. Until I start typing, the only entry that works is "Open Dialog" but the others aren't disabled. I think this is just a bug and the lack of disablement is just adding to the initial confusion. Created attachment 64088 [details]
(poorly designed) mockup showing stronger feedback
My mockup isn't a particularly great design but it's trying to convey the notion of stronger feedback by:
1. Showing that the selected text is now part of the mini dialog
2. Adding some text white edit area around it to also suggest its an input area. See XP renaming of a deskop item for feedback cues. We do a better job in our quick dialogs though but the white was easier for me to draw :)
I'm sure there are better solutions still.
> - For keyboard rename accelerator you get the inplace fast workflow > you have now. I am a heavy keyboard user, and I don't find the new workflow any faster. The old behavior (alt-shift-r, type in name, press enter) required the same number of keystrokes as the new behavior. The more serious problem is the time it took me to figure out how this worked. Even after reading the comments here and in bug 175957, I was left with the impression that the correct sequence of keystrokes was (alt-shift-r, type in name, ctrl-s), but that leaves the workspace with compile errors since references outside the file only get fixed if you press enter inside the rectangle before saving the editor. The problems I see here are: When the UI shows the orange popup and the rectangle around the text, there is no guidance about what you're supposed to do. I thought the orange popup was a menu, and I had no idea I was supposed to type the class name inside the rectangle and press enter. Normally, "enter" inserts a newline when typing in the text editor, and I didn't realize that it would submit my rename in this situation. Suggestion: 1. Rather than the orange pop-up, open a window that says: "Type the new name here and press enter" ---> "Press Ctrl-enter for a preview" 2. Include a big arrow that points to the rectangle where you're supposed to be typing. That should make it obvious where you're supposed to type and what you're supposed to do when done. Additionally, I'd suggest the following: 3. Remove the current orange popup. It looks too much like a menu and doesn't behave like one. 4. Remove the preference and the old dialog (or alternatively get rid of the new in-place version and restore the dialog). Having two ways of doing things just clutters the UI. *** Bug 175957 has been marked as a duplicate of this bug. *** It seems to me that the core problem is that it that the linked input field doesn't get enough attention. In particular if you fully select a name, the border around the name doesn't look different than the selection. So both Kevin and Stefan's attention got caught by the info dialog, with is intended to just assist. During development we experimented with several UIs, including the one suggested in comment 7. There are big advantages of changing a name in the editor directly: You can you copy/paste, use code assist, see more of the surrounding code. So we want to stick with that. Suggestions: a. We find a better border for the input field. Double border or brighter color b. Full selection is replaced by a single cursor c. Picking up the 'arrow' idea from comment 8, using the speech bubble design? (not sure if this is doable) d. Add more comment to the dialog. Note that we already have 'Leave linked mode'. - At the top 'Enter new name' Did you realize that the dialog can be replaced? Do you think there are better placements? Above? At the corner? Note that 'Enter' always leaves the linked mode. That's the default linked mode behavior. It's really important that we tell the user to press enter when done. No matter how long I spent experimenting with this, I never would have discovered it because I don't want a newline inside my class name and I've been trained over 20 years of using text editors that "enter inserts a newline". The most important bit from comment 8 is the text "press enter when done". Just to clarify, in my poorly designed comment #7 I was suggesting you still change the name directly, I was trying to come up with an overlay dialog that had some additional feedback around the selected text to guide the user. Like a hole in the dialog that sees through to the editor text selection. So still in place, just more guidance. I think we're on the right track. Although I agree with Stefan's comments that I don't see how this speeds up workflow, I assume that some people do like this new behaviour so am happy to try to figure out the user guidance issues. You're correct that because the text is already selected (in order to start the operation) I cannot tell that its now acting as input because the blue input rectangle is quite subtle. I also agree with Stefan's observation that I was interpreting the mini dialog as a menu, which was adding to the confusion. >>a. We find a better border for the input field. Double border or brighter >>color This would almost certainly help. Perhaps there's lessons learned from our quick dialogs, which do work quite well (e.g. Quick Outline, which allows user input for filtering). It might help make it look less like a menu by borrowing from an existing UI metaphor. For example, the border treatment for our quick dialogs. >>b. Full selection is replaced by a single cursor I had thought of that, but I assumed that you want the user to start inplace typing and thus the original text must be selected so that its immediately erased. Note however that other examples of inplace edit such as in XP leave the text selected but provide additional feedback that something more is happening. An added confusion in our case though is that the text is *already* editable because its based on selection in a text editor, so again we need even more feedback that you're now in a new mode (ie. in XP explorer the mode change is to be editable, in our case the mode change is editable to editable but now as input to an operation). >>c. Picking up the 'arrow' idea from comment 8, using the speech bubble design? >>(not sure if this is doable) No opinion either way but my assumption is that we need more integration between dialog and text since the text is now in a sense part of the dialog. >>d. Add more comment to the dialog. Note that we already have 'Leave linked >>mode'. >> - At the top 'Enter new name' We may not need the actual words if we can provide other visual guidance (then again, the words may not hurt). Btw, I didn't understand what "Leave linked mode" is because I don't think I've seen the term "linked mode" anywhere else in the UI. Do we use this term elsewhere or has it been introduced for this specific affordance? > I don't see how this speeds up workflow, I assume that some people do > like this new behaviour so am happy to try to figure out the user > guidance issues. When I first saw this behavior, I really hated it because I had no idea what to do. Now that I "get it", I'm starting to prefer it over the old dialog. I'd like to see this succeed. The trouble I see here is that most users probably won't get it the first time around. I agree that what we need is better guidance. > We may not need the actual words if we can provide other visual > guidance (then again, the words may not hurt). Besides actual words, the only other affordance I can think of that would indicate that I need to press enter when done would be okay/cancel buttons. Created attachment 64231 [details]
Shows a lightweight rename affordance with okay/cancel buttons
Can we reopen this and put it on the plan? The nonmodal rename is fine, but we should really improve the user guidance for this release. Our guidance should be sufficient such that a user who has never seen linked mode before should be able to tell immediately that they need to press enter to submit their change. Linked mode aka template mode has been around since 2.0 and is used for code assist templates and quick fix. The keys in the template mode have always been, 'tab' to navigate between linked fields and 'enter' to leave the template mode. For the first time we have now an affordance that explains that 'enter' leaves the mode. But you're right, I will check that we use the same terminology everywhere. I also understand the confusion and the 'OK' 'Cancel' button would make this more clear. However this looks like quite a fundamental new design for which we probably won't find time to experiment with in 3.3. Note that the window shown is supposed to be 'extra information' for the linked mode, not really a dialog. I'll reopen the bug if we find and agree on improvement implementable in the 3.3 time frame. BTW: Also see the original bug 92322 > 'tab' to navigate between linked fields and 'enter' to leave the
> template mod
I've used template mode, but I always just cursored out of the fields when I was done with them and kept working. I never discovered the special usage of enter because it never did anything essential.
This usage of linked mode is different from templates in that if you don't press enter, the refactoring won't happen completely and you'll end up with compile errors.
So yes it's true that linked mode has had a this keybinding (that I never discovered) for a long time. The difference is that now we're going to start using this keybinding for something really important, so the relevance of its discoverability goes up drastically.
If there's no time to develop better guidance for this release, that's fine. Let's hold off on enabling the feature until we have the time to do it properly. Leave it as a preference for people who have read the blogs and know how it works... once we get enough guidance that we believe that everyone will figure it out, THEN it should be on by default.
(In reply to comment #16) > Linked mode aka template mode has been around since 2.0 ... > But you're right, I will check that we use the same terminology everywhere. Yes, I meant simply as a term, whether or not we've introduced these words as a user notion anywhere else, whether its in the doc, etc. I did a quick Help search and only saw the term in Java Doc. "Template mode" yields zero hits. Just a general concern around the number of terms and concepts our users must remember. We need a glossary! (ugh) We already have a preference page "General > Editors > Text Editors > Linked Mode". Created attachment 64514 [details]
Mock of a few ideas
I quite like the new lightweight renaming feature and didn't have too much trouble understanding it, though I had seen the New and Noteworthy entry and also remember that I used to be very confused by 'Rename in file' ('Rename what in the file?', 'Why doesn't it do anything?') so I can quite understand people being equally confused by this new mode and the enhanced tooltip acting as a prompt/menu. I am used to using Enter to mean complete the operation, I guess the key issue is to realise that there is an operation to complete.
The feature should be easy to grasp for somebody who encounters it for the first time but it shouldn't be visually cumbersome for those who use it on a frequent basis without so much as a mouse click.
My suggestions would be:
- Change the menu option to "Rename Inline..." or "Rename In-Place..." (if it agrees with the preferences).
- Use a text field-like paradigm: draw an inset border for the text around the cursor (editable) and a flat border around the text elsewhere.
- Increase the vertical space between the text and the prompt to emphasise the border.
- Replace the prompt with a short text cue/tooltip such as "Type text, press Enter to complete". Also add a widget which expands into the existing menu, possibly using a real pop-up menu. The appearance would be similar to the prompt in its 'minimised' state. The keys would operate regardless of whether the prompt lists them or not.
- Do similar for other linked mode capabilities as far as it applies.
See the attached mock-up.
As for invoking different editing modes from different contexts, I think there is some logic that somebody who invokes a rename from the GUI can complete it within the GUI and somebody who invokes it from the keyboard can complete it within the text editor from which it was invoked (with the option to switch modes), although the dialogue is easy to navigate via the keyboard. Not to hail them as exemplary UI designs, but some applications use identical actions to invoke different behaviors depending on the method of invocation. An obvious example is printing in Word (Print icon prints, Print menu item opens print dialogue). Consistency and predictablility are important, of course.
If there is no time to make changes to the UI then the question (were this bug open) would be whether to enable the feature by default.
Thanks for the great input. a.) Aggreed, 'In-place' is a better term b.) The 'inset' border is an interesting idea, and we will experiment with it. But it has to be said that for editors we use the flat look of widgets, so adding this here would be inconsistent. If I'm not wrong, the 'inset' design is platform dependent. c.) yes, good idea We started to work on improvements. Will post a first mock up as soon as this is ready. Created attachment 64751 [details]
Mac-style in-place editor field
Created attachment 64755 [details]
Screen cap of hover interacting with light weight dialog
While we're looking at hover help etc:
I notice that you can get both the little in place menu AND the default hover help for the selected item at the same time. The appearance of the hover distracts from the menu and makes it even harder to figure out what to do. I can enter this as a separate bug but I know we're looking at use of hover as guidance so maybe the default hover will just go away as a result of the design refinement.
Created attachment 64756 [details]
(better screen cap) Screen cap of hover interacting with light weight dialog
Created attachment 65224 [details] Screenshot of latest version Thanks for all your input. Here's a screenshot of the latest version that has been released for the next I-build. We've also fixed a few problems with keyboard navigation, see bug 81790, bug 96490, and bug 183925. Fixed for I20070430-0010: - disabled other hovers while in-place refactoring is active (comment 23) - delayed the information hover a bit to focus user attention on the linked mode Re: comment 25 Sweet. That really seems to address the heart of the problem. Thank you for looking into it. |