User Experience Stack Exchange is a question and answer site for user experience researchers and experts. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I've attached a sketch wireframe to hopefully help. I wonder when is it necessary to lock the answer that has been input into a textfield, then if the user wishes to edit the answer they have to press the 'X'? Why is there a need for this?

enter image description here

share|improve this question

closed as not constructive by Benny Skogberg, Matt Rockwell, Ben Brocka Nov 20 '12 at 21:37

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

Hi. Your recent questions have been particularly low on the detail / reasoning. Are you able to provide some more detail as to what the actual problem is you're trying to solve? Everything is rather general, so you'd only get general advice rather than an actual solution. Why are you locking in the first place? What is the use-case for this situation? Are the answers likely to be amended often? – JonW Nov 20 '12 at 17:11
Hi Jon, the question is quite general as I'm not trying to solve a particular problem. I'm just curious as to when this approach is valuable? – user19592 Nov 20 '12 at 17:37
This seems completely hypothetical. Have you ever seen this before? – DA01 Nov 20 '12 at 18:18

This mechanism is sometimes used in cases where the user's input has a big effect on other UI controls, and the logic is "if the input is A, display UI X, but if the input is B, display UI Y". Once the user has selected A and then went on to interact with the rest of the UI, we don't want him to be able to change it to B, because then we'd either have to change the UI and discard the work he has done, or save his work, leave UI X in place, and create a discrepancy in the screen, arriving at a screen which doesn't make sense.

Just to illustrate the concept, a very simple example - month and day selection. If you select December in a month dropdown and then 31 in the days control, and then you backtrack and change the month to November, I can't let the 31 remain there, since November only has 30 days. But noone in their right mind would lock month selection, because the amount of user work we're losing is very small - just the selection of the day.

An extreme example would be a site that lets you fill out business school applications for different schools. Selecting a school affects literally hundreds of controls, so after you've filled out an application to Stanford I won't let you go back and change the school name to Harvard. In reality it's a complex multi-stage process, where sometimes you can't go back once you've made a specific choice, but if we were to display all the stages on the same long web page, that would be the reasoning.

share|improve this answer

In addition to Vitaly's answer, applications also use this type of interface when the single text input can be used for multiple values.

For example, when tagging a post in Wordpress, users enter a tag, hit return, but can then use the same field to add more tags. Each tag is added below the field with a little 'x' in case the user wishes to remove it.

screenshot of Wordpress Tags interface

share|improve this answer

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