CMSI 370 Interaction Design, Fall 2019
We conclude your exposure to direct manipulation implementation with a different type of product—instead of a full application, this time you are asked to build a reusable component that uses direct manipulation.
For Submission: Reusable Direct Manipulation User Interface Component
We wrap up our programming work by going back to the basics: design and implement a reusable direct maniuplation widget for general use—including your custom front end. The mechanism for enforcing usability depends on the selected front-end technology stack. Traditional web apps will use a jQuery plugin; React web apps will use a React component (whether class- or hooks-based); iOS apps will use a
UIControl subclass. As a reusable component, your widget must maintain a per-widget model for storing the specific data/state of that instance of the widget. Further, you are to provide a notification mechanism (either in the form of a callback or a native platform event) that informs users of your widget of relevant events, e.g., such as when the widget’s model value changes.
The point here is to see how low-level event handling (e.g., mouse/keyboard/touch activity) translate into higher-level ones (e.g., selection or change events). Some ideas:
- A selection knob or slider
- A rolling or scrolling item selector
- An entry field that accepts text/numbers with drag-and-drop character tiles
- A “here-to-there” drag-and-drop area
- A directional pad (“d-pad”) control
If you have a widget idea that is not in this list, check with me to see if it will work.
Low-level events that can be used for implementing direct manipulation interactions include but are not limited to:
- mouse events
- touch events (multitouch is optional)
- device motion events If your component is not handling any of these events, then there is a strong chance that you aren’t using the direct manipulation interaction style!
Starter code for the possible front-end technology stacks is available in the bazaar repository. Copy these files to the top level of this repository, including “invisible” files starting with
., to get started. Confirm that these copied files work just as they do in bazaar, then proceed to revise them for your own component:
- jQuery plugin: jquery-plugin-samples (for this starter, you only need to copy code for the swivel plugin)
- React component: react-component-samples (this starter contains both class- and hooks-based implementations of the same direct manipulation component)
- iOS view: ios-direct-manipulation-samples
The web-based starters require Node.js and are fully configured for linting (ESLint), unit tests (Jest), and code coverage (Istanbul, built into Jest). These will be run automatically whenever you push to GitHub.
The iOS starter requires Xcode and has similar tooling.
jQuery Ground Rules
React Ground Rules
If you are in the React stack, your component must be the direct recipient of low-level events; i.e., you may not build upon third-party libraries for the core behavior of your component. You may use third-party subcomponents within your component, but the widget itself must be yours at the foundational level.
Browser Drag-and-Drop API Ground Rules
Modern web browsers have a native drag-and-drop API that handles rudimentary dragging and dropping of elements. This functionality can be accessed both within traditional web and React code. You may use native drag-and-drop as long as your component does more than a drag and drop. In other words, native drag-and-drop by itself does not count as a direct manipulation implementation.
The notion of how much “more” is enough can be a judgment call, so make sure to check with me if your idea for using native drag-and-drop will be sufficient for this assignment.
iOS Ground Rules
For iOS, your
UIControl subclass may not extend third-party libraries that already handle direct manipulation events. You may implement your component either completely in code, or accompany it with a .xib file (the starter code is completely code-based). In neither source type, .swift nor .xib, may you use a third-party library to handle or assist with direct manipulation event handling. Callbacks may use
UIControl actions, the delegate pattern, key-value coding, or a direct closure, in that order of preference (actions and delegate are perhaps the most common component-callback conventions within this tech stack).
General Ground Rules
When you integrate your reusable component into your front end, you may not change the component’s external interface nor internal implementation. That defeats the purpose of its being reusable! Treat it like a black box whose code cannot be changed solely for your front end. If you discover that you do need to change something about your component in the process of trying to integrate it with your front end, make sure to reflect that change back in the standalone component repository (this one).
How to Turn it In
Commit your code in two places. Within this repository, provide:
- The reusable code for the widget
- The unit test suite for the widget (see the supplied sample code for examples)
- A standalone demonstration page or app that shows an instance of your widget in action (see the supplied demonstration gallery page for examples)
Under your repository for front end development:
- Create a branch called
reusable-component-integrationand commit the work for this assignment on that branch (this way, your original front end stays untouched)
- Copy and commit the reusable code to this branch (we will forego the more sophisticated ways for including external libraries—that’s out of scope for this assignment), and
- Integrate your widget into the user interface that you have already built.
Specific Point Allocations
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:
|Model Implementation||20||3a, 3b, 4a, 4b, 4d|
|Direct Manipulation Implementation (view/controller)||20||3a, 3b, 4a, 4b, 4d|
|Notification Mechanism (callback/event)||20||3a, 3b, 4a, 4b, 4d|
|Front End Integration||20||3a, 3b, 4a, 4b, 4d|
|Inappropriate Third-party Library Use||deduction only||4a|
|Test Suite and Coverage||20||4a|
|Version Control||deduction only||4e|
“Deduction only” categories mean that you will only get points taken off if there are significant issues with those categories (or, in the case of third-party library use, the very presence of inappropriate third-party library code). 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).