To Button, or Not To Button
We are in the process of updating all of the gallery modules for the online courses at HerbergerOnline. There are several improvements that will be made during the overhaul. I designed and coded the originals. They are scalable and pull images and text dynamically from external jpgs and txt files respectively. They are however, procedural and require an individual compile for each gallery. They also lack the ability to print.
So, I decided that since there was so much work to be done, we might as well re-address design choices to enhance the user experience. The biggest was certainly the redesign of the previous and next buttons on the interface. The initial buttons were a hack job to be perfectly honest. They had an over state and that’s about it. They didn’t disable when there were no options available, and though you could tell where you were in the gallery via the “image __ out of __” information, this was still a huge design flaw — updating was a must.
The question is basically this; If a button is not functionally available, do you leave it on screen and visually disable it, or do you get rid of it all together?
The argument for leaving it, is that in doing so you are presenting the user with the information of potential functionality — I may not be able to do this now, but I will be able to do so in the future. This could aid a user who may be apprehensive about moving forward (in our case), for fear that a return view might be disallowed. The argument for taking it away altogether, is simple, if there’s not an option, the option shouldn’t be available as it may create confusion.
In the end, I think my decision came down to trust. I believe that users are at the point where they should not only be able to trust the application, but should expect to only be given options the are functionally available or inform a decision. I truly believe that the deduction to the smallest common denominator (for lack of better description) reduces potential confusion. In other words, I believe (without scientific evidence) that something not being available creates less questions than something being available and not functional. An office vote had 4 on the side of removal, and 3 on the side of disabled. (note: it was mainly old men that voted for the disabled — I’m just sayin’)
I will say that this is a case-by-case basis and the decision should be based on whether the information about potential use is important to the user, now or in the future. Photoshop is a good example of where disable tools and menu functions convey important information to the user. In some cases, this information will lead the user to an action that must take place before potential use is made functional. For instance, Hey, why aren’t these disabled effects available to me? Well, maybe if I shift over to RGB mode I can change that. Sure enough! In this instance, a disabled button gave me the information I needed to take action.
To conclude, I believe that if there is no extra information being conveyed by a disabled button or function that is potentially essential to a user engaged in a decision making process, then that disabled button or function has the potential of creating more confussion than clarity. In other words, a disabled button needs to have a reason to be there, otherwise get rid of it until it’s of use.
