CMSC 434 - Phase #4 - Fall 2020
Prototype Refinement

General Description:
Between the time that you turned in Phase 2.2, and the due date for this phase, you will have had new feedback about your application. This will have taken the form of the report given to you by another team in the class, and feedback comments uploaded by me in your Slack channel this coming weekend. You may also have had details that you planned to complete but did not. Additionally, you have hopefully reviewed your prototype and you may have discovered issues in that way.

For this assignment, you will continue to work on turning ideas into representaions of what your prototype would look like, that can be used to assess the usability of your design.

Your deliverable this semester will be in the form of a PDF report with discussion and screenshots. The way that you generate those screenshots, and the depth shown in them might take one of several forms, depending on the state of your Phase 2 work. For example, if your team had less implemented in Phase 2, you will likely need to either implement the "front end" of screens or at least create new realistic screenshots documenting the flow of multiple new things to demonstrate filling in the gaps that were significant in your Phase 2 submission.

For teams where things that were implemented need some level of fixing or reworking, you'll likely be in a position where doing some "top level" re-coding (ie: chnaging the code to create the look but not worrying about the code to integrate that into the functionality) to demonstrate how you would do so might be the most efficient path to creating the new screenshots. However, as above, you might feel that it would be easier to have the screenshots represent exactly what the redesign would look like if you did them with image editing software, and that can work as well.

If your Phase 2 had many working elements and not many suggestions on fixes needed you also might feel that the most appropriate way to discuss plans moving forward would be via screenshots representing iterations or additions to your prototype design.

We are not going to request your new code base, just the screenshots this semester.

Something very important is that we want to see realistic data from everyone in whatever screenshots you create. As mentioned earlier in the semester, it's fine (and expected) to not have a scalable/working back-end for true database operations, but the data that your application shows must be realistic. The level of realism is critical when building prototypes. Fake names, phone numbers, rooms, food stats, recipes, etc. that don't make sense for the context when there are plenty of valid examples available removes a sense of reality and can decrease the ability to form an accurate assessment of how the system will feel in use.

You should look to see what "biggest bang for your buck" redesigns you can implement based on the feedback and your own assessment of shortcomings. This might be at the horizontal or at the vertical level. Your work needs to demonstrate your new understanding about how to improve the usability and functionality of your design.

The screenshots of your revisions will be incorporated into a report. This report needs to address the concerns raised in the reports delivered to your group as well as presentations/grading comments. You should point out each change reflected in your screenshots and identify the concern it addressed and why you feel it addressed it. For concerns mentioned for which you do not have screenshots showing how they would be addressed, be sure to explain how you would address it if you had additional time (either in the one-month, four-month, or six-month time frame). This timetable for the changes to be made would probably benefit from a brief explanations of how you prioritized modifications. Your description of how you will approach a change should be detailed enough for us to be able to bring it back to the person who raised the concern and convince them that your solution would address that concern. Again, feel free to use a picture to show how you would change things if it is easier than trying to describe it in text.

Additionally, all teams will need to put together a plan of action based on what you have learned from the feedback you received.

Create a single PDF of your full report with your overall plan for if you were to approach iterating your prototype over the next month or two, as well as your discussion of the valuable changes you have made with integrated screenshots to upload to ELMS. Make sure it is well organized for us. Be sure to provide a solid level of detail and information and keep lessons from across the semester in mind as you do this.


Grading Note
The elements of this phase will be worth 5 of the 40 percentage points that the team project makes of the semester grade.

Updates
If any updates to the description are required, they will be announced on places like Slack and ELMS. website.