user interface pattern for associating single or many objects to an entity

Question

Need suggestions on implementing associating single or many objects to an entity.

1. All soccer team players are registered individually (e.g. they are part of 'players' table)

2. A soccer team has many players. The click sequence is like this:- a] Soccer team owner provides a name and brief description of the soccer team. b] Now it wants to add players to this team. c] You have the following button 'Add players to team' which lets you navigate to the 'View Players' page and lets you multi select users from there.

Assuming this is a paginated list of players, how do you handle the following:-

• Do you provide a check box against each player and let the manager do a multi selection.
• If you need to add more players, it doesn't make sense to show the players who have been already added to the team. Do you mark those entries as not selectable or you would still show them but provide some other indication
• If you need to filter, do you provide search filters at the top of this page.

Am looking for ideas on how to implement this or sites which have already done something similar.

Answer 1

I would have something that looks like the following:

     Players                     Roster
+---------------+          +---------------+  
|               |          |               |
|               |          |               |
|               |          |               |
|               |          |               |
+---------------+          +---------------+

Filter: ---------

With list elements in the Players list having (maybe) a picture, name, and other information about the Player.

The Filter text box would allow the user to type a partial name and filter the list to make finding the desired player easier.

Each element is draggable to the Roster column at which point the player would be added to the roster.

I have intentionally left this platform agnostic since you didn't mention if this was for a Desktop or Web app.

Since this is for a web app, I would suggest making each player in the list its own seperate div, using jQuery Draggable to enable the drag/drop functionality, and using jQuery's AJAX functionality for posting back to the server to make sure the player gets added to the roster.

Answer 2

Take a quick look at the UI at http://www.extjs.com/deploy/dev/examples/writer/writer.html

I would have an autocomplete box which drops down the list of players and adding it to the soccer team when the user presses enter or a button

Answer 3

1. The check box is the appropriate control to allow multiple selection in this case. Other forms of multiselection, such as ctrl-clicking should be considered expert action that are not known to all users, so if users usually select all their players at once, then you should make that capability explicit with check boxes. Alternatively command buttons may be used but only if there is some clear indication that the player is selected or not.

2. Two designs:

   a. Players page, which shows a sortable/filterable list of all players. The list includes a read-only field identifying the team the players are on. It’s blank if the players are on no team. For players with no team, there’s checkbox is beside this field labeled “Sign Up.” Checking it immediately fills the field with the user’s team name. Unchecking it clears the field. Any players currently on the user’s team are indicated with a checked checkbox no matter when they were added. This design is preferred if there are several functions the user can apply to the players through this page, avoiding the complexity of having separate pages for each function, which complicates navigation and reduces user flexibility. The Players page is a general “player management” page that the user can navigate to off the main menu –not just from an Add Players button. Note, for example that it also allows the users to delete players from their team, which could come in handy (e.g., “Wait a minute. I put Daniel Beckham on my team yesterday when I wanted David Beckham!”). Of course, users should also be able to delete players directly from their respective Team pages.

   b. Available Players page, which shows a sortable/filterable list of only players not assigned to a team. In this case, players that are already assigned to the user’s team (or any team) do not appear on the list. This design is preferred when usually most players are already on teams, and you want to avoid making the user scroll or page by players that can’t be added (or otherwise edited/managed). In a variation on this design, the Available Players is a modeless dialog pane that inserts itself in the Team page when the user clicks Add Players. Instead of a check box, there’s an Add command button beside each player. Clicking Add removes the player from the Available Players list and the user sees the player appear on their Team player list. Likewise deleting a player from the Team player list removes the player from the Team and inserts it in the Available Players pane. Of course Delete Player should also be available without opening the Available Players pane first. To support power users, you can also allow multi-selection by the usual methods (dragging, ctrl-click, shift-click) and allow the user to drag and drop players to and from the Available Players pane.

3. Filters at the top of the page are fine if you expect users will need to use them regularly. However, for a list, the left or right margin may be better for filters, allowing the user to see as many players as possible without scrolling. If the filters are a rarely-used expert feature, make them something set on another page, or make them hidden by default. Always indicate the current filter settings on the Players page. If the filters are on the Players page, ideally they should (a) not take up too much space (say, no more than 150 vertical pixels when at the top), (b) apply instantly (i.e., “faceted search”), (c) not scroll out of view when the user scrolls down the list.