Crunch time! Your interactive prototypes have to be ready for user testing by the end of this week.
By the end of this week, your interactive prototypes should be fully functional. Your app should write JSON data as well as read it. (The JSON data won't be persistent when you close the browser, but it will endure across pages within the same session.) Your app should have several pages where users can submit and view data stored in JSON. Remember, we are not at the "making it pretty" phase yet, so don't procrastinate by playing with Photoshop. If you planned it out right and you have been doing your work, you should be in good shape. If not, it's time to step it up. You will get much less out of user testing if you are still struggling with bugs and a half finished interface. Now is also the time to make sure your app fits into a mobile form factor, use Google device mode to help with this or your own devices.
Follow the development plan you created last week, and update it as you go. Keep marking tasks that have been completed and add new ones if you need to. Make sure that your next week is planned out with goals and who is responsible for each task. (If you'd like to give yourself the option of "late days", set an early deadline so your schedule has some flexibility.) Re-evaluate your stretch goals and what's feasible and what isn't. You may decide that your plan is too ambitious, or you may decide that your plan is too conservative; maneuver accordingly.
In studio, to follow up this assignment, you will receive feedback in the form of a brief heuristic evaluation from another member of your studio directly. Your team will pool that feedback, update your implementation plan accordingly, and then present your app to the whole studio.
Here are some examples of development plans: (1) is very stylized, dynamic, and mostly thorough, (2) is fairly thorough, colorful, but is missing time estimates and has only one stretch goal listed, (3) is a mediocre plan that's mostly thorough, where most tasks are broken down into less than 1 hour chunks, (4) is very thorough, with time estimates and time costs, but some tasks could be more actionable, (5) is a great video of the dynamic nature of implementation plans throughout the project.
GradeSource++: This example project from last year abstracts GradeSource for you and works with the data to show you where you are in a class.
Balancr: This app helps people balance their time between work and play. They have done a wonderful job making the app functional-- you can create a sign-up, add activities, and see it reflected on the pie chart.
For both examples above, the data that undergirds the functionality of the apps are pre-populated and updated from JSON. For instance, login information should be stored as JSON. You should have a pre-canned user that is persistent, and the ability for creating a new user whose credentials will be stored in JSON for the duration of the session. Look to Lab 6 for the necessary machinery to implement this.
Example of task description for an office hour reservation app that encourages group discussions: Make an appointment with a professor and mark it public so that other people can join. Then cancel this appointment and make a new one.
Note: since we may grade your assignment up to a few days after submission, per the honor code, we expect that the prototype URL show the state of your prototype at the time of submission. You will very likely be updating your prototype after submission, but please do so on another version.Submit your formatted pdf here
|No pages are connected and interactive. The app is not available through heroku or equivalent.||Prototype lacks a lot of features or has many bugs.||Prototype is mostly complete but may still lack one or two features.||Prototype is completely functional and ready for user testing. While not completely polished, the overall look and feel is reflective of the final prototype.|
|No Github URL; or if Github URL present, no data customization.||Data customization (e.g., JSON/Handlebars) in key places.||Pervasive data customization and templating. All major functionality is templated rather than copied & pasted.|
|Prototype is not designed for a mobile form factor.||Minimal attempt to design the prototype for a mobile form factor.||Prototype is somewhat designed for a mobile form factor.||The prototype's information architecture is well-tuned for a mobile form factor.|
|No goals were met.||Only a few goals or equivalent were met.||Most, but not all, of the goals or equivalent were met.||All goals or equivalent were met. Stretch goals need not be met.|
|Updated Development Plan
|No significant updates to plan, or plan.||Plan is mostly updated, but is lacking some detail or deadlines seem unreasonable.||Plan is detailed and reflects progress, new tasks, and any changes to previous tasks.|
|Task description missing, shorter than 2 sentences, or extremely vague.||2-3 sentence task description present. Task is either overly vague (confusing) or too specific (telling us what buttons to click). Not clear that you'll learn what you need to improve your app.||The 2-3 sentences clearly describe a concrete task that reflects your app's core functionality. The task will help you learn what you need to improve your app.|
Outside the Box
1 pt. Reserved for unusually impressive submissions.
|Your prototype is amazing and the TAs are extremely impressed with how complete it is. Not only is everything working, you have either solved an incredibly difficult engineering problem or you have introduced an extremely unique design. Your prototype shows thought and care. For example, even though not required for this week, you used a real database (Mongo) and made it sing.|