MIT Climate Collaboratorium Plan Comparison Wireframe

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 athttp://www.topcoder.com/wiki/x/dI0sAg). This contest will be focused upon the "plan comparison" sub-component of the overal project, which will allow users to easily compare different plans to address climate change. These plans are developed in another part of the site, and will each have a set of data that will be used for comparing plans in the component you will be designing.
The goal of this wireframe contest is to lay out a specification for interacting with a component of the site that enables users to compare,vote for, and navigate through plans to address climate change. Most of the back-end technology has been or will be developed. We are looking for a wireframe that describes howthis functionality is presented to the user. 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); critically, your component should make it easy for people to compare plans along the metrics specified.
• Any suggestions, interactions and user flow you recommend to achieve the client's intended functionality (as notes or comments for the client)

Background The MIT Climate Collaboratorium is a highly functional web site that will contain many different pieces of functionality. The plan comparion component (which this contest is focused upon) is just a part of the site, though it is an important piece of functionality. It is important to understand what a "plan" is for this contest. Plans will have a name, date of creation an author, and user provided tags, and number of votes. Plans will also have detailed information and user generated content that will be avilable on a plan detail page, but will not be displayed in the comparison component. Plans will also have several types of data, and these will be the primary means for comparing plans. In the version of the system this design contest is targeting, these types will be: Actions

• A set of emissions targets for three groups of countries (Developed, Rapidly Developing, and Developing). (billions of tons of CO2 released)
• An index (from 0-1) indicating the degree of deforestation.
• An index (from 0-1) indicating the degree of carbon update due to treegrowth.

Impacts

• Anticipated CO2 concentration in 2100. (in ppm)
• Temperature change. (in degrees)
• Sea level rise. (in cm)
• Costs of mitigating (preventing) climate change. (in %GDP)
• Costs of damage due to climate change. (in %GDP)
• Impacts (textul descriptiona of other aspects of climate change - such as food production, water supply, etc).

"Actions" are values that the users choose when developing a plan. "Impacts" are outputs that are determined by the system. Each of category of impacts might have several numbers that represent estimates from different sources. For instance, every plan might have 5 numbers describing different estimates of mitigation costs. It may be possible to summarize these numbers using a mean and varience. In subsequent versions of the system we expect that we will be adding additional estimates within some categories, and new categories of data (in both actions and impacts) to each plan.Your design should account for these anticipated extensions. In our vision, many people (10s of 1000s) will generate many (100s or more) plans, and will also vote on these plans. The goal is for site users to collectively generate a set of plans, and then to pick the "best" plan to address climate change by voting. The plan comparison component that you are designing is intended to make it easy for people to compare plans. Anything you can add to your design that will support easy and rapid plan comparison will be highly valued. Use Cases 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. 1. Default view - User looks at the list of plans - System displays a default set of information about each plan 2. Customized view - User looks at the list of plans - User selects which kinds of information to display - Plan comparison display is updated to show information 3. Sorting - User sorts plan viewby any information type - User can add additional sort criteria 4. Filtering - User selects sort criteria (variable ranges, text search, tags, etc.) - Plan comparison display updates dynamically 5. Graphical comparsion (optional) - User selects some subset of plans & subset of information categories - System displays a graph of plans for easy visual comparison 6. User navigates to plan detail - User identifies interesting plan - User clicks link to go to plan detail. 7. User finds own vote - User navigates to plan comparison component - User quickly identifies plan they had voted for previously 8. User retracts vote - (Use case 7) - User retracts vote 9. User votes on a plan - User finds plan to vote upon - User clicks a "vote" button - System removes users votes from any other plans (if the user has previously voted). Presentation The plan comparison component should be designed as a "portlet" 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 confgured to use as much space as required. Portlets typically have a handful ofmodes- e.g. a "view" mode, an "edit" mode, a "help" mode - that display different content. Portlets may also be designed to use several differentwindow states; for example, a portlet might be maxmized to fill the browser window and show additional detail or minimized to show high level summary info. (Note that we do not expect that the plan comparison portlet will actually require the use of multiple window states. However, you are welcome to propose multiple window states and corresponding designs if you feel it improves your submission). In general, portlet technology should not constrain you, the designer, but you should feel free to leverage the affordances it offers. Submission & Source Files Preview Image Please create your preview image as one (1) 1024x1024 JPG or PNG file in RGB color mode at 72dpi and place a screenshot of your submission within it. You are free to resize or crop your submission to fit this size, but do not add any filters or elements for dramatic effect, such as drop shadows or reflections. Submission File Wireframes can be built in HTML or OmniGraffle. Visio is possible, but if using VIsio, please provide PDFs that illustrate flow. The resulting files are not critical for this contest. The most important point is that all the content is listed and that flow though the content is clear so that it is apparent how the user will interact with the component. Source Files All original source files of the submitted ideas.