desktop 🠖 interface documentation

Name Generator for Roster Data 

Name Generator for Roster Data Interface
Name Generator for Roster Data Interface

Name Generator

Creates nodes of a single type, based on data from a roster

Uses Prompts:

Name Generators are one of the fundamental components of a network interview. They allow your participant to create alters, thereby describing one of the two main entities in your study's networks.

There are three name generator Interfaces in Network Canvas that can be added to your study, all of which can be configured within Architect.

Each of these Interfaces is designed for a specific type of alter elicitation, with several associated advantages and disadvantages. Although they have some configuration options that are shared with all other Network Canvas Interfaces, this article will focus on options specific to the Name Generator for Roster Data.

The Name Generator for Roster Data is useful when you have a known set of network members from which you want your participant to be able to nominate. The interface can accommodate rosters of varying size, but the method of nominating a member of the roster will differ depending on roster size in order to facilitate ease of searchability for the participant.

Defining a Roster

This interface requires you to have a datafile that represents your roster. See our article on working with roster data for more information about how to create such a file. Have this file, or a suitable mock file, ready before you attempt to configure either of these interfaces.

Alter Nomination

The roster interface is split into two panels. One panel displays ‘cards’ that represent each item in your roster. The other panel represents nodes in the interview, and will initially be empty. To nominate an alter, the participant must drag a card from the first panel on the left into the second panel on the right. The card will then be removed from the card list, and a node will be created representing the roster member in the interview network.

When using a small roster that contains less than 100 nodes, cards representing all members of the roster will be displayed on the interface according to the display and sort options you have configured. Participants can scan the list displayed and select the appropriate card(s) to add to their network.

When using a large roster that contains more than 100 nodes, participants must use the search function before any cards are shown. The participant can type to search for nodes based on the search options you have configured. As the participant begins typing, all node data that meets the criteria will be displayed as cards above the search box.

By default, the cards will display the name attribute from the roster data as the card title. The display options of these cards are completely configurable. You should display all attributes that a participant might need to disambiguate roster nodes with similar names.

The search function is also heavily configurable, allowing you to choose which attributes from the roster are indexed, as well as the accuracy (or 'fuzziness') of the search matching. These options are powerful, and should be configured carefully. Each attribute added to the searchable properties list will decrease the performance of the search function, and may make matches less accurate. Similarly, using too stringent or too lax search accuracy will compromise the ability of participants to locate nodes in the roster.

As a general rule of thumb search accuracy should increase as roster size increases, and only attributes containing terms participants are likely to search by should be included as indexed attributes.

Best Practices

Ensure that the roster data file used has name attribute to avoid seeing "No name variable!" on your cards. See our article on node labelling for more information on this topic.

Try to Avoid

Avoid using this interface with a large roster (>100 nodes) on devices with a software keyboard, particularly where they also have a small (< 9") screen. The software keyboard will cover a substantial area of the screen, and make the process of searching and nominating more tedious.

When using a large roster, avoid setting all properties to be searchable. This will cause slow performance and less accurate search results. Ensure that you test your search feature thoroughly.

Avoid adding needless attributes to the sort options. This will confuse users and may potentially cause display issues on smaller screens. Aim for no more than 3 sortable properties.