Design Language

Buttons

Applications built on VertiGIS Studio Web technology have many button variants and options available but VS Web does not use all of the available options. To simplify the choices, VS Web uses three basic types of buttons. They are based on the level of emphasis required for the task. There are 'Low', 'Medium', & 'High' emphasis buttons.

Usage

As a general guideline there should only be one High emphasis button per view. Typically buttons are used at the end of forms used in pairs, such as “Submit” and “Cancel”. Usability best practices state that the user should always have the ability to safely exit a task so it is always recommended to have a 'Cancel' button available.

Depending on the purpose of the button you can use combinations of a High Emphasis and Medium Emphasis button, two Medium Emphasis buttons, or a Medium and Low Emphasis buttons.

Primary action is emphasizedBoth buttons of equal importanceSecondary action is less important

Developer notes:

Low Emphasis buttons consist of MUI Text Variant buttons using the 'Primary' colour
Medium Emphasis buttons consist of MUI Outlined Variant buttons using the 'Primary' colour
High Emphasis buttons consist of MUI Contained Variant buttons using the 'Primary' colour

Visit the Developer Center for more details for implementing buttons

Action Button Order and Alignment

The primary action (eg: Save, Apply, etc.) must be the first button in the hierarchy of buttons. In the context of a form, it should be the first thing a keyboard user will tab too after filling in all of the form inputs. The secondary action (eg: Cancel or Back) button follows after the primary action in the tab order.

As a general guideline, forms with labels and inputs stacked on top of each other (as in most VertiGIS Studio applications) it's better to align your buttons with the start of the content. That means left-aligned in most languages and right-aligned in RTL languages. The close proximity of the buttons to the form inputs and labels allows the eye to simply follow the natural flow down the page to find the submit action. This is especially true when using large screens where your form input and action buttons potentially end up on opposite sides of the screen.

Example of form action buttons aligned to the start of the content

Buttons aligned with the labels and the start of the content

Example of form action buttons aligned to the end of the content in a dialog

Buttons aligned to the end of the dialog

If the form is in a dialog then the common practice is to place your action buttons at the end of your content (right-aligned for most languages and left-aligned in RTL languages). The smaller contained space of a dialog creates a natural ending place for your eye to flow to at the end of the content area.

Small screens and mobile devices can also use center-aligned or full width action buttons to help draw attention to the primary action and to reduce the distance you have to reach with your thumb or finger to tap on a button.

When deciding if your form button alignment should be to the left or right, it's important to consider the specific context and user needs when designing a form. Conducting user testing and gathering feedback can help ensure that the button alignment aligns with user expectations and improves usability. If you're still unsure, then the default fallback position should be to align the buttons with the start of your content (left-aligned).

Button Labels

Always attempt to use concise, descriptive, and actionable labels with three or fewer words for buttons. Verbs are ideally suited for buttons to prompt the user to perform the desired action. Button labels must use 'Title Case' where each main word has the first letter capitalized.

Don't

Sizing and Spacing

Sizing of buttons are set to "small", "medium", or "large" by using the "size" prop on the button. The width of a button will automatically adjust to the length of the content (icon and/or label).

Padding within the button should not be altered or over-ridden in CSS as the padding is pre-set in the Design System so that buttons can participate in the system wide density settings. Margin around buttons should be controlled by the parent component. The parent component is responsible for the spacing around child components (like buttons), positioning, flow, and sometimes the size. Please refer to the Developer Center for more information on presentation attributes.

Additional Options

Icons can be added to buttons for added emphasis or to help convey the purpose of the button. For added visual style flexibility, you can choose to use the "round" style to create circle or pill shaped buttons. You can also choose to have a button with only an icon and no text.

Icons can add additional emphasisIcons can be place at the start or the end of a buttonUse the "disabled" property to block the user from clickingRound style buttons

Form Design

A properly designed form allows people to quickly enter values in a logical order and in a manner that makes sense to them. This requires fields to be flexible when interpreting the user's input.

Labels

Are easily interpreted.
Located on top of or to the left of most fields.
- Labels on the top is better for internationalization and long strings.
Usually appear to the right of check boxes and radio buttons.
Ensure there is not too much space between the label and it's associated field so that it is clear which field goes with the label.

Fields

The length of text fields should suggest the amount of data that should be entered.
Ensure that there is not too much space between fields so that nothing gets accidentally overlooked.

Links/Buttons

Primary actions should be clear and obvious.
Secondary actions are for more discrete actions.
Multi-step and complex forms should have all other navigation removed.
- Back links should be included for easy corrections in multi-step forms.
Include a Cancel link to provide a safety net for users to escape the form.

Error Messages

Provide clear and constructive error messages.

Do's and Don'ts

Don't require unnecessary input.
Allow people to undo actions where appropriate.
Require confirmation for (important) irreversible actions.

Keyboard Use

Do not force users to frequently switch between the keyboard and mouse.
Correct tab order is set up.
If possible, avoid drop-down lists where typing is quicker.
- Auto-complete or auto-suggest is very beneficial.

Be Helpful

Be flexible when interpreting the values that users enter.
- Eg: when entering a phone number, accept both no-spaces and dashes.
Help users check the information they've entered before submitting.
- WCAG 3.3.4 requires error prevention for legal and financial data so that it is reversible, checked for errors, and confirmed.
If possible, provide confirmation or error information where the user's attention is currently via immediate inline feedback.
If possible, try to avoid multiple columns for form layouts. This increases the likelihood that something in the right column will be missed.
- Usability testing ^{[1] [2]} has shown that multi-column forms do not perform as well as single column layouts.
Remove any unnecessary distractions and links that competes with and takes the users attention away from the form they are filling out.

Icons

Where can I find the Icons?

Our master repository of icons, consists of over 600 pre-created icons ready for use in our icon package. Instructions on how to install packages can be found in the Developer Center. We store all our icons in this online repository, in several formats (png, svg, pdf). The .svg format icons are comprised of compound paths, black #000000), and an artboard of 24px by 24px. They have been stripped of all unnecessary meta info and optimized using the SVGo optimization script included in the repo.

How do I use icons in my app?

Instructions for using either built in icons, or your own, can be found in the Developer Center.

How do I create a custom icon?

When creating our icons, simplicity is key. Since we are working with a canvas of only 24px x 24px, every design provided must be concise and communicate the idea clearly, and easily. Fine details are less important than trying to ensure that shapes stay recognizable. Information regarding this process is available in the Developer Center.

Style

The visual language of our icons should be consistent, creating a harmonious appearance across all of our products:

All icons must be made using a single color (black), with negative space being transparent.
When employing linework, trying to maintain at least 2 pixels in width, with an equal amount of white space allows the designs to remain clear when viewed at 100%. This guideline is flexible however, depending on what elements are used.
Modifiers must be placed in the bottom right of the icon, with a border of 2px of empty space outlining it.
Simplistic, clear, and simple designs are preferable to complicated patterns.
The visual loudness of the icon should convey its importance, but not overpower other messages surrounding it, including the written identifier.

Available Icons

Accessibility

AccuracyOff

ActionMenu

Activate

Add

AddIntersectingVertex

AddToDrawLayer

Address

AddressSearch

AdjustHeight

AfterActionPlayback

Alarm

AlarmAdd

AlarmClear

AlarmDisabled

AlarmInfo

AlarmNone

AlarmNotifications

AlignToEdge

ArcgisSave

ArcgisShortcut

Lists and Menus

Lists come into use in many aspects of our products: Feature Details, Search Results, Building information, and many more. No matter what needs to be displayed, if it falls into a list like quality, then a list should be used. Examples of different utilizations of the list element are below.

Simple List

Line item 1
Line item 2
Line item 3
Line item 4

The most straight forward of implementations. This simple list view can include text, or text and icons. The selected item's highlight will consist of the primary theme colour, as well as a gradient grey. If tabbed to, you can use your up + down arrow keys to navigate the list.

Nested List

Menus are used to group additional commands for components that are not worth displaying in a more prominent visual manner, or that simply don’t belong anywhere else in the interface. Menu items consist of a single line of text to indicate what function will be triggered when the item is clicked. The hover state for menu items is built in an identical fashion to those used in list items (See above). A colored bar is added to the left side, and the background receives a gray gradient to white.

Pinned Subheader List

States

A few guidelines should be followed to ensure that the list element looks uniform, and fit within the application properly.

Hover

When a hover state is triggered, it cannot just rely on a colour change. There also must be a state change that shows the differentiation. For example, in our programs, there is a background colour change, as well as the addition of a side border colour. Hover states always include a styling change, and the background colour will get a gradient.

Focus

Focus indicators provide an easy way to identify currently active elements, against the rest of the design elements. Focus states must be unique from the hover state to make them distinct when using a keyboard for navigation. Focus states have a triple border design, so that regardless of the background they are implemented on, they will always be visible and easy to identify.

Selected/Active

Selected and Active states for list elements should showcase similar behavior to the hover state. They must show that they are currently active, and visually distinct from the rest of the list elements.

Loading and Progress Indicators

Multiple options are available to denote a loading state, the "3 dot loader", "skeleton", "circular", and "progress bar". These are indeterminate (unspecified wait time) indicators with determinate (known wait time) options for "circular" and "progress bar".

The 3 dot loader, indeterminate only, is used when loading large areas such as an initial app launch.
Circular indeterminate, used when loading large areas or areas with unknown content.
Circular determinate, used when loading areas where progress can be measured and it provides value to the user.
Linear indeterminate,

Skeleton (indeterminate)

This loader can be customized to display a placeholder of incoming content for example, a block of text or a results list. When using this method it is advisable to create a simplified layout, just enough to give the user an idea of whats coming. Skeleton helps improve perceived responsiveness. Read more about skeleton in the MUI docs.

Consider using Skeleton to:

Display small portions of incoming content that can be represented with basic geometric shapes.

3 Dot Loader (indeterminate)

Use this when loading large areas such as during the first load of an app.

Consider using the 3 dot loader for:

Large blocks or regions of a layout that are loading.
If the incoming content is of unknown size, shape, or layout.

Loading bar (indeterminate)

Typically used during the first load of an app. Placed at the top of the page as an overlay to not affect component positioning. Color is determined using the app's primary color.

Tabs

Normal Tabs

Scrollable Tabs

Icon Tabs

Indicator Color Tabs

Vertical Tab

Panels

Using Panels in our application affords the user a good deal of information all contained in an easy to view place. Most information can be placed within a panel. Panels are designed with a minimum width of 365px so that they work on smart phone screens as well as larger tablet and desktop displays. The user can resize the panels with the provided drag handles. For full information regarding panels, refer to the Developer Center.

Panels come with an assortment of configurable navigation controls:

Maximize: This button will extend the content of the panel to fill the entire view width.

Minimize: The minimize button will collapse the panel down fully. It is expandable again by click the ‘Restore to Original Size’ button that replaces minimize.

Back Button: Navigates you to the previous panels content.

Close Button: Closes the panel entirely.

Examples

Dialogs

Occasionally, there will be a need to display information, warn the user, or present controls in a manner that needs to utilize a more focused interface. Modal dialogs provide a flexible layout strategy to allow the user to put any content they want before the user and draws their focus to it, setting the rest of the app into a non-interactive state until it is dismissed. This allows important information to be displayed, and preserves the background information.

Examples

Additional information regarding modal alerts can be found in the Developer Center.

Alerts

Dialogs are a good method of presenting alerts to the user, since they allow information that is relevant to a state change, or problem, without navigating away, or impacting the information within the app. This can include, but are not limited to:

Destructive actions that would otherwise destroy information that has been altered.

Alerts must always preface the problem, and offer the user the ability to dismiss, edit, or disregard the problem in question.

Notifications

Notification appear in a non-invasive manner. They can be configured to either dismiss automatically, require the user to dismiss, or not be dismissable at all.

There are four types of notifications available to use:

Care should be taken when choosing to use a notification as too many notifications can annoy users by being overused.

For full information regarding panels, refer to the Developer Center.

Typography

Good typography plays a large role in creating not only an aesthetically pleasing app but a usable one. It is essential that style guidelines and semantics are followed as they ensure consistency across our suite of applications. For example, by keeping headings and body text at predefined sizes makes it easier for developers to implement. There is no guessing required as to which size an H1 should be. Users working with our applications will instantly know they are using a VertiGIS app simply but the way it looks (and behaves).

Type Scale

h1. Heading (2rem/32px, weight: 300)

h2. Heading (1.625rem/26px, weight: 300)

h3. Heading (1.375rem/22px, weight: 200)

h4. Heading (1.25rem/20px, weight: 400)

h5. Heading (1.125rem/18px, weight: 300)

h6. Heading (1rem/16px, weight: 600)

subtitle1 (1rem/16px, weight: 400, letter-spacing: 0.00938rem). Lorem ipsum dolor sit amet, consectetur adipisicing elit. Quos blanditiis tenetur

subtitle2 (0.875rem/14px, weight: 600, letter-spacing: 0.01071rem). Lorem ipsum dolor sit amet, consectetur adipisicing elit. Quos blanditiis tenetur

body1 (0.875rem/14px). Lorem ipsum dolor sit amet, consectetur adipisicing elit. Quos blanditiis tenetur unde suscipit, quam beatae rerum inventore consectetur, neque doloribus, cupiditate numquam dignissimos laborum fugiat deleniti? Eum quasi quidem quibusdam.

body2 (0.75rem/12px). Lorem ipsum dolor sit amet, consectetur adipisicing elit. Quos blanditiis tenetur unde suscipit, quam beatae rerum inventore consectetur, neque doloribus, cupiditate numquam dignissimos laborum fugiat deleniti? Eum quasi quidem quibusdam.

Caption text (0.875rem/14px)

Font Stack

Our current font stack is "Segoe UI, Helvetica Neue, Roboto, Helvetica, Arial, sans-serif". Segoe UI is installed by default on Windows. MacOS/iOS will take advantage of Helvitca Neue and Roboto is Android's default font. Font sizes rely on the browser default font-size of 16px. This value should not be changed.

Headings

Headings are the largest text on the screen and are used for titles. They help organize content and demonstrate importance using a hierarchy that ranges from 1-6. For more information regarding headings and the best practices for usage please refer to W3C and MDN Web Docs.

Considerations when using Headings

Multiple H1 on a page is not considered best practice. Reserve for app title or to describe the content of a page.
Do not alter the size, style, and weight of headings using CSS or HTML tags.
Always choose a heading based on the hierarchy of the content and not on the heading's size.

Example of Headings, Subtitles, and Body1 in Studio Web

Subtitles (1 & 2)

Smaller than headings, used for medium-emphasis. Usually paired with a heading to enhance context. 2 sizes are provided.

Considerations when using Subtitles

Avoid using subtitles as a replacement for body text.

Body (1 & 2)

Use for long-form text (paragraphs). Emphasis can be added using standard HTML tags, for example strong and em. 2 sizes are provided.

Considerations when using Body

Should never be used in place of a heading.

Caption

Typically used for annotating images.

Considerations when using Captions

Avoid using captions as a source of small/italicized Body text.

Buttons​

Usage​

Developer notes:​

Action Button Order and Alignment​

Button Labels​

Sizing and Spacing​

Additional Options​

Form Design​

Labels​

Fields​

Links/Buttons​

Error Messages​

Do's and Don'ts​

Keyboard Use​

Be Helpful​

Icons​

Where can I find the Icons?​

How do I use icons in my app?​

How do I create a custom icon?​

Style​

Available Icons​

Lists and Menus​

Simple List​

Nested List​

Pinned Subheader List​

States​

Hover​

Focus​

Selected/Active​

Loading and Progress Indicators​

Skeleton (indeterminate)​

3 Dot Loader (indeterminate)​

Loading bar (indeterminate)​

Tabs​

Normal Tabs​

Scrollable Tabs​

Icon Tabs​

Indicator Color Tabs​

Vertical Tab​

Panels & Panel Navigation​

Panels​

Panel Navigation​

Examples​

Dialogs​

Modal Dialogs​

Examples​

Alerts​

Notifications​

Typography​

Type Scale​

h1. Heading (2rem/32px, weight: 300)

h2. Heading (1.625rem/26px, weight: 300)

h3. Heading (1.375rem/22px, weight: 200)

h4. Heading (1.25rem/20px, weight: 400)

h5. Heading (1.125rem/18px, weight: 300)

h6. Heading (1rem/16px, weight: 600)

subtitle1 (1rem/16px, weight: 400, letter-spacing: 0.00938rem). Lorem ipsum dolor sit amet, consectetur adipisicing elit. Quos blanditiis tenetur

subtitle2 (0.875rem/14px, weight: 600, letter-spacing: 0.01071rem). Lorem ipsum dolor sit amet, consectetur adipisicing elit. Quos blanditiis tenetur

Font Stack​

Headings​

Considerations when using Headings​

Example of Headings, Subtitles, and Body1 in Studio Web​

Subtitles (1 & 2)​

Considerations when using Subtitles​

Body (1 & 2)​

Considerations when using Body​

Caption​

Considerations when using Captions​

Buttons

Usage

Developer notes:

Action Button Order and Alignment

Button Labels

Sizing and Spacing

Additional Options

Form Design

Labels

Fields

Links/Buttons

Error Messages

Do's and Don'ts

Keyboard Use

Be Helpful

Icons

Where can I find the Icons?

How do I use icons in my app?

How do I create a custom icon?

Style

Available Icons

Lists and Menus

Simple List

Nested List

Pinned Subheader List

States

Hover

Focus

Selected/Active

Loading and Progress Indicators

Skeleton (indeterminate)

3 Dot Loader (indeterminate)

Loading bar (indeterminate)

Tabs

Normal Tabs

Scrollable Tabs

Icon Tabs

Indicator Color Tabs

Vertical Tab

Panels & Panel Navigation

Panels

Panel Navigation

Examples

Dialogs

Modal Dialogs

Examples

Alerts

Notifications

Typography

Type Scale

Font Stack

Headings

Considerations when using Headings

Example of Headings, Subtitles, and Body1 in Studio Web

Subtitles (1 & 2)

Considerations when using Subtitles

Body (1 & 2)

Considerations when using Body

Caption

Considerations when using Captions