A6: Meat on the bones Team submission

The goal for this week is for you to complete the interaction flow. Spend this week fleshing out interactive features. Don't worry about making it pretty yet—fonts, colors, and pixel-perfect layout can all come later. Also, update your development plan as you discover more about what you want to prioritize, what you can expect to implement, and what you may need to mock up

Step 1: Revisit POV & Inspiration

As you complete the core features of your app, it's important not to lose sight of your point of view and inspiration. In 2-3 sentences, summarize your POV and key inspirations for your app. For most teams, this will be a revised version of your earlier POV & inspiration. Keep your POV within 10 and 20 words. (Hint: "a one-stop-shop for X" is not a POV because it just mashes everything together)

Step 2: Render JSON data

Your webapp should read a JSON data file (such as data.json) with pre-stored data. Your code should ruse that data to customize handlebars templates. Populate your app with it by manually adding new objects to the data variable. It is not required that your data.json file dynamically update with new data. Refer to Lab 4 & Lab 5 for help.

Step 3: Unique Interactions

What is it about your app that makes it unique? What specific features make it stand out?

Now is the time to implement the features that separate you from the other apps. Think about the core functionality of your app. What needs to be done to make its features work? In an app that manages goals and todo lists, you might be implementing the feature to make events and add/delete them from a task list. If you were developing Yelp, you might implement a feature to search for suitable restaurants based off of filter preferences and the user's location this week. With Yelp, you might also develop the review system, where users can write reviews for each place and rate it.

Your goal is to provide the users with more ways to interact with your app, including the most important interactions required for your app, by the end of this week.

Step 4: Wizard of Oz Login

Making a login screen will help you keep track of individual users and their unique features or progress within your app. Using Wizard of Oz techniques, create a fake login, which simulates the experience of logging in. You may ask for a login and password, which on submit leads the users to the first page of your app. You are not required to save the information or actually authentication via username and password. If you do use real auth, great! Just remember to include any needed login/password information in your writeup :).

Step 5: Update Development Plan

Follow the development plan you created last week, and update it as you go. Include a sum of the expected and actual number of hours for each teammate in the top left hand corner. Mark 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. 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.

Step 6: Task Description

Write a 2-sentence description of a task you'd like us to try without giving away the exact instructions on how to accomplish the task. For example, if you ultimately want users to visit a newsfeed page and subscribe to it, the instructions might be "find a way to keep up to date with current events outside of the app." In another example, if you were developing Uber, you might want the user to enter a destination, use the fare estimate feature, and compare UberX from Uber Black, but the instructions might say "Find the cheapest way to get home from UCSD." The task should not require the TA provide any personal information or create an account (including third party platforms). If your task requires any such information, create a dummy account or dummy information for the TA to use and add it in the description.

Student Examples

Here are some examples from prior years. Note assignments change from year to year, so use these examples as a reference, see where they succeed/breakdown, and make sure your final submissions adhere to the rubric for this year.

Development plans: (1)

In this assignment, we want to emphasize the user task at this stage of development. The interface should be fluid with respect to a particular task made intuitively easy to step through as a user. For this assignment, this team would complete functionality by capturing all of the relevant information entered into the text boxes, and updating the content of each page with that new information.

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 made their app functional: you can create a sign-up, add activities, and see it reflected on the pie chart.

For both examples above, simply imagine that the data that supports the functionality of the apps are only temporarily stored in a data variable that is pre-populated with data from a .json file.

Team Submission

  • One paragraph on your point of view & inspirations for your app.
  • Write 2-3 sentences explaining what is the best way for a user to complete this task if your app did not exist. If people didn’t have your tool, how would they accomplish something similar today? Before you submit, do a quick search for similar apps out there.
  • The URL of the prototype (preferably on heroku) that you want us to see. Note: the URL must work at least until your assignment is graded. If it doesn't work, you'll receive no credit. Verify that you deployed your application to Heroku so you don't get a zero for an empty submission.
  • Readable, properly-oriented PDF Export of your A6 development plan.
  • Readable, properly oriented snapshot of your updated development plan. (We recommend making a Google spreadsheet and saving it as a pdf; this gives you a snapshot for comparison.)
  • A ~2-sentence description of the task you'd like us to try. This should include any needed login/password information.
  • The shared Github URL for your project.

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

Evaluation Rubric

Note: if you are a rare group of 2: pursue a dev plan that meets the rubric with a reasonable workload. If you are unable, you may propose an accommodation to this on Piazza; include a link to your dev plan.

  1. POV & Inspiration
    1. 2-3 sentences summarize the POV and inspirations for the app, and how the app is relevant to the studio brief.
    2. 2-3 sentences explain what is the best way for a user to complete this task if your app did not exist.
  2. Application
    1. Screens where reading JSON data is used are able to do so successfully and without error.
    2. JSON data used to create custom templated pages display information that is more meaningful than having pre-set data.
    3. User interface includes all applicable elements. Depending on the page, this may include navigation, content buttons, images, header, footer etc.
    4. All user interface elements function properly; they may use placeholder data.
    5. Functionality in each page does not lead to dead ends or errors.
    6. Every page performs a task that contributes to the overall goal of the app.
    7. There are no major violations to Nielsen’s heuristics.
  3. Link
    1. Development plan is updated, showing progress and additional tasks in the new version compared to the previous week, and includes a sum of the expected and actual number of hours for each teammate.
    2. Submission includes access to heroku dashboard and git repo. Your Heroku URL should be “a6-projectname.herokuapp.com”.
  4. Tasks
    1. 2-sentence task description provided. Task description does not give specific instructions, but describes a task that a real user might want to do.
    2. App's functionality for task described is complete in its interaction and causes no errors.