Canvas Glossary

A-C Terms

Accent Icons

Accent Icons are presentational icons used to add meaning, clarity, and visual interest to a page. They should generally not be actionable.

View all Accent Icons

Applet Icons

Applet Icons convey entry points, categories of actions, or information sources on the Workday homepage.

View all Applet Icons

Assets

Visuals built entirely with Tokens. Types of Assets in our system include: These are illustrative elements that depict wayfinding, notifications, branding, and system feedback. Assets, such as some illustrations, are used to depict system feedback like an empty state, while others are purely visual and are meant to provide a moment of delight for a user.

View the Assets section

Anthology

Anthology is the curated collection of Workday’s Web UI Storybook stories - a Storybook-of-Storybooks

It will help you:

• Search for and discover available React components from many products
• Improve awareness and communication between you and your development teams
• Share components between teams to encourage reuse over rebuilding
• Essentially, its goal is to foster a community model for building and maintaining components at Workday by encouraging maximum visibility, code sharing between products, duplicate management, and more.
• For discussions and more info, join the slack channel #anthology.

Brand Style Guide (Brand Central)

The Brand Style Guide is the defacto reference for any marketing or branding content. It builds on top of the foundations of Canvas (colors, icons, etc.), but offers more prescriptive and niche approaches that are specifically chosen for our company branding. Here you can find information about our logo, illustrations, photography, font, marketing content guidance, and more.

Canvas

Canvas is Workday’s design system that is made up of reusable UI elements, design principles, and guidelines. It is composed of three sub-products:

• The Canvas Design Figma Libraries
• Canvas Kit (Web, iOS, and Android)
• The Design Asset Repo

The Canvas Design Figma libraries contain visual copies of Canvas’ UI elements that can be copied and reused to create high fidelity product mockups. These designs can be implemented in products using Canvas Kit, which contains code components found in the Canvas Design Figma libraries that can be imported into applications. The Design Asset Repo contains the web code equivalent of Canvas assets (icons and illustrations) that can also be used to implement Canvas assets in code.

Canvas Champions

This is an initiative whereby Workmates outside of Canvas spend a period of time working with the Canvas team for a period of time in order to get a better understanding of how Canvas works. This is generally seen as a positive initiative for both parties to increase empathy and understanding of different areas.

Canvas Kit

Canvas Kit (CK) refers to the open-source, reusable web code library for Canvas, Workday’s design system. Canvas Kit represents Canvas tokens and components in code formats, allowing product teams to simplify Web UI development with pre-built and customizable UI elements.

Canvas Kit (CK) is generally synonymous with Canvas Kit React (CKR). We also offer a CSS library (CKCSS), but it is no longer actively supported.

Canvas Kit Labs

While we iterate on a new web component’s API, functionality and accessibility, sometimes we want to make it available to consumers ASAP. If we introduced the web component normally, this could result in many breaking changes to our codebase. To avoid this, we have introduced Canvas Kit Labs as a place to incubate components.

Canvas Kit Preview

Canvas Kit Preview is similar to Canvas Kit Labs; however, Canvas Kit Preview is for web components that have had a full design and a11y review, so they are approved for use in product. The API’s and/or underlying architecture could still be subject to change, but not without strong communication and migration strategies. Essentially, Canvas Kit Labs is for alpha components and Canvas Kit Preview is for beta components.

Code Library

This refers to libraries of code for a particular area. Canvas Kit is an example of a code library. Many teams within Workday have their own versions of Custom Code Libraries too. This is generally synonymous with “code repository”

Components

The building blocks or UI pieces of our Design System. Components should be generic and intended for reuse in multiple applications. They are typically composed of Tokens, Assets, and/or other Components. There are four types of Components based on varying levels of complexity.

For more information on how mobile components are composed, please refer to the Mobile Contribution Guide.

Primitive Component (Web)

Lowest-level component abstraction, rarely used on its own.

Examples: Box, Flex, Stack, SVG

• Flexibility: High
• Complexity: Low
• Structure: Low
• Size: Small

Note: These are technical entities generally not represented in Figma.

Level 1 Components (Web)

Composed entirely of Tokens and/or Assets. Only supports one type of function and interaction.

Examples: Button, Text Input, Count Badge, Status Indicator, List

• Flexibility: High
• Complexity: Low
• Structure: Low
• Size: Small

Level 2 Components (Web)

Composed of 2 or more Level 1 components. Serves 1-2 primary functions and whose interactions are considered simple.

Examples: Action Toolbar, Breadcrumbs, Tabs, Page Header, Side Panel

• Flexibility: Medium
• Complexity: Medium
• Structure: Medium
• Size: Medium

Level 3 Components (Web)

Composed of Level 1 and Level 2 components. Can support a number of interactions which can be complex and varied.

Example Rich Text Editor

• Flexibility: Low
• Complexity: High
• Structure: High
• Size: Medium-Large

Compound Components (Web)

Compound components is a pattern where higher level components are composed using smaller sub-components. This allows you to retain access to all the semantic elements of the higher level component. The paradigm makes compound components extremely flexible so they can be reused or adapted for many use cases.

A compound component contrasts with a “configuration component”, which instead is configured from a single interface. Configuration components are essentially a “black box” that offer little flexibility if the API/props do not offer the functionality you need.

Here are the parts of a compound component:

• Container component
• Sub-components
• Shared model (optional)
• Behavior hooks (optional)

Composability

We refer to this as a method of building Web UIs from individual building blocks. This method empowers developers to craft UIs without being limited by the shipped capabilities of components. Composability is the foundation of “Compound Components”. The tradeoff is that composability may require a bit more effort/code in exchange for flexibility, compared to large configuration components which either offer very specific functionality or are very complex.

Configuration

We refer to this term as a method of building Web UIs that relies on a finite number of configurable parameters. UIs can be quickly, reliably, and predictably built this way without a lot of expertise. However, the tradeoff is that new functionality relies on adding configuration options. This needs to be done by refactoring/adding to the component itself. Expanding the API surface area like this can quickly make components unwieldy.

Consulting

Refers to guidance and advice provided by members of the Canvas team to product teams working with Canvas. These engagements are generally lighter touch, within a defined amount of time or for a particular project.

Custom Team Library

These can be made up with existing Canvas building blocks — Canvas tokens and Components, so they are in keeping with the styling and behaviours that we see throughout Workday products. Organizing your custom components into a product specific Figma library gives you the power to make updates from a single source of truth and have them roll out across dozens of screens and flows easily.

Check out the Customizing Canvas section for more information.

D-G Terms

Deprecation

Deprecation warnings are added to utilities or components that are marked to be removed at a later date. Canvas utilities and components are typically deprecated when a more stable and updated version of that utility or component exits. Although Canvas users can still consume this code while it is deprecated, it is recommended to move to a new utility or component that is more stable.

Design Library

A file of reusable Styles, Assets, and/or Components built and published in Figma. Ideally, Design Libraries have a Code Library counterpart.

The Canvas Team maintains four Figma Libraries:

Canvas Tokens Library

This library contains the core styles of our Design System. Use this library to access all of our predefined Color, Type, Depth, Spacing, Layout, and Line styles.

Canvas Assets Library

This library contains all the asset and brand elements within our Design System. Use this library to access all of our Brand Elements, Icons, and Illustrations.

Canvas Web Library

This library contains all the web components within our Design System. Use this library to access all our web components.

Canvas Mobile Library

This library contains all the mobile components within our Design System. Use this library to access all our mobile components.

Design System

A collection of reusable UI elements (tokens, assets, components) and their code counterparts, built using a set of design principles and guidelines. The UI elements provided by a design system are flexible enough to be implemented in a variety of use cases, allowing product teams to quickly build and scale. Design systems can also include guidelines around content tone, branding and accessibility requirements to help teams build cohesive products embedded with an organization’s design philosophy and strategy. Canvas is Workday’s Design System.

Design System Engineering (DSE)

Design System Engineering, is a team in the Canvas organization. Its responsibility is to develop Canvas Kit and support the organization in using it.

Extended Systems

An Extended System is a custom library of components and patterns built with Canvas building blocks, which lives outside of Canvas Kit. These are generally created, documented and maintained by the team who creates it. The components in the official Canvas design libraries and Canvas Kit code repository have been created to be as universal, flexible and scalable as possible. This means they can be of most value to the most amount of teams using them.

Extended Systems may have been created for a variety of reasons, usually to serve a more tailored, specific experience in a product area or for a technological need. New custom components should be composed using Canvas tokens and components where possible. These can be simple components (generally more shareable) or highly tailored components (generally less shareable).

Read the Extended Systems documentation for more info.

Figma

The interface design tool we use at Workday. Also home to all Canvas design libraries that depict Canvas-kit tokens, assets, and components to be used in your design solutions.

Figma Workspaces

Canvas Design creates and maintains a number of different workspaces in Figma. For more information check out Canvas Spaces.

GitHub

GitHub is a web-based version-control and collaboration platform for software developers. Canvas Kit uses GitHub.com (public) to update and maintain the Design System in a centralized and organized way. Most Workday code repositories are on GitHub Enterprise (ghe.megaleo.com).

Google Web Toolkit (GWT)

GWT is a library and framework for building Web UI Applications in Java which compiles into browser-ready javascript. Workday uses GWT to drive the metadata application rendering. This is sometimes used interchangeably with UI-HTML. This approach is the “legacy” way of doing things, as more and more of the platform is rendered with React.

I-R Terms

Intake

This refers to the process of other teams requesting or proposing changes or additions to Canvas assets and components. For more information see Canvas Contribution

Internationalization

This refers to the design of UIs that enable it to be adapted (localization, l10n, although sometimes used interchangeably) globally. Also referred to as i18n (i with 18 letters in between followed by n).

For more information, check out our Globalization docs

Input Modality

Modality refers to how a user interacts with a device. Checking modality implies the system is checking if a user is using a mouse and keyboard, or using their fingers to swipe, touch, and zoom. This can also check if they are using a stylus, voice control, or other accessible devices. Knowing modality can help Canvas build more custom or natural experiences for users based on how they’re interacting with our components.

Native Mobile

Native Mobile is a term used when referencing the building of apps or screens using development languages exclusive or “native” to mobile devices. For example with iOS, this would be a page built using Swift, a language specific to building applications for Apple hardware. This term applies to any instance where the language used to build an application or component is specific to that software or platform in mobile operating systems, hence a “native mobile” component.

NPM Module

A set of Web Components and Styles managed in a central repo that is published on NPM for many teams/files to use. This is how Canvas Kit modules are distributed for consumption.

Patterns

Abstract guidelines to classify and document reusable solutions built to respond to common user scenarios. Following these guidelines allows us to design experiences that feel consistent and natural for users as they move between applications and ensures that our approach aligns with industry standards.

Playgrounds

Playgrounds are an area in Figma where the Canvas designers experiment and iterate on new components and patterns. These are separate from the main libraries of Canvas so that experimental work is not confused with what’s generally available. Playgrounds can also be created and maintained at a product team level.

Princess

Princess is the name of Workday’s metadata rendering framework. Often analogies are drawn to an Operating System model — Princess is the operating system that facilitates component life cycle, user navigation, supporting intermixing components, and other low-level concerns. Comparisons are sometimes made between Princess and other popular frameworks, like React or Angular, but particularly with view-oriented frameworks like React in particular: they tend to complement Princess rather than conflict.

Although capable of being run as a standalone application, its most common usage is as a library brought in by ui-html to enable widgets built externally in any javascript framework (e.g. React) to be integrated into the mainline metadata app.

React

A JavaScript library built by Facebook for building interactive UIs. This is Workday’s de facto UI library. UIs not built with GWT (i.e. new UI) are built with React.

Repository

This term is generally used to describe where code lives at Workday as a product/project. At Workday, most code repositories live internally in GitHub Enterprise, but several live in BitBucket. Canvas Kit is one of the few projects that lives publicly on GitHub.com

Viewport Responsive Web

Responsive Web refers to monitoring the width of the screen and adjusts the page view accordingly. For example, cards can be displayed in a row or a column to accommodate a user’s viewport size. If a user is on a desktop viewport size, the cards will be displayed in a row. However, when the user’s viewport width reaches a point where it is too small to accommodate the cards in a row, those cards will be displayed in a column. Responsive Web is when the display adjusts according to the user’s view. Responsive Web designs are dynamic (not static or fixed) views of a page or application.

S-Z Terms

Sememe (Mobile)

A non-exclusive unit of meaning that a mobile UI component should convey. They are represented in code as English morphemes. They need to be clear, unambiguous, non-exclusive universal meanings.

Semantic Context (Mobile)

A set of Sememes (units of meanings) that some tokens of some part of a UI element might communicate to a user. A mobile component’s look/behavior is shaped by a set of Sememes.

Specs

The design specifications for how a component should be implemented by engineers. These specs encompass information about token usage, sizes, variants, accessibility, globalization, theming, etc.

Standard Tooling

This term is used to describe the tooling UI Platform provides to build web user interfaces through XO metadata rendering.

Storybook

The client development environment for our web UI Component library, Canvas Kit. Often used as a reference for what components are available in CK, and how they can be used. Anthology is the curated collection of Workday’s UI Storybook stories - a Storybook-of-Storybooks, if you will.

System Icons

The goal of a System Icon is to minimize the amount of text on the page, so the user can take action directly with visuals and less reading. Icons generally have multiple states, including: standard, hover, click, focus, active, and inactive. Icons shouldn’t be used to serve two purposes within the same page. They’re not configurable because each icon has a set color chosen for the environment or page where they live. View all System Icons

Taxonomy

This refers to the categorization system and naming conventions Canvas uses to organize the different types of components, tokens, assets and so on.

Task

A Task in Workday refers to a process built within Object Management Services (OMS) to accomplish something. Examples of tasks include changing your contact information, requesting time off, or marking an item in your inbox as read. Some tasks are intended to be run as part of the Workday service: running behind the scenes and keeping things running. Other tasks have a visual component to them, and are designed to be interacted with by an end user.

For example, a simple name change task might look like a Text component (representing the user’s current name) paired with a Text Input component, representing the new name a user can enter their value into. In traditional development terms, a visual task is probably most analogous to a Page. These tasks are supplied to the client to render as a series of components described to the UI using WUL.

A View Task is a specialization of a task that does not mutate data in the OMS. Once the data has been read from the task, there is nothing more to do. Due to this specialization, certain optimizations are often able to be made in regard to how memory and state is handled when running the task, and how it is handled afterward.

An Edit Task is a specialization of a task that creates a change in the data stored in the OMS. When pushing data back into the OMS, there are a couple things to consider. First, the OMS is stateless, and therefore each interaction with the OMS must include the full state of the operation being performed. Second, the protocol as exists today for interacting with the OMS dictates that the full data represented by the task must be provided back to the OMS (missing data is considered deleted).

Combined with the fact that OMS tasks can easily encompass large amounts of data, middle-tier services (notably UIS) exist to be the state management system while the user interacts with an edit task. The state management system is valuable both for offloading large amounts of data from clients, but also for handling failures when the data fails to pass application developer validations on user input, useful data transformation, and other goodies.

UI Solution

A term we use to describe a reusable solution when defining patterns. The term is often synonymous with Components. It is typically used when recommending specific Components to designers when they are curious about higher level patterns.

WebView

WebView refers to the instances when native mobile devices are browsing apps or pages built using web development tools such as React. WebView for Canvas usually implies building mobile friendly React components that work for both mobile and desktop devices.

WD-Components

WD-Components (WD-C, or WDC) is a React-based library built on top of Canvas Kit that provides components for use in the Workday application. Generally, these components are opinionated compositions of Canvas Kit components that are specific to the Workday product.

There are no plans to open source this project, so it can contain a mixture of:

• Proprietary interactions that we don’t want to release publicly (competitive advantage),
• Legacy components we must support that we want to exclude from the design system/public offering
• Compositional components and patterns (groupings of components to reduce duplication that are not a fundamental part of the Canvas Design System)

For more information about how WDC and Canvas Kit relate to one another, check out this section in the FAQ.

Workday Extend / Workday Cloud Platform

Workday Extend (formerly Workday Cloud Platform) is an initiative to expose functionality of Workday via web APIs that allows both internal and external developers (customers, implementers, etc) to extend the Workday web application, or build applications that integrate with Workday. They not only utilize the REST endpoints outside of the Workday application, but also extend Workday by customizing and adding new features to the application itself.

Workday Private Cloud

Not to be confused with WCP, Workday Cloud Platform, Workday Private Cloud is a web deployment mechanism that allows for services to virtually provision the resources they need. It is built on top of OpenStack.

Workday User Language (WUL)

WUL, or the Workday User (Interface) Language, is the communication protocol that occurs between the web client and server(s). It is effectively a way to provide data and a tree of components to the client so that it knows what to render and how to behave. Due to the large breadth of application surface area Workday covers, it is extremely infeasible to develop full applications for each individual task that can be done. Aside from the massive amount of duplication that would naturally occur from development at that scale (both in terms of code and process), the cost of refactoring such a large application would be prohibitive to innovation and iteration.

Instead, a process was developed in which rules, layout, and data are sent down to the Workday clients and honored by the WUL (metadata) renderer. By defining what application developers can build as metadata, a relatively small set of rules and components (roughly three hundred components of various complexity) can scale out to hundreds of thousands of application tasks. An interesting side effect of the metadata rendering system is that it causes all domain-specific logic to exist entirely within XpressO: the clients never know whether they are rendering an expense report, a student course calendar, or a financial bank statement. The analogy is often made that our metadata renderer is more like an operating system or a browser than your traditional client application.

WUL may be replaced by the Workday Data Language (WDL) in the future. This is currently under development.

Xpresso (XO) & YP

XpressO and YP are Workday’s proprietary application development programming languages. These are form based experiences to control how data/metadata is rendered for most Workday tasks. All UI elements available to XO/YP developers must be manually added to the UI-Platform - they cannot directly consume Canvas Kit.