Nvidia. Apple. Google. Microsoft. Amazon. Walmart. These companies are the "rockstars" of the modern era. Everyone knows the name of these behemoths - they are so large and influential they almost seem invincible. But today's giants were yesterday's startups and yesterday's giants may no longer exist.
In this visualization, we explore the evolution of American giants over time. Specifically we ask two primary research questions: (1) For a specific time, what are the largest companies by S&P 500 market cap valuation? and (2) For a specific company, how does its market cap valuation change over time? To answer these questions, we use dual-view coordination.
Now, let's dive into the visual design decisions we made. For more information about our thought process please visit the following Observable Notebook: https://observablehq.com/d/3cb48db7d2660444
For temporal snapshots, we chose a squarified tree map which visualizes the top 20 companies by market capitalization at any given year. Market capitalization is encoded by the area of the rectangles, while the hierarchical grouping of companies into sectors is encoded through position (companies belonging to the same sector are placed closely together) and color (companies belonging to the same sector are shaded with the same color, given by the legend). Alternatives we considered include grouped bar charts (length is easier to compare than area) but this was deemed too space inefficient as compared to a tree map. A tree map is also better at showing proportions of a whole compared to a regular bar chart. Pie/donut charts were rejected for a similar reason - it is difficult to compare 20 different angular slices. Finally, we also considered sunburst diagrams, but again radial area comparison is harder than rectangular area comparison and the sunburst format is unfamiliar to most viewers. Our tree map utilizes D3's built-in re-squarify algorithm as well as pre-computation of historical sector caps to ensure that companies' shapes are as close to being squares as possible and that they tend to stay in the same place ("sticky") from one temporal point to another. Tis allows users to read the labels more clearly and keep track of company's trajectories more easily.
First, let's dive into the coloring choices. The colors for the sectors were chosen using the Tableau 10 Color Palette, which are 10 distinct, color blind accessible pallettes. As mentioned before, each color represents a different sector, making sector differences easier to spot. This also helps see trends over time (such as rise of tech, fall of energy). Coloring by market cap was rejected (obscures sector data). Coloring by company was also rejected (too many colors).
Now, more about the area sectors. These use a linear scale to make differences between companies more obvious. So if a company has a 3x larger market cap valuation than another company, it's area would be 3x larger. An inner padding (2px) helps to separate companies while outer padding (5px) helps frame the visualization.
Let's explore the text hierarchy inside the rectangles. The text color is white to contrast with the darker colors of the rectangle. The company name is bold and uppercase so that it immediately catches the eyes of the viewer. Below that, the company ticker and valuation is shown in lighter, smaller font. This is hidden if the rectangle is too small or on Safari (because of known problems with Safari and foreign object which causes the text to become distorted). Dynamic thresholds mean that the font sizes automatically adjust to the area of the rectangle.
Finally, the tooltips. When the user hovers over a rectangle, a small tooltip fades in with black background and white text providing more information about the specific company. Tooltips allows the user to learn more information while keeping the interface uncluttered. Tooltips fade out when the user moves the cursor away and they follow the cursor around to keep the user's attention.
We use a line chart to show company timelines. Line charts are the familiar convention for time series data such as market cap evolution because it emphasizes continuity, something which bar charts don't do. Area charts would not be a good choice here because they are usually associated with accumulation, not year-by-year values. The line chart is green to make it stand out on the white, gridded background below. Data points are indicated with a circled dot for easy identification. The axes are clearly labeled to help the user calculate exact numbers. For years in which the company was not in the top 20 of the S&P 500, and therefore no data exists, the connecting line at that year has much lower opacity. This is to prevent misleading the viewers and making them interpolate market caps for years where that data is unavailable. The line of best fit is a monotone X curve to make the curves appear smooth and not disjointed. The user can hover over a dot to learn more about the exact year and market cap, reducing the cognitive load of actually reading the graph's axes and calculating values. We chose for the line graph to only depict one company at a time to reduce cluuter and axes scale mismatch. The close buton allows the user to remove the company line chart if they so wish.
Multi-view Strategy: The treemap provides comparative snapshots (what is the state of the market at a given year?) while lines reveal temporal patterns (how has the market cap for a specific company evolved over time). This supports both big-picture and more subtle explorations. There is cross-filtering between the graphs. So, if I click a company in the tree map, its corresponding time series line graph shows up. If I click a data point for a specific year in the company time series line graph, the treemap snapshot for that year shows up. The current year is indicated by a dashed vertical red line on the time series line graph so users can very easily contextualize the data they are seeing.
The tree map covers a majority of the space and has a 3:2 aspect ratio. This is the main attraction and what should get the viewer's attention immediately. The line graph only appears if a company is selected, and is much smaller. The line graph is positioned and sized so that even though further inspection is needed to get exact data values, the overall trend is visible with just a cursory glance.
In fact, the line graph is just a portion of the sidebar. The sidebar also contains a slider for the user to manually change the time indicated by the red line in the company-specific graph and by the treemap. This is more visually intuitive in indicating temporal continuity (slider's positional changes equals changes in time) compared to alternatives like a dropdown. On top of the slider, the year is written in large dark bold letters so the user always knows the exact year. Each year has a specific netural annotation to give the user larger context as to what was going on in the world at the specific time that might affect the data shown and also summarize the data to help the user draw conclusions and make decisions.
The entire view is sized so that it can fit in a single page without requiring the viewer to scroll. The SVG viewBox provides responsive scaling while maintaining proportions.
Below, the slider is a PLay/Pause button that allows the user to see changes over time without manually moving the slider - creating a movie of sorts. This is again meant to reduce the work needed from the user's end. The time between individual treemap snapshots was chosen to be 2 seconds (not too large as to cause the user to wonder if the animation was broken but also long enough for the user to engage with the data for a specific year).
Finally, the sidebar contains a search box that allows users to search for a specific company on the provided tree map by ticker or company name. The company, if it exists in the treemap will b e given a yellow, pulsing border with all other rectangles on the treemap being dimmed to draw the user's eyes even more towards the searched company. If the time slider changes after a search, this highlighting effect remains until the search is cleared. This enables user exploration by allowing users to more easily track a specific company's rectangle over time.
The sidebar collapses on smaller viewports.
Animation is one of the key ways we show changes over time on the treemap. The purpose of smooth transitions with key binding on company ticker is to maintain object constancy over time (making the treemap "sticky" is also useful here). As companies' market caps rise and fall over time, their corresponding rectangles grow and shrink. However, if a company exits the top 20 or enters the top 20, we do not want to give the viewer the false impression that the company is either going out of business (shrinking to nothing) or just "popped" into the scene (growing out of nothing), rather we make companies fly in from the left or fly out to the right, indicating that they may still exist but are just entering and exiting the top 20.
If a company changes its position on the treemap (which we try to prevent but sometimes happens nonetheless to maintain the treemap's shape) the movement is animated as well to help users' eyes track that company. For readability, text labels on the rectangles also resize to fit the changes in size of their enclosing rectangle.
Supporting Elements: The title and subtitle clearly indicate the research question and are positioned at the top of the page. The legend helps users map color to sector and are clearly visible above the tree map as well. The compact horizontal orientation of the legend helps preserve vertical space. The footer contains data attribution links in case the viewer is interested in learning more about the data shown.
In designing this visualization, we kept in mind the principle of progressive disclosure. Big picture details are always visible, and more minute details are visible upon the user's request. A tradeoff was also made between analytical power and accessibility - extra information that we thought might be helpful was moved to the tooltips instead of kept on the rectangles to prevent clutter.
The tree map is a common visualization technique used for ordered, hierarchical data. See this link for more information about treemaps: https://www.cs.umd.edu/hcil/treemap/
We used the following Kaggle dataset for information about top 20 S&P500 companies' market caps from 1989 to 2024: https://www.kaggle.com/datasets/juanmerinobermejo/s-and-p-500-top-20-companies-by-market-cap-from-1989/data
In the process of cleaning up the above dataset, we found the following CSV file helpful in mapping tickers to actual company names: https://github.com/datasets/s-and-p-500-companies/blob/main/data/constituents.csv
Our software development lifecycle (SDLC) was rapid prototyping. We felt that this was the best option for a small project like this one. We repeatedly iterated on the code and saw how the visualization looked. We then altered the code to change something we didn't like, and the process repeated until we were satisfied. The initial visualization design for the treemap was done by Bimiyan, with the idea of the sidebar with specific company line graphs provided by Shreyan. Kalkidan helped procure the correct datasets for the task. The visualizations themselves were programmed by Bimiyan and Shreyan, with Kalkidan providing feedback from the user perspective. Kalkidan then summarized the design decisions included in this write-up.
We spent approximately 5 hours creating the first prototype. From there on, it was roughly one week of iteration and improvements. We also visited the professor during office hours, and he gave us a lot of good feedback as well (such as removing the need for the user to scroll and making the treemap "sticky" among other things).
The aspect that took the most time was the programming of the cross-filtering between the treemap, time slider, and the company line graph. We ran into a lot of bugs whereby clocking a specific year on the line graph would not update the treemap and the slider, or moving the time slider while a search filter was active on the treemap caused empty spaces and incorrect dimming. We fixed this by trial and error, and by writing minimal working examples to narrow down the cause of the issues.