Addressing the Growing Need for Dissertation Management

Doc.Life

Addressing the Growing Need for Dissertation Management

Intellectual Product of TSI

A Caveat and Request to the Reader

The document will here forth contain a number of declarations regarding the current state of the dissertation process and perhaps doctoral programs as a whole. These statements reflect the perspectives of the authors; none of whom have experience with the process. In reading this proposal, should you find any great discrepancies between your perceptions and those described in the document, please voice them. The authors’ underlying assumptions are the roots of any proposals contained in the document and we could only be benefited by your insights.

Purpose

The purpose of this paper is primarily as a project proposal and secondly as an introductory design document. The proposal piece is for a new approach to dissertation software with an emphasis on collaboration. The latter piece of this document begins an outline of what this tool’s components may be and what existing technologies could be utilized.

The Problem

In a recent EdLab seminar, concerns with efficiency of the dissertation process were raised. It was suggested that the process:

• Lacks a coherent method of scheduling
• Provides poor structure for the reviewing stages
• Offers little assistance with writing and analysis
• Provides few explicit resources such as other exemplary dissertations

These oversights in process create confusion, lead to the disregard of timelines, and depress performance in a critical work for doctoral students. To this, the authors add that the process fundamentally lacks means for collaborating with one’s peers; and suffers little internal coherency with the surrounding processes of publishing, attending conferences and preparing for academic life in whole.

Conceptual Solutions

To address these discrepancies TSI will design an online system for doctoral students at the university. The system should:

• Provide means for scheduling deadlines for oneself and her reviewers
• Structure the review process so that changes/critiques are immediately available and prominent
• Provide resources for developing an idea, writing to standards, and performing analysis
• Facilitate collaboration and the forming of review groups
• Assist in the processes of picking a topic and establishing an agenda

Preliminary Designs: Starting with Ez.D.

The initial plans to develop a system aiding the dissertation process were titled “Ez.D.” and a general outline was provided (see Appendix A). The purposes of the Ez.D. documents were (1) to develop a conceptual framework which captures the generic processes of dissertation writing; and (2) to highlight those processes which may be facilitated by computer technology. The system follows six generic stages, and no specific technologies were highlighted in this design.

Widening Scope: Axioms for Dissertation Software

In reviewing the technological requirements of Ez.D., we found the need to more clearly establish an agenda (the “Conceptual Solutions” section) and coherently describe our core principles:

1. The degree of format differentiation both between and within programs requires either a complex decision-tree system to target the applicability of stage x for user y, or an asynchronous system which allows users to move freely between stages. We believe the latter approach will be programmatically more efficient and will afford the user additional benefits. Following trends in language software development, we hold that users rarely work linearly and enjoy having some control over their interactive experience. An asynchronous approach will address both these needs.

1. Providing relevant information requires managing the changing knowledge of the field quickly and efficiently. This task is best served by a knowledge community with tools to collaborate and produce shared content.

1. The relevant field expertise includes much specialized knowledge and widely different information-organizing structures. Additionally, insights into the process of dissertation writing embody a great deal of tacit knowledge. These needs are best met by a system which allows individuals to share knowledge in an unstructured way.

1. Although the dissertation is a single product, its development does not begin until after many years of involvement within the university; this time is spent preparing for and thinking about the dissertation. We believe that even a great dissertation tool will not be used if it is only presented once an individual begins the writing process. It should instead be a resource available and relevant to the student upon their first steps into the university.

Doc.Life Overview

The shift from Ez.D. to Doc.Life embodies a larger shift in perspectivefrom a technical writing lens to a growth/needs perspective. Doc.Life aims to encourage writers by providing an online environment: which provides a sense of direction; and promotes learning through collaborative feedback and open discussion.

The design goals of Doc.Life are to:

• Create internal congruence of content by using a node model with Access Anywhere Components
• Promote collaboration: encourage group formation and feedback
• Engender a sense of purpose via asynchronous systems so that users do not ever feel lost or like they have reached an ending. The dissertation is a living document and Doc.Life will facilitate its development during the six generic stages, but also before, after and between these stages.
• Prevent common frustrations by overseeing the review process and structuring review timelines

As a development piece, Doc.Life supports collaboration by utilizing Open Source technology. Where possible, code will be used/recycled from existing Open Source projects to minimize EdLab investment. Additionally, Doc.Life will be released to the Open Source market when fully tested.

A Nodal System

Doc.Life is designed such that every element in the system is considered a “node.” Node types include uploaded files, suggested readings, blog/wiki posts, events/deadlines, profiles, groups, internal emails/messages. The purpose behind this structure will be to allow for integration of any item type in the site. All nodes will be searchable under a single search and each will be analyzed using latent semantic analysis. This analysis will provide a measure of relatedness-strength which will be used to provide “related content” to each item in the site. For example, when viewing a dissertation on “The Effect of Team Driven Classrooms in Labor Market Success in Twelfth Grade Urban Students,” the system may provide links to the author’s profile, the “It’s All Just Hidden Curriculum Anyway” group, and a blog entry concerning the modern implications of “Learning to Labor.”

Nodes will also serve to divide the site conceptually by program. Each node will be given a program ID and duplicated across programs. Thus when a user clicks to view “suggested readings,” she will be directed to the readings node associated with her program. This will prevent unnecessary cognitive load on the user, though a drop down menu will provide access to the equivalent nodes of other programs.

Access Anywhere Components (AAC)

The nodal system of Doc.Life will introduce the concept of Access Anywhere Components (AAC), which provide a common interface for interacting with node objects anywhere in the site[1]. Currently, AAC components include tagging, commenting, making suggestions to the administrators, and personal notes.

Public tagging and commenting allow for community interactions anywhere in the site, facilitating a collaborative environment. The “suggestion component” will allow the community to make suggestions regarding content and will only be available for certain nodes. For example, sections of the site will provide a list of “seminal readings” and will contain a link to “suggest additional readings” which updates an administrative queue. To maintain the integrity of these links, only administrators will be able to update the list.

The “personal note” feature is designed as a tagging/commenting/bookmarking feature. This component allows users to associate a node with some text for personal use and is unseen by anyone else. The user profile section of the site will allow users to view their personal notes and provide links to the corresponding nodes. This will allow users to bookmark content for private use and retrieve it later.

Users, Groups and Collaboration

When users sign up for Doc.Life they supply standard information, their current program, and academic interests. They are also provided with a personal “Biki”. The Biki is a cross between Blog and Wiki, a blog where each entry may optionally be set as a Wiki for anyone else to alter. It will also support video blogging, where users upload audio or video as a blog post, by integrating YouTube[2] functionality. These features allow one to create a Doc.Life identity which others will recognize when looking for other collaborators.

Groups are an often overlooked aspect of the writing process. In our interviews we found disparate ideas of how dissertation groups collaborate and varying levels of success. To provide users with a comfortable means of collaborating, each group consists of a user list, photo, description and a Biki. The Biki is unstructured and designed to allow groups to work in the format with which they are most comfortable, blogs, wikis, video all in one. Additionally groups may be public or private. An initial sketch can be seen in Appendix C.

Collaboration will occur as individuals interact with the one or more groups to which they belong, as well as other individuals in the system. Doc.Life supports collaboration with modules for calendars, internal messaging, and public reviews. The calendar system (shown in AppendixD) stores events entered by the user, by their groups and by the community at large to support shared deadlines and community notifications regarding events such as academic conferences. In addition to sharing events, members are able to send messages to one another using a simple internal messaging (email) system. We are also reviewing the capability of an internal chat system for live discourse.

The Dissertation Phases

The front page of Doc.Life (for an incomplete sketch see Appendix B) will present the six asynchronous stages of the dissertation process with a defense preparation tool and an independent “review cycle” module. Each of these units corresponds to a mini-site integrated with Doc.Life complete with links, search features, maps, and other relevant features.

Additionally, there are certain features found at all stages to be mentioned here:

• Each program/stage pair (Sociology and Education: Methods) will be equipped with a Biki linked from the mini-site for community support and discourse. Each stage will be primarily driven by this forum in conjunction with the recommended resources provided at each section (see below).
• Each program/stage links to a list of “exemplary papers” from Doc.Life. These papers are found by statistically weighting the responses from the review cycle stage a la Mechanical Turk. (See the “Review Cycle” section below for details.)
• Each will link to versions and reviews of the user’s own dissertation for said section.
• A small number of short interviews or talks from faculty regarding the criteria for the stage and helpful suggestions.

Picking a Topic/Defining the Problem

This component is the largest of the eight modules. The conceptual center of this module is a collection of seminal papers uploaded and tagged by administrators. The papers will be tagged with relevant program(s), field(s), keywords, and author(s). They will be presented as a list, be searchable and also viewable within an interactive module which displays the content as a map of field  keyword  papers (see Appendix E). We have established a good means of creating these graphs dynamically using AJAX and JSViz[3].

A second map will describe the relationships between authors using the seminal papers and the WebOfScience[4] citation finder. A map will be provided showing the authors of seminal work as central nodes, with adjacent nodes displaying prominent authors who have cited these papers.

A final map will display appropriate methodologies. Since methodologies are stable, we believe the EdLab could produce a list of various methodologies (headed under qualitative or quantitative) with a selection of representative papers tagged by methodology. In the map, the central nodes would be “Qualitative” and “Quantitative” with surrounding nodes of specific methodologies, each surrounded by example journal articles. In addition to browsing the map, each paper would be indexed by Doc.Life such that a user could search by paper content to reveal the associated methodologies. For instance, one could search “Video Game Learning” and find “Virtual Ethnography” but not “Factorial Design.”

Review of the Research

In addition to the features found in all stages mentioned above, this section will contain links to faculty suggested search engines. We’ve considered creating technology to provide resource recommendations based off the user’s provided bibliography; however, we feel the technology would be inferior to a human and instead suggest a series of videos discussing proper search methods. Professor/expert opinions are preferred, but a few videos should also center around selected students and their research methods.

Methods

In addition to the features found in all stages mentioned above, this section will contain links to recommended papers and online courses. This section will also link back to the “methodologies map/search” described in the “Picking a Topic” section above.

Data

In addition to the features found in all stages mentioned above, this section will contain links to recommended papers, datasets, and analysis tools[5]. Another JSViz map will display the connections between modes of analysis, example datasets and the appropriate tools. For example, the map may contain a node “qualitative” linking to the tool “NVIVO[6]” as well as several qualitative papers which used the NVIVO software.

Results

In addition to the features found in all stages mentioned above, this section will contain links to recommended papers and, if possible, a variety of templates for data reporting to assist young writers in conforming to reporting norms. A video or two should also interview professors concerned with “best practices” in display modes. For example, Aaron Pallas has an interest in these best practices such as: not using pie charts because they have a poor space to content ratio[7].

Implications

In addition to the features found in all stages mentioned above, this section will contain a list of resources for writers to engage the field. They could reference grass roots movements, current legal cases, etc.

Defense

The defense preparation stage should contain a series of videos describing the process and if possible a number of videotaped defenses. Supplemented by tips and the ability to upload self-authored videos of one’s presentation for review, this section aims to make the user feel confident and well prepared with the presentation.

Review Cycle

Asynchronous Design

In keeping with the asynchronous design, the review cycle will be a separate module of the system, accessible at any time. When entering a paper version for review, the system will ask the user to identify the type of review in correspondence with six stages of the dissertation: problem definitional; literature review; methods; data; results; implications; and other. A selection of a stage will cause the version to be displayed under that stage’s page. For example, uploading a “methods” version will cause said version to be displayed (and downloadable) from the Methods page. During this process, users will also be able to assign reviewers, make the document public or private, and provide tags (which default to the tags provided on the prior version).

Technologies in Play

After a review of current technologies, we have decided that online paper writing with tools such as Google Documents and ThinkFree[8] are not suitable and a file upload system will be used instead. Additionally, the review cycle will be greatly aided by allowing users to immediately see edited/altered content, not just the whole file. Under this scheme, all posted reviews would include a link to “See Revisions” which would display only altered content. We have determined a means of doing this using software to extract text from Word files in conjunction with Open Source versioning software[9].

Automated Reviews

After a review of automated essay analysis software, we have determined that little of it works well; and that which does, does not do so in a manner applicable to web development. However, we are still investing the use of SAGrader[10], and believe that it may be possible to utilize this software to provide limited automated analysis. The current obstacles include finding a command line interface to the software and finding a sound method of developing criteria. Should these problems be solvable, it would be feasible to create a system where users selected topics related to the piece and the system returned feedback regarding the writing style and content.