Developers seeking approval for their institutional data product must meet the standards outlined in this document. These guidelines apply whether the report is published on our hosted servers or on public platforms.

Role of Data, Academic Planning and Institutional Research (DAPIR) 

For the purposes of authorizing workbooks, enforcing standards, and maintaining organization of the server, the Data, Academic Planning and Institutional Research (DAPIR) will review and approve all Tableau workbooks for the enterprise. DAPIR also serves as the first point of contact for troubleshooting Tableau Server issues and for interacting with UW System Administration on Tableau Server.

Role of Data Stewards

Under UW-Madison’s Institutional Data Policy, Institutional Data Stewards authorize access to institutional data and have broad responsibility and authority with respect to maintaining a quality institutional data environment. Data Stewards review enterprise Tableau workbooks and determine the appropriate access group or audience for each workbook prior to publication.

DAPIR does not proactively reach out to Data Stewards to complete their reviews. If you notice a workbook has not been reviewed in a timely manner (typically a week or more), then you should reach out to the stewards yourself. You can find the stewards still in review on the specification's Data Cookbook page.

Onboarding authorized developers and publishers

To develop Tableau workbooks for publication to the UW-Madison’s Tableau server and Tableau Public, you must be an Authorized Developer. If you are going to be publishing to the production folder on the server as well, you will need to be an Authorized Publisher. To request an Authorized Developer/Publisher role, fill out the following form: 

Tableau Developer/Publisher Request

and after it is approved, somebody from DAPIR will reach out to you. In the form, the requester agrees to comply with the standards and guidelines. Please make sure to review them before submitting a request.

The next step will be scheduling an onboarding session by DAPIR. 

After onboarding, Authorized Developers/Publishers will be given access to: 

• The development area (Staging and Templates projects) of the server. 

• If you are an authorized publisher, you will be added to the production project as well)

• Data Cookbook’s proper groups.

• Tableau Dev Community Team’s channels. 

• Tableau Dev Community email group

Setting up Tableau

Purchase a license 

Here is information on how to request a quote through AE Business Solutions: https://kb.wisc.edu/msndata/103217 

Download Tableau

Download the version matching our server’s version. You can find this information here:

https://data.wisc.edu/tableau/

The download links can be found on Tableau’s website here:

https://www.tableau.com/support/releases 

Add UW color palettes 

These palettes should be saved inside the preferences.tps file (usually, it is inside the “C:\Users\<your_user>\Documents\My Tableau Repository” folder). Here is how the preferences.tps should look like (you can copy it over the existing one): 

https://uwmadison.box.com/s/xchlzp8gklxo3br8izduikqgy3qskbk1 

Testing Tableau upgrades

UW Systems and AE Business Solutions process an upgrade on a biannually. We all play a role in making sure that upgrade goes smoothly. When the development server is upgraded and the upgrade has been communicated to the community, developers need to test their workbooks in the dev server. Here is a KB on testing process: https://kb.wisc.edu/msndata/111745 .

If everything goes well, then production will be upgraded. Look for related communications from our office.

Publishing or Modifying a Tableau Workbook

To publish a Tableau workbook:

1. An Authorized Developer should develop a workbook following the Tableau Visualization Standards section of this document. 

2. Once an Authorized Developer has created a workbook, the developer should publish the workbook in the Staging project of the Tableau server and provide access to any staff that will be testing and/or approving the workbook before publication. 

3. When the Tableau workbook is tested and ready for publication, follow instructions in the Cookbook Manual for Tableau Developers of this document to enter and submit publication information and start a review process. 

4. After approval, finalize publishing the workbook to the UW Madison Institutional Data project and cleanup if anything left over in Staging.

Standards and guidelines for publishing a Tableau workbook

Comply with all applicable internal and external policies, regulations and guidelines.

UW-Madison’s policies

The Institutional Data Policy can be found here:

https://policy.wisc.edu/library/UW-523 

Data Classification policy:

https://policy.wisc.edu/library/UW-504

Comply with any other applicable internal and external policies, regulations and guidelines

This includes section 508, FERPA, HIPAA and any other applicable internal and external policies, regulations and guidelines.

Follow UW Madison digital accessibility guidelines and best practices.

Organizations are required by law to follow accessibility standards. You can read more on section 508 here: https://www.section508.gov/manage/laws-and-policies

Pay attention to accessibility guidelines when creating the visualizations. When designing visualizations, consider color-blind and black-and-white printing (look at the Tableau Visualization Style Guide in this document for details).

There are accessibility tips in the following KB: https://kb.wisc.edu/msndata/111708 

Here is a good read on accessibility in visualizations at UW-Madison: https://it.wisc.edu/learn/accessible-content-tech/accessible-data-visualizations/ 

You can reach out to the office of accessibility with any questions you might have. Here is their website: https://accessible.wisc.edu/ 

Keep clear and up-to-date documentation 

Required components of documentation

Make sure the following required components are documented. They all have a corresponding field in the Data Cookbook. An overview of these fields are presented in Cookbook manual for creating a Specification section of this document:

Description

Explains what is in the reporting object. For example, "a summary of all budgets and year-to-date totals by department with grand totals provided at the school level."

Definitions

These include any term in the workbook that requires further explanation. These terms must be consistent across the organization. In the Data Cookbook, they are added under the “Definitions” tab.

Purpose

The specification's purpose is a description of why the reporting object is needed.

This might describe a business process that requires a specific report, a regulatory or other mandated requirement, or a specific user need that it fulfills.

Sources

Any data sources behind the workbook need to be listed. Also, the views if applicable. This information is gathered through the following fields in the Data Cookbook: “Data Systems” and “Other data sources”.

Owners

The owner is an optional attribute that may be used to identify a person or office users should go to if they have questions about the report’s contents. Either they created the report themselves or they have requested the report to be created on their behalf.

Security

Includes the permission groups and roles that need to be applied to the report. The corresponding fields in Data Cookbook are:

Access restrictions:  This field indicates any access restrictions for the specification. This field indicates what permission group(s) need to be set in Tableau.

Request url: This is the URL or email address to make an access request to the specification.

Classification: This field describes the overall data risk for the specification. More information is available here: https://data.wisc.edu/data-governance/data-classification/ 

You can find the details of existing groups and roles in the Tableau Permission Groups and Roles section of this document.

Refresh schedule

Specify the frequency and timing of data updates. Examples include (1) Data will not be updated. (2) Data are extracted on the tenth day of classes for each term and are typically updated in November for the fall term and March for the spring term. (3) Data is refreshed nightly for the current term but is frozen for completed terms. (4) Data is updated annually as the report is revised. 

Data classification

The presentation of data is classified under one of UW-Madison’s 4 risked-based data categories: https://data.wisc.edu/data-governance/data-classification/ 

The related policy and detail explanation of each classification can be found under Data Classification policy: https://policy.wisc.edu/library/UW-504 

The proper classification must be added to the Data Cookbook as well as the Workbook itself. The Data Cookbook specification template has a field for Classification. Refer to the Tableau Visualization Style Guide in this document to see how to meet this requirement in the workbook. 

Cookbook manual for Developers

For our documentation, we use the Data Cookbook. In addition, this tool allows us to track and save the governance process as well as necessary information. Every workbook must have a specification in Cookbook before it is published.

Updating existing specifications:

Open the specification and click the “Request a change” link below the title and make necessary changes if needed (there is an “Edit” button below the “Overview” tab) and add/remove necessary Definitions if needed (under the “Definitions” tab). Add a comment explaining the modification and the link to the workbook in Staging. Then start the review process by sending it to Data Governance (click the “Send to Data Governance” button on top right of the screen).

More descriptive step-by-step guide can be found here: https://kb.wisc.edu/msndata/117596 

Here is a KB on how to create and link definitions:

https://kb.wisc.edu/msndata/117575

Creating a new specification:

From the top menu bar, hover over “Specifications” > then from the opened menu, choose “Create a Specification”. Then fill out the “Create s Specification” form and make sure to include all information mentioned in the Required Components of Documentation section of this document.

There is a screenshot under the Index section at the end of this document that describes all the fields one by one.

When the specification is created, related definitions need to be added to the “Definitions” tab. If the definition doesn’t exist, you need to create a new one. 

Creating a Definition

Make sure there isn’t already an existing definition for the term. Here is a useful glossary tool: https://search.data.wisc.edu/glossary. The minimum information needed to create a new definition is:

• Name: Pick a proper name for the definition

• Functional Definition: The descriptive definition of the term

• Functional Area: These are the domains

The specification will be reviewed independently from definitions (if a definition isn’t approved yet, it does not hold the specification’s review and publication process).

More descriptive step-by-step guide can be found here: https://kb.wisc.edu/msndata/117596 

Here is a KB on how to create and link definitions:

https://kb.wisc.edu/msndata/111955

Conform to rules on branding and visual identity for a consistent, clean, and visually appealing look

• Use the UW color palettes. 

• Follow Tableau Visualization Style Guide in this document.  

• Our Templates already incorporated the style guide as well as best practices. Here is a KB on how to use the templates: ttps://kb.wisc.edu/msndata/111773

Tableau Visualization Style Guide

Before a data visualization is submitted to Data Governance for review for publication, the developer must ensure that the visualization meets the standards described in this document. These standards should be used for all dashboards to create consistency in look, usability, and functionality across the UW-Madison Tableau Enterprise Server and UW-Madison Tableau Public. However, there may be instances where deviations from standards are permitted. Variances from these standards may be requested from and granted by Data Governance. A justification for any deviation from standards must be added to the publication request.

General rules

• Apply accessibility compliance when creating the visualizations such as:

  • All images and icons must include alternative text.

  • A contrast ratio of at least 3:1 between adjacent colors is required. This contrast ratio must be maintained regardless of what color palette is used. Here are related guidelines: https://www.w3.org/TR/WCAG21/#non-text-contrast

  • If meeting the contrast ratio rule is not possible, use borders to separate adjacent components (KB on how to add borders).

  • Use the UW color palette.

  • Color should not be the only means of conveying meaning. In addition to color, shapes and/or other methods of differentiation should be used.

  • Summary data should be available for download.

• Make sure views and their components include necessary context, titles, captions, units, and commentary where applicable to help the audience better understand the data and visuals.

• Make sure views are user friendly, intuitive, consistent and pleasing to the eye.

• All multi-dashboard workbooks must include a navigation page with summary and table of contents, which link to the relevant dashboards. Notes:

• When there are two dashboards or less, the home page can be omitted.

• The home page can be omitted, when the visualization is embedded in a webpage which already has the summary and table of contents.

• Workbook must be published with the “Show sheets as tabbed” option enabled.

• All workbooks must have the link to user instructions that covers the basics of using a Tableau visualization. This is added under the “?” icon.

• All dashboards must identify the owner office of the visualization and contact information for questions about the visualization inside the footer.

• Extract only necessary data and use aggregations at the query level if possible.

• Embedded credentials must only use a personal account and not a service account.

• Start with one of our Templates. Here is a KB on how to use the templates: https://kb.wisc.edu/msndata/111773

Layout

• Different sheets on the same dashboard should be differentiated from each other. This can be achieved through adding borders, shading and/or spacing.

• All dashboards must be within the width of 1200 and height of 2500 maximum dimensions. Smaller dimensions must maintain proportionality of all elements.

Fonts

Comply with what is in the Templates (use any of the fonts prefixed with “Tableau” such as Tableau Regular, Tableau Light, etc.). Font size has to make sense to the purpose of the text (for example, titles vs normal texts). Text must be readable.

Titles

When appropriate, titles should be dynamic to represent current filter selections.

The navigation panel on home page

• Width can be up to 700px.

• Red arrow buttons in the container navigate to the corresponding dashboard. Instead of the red arrow button, text buttons can be used for the same purpose. 

• Technical Notes and How to use Tableau need to be on the navigation panel as well.

Filters and Parameters

Filters/Parameters can be placed either on top or on the side. They must be grouped based on their cascading effect:

• Parameters and non-cascading filters should be grouped together:

  • Use #b4b4b4 color second thinnest solid border around layout container.

  • Do not fill the background color.

  • Do not select “only relevant values.”

• If filters have a cascading effect (chained interactivity):

  • Use #b4b4b4 color second thinnest solid border around layout container.

  • Fill layout container with 33% #b4b4b4 color.

  • Select “only relevant values.”

• To avoid user confusion, if needed, a filter can be positioned near the viz that uses it. It still follows the cascading effect rule. And it should not cover any data part of the graph.

• If a legend applies to all views, place it in a layout container with filters.

• If a legend applies to one view, place it as close to view as possible.

Tooltip

Tooltips must use meaningful names (no standard Tableau terms or database field names). 

Footer 

Footer must include (left to right):

• Logo: must have an alternative text and navigates to: https://www.wisc.edu/

• Footer Text: Follows this wording: “This visualization was created by [Department]. Questions, feedback, or accessibility requests should be directed to [Full Name], [email@wisc.edu].”

• Data classification icons:

  • Internal data

The link to the information page for “Internal data” classification:

https://data.wisc.edu/internal-data/

The icon that needs to be used for “Internal data” can be found here:

https://uwmadison.box.com/s/fphq2qv6rgr1tdabt6111zcjolaiga60

• Public data

The link to the information page for “Public data” classification:

https://data.wisc.edu/public-data/

The icon that needs to be used for “Public data” can be found here:

https://uwmadison.box.com/s/9a47y9hfkq1811chg73bv0b3oawnslt0

• Restricted data

The link to the information page for Restricted data” classification:

https://data.wisc.edu/restricted-data/

The icon that needs to be used for Restricted data” can be found here:

https://uwmadison.box.com/s/lqwaklhf5fg3jsxyllc2fiphcodmmdme

• Sensitive data

The link to the information page for Sensitive data” classification:

https://data.wisc.edu/sensitive-data/

The icon that needs to be used for Sensitive data” can be found here:

https://uwmadison.box.com/s/qejax8mufwiyrbixd5a06ipwzets03bu

Axis

Axis labels must include units. Removing axis labels and values is only allowed when a lack of axis labels does not cause confusion.

Information Icon

• Links to technical notes and underlying data and definitions in the Data Cookbook.

• The icon’s image can be downloaded here: https://uwmadison.box.com/s/l55wuu9xmr2zosna9dinoiv77gehjx79

Help Icon

• Links to PDF with basic instructions on using a Tableau visualization at: http://data.wisc.edu/wp-content/uploads/How_to_Use_a_Tableau_Visualization.pdf

• The icon’s image can be downloaded here: https://uwmadison.box.com/s/adeeiszb3s1zm1510j1zftmvp06m4td7

Our templates meet these guidelines. Additionally, we have created dashboards that include notes on format specifics. These are a visual way of understanding style guide:

This is a link to a dashboard with notes on home page formats

This is a link to a dashboard with notes on dashboard formats

Submit their data product for review by the appropriate data steward to receive data classification and follow all associated access restrictions

We have a sophisticated governance process for our visualizations. Currently, we are using Data Cookbook to record the governance process. For every Tableau report, there must be one specification created. Please refer to Cookbook Manual for Developer section of this document. The following table illustrates the review process for specifications:

 

Review Exceptions:

Data Steward review will no longer be required for minor revisions of workbooks that do not change the way data is defined, collected, or presented. Examples of these changes include updating a workbook's data source to include a new year of data, transferring a workbook's owner to another developer, minor visual changes for accessibility reasons, and copy edits. If the change you are making to a workbook falls into this category, please put the phrase Minor Revision at the beginning of your change comment. After completing their review, DAPIR will approve and activate the specification without Data Steward involvement. The developer will not have to activate the specification. If DAPIR determines that Data Steward review is in fact needed, they will make note of that and advance the specification to Data Steward review as is standard.

Tableau Permission Groups and Roles

There are different Tableau groups that can be added to a workbook based on data restriction groups approved by Stewards in Cookbook for that workbook.

The following Table displays the currently existing permission groups. These groups are automatically generated and updated nightly based on their related manifest groups.

NOTE:

If during publication to production, “VIZ-Groups-BI UW Madison Employees” was automatically added, remove it (unless that is the access group that ADAWG approved for your workbook).

Respond to any quality control feedback in a timely way

• Collaborate with experts on the area to prevent faults and flaws in presenting data.

• Explain any mismatch with already reviewed and published reports.

Avoid duplicating existing data products

Review already published products and recommend enhancements to fit a new need. We have a searchable tool called RADAR that retrieves a list of available reports with a brief overview of each item. Here is a link to the tool:

https://search.data.wisc.edu/

Another useful tool is a searchable database of definitions in the system: https://search.data.wisc.edu/glossary

Communicate the institutional data product’s life cycle 

This includes creation date, review cycle, and anticipated conditions for destruction. 

Document how often data is refreshed. 

Document if the workbook will be live for a temporary period and let DAPIR know when the report needs to be taken down. Do not remove the report yourself. Email DAPIR for a workbook removal. DAPIR will archive the specification and delete the workbook.

Index

Creating a specification: