2020.11.09 Brainstorming for Wiki-text

Instructions

If you thought dealing with temporal data was challenging, text data are even harder. In this activity we will brainstorm visualizations for helping users make sense of data that are primarily composed of text. Here are the rules:

Please follow this procedure:

Step 1 - 5 minutes - [GROUP] Identify Key Goals
  1. As a group, read the instructions.
  2. Together, take a look at the Domain section and identify between 3 and 5 domain tasks that you want to help users perform through your visualization.
  3. Rank those tasks in order of importance using any method you'd like

Step 2 - 12 minutes - [INDIV] Two sketches
  1. Now, working individually, begin making two very rough visualization sketches that best satisfy those tasks. Keep them low fidelity.
  2. Refer back to the dataset and think about what you want to show.
  3. Keep polishing your ideas until your group reconvenes.

Step 3 - 20 minutes - [GROUP] Final design
  1. As a group, go around and discuss each person's sketches. Keep it to 1 minute per sketch.
  2. Working together, create a consensus sketch. You will need to pick a group member to record your final idea and present it to the class, but everyone should sketch as they go.
  3. We will reconvene at the end to check out everyone's ideas.
Note that you may design for mobile multi-touch devices or traditional desktop platforms. Pick one as a group.

Your brief

Your goal is to build an interactive visualization that helps people understand how a Wikipedia article has evolved over time or otherwise make sense of its history. For example, the article on Social Information Seeking was fleshed out by one interested person, only for them to become bored and leave. It languished for years, getting out of date, before a set of new editors collaborated on it, making it once again accurate. In another example, the article on the fictional space station, the Death Star, was for a time constantly edited by many different people because it contained a controversial diameter. Unlike the previous article, this one quickly changed between two different versions of text as editors battled over the exact diameter of the fictional installation. Articles on sensitive topics or politically fraught ones often involve factions of editors with specific viewpoints that influence the content, spreading to other related articles. These can happen in some unexpected places. Take, for example, these samples from the edit and discussion history of the article on hummus:

Here, the benign content hides rich discussion about its etymology and contentious spill-over from ongoing socio-political conflicts. Check out the Lamest Edit Wars list for more examples of conflict. Remember that conflict on Wikipedia matters. Academic research has identified how early rejection can stall otherwise successful editors (perhaps because they didn't know Hummus was a battlefield of debate) or delay progress on an article (debating diameters rather than the much more important questions about the Death Star's power source and number of decks). Because article history and discussion can be positively enormous, moreso for contentious pages, it's hard for editors to make sense of how best to contribute. One can't expect someone to make a successful contribution when the past changes made to a page are several dozen novels in length. For this reason, infovis researchers have investigated how best to help people understand Wikipedia's socio-temporal textual data.

Your goal is to build an interactive visualization that helps people understand the content history of a wikipedia article, conflict among articles, or connections between articles. Users might employ your visualization for figuring out whether the article is trustworthy, understanding if the article represents the viewpoint of one person or many, identifying how the article relates to other ones to which it links, finding factions of editors that spread across the site, locating places where a person might contribute, and figuring out how to successfully contribute to an article (e.g. “don’t talk about the exact diameter of the Death Star”). Feel free to focus more on text-, user-, time-, or article network-centric goals. Or mix them together. Choose whatever granularity you feel is appropriate.

   Articles:
Text of the article at any point in time
List of users who have viewed the article, popularity
All users who have edited the article
Most recent edit date and all past edit dates
Time article was created, average amount of content contributed per day
All articles that this one links via blue text (e.g. Death Star -> [George Lucas,...])
All categories the article belongs to (e.g. Death Start -> [Category:Fictional doomsday devices,...]
   All revisions made to the article:
Time the revision was made
Who made the revision
Changes the revision made
Size of the revision
   All "talk" discussion on the article:
Time the comment was made
Who made the revision
Comment text
Threading / replies
Size of the revision
Part of the article it references
   Contributors:
Demographics
Years active on wikipedia, # articles they have edited
List of edits over time
   Implicit connections between editors:
Co-authorship (editing the same article)
Revision (editing someone else's comments)
Conflict (wiping out some else's comments)
Shared interests (# pages edited in common w/another user
Shared project/category membership
Domain tasks

Choose between 3 and 5 domain tasks that are most important for making sense of trends over time and rank them in order of importance.