Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

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?

share|improve this question
    
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 '12 at 17:34

1 Answer 1

up vote 1 down vote accepted

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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