CMSI 370 Interaction Design, Fall 2019
Now that you have your design and some startup know-how, you must be itching to start implementing it. So now we will, but in two phases.
The first phase is solely about the front end. We will leave stubs, placeholders, or mocks at the points where we expect to call our chosen web service APIs. Filling those in will be the concern of Assignment 1114. For this assignment, we focus on the core content of the course: your application’s user interface.
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.
For this assignment, you will want to be acquainted with one or more of the development resources listed in the course website, depending on the front end technology stack that you have chosen. You are likely to be consulting those frequently, including other resources that you might discover on your own.
Textbook reading is centered on the menus, forms, and dialogs interaction style, which would be Shneiderman/Plaisant Chapter 6.
Best Practices and Automated Feedback
Starter code for the possible front-end technology stacks is available in the bazaar repository:
- jQuery and Bootstrap web app: giphy-sample
- React web app using classes: giphy-sample-react-classes
- React web app using hooks: giphy-sample-react-hooks
- iOS application: giphy-sample-ios
The web-based starters require Node.js and are fully configured for linting (ESLint), unit tests (Jest or Karma), and code coverage (Istanbul, integrated into the test framework). When properly copied into your repositories, these will be run automatically whenever you push to GitHub.
The iOS starter requires Xcode and has similar tooling.
In order to connect your repository to Travis, our automated code review and feedback system, make sure you completely copy all files from the starter code of your choice. Once these files are committed and pushed, 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.
Note: The education subscription for Travis is limited to a single review task at a time, so don’t all commit at the last minute before the due date because the automated feedback will take much longer to get back to you!
For Submission: A Front End to an Existing Web Service API
The title pretty much says it: put together a front end for a pre-existing web service API. Details on selecting this API and the scope of usage for this API were specified in Assignment 0919a and with Assignment 0919b you got some hands-on time using it manually. The key requirement is worth reiterating: we are looking for the implementation of at least three (3) non-trivial web service functions. Also as stated in that assignment, there is a “home-grown” option which, if chosen, hikes the requirement to five (5) specific services.
Technology, coding, and architecture specifics will vary by technology stack, but one specification is common across the board: this assignment expects you to implement the front end only (i.e., no real connections to the web services yet), but also requires that there are clear, well-defined placeholders for those web services in your code. The starter code already has these qualities, so as long as you don’t veer too far from them, you should be fine.
How to Turn it In
The starter applications can be run/built from within their own subfolders, but for your own submission, copy all of the files from the starter code of choice to the top level of this repository, then start working on those files as your own. This has the secondary effect of keeping the starter code untouched—you’ll probably benefit from that, in case you do something that breaks the application code.
As you then implement your own design, do add, move, rename, and reorganize files as needed. The only things to preserve from the starter code are the tool chain configuration and setup (i.e., linting, testing, Travis) and the overall structure (primarily the API abstraction layer). For everything else, make the code your own.
To evaluate your work, we will invoke or build your application based on the files at the top of the repository.
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|
|View Implementation||25||3a, 3b, 4a, 4b, 4d|
|Controller Implementation||25||3a, 3b, 4a, 4b, 4d|
|API Stubs/Mocks||10||3a, 3b, 4a, 4b, 4d|
|Test Suite and Coverage||20||4a|
|Version Control||deduction only||4e|
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).