This blog post explores introductory concepts and investigations around the use of Labels in managed systems. It focuses principally on the topic of label creation. One of the goals of this blog post is to surface additional requirements and areas of concern. Known “Open Issues” are listed at the end of the document. Please leave comments with any questions or suggestions that you might have, thank you!
A label is user-defined text that is associated with a managed resource. Labels support richer search and filter options. They are not intended to be unique identifiers, like resource ID’s. Many resources can, and often do, have the same labels applied to them.
Labels enable users to identify and associate resources according to their own model, rather than that of the organization or the semantics of a system. In non-hierarchical systems, labels are a particularly useful tool. They allow users to make associations among resources where explicit object associations might not exist.
- Use case example:
A user needs to label resources, that are located in different physical locations, in order to manage maintenance work across these locations. The user creates or selects labels and applies them to the resources. They can then filter by label to the specific servers that they need to manage.
The label is a text string, formatted as a key-value pair (KVP). It is presented in the UI as a “key name” preceding a colon separator, followed by a “value” text string after the colon. The use of a colon as a delimiter should be configurable, by the software, to support other technologies.
There is no requirement to represent a hierarchy or an ordered pairing. The text string could be seemingly arbitrary.
Fish:Dog = Valid entry
Although whether the text is assigned to a “key name” or a “value” does matter.
“Dog:Fish” is not equivalent to “Fish:Dog”
Labels that share the same key name may implicitly or explicitly form an association. Using a consistent set of key names makes it easier to identify and manage resources. The onus is on the user to create a consistent set of labels to best support their work-flow and resource types.
Label Syntax Requirements
- Each label must include a key-value pair delimited by “:”.
- Labels are case sensitive.
- Spaces are allowed.
- Must begin and end with an alphanumeric character.
- Special characters may be used, provided they are not used at the beginning or end of the label values.
This initial pattern addresses the action of “Create.” It is intended to be one of a set of actions that will be covered in future patterns, which include:
Creating a label means adding the label to a stored list of labels. Delete would purge the label from the stored list of labels.
- Apply/ Remove
Applying a label means associating that label with a given resource. Removing a label entails removing the association with a resource, but does not purge the label from the stored list of available labels.
Create: Labels are created by entering the KVP text strings into form input boxes. One input box is used for each member of the pair. A read-only colon separates the two input boxes. Every effort should be made to ensure that these input boxes align on the same horizontal line.
1) Creating a new Label.
2) Using an existing key name and creating a new value.
Previously created labels appear in a drop-down selection list, within the “create” labels form fields. A drop-down list is presented when a user types-in values which match an existing label. This “type-ahead” functionality is similar to: https://twitter.github.io/typeahead.js/examples/
3) Supporting the creation of multiple labels
Users may create more than one label at a time, by clicking a “+” icon button to the right of the form fields. Clicking this button will add a new pair of empty inputs. Alternatively users may clear a label before submitting by clicking the “x” icon button to the right of the form fields.
Submitting the form creates the label. Placement and terminology for the form submit buttons depends on the context in which the labels form elements are placed. The “Create” inputs could be used in a variety of contexts: Modal Dialogs, Wizards, Pop-up dialog, within another form and etc. Presentation details will be expanded when work around the other Labels actions, particularly “Apply,” commences.
In the interim, if the create-label action is a stand-alone form then the recommendation is to use generic Cancel/Save button labels wherever possible. If it is necessary to use a specific action label, refer to “Terminology and Wording for Action Labels” for more details: https://www.patternfly.org/styles/terminology-and-wording/#terms-and-words.
- Question: Our rationale for using the term Label rather than Tag is due to the semantics of a name:value pairing. Does this resonate with others?
- Open Issue: Is the label “Value” a required field, or just the “Key Name? Different technologies/products seems to enforce different requirements.
- Open Issue: Should it be possible to “Create” a label without having to “Apply” it to a resource?
- Open Issue: If Delete purges the label throughout – in a multi-user application, how do I know if others are using the label so that I don’t get a purge/cascade effect?
- Open Issue: Additional syntax requirements:
- * Maximum number of labels?
- * Maximum key length—127 Unicode characters in UTF-8?
- * Maximum value length—255 Unicode characters in UTF-8?
- * Any reserved keys that can’t be used.
- * Are labels specific to a user or a global-wide per resource?
- Open Issue: Where does one go to manage all the labels (see the full list)?