CMSC 434 - Phase #4 - Spring 2021
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 as well as time to reflect on your design. You may also have had details that you planned to complete but did not.

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 before/after 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 (how it looks without interaction logic) 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: changing 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. That is still true here. 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 before/after screenshots of your revisions will be incorporated into a report. The "before" of each pair should be a screenshot of the part of your interface being updated from before you made the changes, or if it is a new screen, shoud just say "There was no before for this." The "after" of each pair needs to reflect improvements to that part of your interface. The report part needs to address the concerns raised in the reports delivered to your group as well as presentations/grading comments that lead to the design of your "after" screen, and it should briefly explain each change reflected in the screenshot being discussed. and identify the concern it addressed and why you feel it addressed it.

You might approach this by creating (for example) three screens that demonstrate multiple important improvements, or four-five screens each showing one or two moderate to important improvements each. If you end up feeling that smaller improvements are what you want to focus upon, you would likely need to demonstrate them across at least six screens. Also please note that these need to be distinct from each other. For example, if you had a font choice that needed to be fixed, making that fix on six screens would only count as "one" fix.

Your primary focus in this phase should be on iterating on what you have based on feedback, especially the official feedback posted by the instructor and TAs in the text file uploaded to your Slack channel. In some cases, that feedback will discuss missing functionality, the visual demonstration of which might be among your Phase 4 screenshots. In the event that there was minimal feedback regarding improvements to or omissions from your current prototype, your Phase 4 might then be able to move on to screenshot demonstrations of additional features that you had planned, even if those would interact with outside services

At the end of the report, all teams will need to put together a general plan of action based on what you have learned from the feedback you received and your own observations. For example, there might be concerns for which you do not have screenshots showing how they would be addressed, in which case at the end of the report you should explain how you would address each if you had additional time (in a time-table, such as a 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.

Create a single PDF of your full report with the before/after screenshots and discussion of the valuable changes you have made integrated with the screenshots, as well as your overall plan for if you were to approach iterating your prototype over the next few months. This is what you will 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 4 of the 35 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.