Initial Conceptions and Design

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 EdLab’s 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 library’s 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 (Biki’s 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 advisor’s 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 GA’s 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 lab’s 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 user’s 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 registrar’s 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 you’re 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 socio-emotional 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 one’s 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: (I’ve 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.