Collaborative Bibliography
http://www.scn.org/edu/tesc-ds/2000-2001/fall/case_study.html
Updated: October 2, 2000
The objective of this case study is to create a useful web application
for the network, a
CPSR working group dedicated to community networks and other forms of
democratic technology. The working group is informal and does most of
its work online. It has about 150 people on the list from about 30
countries.
We will be using the same set of tools for the case study as we'll be
using during the rest of the quarter. This is a real, though somewhat
scaled-down, application. It is intended to be used and useful. It is
also a focused prelude for what we're going to be doing in terms of
software development for the rest of the quarter. (The only thing
missing -- albeit a critical component -- is that the teams won't be
engaging with a community for feedback and guidance and ideas during
the course of the case study.)
Working in groups of four, students will develop a collaborative
bibliography web application. The important thing to remember is that
your team should actually deliver a working application. This will
often mean sacrificing something that you'd like to include.
Each application will be put on the web. Each team will send the URL
for the application to Doug or Randy who will put the link on the CIS
web site. This will enable network members to comment on the look and
feel, ease of use, and overall usefulness. (Doug and Randy may devise
some online feedback / voting / eval form to make it easier to get
feedback from the network. )
Each application will be developed using HTML, CGI, Perl, and MySQL.
There will be a page that displays the citations in a standard way.
The citation should be listed alphabetical order by last name. This
page should have a link to the input new citation page.
Examples
Holtzblat, K. and Jones, S. (1993). Contextual Inquiry: A
Participatory Technique for Systems Design. In Schuler, D. and
Namioka, A. (eds.), Participatory Design: Principles and
Practices. Hillsdale, NJ: Lawrence Erlbaum. (two authors in a book edited by two editors)
Muller, M. and Kuhn, S. (eds.) (1993). Special Issue on Participatory
Design. CACM, 36.4 (June).
(two editors, entire journal issue)
Schuler, D. (1996). New Community Networks: Wired for Change.
Reading, MA: Addison-Wesley.
(one author, book)
Schuler, D. and Groves, R. (2000).
Community Information Systems -- Case Study.
"Fall, 2000 Case Study: Collaborative Bibliography"
http://www.scn.org/edu/tesc-ds/2000-2001/fall/case_study.html
(October 2).
The material in quotes is the title of the actual page you have cited.
The unquoted title is the title of the web page of the material (from
the TITLE tage in the HTML) you
are citing. The date is whatever date cited in the document (often
listed as "last update").
The author of the page is usually listed at the bottom of each web page
as the person to contact. The url should be "live" unless you
know it to be not available.
Strong, G. (1995). New Directions in HCI Education, Research and
Practice. interactions, 2.1. (January).
(article in journal)
Webster, F. and Robins, K. (1989). Towards a Cultural History of
the Information Society. Theory and Society no. 18.
(article in journal, two authors)
Other Information
There will be a page (or other method) with which to enter the
necessary bibliographic information for a new entry using HTML forms
and CGI. The form should collect all the necessary information about
the citation including key words and comments about the citation (event
though they may not be printed). Perl and MySQL will be used. How the
application looks is up to your team. You may choose to allow multiple
citations per page, for example.
The minimum bibliographic types include books, journal articles, and
chapters in edited books. (You can optionally include other types.)
Don't worry about security on this one unless you really want to and
your team is convinced that it's do-able in the allotted time.
Each team will also need to decide how to check for incomplete or
inaccurate information. You must also be able to justify the approach
your team took towards addressing that concern. You may also want to
have certain default values.
Each team member must do approximately the same amount of work.
Although it's fine -- even recommended -- to specialize, each team
member is expected to become proficient in each of the technical skills
that is used.
Teams can modify -- or disregard -- any of these requirements as long
as there is sufficient rationale and team consensus.
More advanced options include an administration screen (password
protected) for editing the citations or a search capability.
Schedule
The team can optionally decide to add other types of information.
Web sites are a great -- and natural -- type to add. If your
team decides to do this, they'll probably want.
to make the url into a hyperlink.