I am working on an (existing) UI that has a feature where the selection in one table drives the content of a second table:

  • Table 1 shows a list of notifications, Table 2 shows a list of bank transactions

  • If an notification is selected in Table 1, Table 2 shows a list of bank transactions related to the selected notification (Table 2 is filtered by the Table 1 selection)

  • If no notification is selected in Table 1, Table 2 all the bank transactions (Table 2 is not filtered - it is as if all the notifications have been selected)

Currently, the UI works as:

  • The initial state is for nothing to be selected in Table 1 (all bank transactions are shown in Table 2)

  • Clicking on a notification in Table 1 selects that notification

  • Clicking a second time on the selected notification deselects the notification (nothing is selected)

Here is the problem - we ran a usability test, and users didn't do well with this interaction. They clicked on a notification to select it, but sometimes clicked again (or double-clicked) and didn't realize that this had inadvertently deselected the notification. This led to errors in task completion.

The explanation for this is that clicking on an item to deselect it is not normal behavior for a selectable table. I feel that something needs to be done, but the development team is split on how to solve it:

  1. Don't change anything. It's a major part of a UI that will receive heavy daily use. Users will learn this behavior. Plus, there's a precedent from brushing behavior in charts, where clicking on a point in a chart selects it and clicking again deselects it (driving the content of a second chart, or a table)
  2. Do not deselect the notifications on click, but add an additional control to return Table 1 to the deselected state (such as a 'Remove notification selection' button, or something like that)
  3. (Not really being considered, but here for completeness) If the user wants to see the transactions for all notifications, make them actually select all items in the table. For various reasons, this isn't feasible

Any thoughts? Any other ideas how to solve this? The additional controls required by solution '2' seem clumsy, and proponents are arguing that solution 1 is the cleanest and most efficient, and that there's nothing to worry about in the long term. My worry is that the habits built up by interacting with tables for which click doesn't toggle selection on and off will be hard to overcome, and lead to errors even after repeated use. Am I worrying unncessarily?

  • Is it a desktop application? – Oztaco Aug 28 '15 at 6:22
  • @Oztaco - yes it is – PK Jellylord Aug 28 '15 at 13:10

Your Answer

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

Browse other questions tagged or ask your own question.