courses.pgbovine.net

A4: A skeleton and a plan – DUE Wednesday, Nov. 1 @ 12:30am

[The workload for the rest of the assignments will ramp up significantly since you need to start writing code and working toward creating a fully-functional web application. Please plan accordingly and get up to speed on frontend web programming.]

Step 1: Make a Development Plan

Using a Google spreadsheet, create a development plan for building your interactive app prototype. Provide a detailed plan for the next three assignments (A4, A5, and A6), and briefly summarize goals for the remaining assignments. By the end of A6, you will have a prototype that is interaction-design complete and ready for testing.

Your development plan should show a detailed and comprehensive task list for the next three weeks (A4, A5, A6) and briefly summarize goals for the last three weeks (A7, A8). For each, clearly state what needs to get done, what deadline, and how long you estimate it will take.

Make two task groups: 1) a conservative set that gives you a basic, design-complete application for testing; and 2) a stretch goal that you hope to accomplish. Write your component tasks so they are actionable and can be easily verified. They should be concrete enough for your peers to assess if they have been completed. "Set up results page" is too vague. "Display train times on results page" is better. In addition to basic and necessary tasks, also set stretch goals that you hope to accomplish and outside constraints that could slow your progress (i.e. out of town one weekend, busy with midterms during week 6, job interviews, etc). The exact structure/layout of the plan is up to you; do whatever will be the most clear to readers (such as your TA who will be grading your assignment).

Again, try to make your tasks as specific as possible, and avoid vagueness at all costs. The value of having specific tasks is that they will help remind your team of what exactly needs to be done each week. Tasks such as "Code up a profile page" are not good. Instead, try to write something more specific such as "Display user's username, email, and profile picture on the profile page".

See the Student Examples section for example development plan templates that you can adapt for your own.

Step 2: Wireframes

With your team, create TWO low-fidelity digital wireframes: 1.) the first page of your app, and 2.) an additional page. A low-fidelity wireframe provides the main details about the layout of a screen in your app and the rough information it holds, but leaves out smaller details and styling. You may use PowerPoint, Keynote, or Google Slides to create your wireframe (or use more advanced wireframe/mockup creation software if you like).

In your wireframe, the first page of your app should NOT be a login screen. Assume that the user has already logged in. What does the first page that contains substantial content look like? That is the "home page" you should be designing. It should include suggestions that you found valuable from heuristic evaluators on your paper prototypes (A3).

The second page in your wireframe should illustrate a major screen, displaying the core functionality. The purpose of that screen is to give us an idea of how you expect users to interact with it.

For now, you don't need to worry about aesthetics for either screen. These wireframes are important to help you organize your app and decide how you would like to implement it in code later.

Step 3: Create Skeleton and All Links

Create a webpage prototype of all screens of your app, with one HTML webpage for each screen. Include a complete set of navigation links on all webpages. This means that every link and button is functional; there are no dead ends (i.e. where a user cannot go back) and no dead links (i.e. a non-working link/button). Although the links should all work, the pages they lead to need not be complete or filled with content yet–you can use empty placeholder pages instead. Now you should have a 'skeleton' for your web application.

Make sure your TA can visit your webpage prototype at a public URL and click around to navigate to all webpages within your prototype without getting stuck on any particular dead-end page.

Step 4: Code up Two Screens of Your App

After creating the full skeleton of your app (Step 3), you will create the home page (the first page you created a wireframe for) in HTML/CSS/JavaScript code. Then, you will flesh out one more major screen (the other one you created a wireframe for) by adding in all the details of that screen. Add the content and set up the functionality that will be required on those pages. For example, if the functionality includes an upvote button, you should create the button, though the upvoting functionality does not need to work yet. (But you're always encouraged to get extra work done early if you want!)

Remember, when functionality is peripheral to your web application, you may Wizard-of-Oz it. See the FAQ for guidance.

Refer back to your labs for HTML, CSS, Bootstrap, and JavaScript help. Lab 1 is also helpful for understanding how to keep good source control habits with your team on GitHub. We recommend that you create a public GitHub repository for your code right now, since in later assignments, you will be required to have a public repository for your TA to grade your code.

Step 5: Revisit the Design Theme

Carefully re-read the design theme for this year. Write 3–4 sentences summarizing how well your project fits this year's theme, why it fits, and what specific users you are designing for.

Student Examples

Here are some examples of development plans. If you want, use File -> Make a copy... to copy over the formatting for each spreadsheet to form the basis for your own plan.

  • (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.

Assignment Submission

Submit a single well-formatted PDF file for your entire team with the following items concatenated within it:

  • Names and PIDs of all of your team members. (If you forget someone's name, they will not get credit for this assignment.)
  • A snapshot of your development plan. We recommend making a Google spreadsheet and saving it as a PDF; this gives you a snapshot for easy comparison. Look up tools for joining multiple PDFs into a single one for your submission. Do not send us a link to your live Google spreadsheet, since it will change over time. (Development Plan)
  • An image or working web link to the two wireframes you made (Wireframes)
  • URL of your webpage prototype. Since the key links should create a "full skeleton", your TA should be able to easily find the two fleshed-out pages (home page + one other screen) by testing the key links. Note: the URL must work at least until your assignment is graded. If it doesn't work, you'll receive no credit. Very important: the contents of this URL should not change in the upcoming week while your TA is grading this assignment, or else that is a violation of the academic honesty policy; test your new changes at a different URL. (Skeleton Webpage & 2 Coded-up Screens)
  • A paragraph summarizing the user, task, and how your project meets the class's design theme. (Revisit the Design Theme)

Submit your single formatted PDF in Gradescope to the bin for your studio section. Only one team member needs to submit on behalf of the entire team.

Evaluation criteria & Grading rubric

The rubric below contains criteria that are worth one point each and will be graded independently and in a binary fashion.

  1. Development plan is included in the submitted PDF itself (rather than a link), is easy for your TA to read and understand, lists specific tasks (no credit for tasks that are too vague), who on the team is responsible for each task, and estimated/actual time for the coming weeks.
  2. Wireframes convey the task or goal of the page. Another person can look at the wireframe and understand what function the page will serve.
  3. Wireframes focus on displaying the critical functions of the page rather than styling.
  4. Wireframe #1 includes all the buttons/text boxes/functions necessary to perform its main action on the page, without actually having to be fully functional.
  5. Wireframe #2 includes all the buttons/text boxes/functions necessary to perform its main action on the page, without actually having to be fully functional.
  6. Key links in webpage prototype do not have any dead ends or disconnected parts.
  7. Screen #1 is easily discoverable by following key links (i.e., not deeply hidden in too many layers of links), and is complete in a way that clearly shows users what can be done on that screen.
  8. Screen #1 includes all features or buttons needed to perform all tasks that can be done on that screen.
  9. Screen #2 is easily discoverable by following key links (i.e., not deeply hidden in too many layers of links), and is complete in a way that clearly shows users what can be done on that screen.
  10. Screen #2 includes all features or buttons needed to perform all tasks that can be done on that screen.
  11. "Revisit the Design Theme" paragraph clearly connects the project to the class's design theme.
  12. "Revisit the Design Theme" paragraph has a clear audience of users that the project is designed for.

Due In Studio: Teammate Assessment

During studio, click here to assess how each of your teammates contributed to this assignment.


Frequently Asked Questions

Q: What are guidelines on using Wizard of Oz in our project?

A: The reason we implement things is to learn about how to better design the interaction, not to do busy work. By making your project more realistic, you will uncover design issues that may not be apparent with Wizard of Oz alone. Your final project will be evaluated on the design of the interactions, and you are certain to produce a better interaction if it is more realistic. Good heuristics to decide what to implement:

  1. If you can implement it, then do it.
  2. You should be focusing on the interaction design. If implementing it will take an inordinate amount of time, you should Wizard of Oz it in the most realistic way
  3. If it would be impossible for anyone to implement it, then your design is wrong.

To make this more concrete, consider the following two examples:

  • You are building a navigation application for pedestrians. This application will leverage GPS information to support wayfinding. In this instance it would be highly recommended that you implement GPS functionality for real, since it is central to the application.
  • You are building a social photo sharing application. Among a host of other features, you'd like this application to geotag photos if a GPS location is available. In this case, it may be appropriate to Wizard of Oz the GPS functionality, since it is not central to the application.

While implementing GPS functionality would take the same amount of effort in both cases, there is a much larger potential payoff for implementing it in the first case because it impacts a much larger portion of the interaction design.

Make sure to think about the easiest way to approximate the functionality you seek. For example, if you need basic phone call or message functionality, you may be able to make something sufficient just by using e.g., <a href="sms:">Send a SMS</a>


Frequently Asked Questions

Q: What web frameworks or open-source tools can we use?

A: Anything you want, as long as you can meet the requirements of each assignment's rubric. Note that the teaching staff may not be able to help you beyond what is covered in the labs, so choose wisely (i.e., make sure the entire group is comfortable with the stack and none of you is burdened to handle things alone). We will only officially support the web stack that we teach in labs, so if you go above and beyond this basic stack, then make sure your team is fully comfortable using your chosen tools.

Q: Where can I find more web development tutorials and resources?

A: As a starting point, check out our web dev resources section.