If a user wants to rename a file, he double clicks on file name, and name becomes editable.

If user types an already existing field name and presses “Enter” or click outside the edit box, there could be this option:

• No warning message appears and system changes the name itself to a proper name and saves the new name automatically.

I'm quite confused what better approach for a good user experience is.

  • 1
    The biggest issue probably is here that you are trapping the user in edit mode. I would consider a system where the name can revert to its original state so that the user can navigate away if they change their mind. That's what operating systems do with file and folder names.
    – KMSTR
    Commented Mar 18, 2014 at 7:30
  • So do you suggest reverting back to "system suggested name" and displaying a warning message too in balloon tip so that user should know the name he entered wasn't accepted? And this message can appear for like 2 seconds and then disappear?
    – Ayse
    Commented Mar 18, 2014 at 7:32
  • Have you considered a floating status bar, much like the one in gmail? You change the color to indicate the status type. Commented Mar 18, 2014 at 7:33

3 Answers 3


Have you considered already indicating the availability during typing? Then the dismissal of the name would not come as a surprise to the user and they wouldn't be trapped in edit mode.

enter image description here

  • But for this we have to continuously monitor the user input even before he presses "Enter"
    – Ayse
    Commented Mar 18, 2014 at 7:45
  • 4
    You could add a delay so that you only check once the user stops typing. I think that's a common practice too. I would also look at a buch of registration forms how they handle this.
    – KMSTR
    Commented Mar 18, 2014 at 8:01
  • 1
    @AyeshaHassan Continuously monitoring user input is perfectly okay. Just as in any autocomplete feature - it's trivial to do both in javascript web-UI and in native code UI. You don't want to update at every keystroke (simply because it may distract the user), but monitoring the input before pressing 'enter' and updating it as soon as there's a 0.3 sec pause is reasonable.
    – Peteris
    Commented Mar 18, 2014 at 12:05

"But for this we have to continuously monitor the user input even before he presses "Enter"

Designer should never think from developer's mind

I'd like to purpose following:

You start typing "Plan...." and system will give auto suggestion like plan ID1, plan ID2, in case plan ID1 is already taken small green text "already taken" will be shown on the right most.

Also drag and drop is not a good idea if you have 20+ fields.

  • "Designer should never think from developer's mind" - that is simply not true. A designer works within the frames of what can and what can't be done. To design a system is based on looking into the future makes no sense. Commented Oct 8, 2014 at 14:41
  • My point was we(read designer) should never restrict our-self in the first draft we purpose to the dev, stakeholder or anybody else. That draft should be evaluated on functional, operational and economical feasibility before the implementation. Apologies for the misunderstanding.
    – UXbychoice
    Commented Oct 9, 2014 at 9:42

Take a minute to think about who your users are. In what cases are they more likely to re-type the same name by accident? In these cases, are they more likely to want a very similar name to be applied automatically (I doubt you can find a transformation method that applies to any field names in elegant ways..), to delete or merge the now duplicate item they were renaming, to give it a different name of their own, or to revert back to the previous step (a case which I have trouble finding a rationale for, other than findability: at least it's easy to figure out what transformation occurred).

Try and decide what are the high probability desirable outcomes, and then think in those terms: at the moment the user is done typing or editing, what feedback/action provides the cheapest interaction cost for reaching the user's most desirable outcomes?

For instance, let's assume my users sometimes want a) to merge the two identically-named fields, b) to type an entirely new name and c) to revert to the previous name. They have a keyboard in this setup.

I would go back to the field in edit mode, select all the field's name so users can delete it in one keyboard stroke and type a new one right away. I would provide the abilities to merge and revert to the previous name with specific links displayed on a popover (think GMail's "undo" popover when deleting emails, http://www.svennerberg.com/2008/07/no-undo-redo/). Besides clicking away or pressing Esc after the name conflict has been highlighted should revert to the previous option.

A second example: now my user is on a touch-oriented device, typing is painful and field names are made of several long words. Add whatever condition makes you think that users may create multiple fields with similar wording. Now the desirable outcome would be to keep what was typed so far and just modifying it oneself. It'd be disastrous to just remove everything the user typed. KMSTR's suggestion is probably the best you can do.

Generally speaking, it's almost always a bad idea to do something different from what the user expected without telling them. They might notice only much later after they had started doing other things assuming you respected their original intent (see the concept of interaction breakdown for more on that).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.