Intuitive term for “tertiary data” or “list choices” in CRUD interfaces?

Question

In CRUD-like applications, you often have tables that contain very few records, and only exist to assign a name to an id value (they have a one-to-many or many-to-many relationship to the "primary" data).

For example, if your application shows real estate listings, you'd have a primary table for the houses being sold, and maybe another table for various "attributes" that could be assigned to the listing (e.g. "gas", "sewer", "zoned for commercial"). Then there could be a many-to-many relationship between the houses and the attributes.

In the admin interface (for people who manage the data -- not the end-users who are viewing it), admin users can add new houses to the listing and choose from the available list of attributes that apply to the new house.

But... there is also tucked away somewhere, a "master list" of those attributes -- which is how the UI for the "add new house" admin screen populates the available choices. This is not changed too often, so I like to put it out of the way. And I like to put all of these lists in one place (because there's often more than one of them).

My question is: what is a good general term for these kinds of things? The best I can think of is "Option Lists"... but I wonder if there's something more intuitive to non-technical users.

Answer 1

I've often seen such "list choices" referred to as:

• "Options" (usually the caption of the button that opens the screen where they can be edited)
• "Configuration" (more technical but Admin users soon associate this word with their special "list of options" screen(s).
• "Lookup tables" once in the screen, especially if there's more than 1 set of choices (tables would be replaced with a word more specific to your app).

I've found that most business/admin people understand "Lookup" due to heavy use of Excel.

Amenities is probably the best choice for real estate options.

Possibilities for button/screen name:

1. Lookup Amenities (could be considered technical)
2. Amenity Configuration (slightly technical)
3. Amenity Options
4. Choose Amenities

Answer 2

I'm making assumptions, since it’s somewhat unclear what you’re really after. You’re customers probably creates a profile which they can visit on the very top of the page through the link “My Profile”. You could as an option add a “My Houses” section on your profile page, since your user probably like to manage their houses. That’s only a list of houses, or probably only one house, but still a list if there are more houses. Clicking the link of a house, you get to a new page with your house and all of the options. I would say there is no need for a naming on that kind of page, since it’s only one house and its’ implied unspoken attributes.

This is what I would do, but I might have misread the question altogether...?

Answer 3

One approach to making it sound less technical is to adapt a term that describes the collection of attributes you are refering to in that case. In your example that would be the possible descriptions for listings/properties/real estate.

For example, this could be Property description terms or Description terms.

Using that term, however, there is a danger that an admin is adding a new real estate and wants to add selections and clicks the Description terms in a believe she is adding them to the property currently being added. To prevent that, the label should communicate that the list contains the "master" values or possible values.

How about Possible description terms or Manage property description terms or List of real-estate attributes.

Either way, I think specifing your "tertiary list" to reflect what is actually in the list is the way to go for any non-generic problem. Hide the technology from the user.