A5: Skeleton and a plan Team submission

This assignment evaluates whether we are straying from the high-level vision of our studio brief. We recognize how proper chronological planning helps us prioritize tasks and clarify the roles of team members, keeping us focused and preventing “scope creep.” We learn to classify essential vs. non-essential functionality. We balance the low-cost fidelity of digital wireframes/mockups against time constraints to concretize our idea (for this, we recommend using Adobe XD). We develop a feel for a “flowing” interaction using an html skeleton. Lastly, we lay the foundation and make our first online deployment.

The following rubric items are independently assessed. In general, evaluation works such that if the student/team meets, for instance, 9 out of 10 rubric items, then they have earned a grade of 90%. The assignment will not be graded unless it is submitted on a single, well-formatted, and easily readable pdf.

Optional project starter code (same tech stack as labs): https://github.com/DesignAtLarge/ixd-skeleton

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.

    Revisit the Brief
  1. A few detailed sentences identify your point of view, user base, and core interaction. Have they evolved? If so, how and why?
  2. A few detailed sentences summarize how they align with your studio brief & user need
  3. A few detailed sentences clearly demonstrate who the user is, a specific usage situation, and the user's motivations for using the interface. Hint: Look back at A3.

    4. Development Plan
  4. Create a column on a spreadsheet listing at least 12 actionable steps per person in your group necessary to complete the entirety of your app development, with future assignments as a rough guide.
  5. In four adjacent columns, assign realistic time estimates, a deadline, an “owner” responsible for completing each task, and identify tasks involving essential vs. non-essential functionality by assigning “high, medium, low” priority. Internally verify the prioritization is accurate, write justifications in a comments column, if needed, and identify potential obstacles or outside constraints, e.g. midterms, in the same column. Include a sum of the expected and actual number of hours for each teammate.

    6. Wireframes (can have color)
  6. A digital (non-functional) wireframe/mockup of your mobile home screen (no login screens). Leave out minor details and styling
  7. A digital (non-functional) wireframe/mockup of your next highest priority screen (no login screens). Leave out minor details and styling
  8. Visualize all potential interactions via content/buttons/text boxes/functions for your both home screen and second wireframes
  9. Content of both wireframes should be specific and not placeholders (eg. Lorem Ipsum)

    10. Screens (no color)
  10. Screens are HTML and CSS. The reason to omit color at this stage is to use the other visual tools available to you: scale, relationships, spacing, layout, etc. Once you get those right, then you can add color. There is no need to make image assets grayscale. Grayscale refers to CSS.
  11. Establish filesharing and source control architecture via GitHub and submit a clickable or easily typed link to your project repository. Deploy you application online (e.g., in Heroku). Make sure the grader has access to GitHub and live app links
  12. Based on the wireframe, use the content in the labs to code up a semi-functional home screen. Include all content/buttons/text boxes/functions sketched out in the home screen wireframe
  13. Link all interactive functions on the home screen to placeholder html pages where applicable
  14. Create a “flowing” sense by providing escape routes and removing dead ends
  15. Based on the wireframe, use the content in the labs to code up a semi-functional second screen, linking to the html skeleton where applicable. Include all content/buttons/text boxes/functions sketched out in the second screen wireframe
  16. Link all interactive functions on the second screen to placeholder html pages where applicable

Please submit a single PDF file with:

  • Revised brief
  • Link to development plan
  • Wireframes
  • Link to screens (GitHub and deployed app)

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 Plan Example: (1)

Here is a cool video of the dynamic nature of implementation plans throughout the project.

Wireframe Examples: (1) (2) (3)

Skeleton Example: (1)