Contest Title:	$1600 MIT Climate Collaboratorium Model Widget Wireframe (R2)
Client:	jintrone
Contest Type:	Other
1 Place:	$900.00
2 Place:	$400.00
3 Place:	$.00
4 Place:	$.00
5 Place:	$.00
6 Place:	$100.00
7 Place:	$100.00
8 Place:	$100.00
Studio Cup Points:	160.0

Have questions about how to compete? Learn more here! The MIT Climate Collaboratorium is a platform intended to enable the crowd sourcing of climate policy planning to address issues surrounding climate change. A conceptualization contest for the Climate Collaboratorium project is currently underway (more info can be found at http://www.topcoder.com/wiki/x/dI0sAg).

This contest will be focused upon the "modeling" sub-component of the overal project, which will allow users to run different kinds of climate models (economic and geophysical). Users will be able to use these model runs to support climate plan proposals.

This contest will be run in the Studio Tournament format. Please read the contest specification carefully and watch the forums for any questions or feedback concerning this contest. It is important that you monitor any updates provided by the client or Studio Admins in the forums. Please post any questions you might have for the client in the forums.

Entries must be your original work, and must not infringe on the copyright or licenses of others. Stock art, clip art, templates and other design elements from other sources are prohibited unless specifically permitted here in the Contest Details.

The goal of this wireframe contest is to lay out a specification for interacting with a component of the site that enables users to run climate models and explore prior model runs (we will refer to these model-runs as "scenarios"). Most of the back-end technology has been developed. We are looking for a wireframe that describes how this functionality is presented to the user.

Contest Format

Studio Tournament Format
This competition will be run as a two-round tournament with a total prize purse of $1600.

Round One (1)
At the end of Round One, the client will choose up to three (3) review winners; each will win $100 and a Wireframe Review. These winners and any member who had a passing submission in Round One will be eligible to compete in Round 2 for the additional $1300 in prizes.

We are now in Round 2

Congratulations Round 1 Winners on your $100 Prizes:

21847 - foxyhu
21852 - oton
21859 - qualitycore

Requirements for Round 2

- Please see revised requirements in the general feedback post in the forums. Incorporate individual feedback where applicable.


Judging Criteria

Your submission will be judged on the following criteria:

How well your wireframes provide a consistent user flow.
How well you implement the specified requirements (see the sections on Use Cases and Presentation below)
Any suggestions, interactions and user flow you recommend to achieve the client's intended functionality (as notes or comments for the client)

Background

The Climate Collaboratorium will run as a browser-based RIA, using a combination of html, javascript, and, where necessary, Flash. Substantial information about the Collaboratorium may be found in our wiki.

Within the Climate Collaboratorium, users will be collaboratively generating and evaluating plans to address climate change. A plan describes a set of actions we can take (e.g. investing in green technology, reducing emissions by a certain amount, etc.), and the likely outcomes if those actions are taken. Models are used to produce the scenarios (saved model-runs) that will be used to support a given plan.

A model is a runnable entity that produces outputs according to some set of inputs. Individual models may cover any one of many aspects of climate change (and possibly several at once), including social, economic, and climate consequences. A model takes as input a set of numbers and possibly other parameters (which may configure model assumptions), and generally produce numeric output. For instance, an economic model might take a a carbon cap policy as an input, the rate of population growth as a parameter, and output the change in GDP over the next hundred years at ten year increments.

A model might also produce text or images that have been associated with various states in the model. For instance, the the Stern ReviewReport on climate change impacts presented a table that described anticipated climate impacts in terms of of water, food, land, health, etc. for different changes in teperature. In the report, these values are not quantified numerically, but are described textually in a table (see page 57 of Chapter 3 in the report available at http://tinyurl.com/n4sa4g). We will build a model that simply simply "cans" these results and displays them according to a selection of inputs. The inputs to such a model would be a change in temperature. It is easy to see how an output might also contain an image.

Server side functionality

By our launch date in September, we will have developed the set of models described in the attached file, "Climate Collaboratorium - Launch version modeling framework.pdf." These models will be accessible via a web-service. Models in our web-service will be associated with meta-data that describes the model itself and each input and output parameter. Meta-data associated with the model itself will include a name and a description (which may be an html fragment). Meta-data associated with the inputs and outputs will include:

• Units

• Min & max value (if applicable)

• Precision / type (e.g. Integer, Double, Text, etc.).

• Long description

• Label

• If the value is ordinal (multiple numeric values), scalar (one value), or categorical (one of a finite set of values)

• If the value is ia tuple (e.g an indexed array such as {x1,y1},{x2,y2}...{xn,yn}) and relevant metadata for each item in the tuple.

The web-service also stores model-runs, which are also associated with a short title, and a description.
Models, individual parameters / inputs, and model-runs may be associated with various kinds of debates, including argument maps and more informal deliberation. Note, that while it is not necessary to spec these aspects of the interface, you should indicate how a user might access these debates from a modeling component, and where in the site these will be displayed. More information about these aspects of the site are included in the following sections.

Use Cases

The modeling component embodies several types of functionality, such as running models, viewing (and changing the view of) results, chaining models together. As discussed, models should be viewed as components of plans, and plans may have more than one model, and so it should be possible to view summary versions of models, and also to drill into individual models.

The following (roughly specd) use cases should be covered in your wireframes. Please interpret these use-cases liberally - the main (numbered) functions are important, but the details of how these things actually play out in the interface are up to you. The itemized lists beneath the numbered elements are merely suggested workflows.

1. Adding a model to a plan
- User browses available models
- Reads available information & debates about models
- Examines models inputs and outputs
- Makes selection which instantiates the component
- Default values are displayed

2. Copying a scenario
- User identifies a model in an existing plan
- User clicks copy
- User chooses "copy to new plan" or "copy to existing plan"
- Scenario is copied accordingly
- User is forwarded to the target plan

3. Running a model
- SYSTEM: renders appropriate interface controls
- User manipulates controls
- User hits "run"
- System displays output in default format (tabular?)

4. User exports data
- Clicks export
- Gets CSV

5. Visualizing model run
- User selects from available graph types
- User selects from among series in Model Run
- User selects configuration options (e.g. color, etc).

6. Saving a scenario
- User adds label
- User adds description
- User clicks save

7. User modifies existing scenario
- Selects existing model run
- Clicks "edit"
- System presents controls for simulation
- Optionally continue with use cases 2 - 4.

8. User connects models
- User selects source scenario
- User clicks "attach consequences"
- User selects compatible target model (system provides a list)
- Scenario interface is created and updated to reflect inputs governed by source scenario.
- (Subsequent mods to source scenario reflected in target model).
- Target

9. User disconnects models
- User selects target scenario
- User clicks "disconnect"
- Model is disconnected, but remains on page
- Edit controls are enabled

10. User views scenarios in a plan
- User navigates to plan
- Sees summary versions of scenarios
- Expands model to see detail

11. User debates model merits
- User selects model
- User clicks view debate
- User is forwarded to a page discussing the merits / drawbacks of the model.

Presentation

The modeling component should be designed as one or more "portlets" that may be embedded within a web page. A portlet is a small application that runs inside a browser window - perhaps the most familiar portlet style inferface is the igoogle home page, where individual "gadgets" are portlets. Portlets may be placed anywhere on a page, and can be linked together (at the back end) so that changes to one portlet cause changes to others. Different layout containers are available to the administrator of a portlet driven site, and users can be given the ability to add & position portlets according to their permissions. Portlets can also be configured to contain other portlets for layout purposes.

Portlets can be maximed & minimized, and may be equipped with several modes (typically view, edit, and help modes, but others may be defined). Portlets may contain any type of web content. Ultimately, portlet technology should not constrain you, the designer, but you should feel free to leverage the affordances they offer.

Several modeling components may exist on a page at once, and will share a page with other content. Thus, a scenario should have a summary view, as indicated in the use cases above. However, outside of this constraint you should feel free to present the modeling component however you see fit, as long as the use cases are covered. A single model might be presented as a single portlet, with multiple pages or frames, or multiple portlets on a single page.

Resources

• Climate Collaboratorium Conceptualization Contest Document


• The Stern Report