Skip to content

Define how you’ll determine if your app is successful & how you’ll be graded.

Notifications You must be signed in to change notification settings

ltw-webdev-6/success-criteria-definitions

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

2 Commits
 
 
 
 
 
 
 
 

Repository files navigation

summary time deliverables
Define how you’ll determine if your app is successful & how you’ll be graded.
1 hour
2 rubrics on GitHub

Success criteria definitions

Overview

The web app team projects are almost independent projects; you define everything about it: the topic, the goals, the outcomes & how to grade yourself.

Before we start to really dig into everything you need to set your expectations for the outcomes & grades.


Details

Determine all the goals that your project needs to meet—and write them all down.

You’ll need 2 sets of goals:

  1. Set of goals & a rubric for the UX
  2. Set of goals & a rubric for code

Ask yourselves lots of different questions to try to determine each goal. And within that goal what would be considered bad & good?

What is important to your team?

  • Good teamwork?
  • Strict convention following?
  • Ability to multitask?
  • Ability to fill many roles?
  • Good leadership?
  • Cohesion?
  • Good sprint planning & execution?
  • etc.

How will your team determine success?

  • Meets goals?
  • Quality personas?
  • Lots of research?
  • Good presentation?
  • Good results in testing?
  • Well produce wireframes?
  • Well produced prototype?
  • Ease of use?
  • Adherence to design best practices?
  • Catchy design?
  • Responsiveness?
  • Accessibility?
  • Performance?
  • Code quality?
  • Commit quality?
  • Code deduplication & maintainability?
  • Validation?
  • Critiques from peers?
  • etc.

How will you determine & grade quality?

  • What defines a good persona vs. a bad persona?
  • What defines quality research vs. poor research?
  • What defines ease of use vs. poor usability?
  • What defines quality responsiveness vs. not responsive?
  • What defines accessible vs. inaccessible?
  • etc.

Goal

Create 2 rubrics as GitHub Issues attached to your web-app repository. Label both Issues with the “product” label. And “Pin” the issue: there’s a button near the bottom of the Issue’s screen’s righthand column.

  1. A rubric defining your success criteria for the UX component
  2. A rubric defining your success criteria for the coded app component

Example Markdown rubric code

Here’s the table generating code you’d need to put into a GitHub Issue to generate a visible rubric table.

| | 0 points | 1 points | 2 points | 3 points |
| --- | --- | --- | --- | --- |
| **Accessibility** | No considerations | Added some alt attributes, nothing else | Just the basics: alt attributes, roles | Accessibility is well considered and tested |
| **Code quality** | Barely started | Indentation is barely existent, lots of validation errors, very poor semantics | Decent indentation, just a couple validation errors, decent semantics | Well indented, fully valid, good semantics |
  • Change the point values
  • Add as many lines as are necessary
  • Add the titles & different descriptions

We’re following an Agile approach, so the rubrics can be massaged over time. But don’t just delete rows because you were unsuccessful at the goal—own up to your failure. Honesty is better.


Hand in

Show the teacher both completed rubrics for marks.

But do make sure to put the 2 rubrics as GitHub Issues attached to your web-app repository. Label both Issues with the “product” label. And “Pin” the issue: there’s a button near the bottom of the Issue’s screen’s righthand column.

About

Define how you’ll determine if your app is successful & how you’ll be graded.

Resources

Stars

Watchers

Forks

Releases

No releases published

Sponsor this project

 

Packages

No packages published