Project - Computer Prototype
In this assignment, you will carry out the second round of iterative design process by building a computer prototype of your project. Your computer prototype should consist of a horizontal prototype of all features needed by your scenarios (i.e., the appearance of all the controls, widgets, buttons, labels, and different screens), plus a vertical prototype of a subset of features that support the tasks you tested in your paper prototype.
- 4/14 (Wed.) Your team should have implemented all major screens and uploaded the screenshots to the course wiki.
- 4/21 (Wed.) Your team should have implemented at least one scenario task.
Recall that in the prototyping lecture, we mentioned five dimensions along which to one can adjust the level of fidelity in prototype making. For the computer prototype, the required level of fidelity along each dimension is given below:
- High fidelity in visual refinement. This prototype should be a vehicle for you to explore the graphic design of your final implementation. Lay out screens as you want them to appear in your final implementation, following your paper prototype design. Recall that the paper prototype you built is low fidelity in look. Now it's time to make choices about colors, fonts, alignment, icons, and white space.
- Medium fidelity in interactivity. This prototype must provide an interactive experience at a fidelity level higher than that of finger pointing in the paper prototype. Users must be able to interact with your system using a mouse and keyboard. But you don't have to implement all your input interaction techniques, such as drag & drop, drawing, and zooming.
- High fidelity in breadth. This prototype should appear to have all the major features needed by the scenarios you described and tasks you identified in previous project assignments. In addition, your prototype should include every major screen you expect to have in your final implementation.
- Mixed fidelity in depth. This prototype should have most features implemented shallowly but one feature implemented deeply in order to allow users to perform at least one of the three scenario tasks you tested in the paper prototype. In other words, while the prototype should seem to have all the features, only a small subset of them need to work, those needed by the one scenario task chosen by your team. The task you choose to implement deeply should be the most important task your system is meant to support. Do not choose the task simply because it's the easiest to implement.
- Low fidelity in data model. This prototype does not need to be supported by a real database backend. Where responses from the backend are needed, for example, a list of the names of ski resorts, make them canned (i.e., always the same) or random. But do make these canned responses realistic. The scale of the data can be small, but needs to be enough for testing the one task you've chosen to implement deeply.
Things you should not worry about
- Window resizing. When a window is resized, its layout has to adjust to respond. Don't worry about this for now. Determine a good default size for your windows and design a good layout for that size (using either automatic layout or even absolute positioning). Your final implementation probably should support window resizing, depending on your application, but you should decide how to make your interface's default look as good as possible, before worrying about variation.
- Platform independence. Even if your final implementation will run on multiple platforms -- different browsers, different operating systems -- your prototype doesn't need to look good or work well everywhere. Focus on one platform for now.
- Error checking. Ideally the UI should check for common errors such as entering text rather than number. But for now, error checking can be ignored.
- User management. While the login and registration pages should be made and included in the prototype, they don't need to be functional. You can assume a particular user (i.e., someone of the persona you created) has already registered and logged into the system.
To help your team get started with building the computer prototype, we provide a starter project template. This template consists of:
- a simple Sinatra web server (server.rb) that supports two services: project/info that returns the id and name of the project and project/members that return a list of members.
- a Flex project that has four basic screens: team, screen x, screen y, screen z. These screens are implemented as four separate Flex components in the src/screens directory. The team screen contains example code showing how to interact with the Sinatra web server. The other screens are just place holders. One possible way to share the development efforts is to use a separate Flex component to handle each major screen of your application and assign a team member to implement the component.
Below is a step-by-step instruction to guide you through the process of using the template to create a skeleton app and deploying it to a remote server on Heroku. But before these instructions can make sense, you need to complete the first part of Implementation Homework 4, which is about installing necessary libraries and tools for using Heroku.
- Prerequisites: Complete Part 1 of Implementation Homework 4.
- On your computer, create a new directory to hold your project code.
- Download the project template (template.zip) and unzip the content to the directory.
- Open Eclipse and import the directory as a Flex project
- Create a Git repository and add all the files in the directory to the repository
$ git init $ git add . $ git commit -m 'initial commit'
- Create a new Heroku application on the Heroku server
$ heroku create
- A temporary subdomain such as freezing-light-94 is created by Heroku to host your application. Rename it to something more meaningful, such as your project's name.
$ heroku rename your-project-name
- Deploy the project to the remote server
$ git push heroku master
- Test if the project is successfully deployed. If so, you should see the message "CMSC 434 Project Template" in your browser
$ heroku open
- Test if the two web services are working (replacing cmsc434-project-template with your application's subdomain name)
- Modify server.rb by replacing the filler team information with the actual information.
- Push the modification to the server
$ git add . $ git commit -m 'add actual team information' $ git push heroku master
- Test if the content returned by the two web services has been updated successfully
- In src/screens/team.mxml, modify the server url of the web services (currently http://cmsc434-project-template.heroku.com) to the server url of your own Heroku application.
- Export the release build (starter.swf, starter.html ...etc) to the directory public (Note: Sinatra treats everything you put in the public directory as static content accessible from the server root).
- If successful, you should be able to run the starter Flex app at http://my-new-app.heroku.com/starter.html
If you have previously taken a course on Software Engineering, you must have learned several good practices that can help you collaborate with your team members in developing an application. If you have not, this section provides some simple tips you can follow using Git and Heroku.
- Assign one person (e.g., the implementation director) to follow the instruction above to set up the project template for your team
- Have that person invite the rest of the team to join the project (more info: http://docs.heroku.com/sharing)
$ heroku sharing:add firstname.lastname@example.org
- Each team member should create ssh public/private keys using his or her own email address.
- Each person then is able to clone the project template on a local machine
$ git clone email@example.com:APPNAME.git -o heroku
- Assign each person to work on a major screen in a separate Flex component file
- After changes are made, push the changes to the remote server by
$ git add src/screens/file-that-has-changed.mxml $ git commit -a -m "log of the changes I made" $ git push heroku master
- Others can see the changes by pulling them from the remove server
$ git pull heroku master
Your prototype will be evaluated by your classmates, who are supposed to give you recommendations how the prototype can be further improved. The prototype must remain frozen (no changes) and accessible two weeks after the due date, giving your classmates and the teaching staff enough time to test drive.
On your team wiki page, please add the following subsections under the Computer Prototype section:
- System requirements. Describe what browser, platform, screen resolution you are most confident that your computer prototype will run smoothly.
- Staring up instructions. Explain how a user can run your prototype. If you are using the project template provided and hosting it on Heroku, give a hyperlink to the HTML file embedding the Flex application. If it's a self-contained Flex application, upload it to the course Wiki and provide a link. If it is a website, give a hyperlink to the site.
- Fidelity. Describe which parts of the prototype are shallow (incompletely implemented), which are implemented deeply, and what tasks are currently supported, what other tasks will be supported in the final implementation, so that your evaluators know what should work and what shouldn't.
- Comparison. For each major screen, show a side-by-side comparison of the photo of your paper prototype and the screenshot of your computer prototype in similar states, such as the examples below.
- Screen for entering order information
- Screen for shopping cart