Sunday, 14 June 2009

Building a Flex multiple selection drop down component

In the project that I have been working on, we wanted to be able to have a drop down box that allowed multiple selections from a list and another that allowed multiple selections from a tree structure. The default behaviour of the Flex combo box is to allow the selection of one item. As soon as an item is selected, the drop down closes and the selected value is displayed in the combo box. In order to determine what the selected item is, the programmer has to interrogate the combo box or use an event handler to capture the selection. This behaviour presented some problems when endeavouring to implement an application using a model-view-presenter style of programming. It was even more difficult to follow when requiring multiple selections.

Examining solutions to multiple selection showed that many programmers had worked out ways of programming around the combo boxes behaviour. We also originally took this path but could never quite get the box to behave the way we wanted. It either closed unexpectedly or didn't reflect the current selections. It was time to rethink the fundamental design of the combo box.

What did we anticipate as the behaviour for our multiple selection control. We wanted a button control that looked like a combo box that when clicked displayed a drop down of either a list of values or a tree of values. We didn't just want the drop down to display the selected items highlighted, we wanted a check box that would show the selected items. For the tree, we wanted to go one step further and have a node and its branch selected when the node was selected. The button should indicate the number of items selected and a tool tip should show a list of the items selected. We were seeking some fundamental changes to the operation of the combo box.

To address our behavioural requirements, we decided that we needed at least three components. The base button, the drop down control, and a data model that reflected the state of the control. The next issue was to assign behaviours and here I will admit that we didn't always make the best decisions. However, programming is about learning so we have learnt and adapted our design. What I describe here is more of a proposal for the next iteration in the design.

The button has responsibility for opening the drop down and reporting the state of the selections. It makes no attempt to retain the selection state or dictate the closing of the drop down or the selection process. In some respects, it is a fairly simple button. It depends on the drop down and the model to find out the current state of the selections and the drop down control.

The drop down and the model are closely related. If a tree control is used for the drop down then the data model needs to reflect the tree structure (OK, in Flex, the data model doesn't need to be a tree if you implement a descriptor that will make the model appear as a tree but that is another issue). In our case, we implemented a selectable collection and a selectable tree data structure. These not only held the data but also reflected the selection status of the items. The data model also returned a count of the selected items and a text list of the selected items. The model is responsible for maintaining the state of the control's component parts.

The drop down looks after knowing how it should be opened and how and when it should be closed. It also knows how to interpret the underlying data model to produce the appropriate selection states on the screen. The drop down control is concerned with how to present the data and not with how to manage the state of the data.

To make the control components more flexible, they should be implemented to a standard interface. That way, the button component can use a factory object to build the drop down and not be concerned as to the type of the drop down or the behaviour of the drop down. A similar principle applies to the data model. This way, the programmer can extend the model to new applications without having to redevelop from scratch.

There is another issue that I am still working through. Should the data model provided to the control conform to the controls requirements or should there be a factory object that can build the data model required by the control? Using a factory would mean that the control could be reused in a wider range of applications without enforcing the programmer to know how to prepare the data. For more complex data structures, the programmer may need to provide mechanisms for interpretation but that isn't really a major issue.

So far we have versions of these controls for a list and for a tree but I see the next being for selection from a grid of icons. As time permits once we settle in the UK, I may look at developing these controls for the open source market. My primary concern is that as many of the components making up the controls are reusable and reflect a flexibility of design.


santosh said...

Hi Errol,
I am trying to come up with a component, a drop down with a datagrid, with one of the columns being a check box. The component that I am working on seems to be similar to the component you discussed on your blog. Just wondering if you there is any progress in coming up with an open source version of it. Also, Can you give me some pointers on how i could achieve it if there is no open source version of it available yet?


Errol Thompson said...

Sorry, I haven't managed to make any progress. I have just taken up a new job and moved into a house after three months in temporary accommodation.

However, I have reused the ideas on a recent project and I can share existing code if you are interested.

Rony Jacob said...

Adobe Flex - Multiple Select ComboBox

Errol Thompson said...

This isn't the only solution that works that way. The problem is that it doesn't work when you want to work with a tree or a datagrid or some other complex drop down.

It also doesn't ovrecome the basic design problem with the Adobe combobox.

Errol Thompson said...
This comment has been removed by the author.
AlexU said...

that's an interesting requirement on a ComboBox you have there. I'd first question the User Experience team if there is one at your project. And if there is no User Experience team, I'd question why is the none ;). Seriously, I would ask the User Experience team if a ComboBox has a defined meaning in GUIs. I'm just vary that if technically (including me) or business orientated minds make up their UI behaviour. This might make UIs more difficult to use and also provide technical challenges because UI controls cannot be used out of the box as in this case. Shouldn't a ComboBox always only allow to select one item? This is the question I'd like to ask a UX person.

I find the example of the multi select ComboBox not straightforward to understand that it offers multiple selection. The user has to know about it to use it correctly.

Errol Thompson said...

Alex, you make a good point. Unfortunately in the context of that project, there was no user experience team in part because of a very tight budget. The development team including the user representative did discuss quite a number of possible solutions to the selecton requirements. It was decided that the implementation selection requirements would be difficult to solve without using some form of dropdown or popup.

I do tend to agree that a combobox should be a single selection item and therefore shouldn't be used as the base for something that requires some form of multiple selection. The code used on the project didn't use a combobox as its base although I have seen others that haveattempted to do so.

Having said that, my exploration of the Flex 3 SDK code and some of the equivalent code in SDK 4 suggests that there hasn't been a clear separation of concerns in the implementation of controls such as the combo box. In some of the SDK 4 documentation, there are indications that this is being addressed.

Murtuza said...

Hello Errol

Unfortunately I don't have a UX team to work with. I am a developer and currently designing a GUI which requires multiselect component.

There would be about 20 instances of the component across the application. The business requirement is that the user should be able to select one or more values from a list which contains anywhere between 20 to 50 values.

At first I thought of comboBox. As you pointed out, there are a few problems with that. Even if I could tweak the component a little to support multiple selection, the user would have to investigate the list by scrolling to know what he/she has selected. It wouldn't let the user know how many values were selected. Also, if I had to add details to the values, it would grow in width.

This is what I came up with:

A Panel with two DataGrids next to each other and two buttons in the ControlBar. All the values which the user has to select from, are in the right grid. The selections would show in the left grid. The total number of selections would show up on the header. Since it would consume a lot of space, in the initial state I would collapse the panel to only show its header. When the user clicks anywhere on the header, the panel expands to show the rest of it. When the user clicks outside of the panel, it behaves like a ComboBox and collapses.

I haven't posted a link to the actual component as its still not in good shape. Do you think such an approach would be good for user experience?


Errol Thompson said...


I need to make it clear that I am not a useability expert. Like any user, I have ways that I like to interact with the systems that I use and I find it frustrating when the developers keep changing the user paradigm or interface (i.e. Microsofts 2007 incarnation of Office).

From my experience, I would contend that the real test of useabilty is the observation of your users using the interface. If they get lost or have difficulty working out what to do then it isn't a good interface.

Of course, their past experience can play a big part in what type of interface they feel comfortable with. A transition to a new interface paradigm or layout can take some time so just because users might initially struggle, it doesn't mean that they always will.

As a general rule, I like to make things visible to the user especially when it comes to selections. Based on my perspective and approach, what you describe sounds like a workable solution and does seem to match some existing interface designs that your user may already have experience of. To see whether it really works, get some users to try it out and get their feedback. In effect, that is what the user experience group is all about.

Errol (Kiwi ET) said...

Did you have a screenshot of what you implemented? Curious to see. We have a component that does most of what you described MultiSelectComboBox MultiSelectComboBoxEx :

Errol and Marilyn Thompson said...

I am no longer involved with developing applications in Flex so don't have any information on it.