4C Database:

4C Database developer's log

Our goal is to develop an on-line, cross - platform and transdisciplinary application which will enable an examination of diverse case studies and a cross-case comparison of research. We introduce fields of analysis which should provide the basis for comparing and contrasting case studies within and from different disciplines. In order to permit this functionality, we constructed, on the server side, an online database that contains tables for storing analyzed condensed data, and, on the user side, web pages that provides a visual display of the information and user interface for communication and interaction with the database.

4C Database Version 2.0

4C Database version 2.0 is written in rubyonrails. Ruby is an object oriented programming language and Rails is an open source Ruby framework for developing database-backed web applications.

Design Overview:

4C database version 1.0 was evaluated by a group of case study researchers in April 2006. We collected and analyzed the evaluation results to determine what to include in the next generation of the the 4C database (version 2.0). Findings indicate that case study researchers wanted to (a) personalize and contextualize case studies based on their own view and research interest and (b) share, recommend, and discuss case studies among themselves.

The current version of the database (version 2.0) incorporates these recommendations and adds several innovative design features to support a cross case analysis process that is both personal and adaptable. The new design takes advantage of the use of tags to provide researchers with the capacity to connect and identify the relationships between case studies in the database.

In order to allow researchers to contribute case studies to the 4C repository, the system provides each researcher with a personal library in which they can add the case studies that they are interested in. The system provides users with a set of pre-defined fields (e.g. title, focus, purpose, and research tool) to express the case studies. Researchers can also include case studies contributed by other researchers (from the public library) into their own personal library and further personalize them through assigning personal attributes (tags) and annotations. This personal library can be modified and updated at any time by its owner. Instead of limiting researchers to using only a set of pre-defined keywords to categorize and relate the case studies the 4C application allows them to create their own personal keywords (tags) and assign them to the case studies. The use of tags will allow the researchers to judge, label and relate different case studies. The provided support for personalized tags increases the flexibility and extensibility of the prototype database by providing researchers with the means to associate cases using terms that are meaningful to them and search these case studies using these terms.

Functional Requirements:

In the 4C version 2.0, the case study researchers should be able to:

Create a personal space which contains all their case studies
Create user defined tags which can be attached to any case study
View, navigate, and search case studies based on the tags attached to them or the users who created or tagged them
Share, recommend, and discuss case studies through the use of the 4C forum.

Design phases:

CURRENT PHASE: (Jan 2007 -)

March-4. The signup procedure was changed. In order to obatain an account with 4C users first need to be approved by the 4C admin.

Feb-17. The 4C forum development was completed. In the 4C forum, members can start a new discussion topic, reply to a posted topic, view all posted topics, view topic posted by a particular member, view topics posted by themselves.

Jan- 15. Access to the database was restricted to members only. Non logged-in people can only see the about page.

PHASE III: (September 2006 - December 2006)

Development of tutorials, faqs, and about pages was completed. These provide information about the 4C database, its features, as well as how to use them.

PHASE II: (May 2006 - August 2006)

Tag visualization was improved by creating a related tags view. Related tags are tags that have been used together.
Functionality was added to allow viewing collection of case studies that are tagged with an intersection of tags (e.g. all case studies that are tagged with both literacy and Vancouver)
Annotation features were added. Members can add notes to case studies. A note can be either public or private. Notes can be modified or deleted only by the member who created them. Members can view all their notes associated to a case study as well as all publicly viewable notes created by other members.
File upload features were added. Members can attach up to 3 files to each case study that they contributed to the 4C database. The size limit for attachments is 1 Megabyte.

PHASE I: (Jan 2006 - April 2006)

By the end of this phase the 4C database supported creation of personal spaces for case study researchers to create/modify/search their own case studies as well as creation of a public space which allows case study researchers to share/view/compare all members' case studies.

Features developed:

Functionality to create an account with 4C, login, updating profile, password reset.
Functionality to view public space (called case archive).
Functionality to allow contributing a case study, or adding an existing case study to one's own library of case studies
Functionality to view one's or other's personal library. A personal library is a collection of case studies contributed by a member to the 4C database as well as case studies from the public space tagged by that member. For each member this collection is called "My library".
Functionality to view tag clouds (public, one's, or others). Each member can define his/her own tags and associate these tags to case studies. Any newly created tag is added to the user's tag list. Aside from creating new tags, members can also associate any exiting tag to the case-study. For each member this collection of tags is called "My Tags". Collection of all tags in the database is called "All Tags".
Functionality to update case studies, removing case studies from one's library, and deleting a case study from the database
Functionality to view a particular collection of cases. This partial view can be defined as (or the intersection of):

A particular member's case-studies
All case-studies under a specific tag
Selected case-studies and selected fields

Full-text search functionality on case studies
Functionality to compare and contrast case studies in a matrix view

-----------------------------------------------------------------------------------------------------------

4C Database Version 1.0 (link)

4C Database version 1.0 was utilized MySQL relational database to store the data and PHP programming language to display the studies and enable data search and analysis.

Functional Requirements
The 4C Database version 1.0 allows the followings:

Contribute research data according to the research criteria to the database on Compose/Edit page
Explore all research studies on View page
Upload text, graphics, audio and video data to the database on Upload page
Make hyperlinks to multimedia files Compose/Edit page
Participate in the discussion on an online forum
Search for relationships among specific cases on Search page
Compare and contrast studies by selecting particular research and variables of interest
Finding a pattern between studies using search keywords and key concepts methods

Design overview
The 4C database does not aim to substitute for existing qualitative research software, such as NUD'IST, NVIVO, ATLAS and HyperResearch. The main disadvantage of the existing qualitative research software is that it is a desktop application which does not allow accessing information outside one's computer. The goal for our online application is concentrated on finding patterns among studies instead of finding patterns within a single study.

PHASE III:

2005-April 30 - a new definitions/criteria page was added for the new fields. We updated print preview page in order to accommodate new database fields.
2005-March 30 - on completion of phase two, an initial pilot test of the database was accomplished. We conducted a Database Probe (see a discussion at http://m1.cust.educ.ubc.ca:16080/bbs/showthread.php?t=342 ), after which the following changes were made to the database:
New fields:

Title - stayed the same
Focus of study - (used to be unit of analysis)
Purpose - (used to be objectives)
Key concepts - stays the same
Research tools - (used to be data sources and tools)
What was learned (used to be theoretical ideas and outcomes)
Related studies (used to be references)
Also the option to specify "by whom the study was recommended by" was added to the compose page.

PHASE II:

2005-March 29 - new user Diane entered her study into the database.
2005-February 1 - back up started on the server using Navicat software.
2005-February 9-26 - The Database Probe was administered in vBulletin to find out user's opinion of the database and its ability to support cross-case analysis.
2005-January 15 - We have a goal to initiate multi-way dialog between researchers by incorporating such options to the website. Therefore, we consider the following options: To make available researcher's (who submit a study) contact information on the website as a link from researcher name however, there is a drawback of displaying contact info as it may make the email address prone to spam. To make an option on the view database page for visitors to indicate that they are interested in particular studies however, this option requires changes in editing privileges allowing other visitors to edit someone else's study which may interfere with database security and integrity principles. To make forum software available to database visitors for communicating online - this option we implemented (see the link at the bottom of the home page). vBulletin software was used since it is an open source software, which is also password protected and secure.
2005-January 5 - In the process of optimizing database usability we did the following changes to the interface: "Methods" and "Instruments and Protocols" fields are deleted. "Data Source" field is changed to "Data Source and Tools". On Compose page, "Reference" field is changed to "References and case study author contact information". In order to prompt a researcher to enter author's contact information to initiate a 3-way dialog between a researcher who studies (input info on the website) the article, a researcher who are interested in reading the article and the author of the article. Include Excel files into list of allowed files for uploading to database. Build an automatic message sending mechanism to thank you a researcher for submitting a study. Consider adding forum software to the website in order to initiate online collaboration between researchers.
2004-December 21 - We uploaded movie tutorials to the website. Tutorials were created in Camtasia software. Tutorials can be accessed from home page, at the bottom, link to movie tutorials.
2004-December 14 - We made the following updates to the flow of page as a response to user testing results: Number of steps for editing a study is minimized - Now a user can delete his/her own study from edit page (previously the user had to go to review page) - Also, a user, when logged in, can edit his/her own study on the page "view all studies in database" Instructional message is posted on compose page that "only unstructured text is accepted to database" to clarify user's options for formatting text.
2004-December 2 - We added a guest book page where users can leave their comments about the database. The guest book can be accessed from the home page.
2004-November 20 - We updated a print preview page for the database view so that a header is repeated on each page and columns are divided into two groups of 5 in order to put up the text in readable format.
2004-November 18 - We found that some users would like a database to be more personalized to work with particular studies and to adjust the database structure to their own fields. It brought up issues of the database integrity and securities concerns. Also, making the database customizable for individual use only contradicts the main goal of the database as a collective space for cross-case analysis.
2004-November 15 - We made the following updates to user interface as a response to user testing results: Changed login access from administrator -controlled typed to user-controlled type in order to improve usability quality, so that a new user is not required to wait for a business day in order to join the research. Changed the error messages text, sign in process flow, and test size and color of welcoming user messages to be more user friendly. Changed the text color on the website from dark green to black in order to improve viewability for the Macintosh computer user. There is a different from the PC color scheme Few changes suggested by user-testers were not possible to implement due to the limitations PHP language and java script capabilities, such as changing font and colour in java pop-up message screens or inserting formatted text into the fields.
2004-November 10 - a usability survey of the database was conducted.
2004-November 5 - We considered inserting additional functionality to the database view pages which allow the researcher to print out any page on the 4c database. The preliminary print function can be accessed through the Browser window, however, the page shown is not always formatted properly and some of the database information is not displayed on the browser provided print page. Therefore, we will add an additional function belonging to the inner database structure which reformats the view page so that all the columns are displayed on the same page.
2004-October 30 - We divided search pages into 3 separate pages instead of one for each type of the search in order to improve usability criteria for the user interface.
2004-October 20 - We hid a couple of columns on the "view all studies" page (but left accessible all the columns on the "view individual study" page) in order to enhance usability criteria for the user interface.
2004-October 10 - We changed login access from user-controlled typed to administrator-controlled type in order to increase security of the database.
2004-September 25 - We considered enabling proximity search. However, an efficient educational dictionary to support the thesaurus definitions was not found.
2004-September 15 - We added upload files functionality to the compose/edit/delete interface.

PHASE I:

2004-August 18 - After some initial testing, Phase I is considered completed.
2004-August 15 - We developed a search engine that allows looking up data by selecting particular research studies and variables of interest - this function is useful for comparing and contrasting a single variable across several cases. Another feature of the 4C search engine allows finding patterns between studies by selecting keywords or key concepts and finding studies that have similar textual data. Search is enabled by Boolean operators AND (intersect), OR (union) and NOT (subtract). Search can be performed on the entire study or on selected fields.
2004-July 20 - We built pages to view all the research studies contained in the database. We divided pages to contain 5 studied per page in order to optimize the user interface and make it easier to view the page, so that there is no need for a long scroll down pages numbers are displayed instead.
2004-June 30 - We built the interface for composing, editing and deleting studies. The user can post the research study info in a structured format according to the fields of the interests (column headers).
2004-June 15 - We developed Login pages which enable the user to store personal information to the database. Access to the editing pages is provided according to the personal information.
2004-May 30 - We designed a database that stores data in a matrics according to the criteria defined by column name. After considering an option to make available a few blank columns in the matrix left for individual researches to define a criteria for it, we found blank options unrealistic in a sense that if there multiple researchers (more than 10) defining individual columns, we might end up with a matrix which will not fit on the view screen and become user-unfriendly.