Team Members: Deric Pang, Ayaz Latif, Michelle Yun

Design Rationale

The driving question that our visualization aims to help users answer is: "How good is my pokemon team?". Since the quality of a pokemon team can be defined in a variety of ways, our team builder's components each illustrate the user's team's performance with respect to different measures: average base totals, type resistances, and how the team compares to overall statistics calculated across all pokemon. To enable easy navigation of the dataset, we also provided interactive controls to help add, remove, and query for team members.

A lot of interesting exploration, especially when the dataset is large, involves selecting specific subsets to study in more detail. In the context of the pokemon universe, one natural subset to explore is the traditional six pokemon team. To enable easy selection, we enhanced a basic scrollable list of pokemon with features such as filtering by desired types and search by text. Although there were a variety of attributes that we could have enabled filtering for, such as the individual components of a pokemon's base total (attack, defense, etc.), we decided that type filtering would be more valuable to a larger proportion of our intended audience because categorical types are much more memorable than numerical quantities -- for example, it is highly likely that an average pokemon fan would know that Pikachu is an electric type pokemon, but it is less likely that he/she would know that Pikachu's attack is 55. However, even with type filtering, users who have a specific set of pokemon in mind may still find it difficult to find their desired team members. The text search box allows such users to quickly put together teams that they want to analyze.

Besides just being able to query for different pokemon, we provide several components to help users analyze their team. As mentioned before, how good a pokemon team is depends on multiple factors. The most important two factors are the base totals of the team and its type resistances, so we created two simultaneously updating bar charts to visualize each. A bar chart for the average base totals was the natural choice to display this quantitative data, but we settled on a bar chart for the type resistances only after a few design iterations. We first tried to display type resistances as a table with types as rows and resistance factors as columns -- each cell would have the count of team members that had the resistance specified by the corresponding column and row (for example, the cell in the intersection between the bug type and 0.5x type would display the number of team members with 0.5x resistance to bug type moves). However, though this visualization allowed users to see all of their team's stats at once, there was no way to enable users to focus on just one or two types at one time. The only option was to display the whole table all at once, which we thought might be overwhelming. We then tried displaying type resistances by just showing users a list of types that their team was weak to and types that their team was strong against, with a show/hide button below that would display and remove the original type resistances table. Though this design was less overwhelming and somewhat enabled the "details on demand" interaction that we were after, a simple list felt like too much of a simplification of the data. Without looking at the table, a team might appear equally vulnerable to all types displayed in the "weak to" category even though the team might have all six members weak to type A and only one member weak to type B, for example. In the end, we settled on a brushable bar chart, which we believed would be the ideal mix of overview plus details on demand that we were after.

Knowing the base totals of a team can be useful to some degree, but given the competitive nature of the pokemon universe, the relative standing of a pokemon's base totals in comparison to all other pokemon can sometimes be even more useful than just knowing the absolute values. We therefore decided to augment our base totals bar chart with tooltips to inform users of the difference between their team's base total components and the average for each base total component when computed over all 801 pokemon. Similarly, knowing the average base totals across multiple pokemon in a team gives users a good idea of how their pokemon fare overall, but we also wanted to allow users to easily query for the individual base totals of their team members. We did this with tooltips that show up when users hover their mouse over particular members of their team.

Another interaction technique that our visualization implements is exportability. We thought that this technique would be especially well suited to our visualization since a large part of the fun of pokemon is comparing teams. Our final product implements exportability as a shareable link that users can copy into their clipboard. This link redirects users to a page that is identical to our default webpage, except that the team has been pre-filled. We had originally planned to allow users to export their team via a static image or PDF but decided that a web page would be the best route since this format would preserve the interactive components of the visualization (such as the tooltips and brushable portion of the type resistances chart). We then considered redirecting users to a version of the webpage that would just display the average base totals and type resistances chart. However, in the end, we decided that including the list of pokemon options was valuable because any people who had received a link could then build their own team(s) by making incremental modifications to the one that they had been sent.

Colors are one of the main visual encodings that we utilized in our design. Because pokemon are naturally categorized by type groups, we assigned a unique color to each of the 18 possible types. These colors were chosen to reflect the type color palette used across the pokemon games. We chose to stick as closely to the original color palette as possible, not because we believed it was the best color palette, but because this would allow us to take advantage of the already existing color mappings that many of our users will have from playing the games. Although changing a few of the colors to be more distinct or attractive might have improved the color scheme in the eyes of a person who had never played the games, because we expect our audience to have familiarity with the pokemon universe, we believed that any deviations from the established color palette may instead actually cause increased confusion (since users would be forced to modify their expectations of what color each type should map to). We rely on this color palette in multiple visualizations -- in some cases to make a large amount of components navigable, and in other cases to provide extra detail. The type filter buttons and type resistance bar charts both have many individual members, but by giving each button its corresponding type color and grouping bars by type color, we hoped to make each visualization less overwhelming. The same type color palette also appears in the coloring applied to each team member to let users see their team's type spread at a glance. Besides using color to organize various components by type, we also incorporated color into the base totals chart tooltips to indicate teams being above average (green) and below average (red).

Development Process

We started the development process by sketching out our ideas and deciding on the components that we thought would be most useful for answering our driving question. Here is our original hand drawn rough draft:

Next, we moved on to making a mostly working prototype where we prioritized functionality over design. This phase was one of the more difficult ones, but only due to our unfamiliarity with d3. After we had implemented working versions of the pokemon selection list, base totals bar chart, and type resistances table (which we later abandoned), we moved on to implementing some of the more interesting interaction techniques such as the team tooltips, type filtering buttons, and text search box. We also began to refine our design of the visualization by choosing colors and arranging the position of components on the page. After a few meetings, we brainstormed different interaction techniques and evaluated the effectiveness of the ones that we had implemented. During this time, we experimented with different options for displaying type resistances, decided to add the additional components to our base totals bar chart that were mentioned above, and implemented the exportability feature. This part of the development process probably took the most time since the interactivity features that we were implementing were more advanced. In the final phase of development, we refined the styling of our page (fonts, colors, backgrounds, etc.). In total, the whole development process took about 40 total hours. Here is a detailed breakdown of the time we spent on the project:

• Initial prototyping: about 10 hours
• Implementing d3 components: about 20 hours
• Design and various final tweaking: about 10 hours

Each of our team members contributed to multiple aspects of the project. Although we didn't assign specific roles at the start of the assignment, we each had our own focuses. Deric handled the deployment of our project to GitHub, set up a Slack channel for our team to communicate on, and calculated statistics from the dataset that were used to update the base totals chart with comparisons to overall averages. Michelle found the dataset, made initial prototypes of the team's ideas, and implemented the d3 code behind the main components of the visualization. Ayaz experimented with different options for selecting pokemon from the options list and was the main designer of the final product.