Doc.

Life
Initial Conceptions and Design

Intellectual Product of TSI

From Proposal to Design

The document last circulated defined the move from Ez.D. to Doc.Life and proposed a conceptual framework for design. This document will outline the design framework and present initial visual frameworks. It has three primary goals: 1. To justify a more elaborate development approach utilizing AJAX and focusing on the tone of the site 2. To begin to put a face on Doc.Life and what the site might look like 3. To explore the integration of Doc.Life with larger institutional structures The first section will outline the proposal for form and tone, arguing that the time should be taken to give Doc.Life a new and exciting interface and content which acknowledges the growth element of the dissertation process. The second section provides an outline of the site with notes regarding function. The third section considers the problem of integrating with the university structure by focusing on the EdLabs role as developer. This document will not revisit the proposals Doc.Life: Addressing the Growing Need for Dissertation Management (hereby referred to as v0.1) and all suggestions and technical components of that document stand, with one exception. After pursuing and testing various technologies (the Education Map being the most recent), I am happy to report success with all but the related content tool. As outlined in Doc.Life v0.1, the system aims to provide related content at each node. For example, when viewing a journal entry the user might be encouraged to read a related seminal paper. This feature has been unsuccessful thus far and I am tentatively suggesting that it become a 2.0 feature for future versions.

Beginning with the Web 2.0 Dilemma

It is a held truth at the EdLab that new sites engage users and their social networks to create a new experience. While the EdLab will not design leisure sites like MySpace or YouTube, our stated aim has been to engage audiences in similar ways. PocketKnowledge attempted to create a social network of learners sharing intellectual content in the online environment; Meety will pursue a similar goal. The librarys Room Booking System (RBS) is not dissimilar, focusing on facilitating collaboration, but does so in a way which draws on existing networks: one signs up for a room to create a collaborative learning environment with individuals with whom she is already familiar. This truth afforded a luxury, the freedom to ignore how networks are instantiated, to RBS which Doc.Life and other electronic environments will not be granted. The creators of Doc.Life must be concerned with how learning environments are created; and thus must be aware of what I will call the Web 2.0 Dilemma. Electronic environments which offer structure for social learning do so by offering membership in a community of learners. More aptly, the community of learners is a network of individuals who regularly engage in discourse with other members; not simply a user-base of individuals who identify themselves as learners. However, the incentive for membership (the collaborative network) does not exist at the time the product is released. To highlight this dilemma, consider the two critical networks to Doc.Life: 1. The Advisor Star: Named such because it involves the classic star graph with the advisor at the center, this network connects advisees to their advisor to facilitate review management and standard hierarchical learning. 2. Informal Social Networks: These are the core of Web 2.0. Users sharing content over blogs (Bikis in our case) and other structures to create an informal learning environment where ideas and experiences are openly exchanged. Both networks suffer from the Web 2.0 dilemma and we can see this from the perspective of the agents. For an advisor, it is claimed that Doc.Life will help manage the review process and facilitate advisement. A wonderful boast is that Doc.Life will minimize the need for face to face meetings. However, consider the advisor with five advisees only one of whom is using Doc.Life. It becomes yet

another tool to learn with minimal positive influence, after all, the other four advisees are still using email and other traditional methods. The student is told that Doc.Life will help her manage the review process and provide an environment for collaborative learning with her peers. The former claim may be problematic (see the advisors perspective above), the latter is problematic in the early stages where the size of the community is small. Addressing this dilemma means actively pursuing the creation of a community. This section will highlight some administrative and technological solutions. Administrative solutions to the dilemma will focus on ways in which outreach can be used to create an online environment. Solutions would include: Advisor Outreach: Begin with a small community of advisors who are willing to enforce the use of Doc.Life by their advisees. This will eliminate the problems with advisor motivation noted earlier. Community Outreach: Select a small group of students to be the trial for the first year of Doc.Life (though the system could be open to all students at the same time). These students would be responsible for using Doc.Life and pressuring their advisors by forwardly insisting on using it as a review management tool. The students would likely need to be compensated. Managed Use: Like done with PocketKnowledge, a small group of GAs could be used to populate content within Doc.Life. This solution can be extremely problematic as these users are only superficially authentic; I strongly recommend avoiding this.

Another perspective on instantiating networks suggests that enticing products will quickly bottleneck with a critical mass of users, or that the network dilemma can be dodged if the community grows sufficiently quickly. I suggest that this is accurate, and that form and content can be used to achieve the effect. To this end, I suggest that we take a radical new approach with Doc.Life and (1) develop the labs first AJAX driven site; (2) focus on the creation of a tone congruent with the community we serve.

Style and Form

Web standards of presentation are constantly evolving. A number of years ago new sites replaced old gray form dialogs with colorful layouts and began using images as submit buttons. Royal blue with classic fonts have been replaced with brighter colors and sans serifs. Images as submit buttons are no longer popular and the old form dialogs have returned, albeit redesigned with CSS. Each new style is readily identifiable and users can sense the feel of a new site even if unable to articulate it. Doc.Life aims to grab the users attention and pronounce that it is a new take on academic sites. It must also engage the user early on: This is the new era in library/university services! To this end, I suggest the interface should: 1. Look New: Doc.Life should have the look and feel of a site that could never be the registrars office. While this effect can be overdone, I believe it will be crucial that Doc.Life has an interface that strikes users as cool. 2. Involve the Easiest Navigation and Use for the NetGen: Doc.Life should utilize AJAX technologies to allow users to interact with content without cumbersome intermediate pages. Want edit your post? Do it on the same page youre viewing! Want to comment or add a personal note? Ditto! Want to assign a new reviewer? You got it! Users must be excited to use the product if we are to reach a critical mass able to drive a learning network. I believe that a cool interface will be a strong first step to creating a feeling of excitement and buzz. While this interface will involve longer development times, it will stand out as the first EdLab AJAX system and, to the best of my knowledge, the first in the university! If situated properly, Doc.Life can become an incredible new look for academic sites and serve as a first step for TSI to incorporate these exciting new technologies in all of our future products.

Tone and Content

The content of the site will revolve around the creation of the dissertation. However, the dissertation is not a single paper, but a process of growth and development through which one learns to take the practical role of researcher and the social role of academic. A professor would not advise her students to view the dissertation as a purely technical feat, and Doc.Life must heed this insight. This developmental period concerns a range of skills and experiences for the doctoral student in education. The process may require that one learn how to deal with schools and school administrators; learn how to effectively survey in unpredictable situations; learn to engage colleagues and sell your work; and many other tasks best housed under the headings of tacit or non-procedural knowledge. It is important that the provided content in Doc.Life speak to both the procedural/intellectual processes of dissertation writing as well as the socioemotional experiences of doctoral life. Interviews of faculty discussing their personal dissertation experiences are exemplars of this goal and should: Engage the user at a personal level Provide a means of passing down tacit and non-procedural knowledge (e.g. adapting to volatile interview situations for students studying troubled youths) Ease feelings of frustration with honest stories and dialogs of problems ones mentors encountered

While the socio-emotional lens is typically not discussed in design documents, it is critical to recognize the needs and behavioral patterns of the potential user. I would argue that supportive environments are highly sought after by TC students, as are personal experiences which highlight the social dimension of research. In order to best serve the needs of the TC community and to create a product which will be utilized, Doc.Life must address both the intellectual and emotional needs of doctoral students as best it can. Doing so will not only ensure use, it may increase doctoral productivity.

Getting to Design
The following section will outline the major pages of Doc.Life through three sections: design, overview, and components. A design page shows the general layout, the overview provides in context description and the components section describes in more detail the functionality and goals of each aspect of the pages. This section is not intended as a mock-up. Additional work will be needed to create a more aesthetic design; this section should only present an idea of the layout and interaction capabilities of the site by section.

FRONT PAGE DESIGN

FRONT PAGE OVERVIEW

FRONT PAGE COMPONENTS

The calendar system is designed to show both a standard monthly view as well as a brief list of upcoming events (right column). The tabs above allow the user to filter events by those which were personally created, those which were created for a group to which the member belongs, and those which are defined to be for the whole community (e.g. Knowledge Center created events of AERA submission deadline). Effort should be made to have the system be AJAX driven with minimal page loads or cumbersome form interfaces. An example is illustrated below:

The Biki is referred to as a journal throughout the system to maintain the appeal of the audience in question. The Biki has two fundamentally important properties. First, it is AJAX driven with dynamic editing power. The user will quickly switch from view to edit mode without reloading the page: (Ive created a rough version of this capability on a development server). Second, the Biki allows for common nodal behaviors as described in Doc.Life: Addressing the Growing Need for Dissertation Management. These include posting comments (called responses in the Doc.Life academic lingo), making personal notes, and making an edit if the entry is set to public:

My Notes is a feature designed to allow a user to bookmark any item and make a comment for personal viewing only. This nodal behavior should help users create their own Doc.Life structure and ease general use, navigation, and recall of important content. The front page will present a list of recent notes, and viewing them in context appears as (for a note on an analysis map):

Profile Page Design

Profile Page Overview

Profile Page Components

All About the User. The left column of the screen has information about the user: contact information, program, advisor, description, research interests, and publications. The profile can serve as a great webpage for a new doctoral student to show a bit about herself and show off some of her publications. The Personal Journal is really just a blog with video capabilities, but again provides young researchers with a place to share something of themselves and their current work. In conjunction with the left column, Doc.Life provides a very workable personal website. The academic MySpace! Community Indicators such as time last logged in help users create a sense of community and also implicitly aid managing the review cycle. Wondering if your advisor is up to speed? Check out her profile and see the last time she logged in! Other indicators could be added as desired.

Phase X Design (Example of a Dissertation Chapter)

Phase X Overview

Phase X Components
Program Selection is provided as a drop down at the top of the screen. All content can be flagged as relevant to a particular university program to filter content to the needs of individuals. For example, a student in the Sociology and Education program may arrive to the Methods Chapter and see a discussion primarily concerned with ethnographic studies, a list of seminal works in Sociology, and journal entries related to that field. A student in Economics of Education may see a discussion of proper statistical methodologies, a list of papers in that field and a corresponding journal. The content on the page would be, by default, different for the two students. But each would have the option to switch the program currently be displayed. Writing Tips are provided first (in the upper left) on the screen. This content should be carefully constructed by someone with great experience and the ability to convey their wisdom effectively. As discussed earlier, this content should address both the intellectual and emotional needs of the student. Seminal Works provides a list of seminal works and exemplar dissertations related to this chapter and this program. My Drafts displays a list of current drafts for review related to this chapter. It also provides a link to the review cycle page. The Journal provides a list of entries written by the community and possibly experts as well if we can entice them. Administrators will have the ability to highlight certain entries which will force those entries to the top and color them yellow as seen in the picture above. This allows administrators the ability to augment the reading experience of many users and select for better content. Interviews are provided for each chapter or phase and as mentioned should cover both the intellectual and emotional needs of the students. Talks of common pitfalls, discussions of best practices, and the interviewees personal dissertation experiences should all be included as videos to watch. Visual Aids (Graphs) will be presented to explore the topology of information. As discussed in Doc.Life v0.1, graphs will include keyword and paper connections, author connections, data collection methodologies, and modes of analysis.

Review Cycle Design

Review Cycle Overview

Review Cycle Components

The Draft Preview window allows the user to see a list of current drafts, optionally filtered by phase or chapter. Draft View Pane provides more detailed information, including reviewer progress, for the currently selected draft. Features include monitoring/managing reviewers assigned to the draft, assigning new reviewers, setting deadlines, downloading the editing draft, and viewing only the changes to the draft as HTML as discussed in Doc.Life v0.1. Upload Draft allows the user to quickly upload a new draft without Reviewer Management in the bottom right of the screen allows the user to manage a list of reviewers to assign work to. In addition to adding and removing reviewers, the user is able to send messages to the reviewer via an internal emailing system.

Group Page Design

Group Page Overview

Group Page Components

Image and Descriptions of the group are presented first in the upper left of the screen and allow for in-context editing via AJAX as described earlier. A Community Journal is provided to allow the group to share ideas and experiences as they progress through the dissertation process. Group Members, Group Events, and Other Related Groups are all displayed in the right column as additional information.

Institutional Hooks
Previous discussion raised the issue of institutional hooks, or ways which the technological functions of Doc.Life can be integrated with the organizational functions of the college. Where Doc.Life integrates with the college, it should serve to make institutional processes more efficient. Possible hooks include: Doc.Life form processing: integrate required forms notifying the completion of critical stages with e-signatures. Use Doc.Life to allow for paperless tracking of students in the Office of Doctoral Studies. Or allow that office to print electronic copies from Doc.Life to eliminate the need for students to hand deliver forms. Faculty Review: allow the Deans Office to monitor the response times of advisors and committee members when giving feedback to students. Using this, a faculty profile can be created and used in assessments such as tenure reviews. Committee Assignment: assign appropriate committee members. Optionally allow faculty to sign up for particular committees on a first-come-first-serve basis. Analyze student progress: allow programs to monitor student progress silently from the backend of the system. This can be used to make sure students do not fall too far behind or otherwise off schedule. Could be monitored by program coordinators with the ability to schedule intervention meetings via Doc.Life

The benefits of these hooks include: Minimize paper document submission Ability to streamline the processes of the Office of Doctoral Studies Easier management of the review process and ability to hold faculty accountable to timelines. Also the ability to perform long term performance analysis Ability to target students who are falling behind quickly and without relying on a report from their advisors.

Many of these benefits are highly desirable and implementation would certainly reflect well on the EdLab. However, I strongly recommend not pursuing any of these goals until the EdLab has addressed a number of lurking questions. Over the past few years, the EdLab has produced a number of products. These include ContentWorks, DocDel, PocketKnowledge, and will soon include Doc.Life and Meety. However, these products are more aptly described as long-term services because the EdLab still maintains the servers and code which embody the systems. Recent

discussions have highlighted that this maintenance has caused a time drain on TSI, and we currently have no plan to push maintenance of these systems onto other groups or individuals. Integrating Doc.Life to the university structure will demand fast response times, impeccable service up time, and the guarantee that the system works across all platforms. This time will take away from time spent innovating; time being part of the EdLab. Until we develop a plan to develop a system and then move maintenance and upkeep to another group, I believe it would be very unwise to tie more systems to the university backbone. The dissertation is a serious work and integrating Doc.Life with the university requires the infrastructure to guarantee a successful experience for every user. Additionally, when tied to the university backbone Doc.Life becomes responsible for meeting the needs of the students and the staff of the institution (e.g. employees in the Office of Doctoral Studies). I believe it would be hasty to say that we are prepared to serve both groups simultaneously in the initial release. Instead, I suggest focusing on the students and then adding the institutional hooks once we find another group to support and maintain the system (e.g. CIS).

Moving Forward
The next steps of this process will involve: Planning the site design Developing content Designing the core programmatic structure

All three stages can be worked on simultaneously to some extent. Upon approval of this document, I will begin working on the core structures and planning the site design by collaborating with the MDC. If it is decided that this proposal is unsatisfactory, I will return to the drawing board. However, the plan for developing content must begin soon regardless of the success of this document. Any depiction of Doc.Life involves writing tips, visual aids, and faculty interviews (see the Phase X section). These tools will require an enormous investment from groups within the EdLab. Writing tips require an expert understanding of the dissertation phases and the ability to tweak a description to the needs of particular programs. The visual aids include methods maps which require a detailed analysis of methodologies and corresponding papers or works (see earlier this document as well as Doc.Life v0.1). The faculty interviews must be guided to probe for critical information as well as personal depth. These tasks are most clearly the defined role of the Knowledge Center, with video recording and editing by MDC. The success of Doc.Life will rely on our ability to begin coordinating these larger tasks to produce the content which will drive Doc.Life.