CMSC 434 - Phase #4 - Spring 2022
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 representations 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 side-by-side 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. In most cases, it feels like implementing, or modifying existing implementations of, the "front end" of screens (how it looks without interaction logic) will support your creation of new realistic screenshots documenting new features to demonstrate (ie: the filling in of gaps in your Phase 2 submission), and/or demonstrating how various redesigns of existing things would look and feel.

This feels likely more efficient than making realistic versions in an image editing program, but you could use that approach as well if you feel it makes more sense for your team.

If your Phase 2 had many working elements and not too many suggestions on fixes needed, you might feel that the most appropriate way to discuss plans moving forward would be via screenshots representing iterations or additions to your prototype design. If your Phase 2 was lacking in features, then we expect to see at least on new feature shown here, in addition to several fixes to existing ones based on our feedback to your team. Overall, all teams will have been given feedback by at least me and the TAs that would provide opportunities in Phase 4.

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 (real and demonstrating the scale of things) 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 on the screen must be realistic and indicative of scalability. That is still true here. This level of realism is critical when building prototypes. Particularly, overly sparse lists (eg: three things when in reality there would be dozens if not more) as well as things such as fake names, phone numbers, rooms, or food stats, recipes, exercises, 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 need to 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, should just say "There was no before for this." The "after" of each pair needs to reflect improvements to that part of your interface. The two need to appear on the same page as each other (top and bottom or left and right). 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. The discussion should be on the page prior to or following the one with the before/after screenshots, and identify the concern the "after" version addressed and why you feel it addressed it. Please do this in a consistent manner.

You might approach this by creating (for example) three screens that demonstrate multiple important improvements or a brand new feature that is well-desiged, 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 completly focus upon, you would likely need to demonstrate them across at least six screens and make sure that they are 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/build 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.

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.

There will also be a who-did-what entry for this Phase.


Grading Note
The elements of this phase will be worth 4 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.