In my previous lab report, I made a network visualization of the Aesthetic fandom wiki. While I loved exploring this graph myseslf, I knew the static nature of the graph offered limited usability to people interested in aesthetics. After posting my graph to the Aesthetic fandom wiki discord server, many wished they could explore the relationships between aesthetics in more detail. The only way I saw to bridge that gap was making an interactive visualization.
My goals for this project was to create a visualization where users could 1) easily explore new and known aesthetics to offer a more complete view of all the aesthetics that exist, 2) visualize the relationships between aesthetics, and 3) offer additional context for each aesthetic such as image and description.
1. Data Collection & Cleaning
I had to revisit my Python code for the previous lab to make sure my code scraped even the aesthetics that were not listed as related. While my previous code scraped the list of aesthetics page, I quickly realized that not all the aesthetics on the wiki were listed on this page. I modified my code to scrape the list of all pages instead and with some assisstance by code and Gephi, I manually cleaned out all the pages that were deleted, not an aesthetic, or redirected to a duplicate aesthetic and fixed any inconsistencies in naming.
After finding all the aesthetics and cleaning the dataset, I added extra columns to have the URL, description, and image for each aesthetic. I had particular trouble with scraping the descriptions due to the loose standardization of HTML among the wiki pages, but I managed to get descriptions for most with about an estimated 20 nodes missing or had incomplete descriptions. To see the code and dataset, here is my GitHub repository.
After cleaning, there were 703 aesthetics with 4402 edges. About 22 of the nodes do not have images.
2. Design
Inspiration
Olivia Turpin’s Say it with an emoji project was a major inspiration. I loved Olivia’s design as she customized the legend to fit the style of the graph more. In addition, I referenced her user testing within her writeup to guide my own design decisions such as her pointing out that her users started just jumping into playing with the visualization rather than reading the provided context and that her users were especially drawn to the unconnected outliers on the edges. I also want to thank Olivia for kindly letting me see the code so I could use it as a starting point for my own project.
Tools
I used Gephi and the Sigma.js plugin to create my visualization alongg with my prior knowledge of HTML, CSS, and JavaScript to customize the look and feel of the visualization. I highly suggest using Glitch to host and edit the visualization as it offered free hosting for static websites, a customizable domain name, and side-by-side code and preview panels for easy editing.
First Draft
For my first draft of the visualization, I mostly kept the same settings from my previous lab. In my network lab, I filtered all the nodes below 15 degrees out and left them out. For this draft, I filtered out all nodes below 15 degrees and then ran the modularity class. I then added back all the nodes I filtered out.
I did this because running the modularity class function on all nodes would create 50+ groups with one really large group that had almost all the nodes.
I turned on stronger gravity and set scaling to 50 to try to reel in the unconnected nodes, but still expanded enough to see connections.
In addition, I reformatted the attribute panel to show the wiki link, image, and description. I also styled the legend and information panel. I played with the label display threshold and max node size a lot to make sure the visualization was not clouded with too many labels at once yet offered enough context.
3. User Feedback & Modifications
I tested my visualization with three participants. One participant with interest in aesthetics, but no prior experience with the fandom wiki and two participants who were interested in aesthetics and had explored the fandom wiki previously.
All three participants were allowed to explore freely around the network graph. After giving them some time to aquaint themselves with the wiki I asked about four major points:
Graph Layout
While overall, the graph layout was well recieved, one participant commented that they wished the color groupings were closer together. Paired with the feedback I got during presentations, I wanted to see if I could produce a better shape to help the overall understanding of the graph.
I went back to Gephi. I followed the same process, except filtered out nodes below 10 instead of 15 to assign modularity classes. I continued to use the Force Atlas 2’s setting LinLog to promote tighter clusters and scaling at 0.9. I then used the Nooverlap function to spread out all the nodes that were on top of each other.
I struggled with getting a shape that was not too dense, but also kept the unconnected nodes within view. I noticed that users generally liked to look at outliers as they stood out so I wanted to make sure they were easily viewable. Despite the troubles, I think the shape is more informative than the previous graph layout.
Coloring
For coloring the graph, I used the default colorings and then made two other options using this python tutorial on calculating color average and dominant color. I made three different color options:
- Default Color: Default coloring in Gephi representing the modularity class.
- Color Average: The color average calculated from the thumbnail picture.
- K-means Dominant Color: Most dominant color in the thumbnail picture calculated with a k-means algorithim with the number of clusters set at 5.
I showed two participants all of the above coloring options for the graphs. Both participants preferred the default Gephi coloring options. After exploring aesthetics in both the color average and k-means dominant color versions, both participants said that though the colorings matched sometimes. Other times, they found the colorings sometimes produced weird or unexpected results that didn’t “match the vibe.” They also said the enjoyed visually seeing the modularity groupings.
I considered calculating the dominant color or color average of the modularity class, but decided not to since the individual node coloring produced mostly neutral colors. I tried to hand pick colors for classes but had a hard time balancing the look while still being representative of the grouping. Aesthetics are often a collection of specific themes, objects, or feelings, which can be hard to represent well in a single solid color.
Information on Panel
I asked participants what they thought of the information offered on the panel when they clicked on a node. While participants were happy with the description and picture, some wished for additional context such as the year of origin or even the entire infobox from the wiki page. However, I refrained from adding this yet as there is very little consistency in information avaliable on the wiki and I did not want the missing information to cause confusion.
Connections was a painpoint for most users. Some list of connections for aesthetics can be rather long and I originally had connections all in one list. This made looking through connections to be a pain for users as it was basically a wall of text and lacked organization. In addition, some users were confused that the number of connections was greater than the number of related aesthetics listed on the page.
In response to these criticisms, I turned on the group by direction setting of the Sigma.js template. This categorized connections based on incoming, outcoming, and mutual links. While users enjoyed the extra organization, they had trouble understanding the terms “incoming” and “outcoming.” After user testing, I changed “outgoing” to “Related aesthetic” as that is what they would be called on the wiki fandom page. I struggled a bit more with “incoming” links as that is not an avaliable feature on the wiki; however, I landed on “Pages that list this as a related aesthetic.”
After explaining what “incoming” and “outcoming” links meant, users loved that they could easily see incoming links as it gave a more complete view of related aesthetics compared to the wiki.
Users also wished for alphabetical organization of connections, but I did not find a way to restructure connections within the code.
Modularity groupings
The participant who was unfamiliar with aesthetics wiki liked the colorings of the nodes and knew they signified that these were grouped together semantically; however, had little comment on the effectiveness of the groupings.
While I had originally kept the participants from actively interacting with modularity classes, one user asked if they could see the groups in more detail. I changed the configuration file during the testing session to allow the “Group Selector.” I found that the two users familiar with the aesthetic wiki liked to see the individual groupings to see if they could discover the patterns within the groupings. The two participants enjoyed the groupings as it grouped together aesthetics in a way they normally would not. One participant described the groupings as like eccletic friends who would sit together at lunch. However, both participants commented they wished the groupings were named. Unforunately, I found no way to name the groups within the settings of Sigma.js template.
4. Final Design
Overall, participants loved interacting with the graph. Participants generally agreed that while the wiki was better for more in-depth explainations, this visualization was great for rapidly exploring different aesthetics and “rabbit holing.” A repeated benefit users seem to say is that they liked that they did could quickly get information on the aesthetics without opening a hoard of tabs. All users said that finding new aesthetics was easy, fun, and found the experience overall enjoyable.
I also realized during the course of this user testing that this visualization was most useful to those who are already knowledgable about aesthetics. While I showed my friends who are not well acquainted with aesthetics this visualization and they were able enjoy finding new aesthetics, the people who seemed to spend the most time and had the most interest were those who already knew a lot about aesthetics. They tended to start with anchor points they were familiar with or knew to be strange/obscure, and make their way out from there. They were able to engage with modularity groupings more while my friends who were not familiar with aesthetics did not pay much attention to them at all.
5. Reflections & Limitations
I absolutely loved doing this project. All my friends and participants that I showed the network explored the graph for at least a small amount of time, jumping from node to node, and exploring aesthetics they had never heard of.
However, if I were to continue this project, there are a couple of things I want to change:
- Explore other visualization tools: While I loved the convenience of the Sigma.js plugin for Gephi, it was frustrating that some of the major complaints I was getting for the network was out of my control (such as the flashing nature when people move their mouse over the graph or the order of connections). I want to explore further options for visualizing this if I were to make this.
- Different coloring options: I spent a majority of my time after user testing exploring color options. While I tried many different variations, it was hard to find a balance between visually distinctive colors and representative colorings
- Make the visualization more friendly to those not familiar with aesthetics. I focused on participants who were already familiar with aesthetics to varying degrees, but I want to further optimize this visualization for those who are new to the world of contemporary aesthetics. I want to test this visualization on people who have no clue what an aesthetic is to see what this visualization is missing for a layman.