I have noticed an on-going prevalence of disabled controls upon component load (clicking on a button to load data, only to find all controls are then disabled). As a usability enthusiast, flow has always played a fundamental part in my mind - it's inherently enjoyable to the end-user.

Some reasons I have thought of:

1. Database statement submission

Counter-argument: Commit rollbacks are most certainly possible

2. Inherent race conditions

Counter-argument: Concurrent defensive coding (synchronization, mutual exclusion locks) should prevent this

3. Locking in the end-user

Counter-argument: There should be little to no restrictions on the behaviour of the user from a usability perspective

Why does this UI disabling exist and how does it provide ergonomic gain to the user?

  • I think it's primarily due to simply having to wait for all the client side rendering and wiring-up of interactions to complete.
    – DA01
    Aug 16, 2012 at 17:34

1 Answer 1


We had a similar discussion when implementing a search. The main argument is on the technical side, similar to what you listed. From usability stand point I don't really see benefits of locking the screen. Some questions around not locking the screen were if let's say the search is in progress and the user types the new criteria, do we discard the previous search? I would say yes, since if the user retyped the search criteria it is unlikely they want the old results. Overall, my impression it is just easier to implement the solution that disables the control vs. keeping everything enabled.

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.