CMSI 370 Interaction Design, Fall 2017
For this assignment, we turn our attention to the direct manipulation interaction style. As before, resources to help you with this include many of the links listed on the course website, assorted samples from the bazaar repository, and the starter files that are included with your GitHub Classroom repositories for this assignment, once you have set yourself up.
Textbook reading is centered on the direct manipulation interaction style, which would be Shneiderman/Plaisant Chapter 5. Additional helpful material outside of the web and the bazaar code will be the case studies in Chapter 9 of the JavaScript textbook. These case studies demonstrate lower-level event handling with some direct manipulation elements. Code from that chapter is available on the JavaScript book’s GitHub repository.
Remember that this is a proof-of-concept app—focus on the multitouch and acceleration functionality and don’t get lost in refinement and details. Do that after the assignment is due.
The sample code that comes with your GitHub Classroom repository is fully configured for code style review (ESLint). It will be hard enough to implement this from first principles, and it will be harder still to write unit tests for these, so no test suite is required for this assignment. Test your app manually.
In order to connect your repository to our automated code review and feedback system, once you are up and running please send your repository’s URL to Thomas O’Brien. Create a GitHub issue on your repository and mention him in it (@obrienthomas13). Once he has you hooked up, the system will provide feedback on code formatting and quality whenever you commit a new version to GitHub. Points will be deducted if issues here linger in the final submission.
This assignment requires access to a multitouch-capable and accelerometer-aware web browser. Most of you already own such a device; if not, arrange to check one out from the Keck lab.
The code in the GitHub Classroom repository is a copy of the boxes-with-physics sample from the bazaar. Modify this code into one of the following options:
Convert the supplied code into a “bubble simulator” app where:
- Instead of boxes, the objects in the drawing area look like bubbles.
- Because these are bubbles, instead of falling toward the ground, they float up instead. Their motion should be as similar to real bubbles as possible, including the way they bounce off the app’s boundaries. (Hint: Define a “buoyancy” vector that accelerates the bubbles upward. This vector’s interaction with gravity will provide the touch of realism.)
- The user “blows” new bubbles into existence by dragging their finger(s) across the drawing area.
- The user can either inflate or deflate existing bubbles (your choice) using a touch interaction of your own design.
- When inflation reaches a designated maximum radius or deflation reaches a minimum radius, make the bubbles “pop”—i.e., delete them from the app.
Bubble creation and, if possible, inflation/deflation, like bubble motion, must be fully multitouch-capable: that is, the user should be able to perform operations concurrently on multiple bubbles, limited only by the number of fingers that the device can follow.
Optional features (time permitting) include:
- Giving bubbles a finite lifespan, such that they “pop” on their own after some time.
- Implementing other objects in the display area, such as fish, seaweed, swimmers, etc. (you can decide how these interact with the environment)
- Implementing bubble-blowing options such as colors and borders.
Convert the supplied code into a “maze builder” app where:
- There are two types of objects—instead of just boxes, there are bricks and balls.
- The bricks can be created and dragged, just like the current boxes but without being affected by device motion.
- The balls are affected by device motion and gravity, but can’t be created nor controlled by the user in any other way. (i.e., predefine them on your web app at preset locations) They should probably also look like…balls.
- When the user rotates the device that runs the app, the balls move accordingly, but they ricochet off any bricks that are in their path.
- Bricks don’t need to interact with each other: they may overlap and be moved freely.
- Design a mechanism for deleting bricks, so that the maze doesn’t monotonically get tighter and tighter.
Brick creation and motion, must be fully multitouch-capable: that is, the user should be able to perform operations concurrently on multiple bricks, limited only by the number of fingers that the device can follow. As bricks are being moved and created, balls should keep on rolling in accordance with the device’s orientation and gravity.
Optional features (time permitting) include:
- Brick destruction: If a ball collides with a brick at sufficient speed, it destroys the brick.
- Ball collision: Balls also bounce off each other.
- Some kind of scoring: You can give the app a pinball-like dynamic by keeping track of a score for events such as brick-and-ball collision, brick destruction, etc.
- Use of images: You don’t need to restrict your bricks and balls to CSS-only visuals; feel free to use
imgelements to give them a custom look.
Commit your direct manipulation web app files such that your repository becomes the root location of a web server. To evaluate your work, we will run a simple HTTP server from a local copy of that directory and use your application from a multitouch- and accelerometer-capable web browser.
Programming assignments are scored according to outcomes 3a, 3b, and 4a to 4f in the syllabus. For this particular assignment, graded categories are as follows:
| Category | Points | Outcomes |
|---|---|---|
| Bubble look | 10 | 3a, 4a, 4b, 4d |
| Bubble motion | 30 | 3a, 3b, 4a, 4b, 4d |
| Bubble creation | 20 | 3a, 3b, 4a, 4b, 4d |
| Bubble inflation/deflation | 30 | 3a, 3b, 4a, 4b, 4d |
| Bubble popping (deletion) | 10 | 3a, 3b, 4a, 4b, 4d |
| Linting | deduction only | 4c |
| Version Control | deduction only | 4e |
| Punctuality | deduction only | 4f |
| Total | 100 |
| Category | Points | Outcomes |
|---|---|---|
| Distinct bricks and balls | 10 | 3a, 4a, 4b, 4d |
| Brick creation | 20 | 3a, 3b, 4a, 4b, 4d |
| Brick dragging | 10 | 3a, 3b, 4a, 4b, 4d |
| Ball motion | 10 | 3a, 3b, 4a, 4b, 4d |
| Ball-to-brick collision | 25 | 3a, 3b, 4a, 4b, 4d |
| Brick deletion | 25 | 3a, 3b, 4a, 4b, 4d |
| Linting | deduction only | 4c |
| Version Control | deduction only | 4e |
| Punctuality | deduction only | 4f |
| Total | 100 |
The last three graded categories are “deduction only,” meaning that you will only get points taken off if there are significant issues with those categories. Such issues include but are not limited to: lingering linting errors as of the final commit (4c), insufficiently granular or unmessaged commits (4e), and late commits (4f).
Optional features, if implemented, will be given bonus points depending on degree of difficulty and correctness of execution. However, such features will not be looked at until the requested functions are fulfilled.