September 30, 2014

Best Practices for Creating and Using Home Page Widgets

Helix ALM
TestTrack Home page widgetNote: This blog post refers to TestTrack 2015 and earlier. The home page was replaced with dashboards in TestTrack 2015.1.   I wrote a previous blog post about how to create a widget. In this post, I'll provide some best practices to help you make the most of TestTrack widgets. I'll cover setting up security and sharing permissions, and provide recommendations on using colors to better call attention to key performance indicators (KPIs). Once you've set up a few widgets and users are starting to apply them to the Home page, you'll likely get feedback on what's working or not working. In the coming weeks, I'll be providing a variety of sample widgets that you can pick and choose from based on the needs of your team. The Home page widgets are still relatively new, so be sure to check back often to make sure you're making the most of them.

Setting Up Security Permissions

There are three permissions that impact creating and using widgets.

Create and edit widgets

In Security Groups, you can set/unset the Administration > Configure Home Widgets option to control who can create and edit widgets. If you're upgrading from an older version of TestTrack, this option will be turned off by default. Make sure you you set that option for at least yourself to ensure someone can create widgets.

Filter sharing

The first step in creating a widget is to create a new filter or select an existing one. When someone clicks on the widget from their Home page, they'll be taken to a list window with that filter applied. Make sure the filter is shared with everyone or matches the widget's share permissions; otherwise your users will end up seeing an error message when they try to view the details of a widget. Error on widget drill-down

Widget sharing

Just like filters, widgets can be shared with one or more security groups. If you share an existing widget with a new group, be sure to review the associated filter to ensure it's also shared with that group.

Configure Color Mappings

There are a few ways to use color with widgets. Here are some ways we've seen used successfully internally and by customers.

Single color mapping

Use a single color to identify item types or to highlight critical pieces of information, no matter what they're showing. If you want to show urgency with one color, use the scaling capability by selecting the Scale color to show transitions between mappings checkbox when setting up the widget. This will maintain the single color but provide some context by scaling the color lighter or darker based on the KPI value. For example:
  • Red for blocked test runs, whether there's 0 or 100 of them
  • Purple for metrics associated with requirements or user stories
  • Dark blue for "my" items showing requirements to review, tests to run, or defects to fix

2-color mapping

Use 2 colors for "binary" metrics, where things are either "good" or "bad." For KPIs where anything greater than 0 is bad, use 2 colors to immediately call attention to them.
  • Security holes/defects, where 0 is green and anything greater than 0 shows red
  • "My" requirements for review, where 0 is white and anything greater than 0 shows green
  • P1 defects in the current sprint, where 0 is green and anything greater than 0 shows red

3-color mapping

Use 3 colors to create a classic "stoplight" KPI, where things can go from "good" to "concerned" to "not good."

Multi-color mapping

TestTrack supports up to 10 different color bands in a single widget, but using more than three colors is challenging and doesn't work very well. Typically users will struggle to remember what each color means, and in practice I've not seen many situations where interpreting the data is complicated enough to need more than 3 colors. If you think you need more than 3 colors, consider trying the scaling option between three colors first. This will result in each of the 3 colors being lighter or darker depending on how close the KPI value is to the color band.