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.
For nuts-and-bolts web details (even for React, to a degree), the JavaScript textbook will be of help, particularly Chapter 6, Section 7.5, and Sections 8.2.3, 8.3, 8.4.1, 8.5, and 8.7. For the best exposure, read Chapters 6, 7, and 8 in full.
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!
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.
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.
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 |
|---|---|---|
| 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 |
| 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).
Once you have your front end sufficiently built out, it’s time to make it load up some real data, do real searches, save real information, etc. Strictly speaking, this part isn’t really interaction design nor implementation, but we want to do it so that your application has some genuine utility. Furthermore, if you do take on front end work in the future, you are likely to write code at this level anyway, even if it resides just below the user interface.
For this assignment, you will most likely use the reference documentation of your chosen web service API. To review the big picture, you can refer back to this Prezi along with the class screengrab recording that talks through this big picture.
Because you are using the same repository for this assignment, you should be good to go with automated feedback. If not, then what’s taking you so long?
Replace the API stubs and mocks in your front end with actual requests to your chosen web service API. If you maintained the recommended design for this layer in Assignment 1029, then this part should be a no-brainer: once finished, your front end will “just work” and immediately shift to reading and writing real information to/from your chosen web service API. Once you have a broader range data coming in and out of your application, undiscovered bugs or areas of improvement may emerge, so make sure you run your front end through its paces afterward, fixing any issues that emerge.
The starter code for the technology stacks all contain an extra “real API” file that genuinely implements one web service API call for you. Pattern your full API implementation after that code.
Once this step is finished, you should have a complete application, with a user interface of your design and implementation communicating with a real-world web service.
Edit your front end code “in place” (i.e., keep on working on the code that you submitted for Assignment 1029) and continue to commit and push it as needed. If you need to revisit first principles, you can refer to the original starter code in the repository (aren’t you glad that you copied these files in the beginning, rather than going straight to editing them?).
Thus, your submission is simply a continuation of the work that you started with the front end. Evaluating your work will proceed as before, based on the files at the top level of the repository.
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 |
|---|---|---|
| API Calls (evenly divided among the implemented 3 or more calls) | 60 | 3a, 3b, 4a, 4b, 4d |
| Test Suite and Coverage | 20 | 4a |
| Linting | deduction only | 4c |
| Version Control | deduction only | 4e |
| Punctuality | deduction only | 4f |
| Total | 80 |
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).