September 30, 2014
Best Practices for Creating and Using Home Page Widgets
Note: 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.Email sign up
Setting Up Security PermissionsThere are three permissions that impact creating and using widgets.
Create and edit widgetsIn 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 sharingThe 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.
Widget sharingJust 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 MappingsThere are a few ways to use color with widgets. Here are some ways we've seen used successfully internally and by customers.
Single color mappingUse 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 mappingUse 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