Answers.Body: <p>I'm going to offer an answer that is orthogonal to your question by looking at a deeper question. The "work-flow" you seek may actually be irrelevant to the problem of (a) being effective with your students and (b) being efficient with your own time and effort. Hopefully, the answer here will be valuable to others who don't have quite the same context that you do. I'll focus on the small number of students and the long daily sessions, primarily. The answer will be less valuable for larger groups and/or shorter sessions, but some of it might be adapted. </p>
  
  <p><strong>tl;dr: Keep continuously aware of their progress, day to day, with short conferences. Restrict your evaluation to the most important issues as they evolve.</strong></p>
  
  <p>With only a few students and long sessions, there is really little reason to have to look at everything in detail, captured by GIT, or otherwise. This is one situation in which printouts sounds like a terrible idea also, though that is often the most efficient method of looking at student production. </p>
  
  <p>You can both reduce your work and be more effective if you require some sort of teamwork, such as pairing. If you only have five projects to keep straight it is much easier than ten. You can, in long sessions, set aside say one hour in which each team consults with you for a few minutes on their current work and issues. They show you their current product and you give them advice. But if they are pairing, they will need less advice. </p>
  
  <p>One concern you likely have is honesty. Looking at each student's (team's) work for a few minutes each day (or so) lessens the likelihood that you won't notice bad behavior. </p>
  
  <p>One thing that will help you keep track of the students and keep them on track as well is to keep a running record of their progress. A Hipster PDA (discussed elsewhere on this site) is one way. A spread sheet is another. Decide before the course starts which low-level results/behaviors/activities are to be encouraged and valued and keep a record of these for each team, each day. A check mark is all that is needed for many things, though occasionally a written note (to them and/or to yourself) might be valuable. It is a continuing and cumulative process, not an all-or nothing evaluation at the end. </p>
  
  <p>If students work in teams you can also keep yourself aware of each student's contributions to the team simply by listening to how they interact when you confer with the team. A quick notation on an index card captures your impressions for re-confirmation later. </p>
  
  <p>If you need to give advice on code quality you don't need to look at it all at once, but can look at fragments (one class, one method) in a review and get a sense about whether they have it right or not. You won't catch every flaw, but you aren't guaranteed to catch everything in an overall review either. If several teams are going wrong in the same way you can alter your "lectures" to guide them back. If a single team/student is off the rails you can focus your efforts there, instead. None of this requires that you capture everything in a repository or even that you comprehensively review their work. </p>
  
  <p>If design is one of your goals, you can focus your daily review on that, warning them the day before that you need to see designs, either on paper or otherwise. </p>
  
  <p>Even if you don't want the students to work in pairs/teams, you can still use a different form of teamwork. You can, for example, set up a rotating peer review system in which each student briefly confers with another on each student's work. Each can give advice to the other. I suggest that the advice be written, say on index cards, with both student's names listed as well as the questions/advice/etc. You can quickly review these cards and can give credit to both the one receiving the advice (for responding appropriately) and the one giving it (for being a good colleague). You can use this instead of conferring with the students/groups yourself on some or all days. Students can teach each other and will if you give them the opportunity and encourage good behavior. </p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-04-18T13:06:58.810Z
Answers.LastActivityDate: 2018-04-18T13:06:58.810Z
Answers.UserDisplayName: Buffy
Body: <p>I am preparing to teach an intro to app development class to approximately 10 students who are there voluntarily this summer using Swift and Xcode. The course will consist of daily, 5-hour class meetings over the span of 3 weeks. All development will be on Macs out of necessity; some will be school-issued devices, but some will be the personal devices of the students.</p>
  
  <p>For curriculum, I will be following Apple's <a href="https://itunes.apple.com/WebObjects/MZStore.woa/wa/viewBook?id=1118575552&amp;mt=11&amp;v0=www-us-education-everyone-can-code-book-app-development-swift-preview" rel="nofollow noreferrer">Intro to App Development with Swift</a>. For most of these high school students, this class will be their first exposure to programming entirely, so I need to bear that in mind as I consider what tools to teach them alongside the language and software of basic iOS development. Given the compressed nature of the course and the introductory feel thereto, I do not want to overload or distract them from the main focus of the course.</p>
  
  <p>All that being said, I am trying to come up with the smoothest workflow for both them and me in terms of file submission, feedback, and assessment. </p>
  
  <p><strong>What are simple, beginner-friendly ways of collecting and grading work in an iOS app development class?</strong></p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2018-04-18T03:40:14.900Z
Comments.Text: I had a very similar issue working with Android projects, and really didn't find any satisfactory solutions. I'm eager to see the answers people come up with.
Comments.UserDisplayName: Ben I.
Tags: <grading><assessment>
Title: How to collect and grade Xcode work
ThreadText: # How to collect and grade Xcode work
  
  (Asked by: username_0 on 2018-04-17)
  
  I am preparing to teach an intro to app development class to approximately 10 students who are there voluntarily this summer using Swift and Xcode. The course will consist of daily, 5-hour class meetings over the span of 3 weeks. All development will be on Macs out of necessity; some will be school-issued devices, but some will be the personal devices of the students.
  
  For curriculum, I will be following Apple's [Intro to App Development with Swift](https://itunes.apple.com/WebObjects/MZStore.woa/wa/viewBook?id=1118575552&mt=11&v0=www-us-education-everyone-can-code-book-app-development-swift-preview). For most of these high school students, this class will be their first exposure to programming entirely, so I need to bear that in mind as I consider what tools to teach them alongside the language and software of basic iOS development. Given the compressed nature of the course and the introductory feel thereto, I do not want to overload or distract them from the main focus of the course.
  
  All that being said, I am trying to come up with the smoothest workflow for both them and me in terms of file submission, feedback, and assessment.
  
  **What are simple, beginner-friendly ways of collecting and grading work in an iOS app development class?**
  
  **Tags:** grading, assessment
  
  > **Comments:**
  > **username_1**: I had a very similar issue working with Android projects, and really didn't find any satisfactory solutions. I'm eager to see the answers people come up with.  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_2 on 2018-04-18. Score: 2
  
  I'm going to offer an answer that is orthogonal to your question by looking at a deeper question. The "work-flow" you seek may actually be irrelevant to the problem of (a) being effective with your students and (b) being efficient with your own time and effort. Hopefully, the answer here will be valuable to others who don't have quite the same context that you do. I'll focus on the small number of students and the long daily sessions, primarily. The answer will be less valuable for larger groups and/or shorter sessions, but some of it might be adapted.
  
  **tl;dr: Keep continuously aware of their progress, day to day, with short conferences. Restrict your evaluation to the most important issues as they evolve.**
  
  With only a few students and long sessions, there is really little reason to have to look at everything in detail, captured by GIT, or otherwise. This is one situation in which printouts sounds like a terrible idea also, though that is often the most efficient method of looking at student production.
  
  You can both reduce your work and be more effective if you require some sort of teamwork, such as pairing. If you only have five projects to keep straight it is much easier than ten. You can, in long sessions, set aside say one hour in which each team consults with you for a few minutes on their current work and issues. They show you their current product and you give them advice. But if they are pairing, they will need less advice.
  
  One concern you likely have is honesty. Looking at each student's (team's) work for a few minutes each day (or so) lessens the likelihood that you won't notice bad behavior.
  
  One thing that will help you keep track of the students and keep them on track as well is to keep a running record of their progress. A Hipster PDA (discussed elsewhere on this site) is one way. A spread sheet is another. Decide before the course starts which low-level results/behaviors/activities are to be encouraged and valued and keep a record of these for each team, each day. A check mark is all that is needed for many things, though occasionally a written note (to them and/or to yourself) might be valuable. It is a continuing and cumulative process, not an all-or nothing evaluation at the end.
  
  If students work in teams you can also keep yourself aware of each student's contributions to the team simply by listening to how they interact when you confer with the team. A quick notation on an index card captures your impressions for re-confirmation later.
  
  If you need to give advice on code quality you don't need to look at it all at once, but can look at fragments (one class, one method) in a review and get a sense about whether they have it right or not. You won't catch every flaw, but you aren't guaranteed to catch everything in an overall review either. If several teams are going wrong in the same way you can alter your "lectures" to guide them back. If a single team/student is off the rails you can focus your efforts there, instead. None of this requires that you capture everything in a repository or even that you comprehensively review their work.
  
  If design is one of your goals, you can focus your daily review on that, warning them the day before that you need to see designs, either on paper or otherwise.
  
  Even if you don't want the students to work in pairs/teams, you can still use a different form of teamwork. You can, for example, set up a rotating peer review system in which each student briefly confers with another on each student's work. Each can give advice to the other. I suggest that the advice be written, say on index cards, with both student's names listed as well as the questions/advice/etc. You can quickly review these cards and can give credit to both the one receiving the advice (for responding appropriately) and the one giving it (for being a good colleague). You can use this instead of conferring with the students/groups yourself on some or all days. Students can teach each other and will if you give them the opportunity and encourage good behavior.
  
  
  ---
  
  