A6: Meat on the bones Team submission

In this assignment, complete the interaction flow, fleshing out the interactive elements. 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

1: Update your goals

As you dive into implementation, don't lose sight of your high-level goals.

  • Bring your 1-2 sentence (10-20 word) POV up to date. For most, this will be a revised version of your earlier POV. (Hint: "a one-stop-shop for X" is not a POV because it just mashes everything together)
  • Write a 1-2 sentence description of a task you'd like us to try, without giving instructions on how to accomplish the task. Write task using concrete example nouns (e.g., ‘monopoly’) rather than pronouns (e.g., ‘any game’). 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." Another example task: "find the cheapest way to get home from UCSD in less than 45 minutes." The task should not require the TA provide any personal information or create an account (including third party platforms). If your task requires personal information, create a dummy account/information for staff to use, and add it to your submission.
  • Write 2-3 sentences explaining the best way for a user to complete this task if your design did not exist. If people didn’t have your tool, how you recommend they accomplish something similar today? Before you submit, think about general-purpose tools (e.g., text messaging, Google Docs), and do a quick web search for similar tools.

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.

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.

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 :).

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. (We recommend Google Sheets.)

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

  • Updated goals.
  • The URL for your A6 prototype (preferably on Heroku). The URL must work at least until your work is assessed. If it doesn't work, you'll receive no credit. (Verify that you've successfully deployed your application to Heroku; a broken app is a dumb way to earn a 0.)
  • Readable, properly-oriented PDF Export of your previous development plan.
  • Readable, properly-oriented PDF Export of your current development plan.
  • 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.

    Goals & Plans
  1. Presents team’s updated 1-2 sentence point of view on a concrete user need. Point-of-view does not offer a specific solution or violate a taboo. Hint: if you have to ask, stretch your thinking ;)
  2. 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.
  3. 2-3 sentences explain the best way for a user to complete this task if your design did not exist. You're not obligated to exhaustively search the far reaches of the Internet. But if it shows up in the first few results of a quick Google search…
  4. Development plan is updated, showing progress and additional tasks in the new version compared to the previous week. Includes a sum of the expected and actual number of hours for each teammate. (Broken links do not earn credit.)

  5. Application
  6. Submission includes access to heroku dashboard and git repo. URL is of the form “a6-projectname.herokuapp.com”.
  7. Screens where reading JSON data is used do so successfully and without error.
  8. JSON data used to create custom templated pages display information that is more meaningful than having pre-set data.
  9. User interface includes all applicable elements. Depending on the page, this may include navigation, content buttons, images, header, footer etc.
  10. All user interface elements function properly; they may use placeholder data (e.g., login UX works but no actual auth required; always render the same 'search results' from JSON).
  11. Functionality in each page does not lead to dead ends or errors.
  12. Every page performs a task that contributes to the overall goal of the app.
  13. There are no major violations to Nielsen’s heuristics.
  14. Complete, appropriate interaction functionality for task/POV described. Causes no errors.