GENERAL OBJECTIVES

Goals

The central purpose of the course project is to gain an understanding of self-directed learning, design, and the issues and challenges in building computational artifacts to support these activities. To this end, the project will be carried out through a learning-by-doing approach. The project will be carried out throughout the rest of the semester, preferably as a collaborative activity of team(s).

Schedule

September 29 Discussion about Projects in Class

October 6 Project Idea

October 13 Initial Report

November 10 Progress Reports

December 8 Final Report & Presentation

Resources

People (e.g., instructors, members of L3D), sites (e.g., the L3D Lab (Computer Science) and the SIMLab (Arch and Planning)) and tools will help you and support you r work in the projects.

Recommendations

To achieve something non-trivial during the short duration of one semester, we strongly encourage you to:

_ work together in a group (while this is encouraged, it is not an absolute requirement)

_ use existing (prototype) systems and enhance them.

REQUIREMENTS FOR PROJECTS

as usual: typed, individual pages stapled together

Project Idea

Format: maximum length of 1 page

Contents

This page should briefly explain:

_ which project do you consider to work on?

_ with whom do you plan to work together?

_ if applicable: on which machine do you plan to work? which programming language do you plan to use?

Remark: The stated requirements are oriented primarily towards implementation projects; if you choose non-implementation projects, adapt them to the nature of the task. This also applies to the other project requirements.

Project Proposal

Format and Evaluations

A maximum length of 3 pages; no handwriting; stapled together, follow conventions described above.

The proposal must contain the following sections - statement of the problem, rationale, technical approach and implementation. Each section will be graded on appropriateness, completeness and clarity.

Statement of problem-

What will your program try to do? Be specific. You should operationalize your terms in order to clarify the problem you are trying to address as well as the approach you will pursue. Use literature citations to support arguments and descriptions.

Rationale -

State the reasons why you want to explore what you are. Why is this a good idea for a project? What do you believe you will learn by doing it? It is from this part of the proposal that you derive the implications to computers science, design, learning, etc., from your proposed study.

Outline and justification of technical approach

This is a method showing how you will do and prove your point or argument, e.g., How will your program work? What tools do you intend to use? Why do you think your approach is reasonable? What other potential approaches seem to be feasible?

Implementation Plan

Mention the steps you will go through in creating your program and preparing your report. Proceed in a way that you consider early implementation efforts as prototypes to give you a deeper understanding of the problem.

References

List the key references, other systems, previous projects on which your work will be based.

Progress Report

Format and Evaluation

A maximum length of 3 pages, follow conventions described above.

Progress reports will be graded like the proposals, based on relevance, appropriateness, completeness and clarity. You will not be graded on how closely you were able to adhere to your original plan.

Content

The progress report must contain a description of your progress against your original schedule. If you have changed your plans (based on your work), it must include a clear description of the revisions and arguments for them.

The progress report must contain specifically the following two parts (at least):

_ a scenario -- i.e. a commented description of your program; what it is supposed to do and how it will interact with the user (this should define the goal -- not necessarily what you will achieve by the end of the semester)

_ a precise representation of a piece of knowledge -- e.g., representation at the code level, heavily commented

Final Report

Format

A maximum length of 6 pages (plus: screen images; code listings and any other supporting information you deem necessary to communicate your work). The final report will be graded based on relevance, creativity, appropriateness, completeness and clarity. These same criteria will be applied to the evaluation of your systems.

Content

The final report must include the following sections:

_ Statement of the Problem -- it describes how your understanding of the problem has changed while you have worked on it over the period of the course

_ Rationale -- it explains why is the problem interesting or important? Relate it to other systems and the literature! Why should someone else be interested in the problem chosen by you? i.e., tell about the contribution it makes to the knowledge of a community.

_ Technical approach -- it discusses the impact of the tools (which you have selected) on the problem solution. Contrast your approach with other approaches to similar problems described in the literature.

_ Description of the program / system -- it describes the structure of your program in sufficiently abstract terms (so that the reader does not get lost in technical details). This description should be very different from a code listing.

_ Description of the program / system behavior -- what does the program do? It should describe a sample run by not getting lost in details as an appendix.

_ Evaluation of the program / system -- it should address questions such as: how well does it work? what are the shortcomings and limitations? which theoretical issues does it clarify?

_ Potential further developments of your program /system -- assuming you would have another year to work on -- what would you do?

_ References -- List the key references, other systems, previous projects on which your work will be based.

_ Appendices -- program listing of the essential parts of your own code (including many comments), sample runs (which illustrate the most interesting aspects of your program), screen images

EXAMPLES OF PROJECTS

P-0: "Thinking, Working, Learning and Collaborating in the Next Millennium - A Joint Research Project by the CS 4830 "Information Society Course", Fall 97

study and explore the context for new essential human activities:

1. expressing ourselves
2. creating works ("ouevres"), artifacts (such as publications)
3. supporting information access and information delivery

methodology and benefit

1. collaborate
2. coordinate and plan a larger project
3. to have something with which you can identify yourself for the rest of your life!
4. it will be accessible from wherever you are

Parts of It:

1. analyzing some of the most exciting websites
   1. Amazon
   2. JIME (electronic journal)
   3. social filtering as a technique (a) to identify interesting websites and (b) to increase the trust worthiness of information on the Web
2. beyond the "gift-wrapping" approach of technology (e.g., innovative approaches for teaching on the Web; see Bruce Henderson's website)
3. creating a Webquest like game for transportation planning - see P-1 and P-2
4. creating improved possibilities for collaboration (Dynasite) - see P-3
5. analyze the relevance of the megatopics of the course for this project

________________________________________________________________________

P-1 (Arias, Eden): Shared Interaction in Support of Design, Learning and Planning

Development of different aspects of the INTERactive SIMulation gameboard station (INTERSIM) effort, e.g., the development of user interfaces which can make the tool usable to children's applications; or the development of a gaming or simulation application which could be implemented in the INTERSIM such as those developed at the SIMLab (or see other options in the NSF proposal); or work on the development of the interaction between physical pieces and the screen.

________________________________________________________________________

P-2 (Fischer, Scharff): Stella / Simcity / Agentsheets

theory: open systems, transcending the given model and the given information, end-user modifiability (structures and behavior), dynamic systems, to which extent are the underlying models accessible, inspectable, understandable, changable

existing software:

1. Stella and Stella-based learning environments: simulation software allowing authors to create learning environments that have a variety of models, various labs and experiments, embedded coaching, and multimedia capabilities. Learners can choose which model they wish to explore at their own pace. - possible applications: Boulder County Healthy Community Initiative, financial services, Healthcare Forum

2. Agentsheets-Boulder HOP

3. Simcity (including Scurk)

objectives to be explored:

why do we need open (end-user modifiable, extensible) system for real problems?

________________________________________________________________________

P-3 (Ostwald): Dynasite Information Spaces

Construct a web-based information space integrating different sources of information relevant to the course. Aim for a website that serves as a resource for class members, and grows to accumulate information produced during class activities. This growth should be accomplished (at least in part) by course participants that are not project members.

Please contact me for more information, advice, demos, etc.:

Jonathan Ostwald

ostwald@cs.colorado.edu

303-492-3547

________________________________________________________________________

P-4 (Fischer): High-Functionality Applications (HFA)

theory: learning on demand, seeding, evolutionary growth, reseeding model (SER), tools versus domains

application domain:

1. Word, Canvas, Pagespinner, Eudora, Preference settings in HFA, color, assistants in Microsoft Software (Word, Excel), in Pagespinner, MS "Tip of the Day"
2. a critiquing system based on the Web style Manual by Patrick Lynch
   (see http://info.med.yale.edu/caim/StyleManual_Top.HTML)
3. programmable applications paper (Eisenberg/Fischer) and
   Chart'n'Art (a system supporting self-disclosure in the domain of chart design
4. eMMa (a color critiquing system)

objectives to be explored: empirical analysis how people use these systems; architectures and features of the next generation of HFA

Selected Example/Details: "Dumping" even more decontextualized information on people is not a step forward in a world where most of us already suffer from too much information. Instead, technology should provide ways to "say the 'right' thing at the 'right' time in the 'right' way." In our research, we have explored problems associated with high-functionality applications (such as operating systems, word processors, spreadsheets, etc.). Our empirical findings (which are universally true for all systems) are illustrated in the Figure below. These systems provide challenging problems for a research agenda for "Learning and Intelligent Systems," because if future "progress" is achieved only by extending D4 to D4', there will be no benefits for users. Instead of increasing the tool mastery burden of users even more, we need new concepts such as learning-on-demand, information delivery, and task-based unfolding, so users can incrementally explore and master such systems according to their needs.

The rectangle (D4) represents the actual information space of a system and the ovals represent users' knowledge about the system's information space. D1 represents concepts well known and easily employed by the users. D2 contains concepts known vaguely and used only occasionally, often requiring passive help systems. D3 represents concepts users believe to exist in the system, some of which lie outside the actual information space. In the case of increased functionality (as illustrated by D4'), the area D4-D3 (representing the functionality users are not even aware of) increases to D4'-D3 , not that of the ovals.