5

I have an application built in Delphi7. A particular screen displays a radio group with about 8 items, which is just manageable for the users by normal standards. But now I need to add another 10 options to Radio Group and I anticipate that this will become difficult for the users to find the right option.

Each of the items within the radio group options refers to an application, and I originally opted for the radio group as it was quick to find one of the 8 applications. However, now with more items to be added I think the users will get confused with this way of displaying the items.

This app is used to control application settings, and selecting an application brings the settings of the last available version.

What's the best way of managing this many number of radio buttons?

enter image description here

4

You can use Master-Detail interaction pattern, see the image:

enter image description here

The list is fully visible, so you can observe and choose any item quickly.

If it's possible, try to group the applications in some meaningful way, like Photo & Graphics, Office, etc. This will help to navigate on the list in a faster way.

  • +1 Interesting your answer so I can arrange alphabetically and put into groups preserving the alignment to sub, I'll wait, if not more suggestions apply this solution, thanks. – David May 18 '16 at 19:30
  • Based on context, and Delphi 7, the given solution solves my problem very well, thank you. – David May 20 '16 at 14:21
3

There are a number of different strategies that you can apply, depending on the relationship between the applications (or lack of):

  • Grouping: try to group applications of similar function into a subset and provide a label, that way the users can scan the headings first and reduce their search space. This strategy will work if you end up having to add another 10 items later on, whereas specific layout strategies may not.
  • Ordering: try to order applications so that there is some natural or logical sequence (e.g. alphabetical, date added, etc). This strategy allows you to manage long lists or provide a secondary structure within groupings. This strategy is good for people who can scan lists quickly and pick out items from a relative order.
  • Filtering: allow users to apply certain filters that will reduce the amount of items shown. This can be a reuse of the logic used to group types of applications together, it can be based on a logical order (e.g. applications added in the last 30 days) or applications that start with the letter A-Z, etc. The difference is that unlike grouping, it actually reduces the number of items displayed on the screen, which has its advantages and disadvantages.
  • Searching: this is related to filtering, but basically could be an auto-fill or auto-suggest function that brings up (or highlights) items matching a search query.
  • Re-arranging: if all else fails, redesign the layout of the interface so that it fits with the amount of content and complexity of the information you are dealing with.
  • The filter and search is a little difficult to implement in Delphi7, but those items that really make sense quoted usability which could be applied to my question. – David May 20 '16 at 14:21
3

From the moment you can only choose one item, could a drop-down also do the job (perhaps even with a grouping as indicated above)?

The reason I suggest this, is that judging by your example, you might get into layout problems when you have items with varying label lengths, which in turn might prompt you to choose for a vertical list (and as a result take up a lot of vertical real-estate).

  • Implement Drop-down in delphi 7 is somewhat complicated, m would not be a quick fix, but I agree it would be great. – David May 20 '16 at 14:19
2

As mentioned by Gino, with bigger label lengths you might run into problems. Whereas a good solution to radio buttons are searchable dropdowns. Something like this should work if Master-Detail interaction pattern doesn't work for you. enter image description here

enter image description here

  • 2
    I thought about that too. Looks like a bit of an overkill for 18 options at the moment, but definitely something to consider if the number of options just keeps growing. – Gino van de Staaij May 19 '16 at 12:59
  • It's kind of hard to do this in delphi 7: /, but it is an optimal solution. – David May 20 '16 at 14:17
  • I don't know about delphi but I did a quick google search and found this. delphi.cjcsoft.net/viewthread.php?tid=48921 – Prerit Mogre May 20 '16 at 15:11
  • Amazing! Not thought of searching the filter code to Delphi7, I thought of implementing it, oh yes would give a little work. If you pass 18 products will have to implement this solution, but by the time caregorizando solve, thank you! – David May 20 '16 at 16:50
1

I recommend using another pattern and ditching the radio buttons. Personally, and according my company pattern library, the maximum for a set of radio buttons is 5-7. For anything higher than that, autocomplete/typeahead (as suggested by @prerit-mogre) or a select menu (as suggested by @gino-van-de-staaij) will provide a simpler interface for your users.

  • There is an old rule that we always have a maximum of 7 members, 7 bottoes, 7 options, etc. Liked it! – David May 20 '16 at 14:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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