Dock
The dock allows users to launch various “services” on Procore pages.
Think of services like plugins that extend the existing Procore experience. These services might let users message a colleague, or import & export data from other tools. Some services are tool-specific, while others apply everywhere in Procore.
The dock functions much like the dock on your computer or phone, allowing users to switch between services and multitask.
Think of services like plugins that extend the existing Procore experience. These services might let users message a colleague, or import & export data from other tools. Some services are tool-specific, while others apply everywhere in Procore.
The dock functions much like the dock on your computer or phone, allowing users to switch between services and multitask.
Anatomy
In the dock, services are grouped into one of three categories, delineated by a divider.
Contextual Services
These services only apply to one tool or page, and are typically not visible in the dock by default. Instead, they’re added to the dock when the user clicks a button or other element on the page. These consist of tool-specific, or contextual, actions, like adding an entry to a list. If your tool has a contextual panel, it will need to be updated to coordinate with the dock.
First Party Services
These services are created in house by Procore, and include features like Conversations, Workflows, etc. These services often apply to a collection of tools, or even globally in the case of Help/Support.
Third Party Services
These services are built by third party devs outside of Procore. They often interface with another company or product. For example, you might use one of these to import or export from various scheduling software.
Correct
Incorrect
Don't exceed 3-4 services per group, or 8 services total. Instead, use an overflow menu to shuttle services to and from the Dock as they are needed.
Each service within the dock contains the following:
Placement
The dock occupies the right side of the viewport, below the global header. When a user clicks on a service within the dock, a panel opens up, squeezing the page content.
Correct
Correct
Incorrect
Adding an inline dock must not break the underlying layout of the page. This includes all permutations and states of the page, so be sure to test thoroughly!
Incorrect
If the page has an existing panel, don’t create a second panel. Instead, add the service contextually, as explained in Behavior.
Browser Scrolling
Scrollbars overlay on top of the dock and global header, and scroll the entire page. When the page scrolls, the icons within the dock stick to the top.
Correct
The page should scroll at the browser level
Correct
Service icons are visible even when at the bottom of the page.
Incorrect
The page shouldn’t scroll to the left of the dock, and the dock should not live next to the global header.
Behavior
When hovering over a service, a tooltip appears containing the name of the service. This tooltip will wrap onto multiple lines if needed.
Counts
Services may use a pill for unread messages or items requiring the user’s attention. This count truncates at 99+.
Service Indicators
When the user clicks on a service in the dock, the panel will open. While this is happening, the indicator within the service switches to the open state.
If the panel is closed or minimized with unsaved changes, or if a different service icon is clicked, the indicator next to that service may change to a running state. If there’s no data within the panel that the user is at risk of losing, then you do not need this state.
If the service is quit, or otherwise doesn’t have unsaved changes, the indicator disappears.
If the panel is closed or minimized with unsaved changes, or if a different service icon is clicked, the indicator next to that service may change to a running state. If there’s no data within the panel that the user is at risk of losing, then you do not need this state.
If the service is quit, or otherwise doesn’t have unsaved changes, the indicator disappears.
Service Multitasking
If a user has one service open, and clicks to launch another, you have various options:
If the first service has unsaved changes, you can set its indicator to running.
If their unsaved work is minor or easily replicated, you can remove the indicator.
If there are no unsaved changes, you can clear the indicator.
If a service has unsaved changes, you can show a modal when the user attempts to navigate away from the page prompting them to save - more info in the Unsaved Changes section.
You should not use a modal or similar to prevent the user from switching freely.
If the first service has unsaved changes, you can set its indicator to running.
If their unsaved work is minor or easily replicated, you can remove the indicator.
If there are no unsaved changes, you can clear the indicator.
If a service has unsaved changes, you can show a modal when the user attempts to navigate away from the page prompting them to save - more info in the Unsaved Changes section.
You should not use a modal or similar to prevent the user from switching freely.
Example of service switching within the dock.
Contextual Panel Services
If a page or tool uses a panel for anything, especially a panel catered to a specific task that only appears on a button click, the service icon will need to be added to the dock.
This involves complex a rewrite of the UX behavior to accomodate the panel living in the dock and avoid edge states, namely because users must be able to switch from the panel to another service at any time. At a high level:
When the user triggers the contextual panel, add a new service to the top of the dock, within its own category. Ensure its indicator is running.
If the user attempts to close the panel with unsaved changes (like partially filled form data) save/minimize its contents and set the contextual service to running.
If the user clicks on a different service in the dock, save/minimize its contents and set the contextual service to running.
If the user saves the contextual panel, remove the service icon from the dock.
If the user cancels the panel, confirm with a modal. If they truly want to lose their work, remove the service icon from the dock.
This involves complex a rewrite of the UX behavior to accomodate the panel living in the dock and avoid edge states, namely because users must be able to switch from the panel to another service at any time. At a high level:
When the user triggers the contextual panel, add a new service to the top of the dock, within its own category. Ensure its indicator is running.
If the user attempts to close the panel with unsaved changes (like partially filled form data) save/minimize its contents and set the contextual service to running.
If the user clicks on a different service in the dock, save/minimize its contents and set the contextual service to running.
If the user saves the contextual panel, remove the service icon from the dock.
If the user cancels the panel, confirm with a modal. If they truly want to lose their work, remove the service icon from the dock.
Unsaved Changes
If the user leaves the page with unsaved changes in any service, you have the option of displaying a modal to prompt them to save.
Clicking “Continue Editing” takes the user to the first unsaved service within the dock.
Not every service needs to do this, but for critical information that the user could lose we recommend display this modal. Ask yourself if the annoyance of showing a modal and inhibiting leaving the page is better or worse than the user having to re-enter their data.
Some services might even have data that can persist as the user navigates around Procore. In those cases you don’t need to do this either - only when there’s a risk they will lose their work.
Use your discretion, and as always keep the user in mind.
Not every service needs to do this, but for critical information that the user could lose we recommend display this modal. Ask yourself if the annoyance of showing a modal and inhibiting leaving the page is better or worse than the user having to re-enter their data.
Some services might even have data that can persist as the user navigates around Procore. In those cases you don’t need to do this either - only when there’s a risk they will lose their work.
Use your discretion, and as always keep the user in mind.