« Back to blog

Overlaying UI Controls/Elements

The overlaying of UI Elements or controls is something all UI Developers and Designers do. While it may be pretty useful, it can bring a lot of questions on efficiency, ease of code and logic. So, lets get down to basics: Why have overlaying or overlapping controls? Well, for one, i have been using it a lot for variable functionality. It basically means making your UI possess a different set of UI elements or controls altogether, offering radically different functionalities in varying scenarios. One in specific is having a ComboBox (drop down menu) on top of a Read-only Textbox. This can be used in a form to great effects. While the user is entering a new Form, there might be a predefined selected set of values which he might have to select from for a given field in the form. But, after saving it once, the selection should no longer be accessible and the value of the field should be permanent for the entire lifetime of the form. To do something as simple as this, we firstly create two different UI elements. Then to manage which appears when, we set up flags or conditions and toggle their visibility. And finally, we manage the communication between these two controls. So let us see the pros and cons of this approach. Pros: 1. It is an obvious logic. 2. With care can be implemented flawlessly, so to say. Cons: 1. Since, quite often you only manage the visibility of the controls, you end up loading two controls where one should suffice, making the UI more bulky. However, this can be negated if the controls are dynamically created. But, this increases back end code and the conditional logic, which decides which control should appear, has to be all the more fail-proof. As, if the logic goes wrong at any point, you have not created that control and the code that is dependent on that control will then start throwing errors, and you will probably take time to track down the root of the issue. 2. If the logic behind the visibility conditions is complex, then there is every chance that the code will fail, time and over again. 3. You have to write more code come what may. You either have to write extra code in the UI markup where you have to define the control. Or like i pointed out in Con 1, you have to make the code behind bulky. 4. The data communication between the two controls, which i refer to as synchronization has to be good at all times. It simply must not fail. The chances of which are very high. So the big and small of all this is that, you have to write more code, which is definitely not localized, which increase of the probability of bugs and make their (read bugs) detection slightly tedious, all this subject to the complexity of the conditional logic and the data to be synchronized. Why go through all this. And mind you this was a very specific and simple case, where you are dealing with two very basic controls: the ComboBox and the TextBox and two very basic data structures: the List of Strings and String. Imagine if things were to get complicated, like they normally do. So what are the possible solutions you ask? Let me draw out a few and let me try and generalize them to a set of similar scenarios. 1. Simple Solution: Keep both controls visible, do not overlap them. This way at least you do not have to manage their visibilities or dynamic creations and that is one thing less to be managed in your conditional logic. 2. Simpler Solution: Redesign the ComboBox so that it acts as a TextBox as per your control logic. One way of doing this is disabling its drop-down after the 1st save. Another method is to populate the combobox's drop down with only one item, i.e. the one that was selected in the form's 1st iteration. This way, you have eliminated the  need for an extra control. There is no need to carry out data sync as there is only one control. The amount of things depending on the control logic has reduced drastically. Overall you are looking at a drastic code reduction and refactor. 3. Difficult and Context-based Solution: Design your UI in a manner which does not invite such situations. Now, that you know such cases can drop up in a UI, spend some time in designing the UI well, before hand. And this is what needs to go into core UI designing. Not the looks necessarily. The usability, the implementation, the functionality. Hence, the big and small is to either keep both the control which eliminate the tough and critical task of managing their visibility or creation+destruction. And to eliminated Data Sync which is another critical task. You should in essence try and make the Data and till an extent Control Visibility, independent of the conditional logic. If not that, keep the dependency to a minimum as they are critical for the UI, simple. There are other cases as well. Such as, toggling between icons, one says List View and the other says Tile View. Keep both icons, what is the harm? Another case is to overlap a password box on top of a regular text box with a check-box which say "show". One stores the password in plain-text and is invisible if the check box is not checked, while the other keeps in the star or dotted fashion and is visible by default. This enables the user to see what he is typing, by simply checking the check-box. Why have it? Make him retype the password. Hiding context menus items, when they are not required on a page for a particular context. Disable them. There are 5 other simpler methods of doing things for a given task. Pick one, they do not look that bad. Simplicity is a virtue.