Designing the Tool, Part II

How can we have students create networks of concepts without telling them to create networks of concepts? This was one of the most significant challenges we faced during the early stages of our project. We (safely) assumed  that students have prior experience writing papers. We also assumed that students have not been asked to interconnect concepts before to produce a network-oriented representations of their knowledge; therefore, they need articulate instructions on how to proceed. Yet articulate instructions (especially those that emphasize making connections) bias students’ thinking and potentially show them a way to game the system. Furthermore, even when they produce authentic networks, it is difficult to compare them: while we can identify some networks as obvious “wrongs” (such no two ideas are connected or everything is connected to everything else), there are an endless list of valid representations that can emerge.

The solution to these problems turned out to be a redesign the project that removed the focus from “building network”. In particular, instead of asking students to interconnect concepts, we asked them to label these concepts with a small set of orthogonal tags; our software then processed these tags to render implied networks. For example, if concepts C1 and C2 both carry label T, then C1 and C2 are inferred to be connected by T. Likewise, if concept C carries the tags T1 and T2, then T1 and T2 are inferred to be connected by C.

This presentation for the roundtable will provide an overview of the design history of this tool (Ali Erkan and his student research assistant Steve Lam will co-present).