MetaMood is a gamified Android application, developed from an existing paper-based health intervention program, designed to increase the motivation and engagement of participants. The development process followed a clinician-based design which was necessary to avoid exposing participants to an untested and unverified clinical tool. This paper describes design considerations and outcomes which could be useful for similar gamification attempts. It also presents the implementation and evaluation of a clinician review process, a vital step required before a full clinical trial. The success of MetaMood, evaluated through the results of the clinician review, suggests that a similar design, development, and evaluation process should be followed by future mobile e-health interventions before they are released through a public App Store.

In previous work we introduced a software studio course in which seventy students used continuous integration practices to collaborate on a common legacy code base. This enabled students to experience the issues of realistically sized software projects, and learn and apply appropriate techniques to overcome them, in a course without significant extra staffing. Although the course was broadly successful in its goals, it received a mixed response from students, and our paper noted several issues to overcome. This paper considers experimental changes to the course in light of our previous findings, and additional data from the official student surveys. Two iterations of the course and their respective results are compared. Whereas our previous paper addressed the feasibility of such a course, this paper considers how the student experience can be improved. The paper also considers how such a course can be adapted for more heterogeneous cohorts, such as the introduction of an unknown number of design and database students, or the introduction of online students.

Previous courses addressing the gap between student and professional programming practice have either isolated small groups' development in such a way that larger scale difficulties that motivate many professional practices do not arise, or have required significant additional staffing that would be expensive to provide in a large cohort core undergraduate software engineering course. We describe the first iteration of a course that enabled 73 students to work together to improve a large common legacy code base using professional practices and tools, staffed only by two lecturers and two undergraduate students employed as part-time tutors. The course relies on continuous integration and automated metrics, that coalesce frequently updated information in a manner that is visible to students and can be monitored by a small number of staff. The course is supported by a just-in-time teaching programme of thirty-two technical topics. We describe the constraints that determined the design of the course, and quantitative and qualitative data from the first iteration of the course.

Recently there has been rapid growth in the number of online courses and venues through which students can learn introductory computer programming. As software engineering education becomes more prevalent online, online education will need to address how to give students the skills and experience at programming collaboratively on realistic projects. In this paper, we analyse factors affecting how a supercollaborative on-campus software studio course could be adapted as a project-led supercollaborative MOOC.

Designers inhabit a world of constraints - the limitations that shape what solution designs are practical. In this provocation, I would like to suggest that we should not only be interested in the day to day business of identifying what the constraints are and what their impact is, but also in understanding the dynamics of how constraints come into being, how they evolve over time, and how to relax them. Unwieldy constraints are a keenly felt problem, especially when dealing with legacy systems, but how they grow and behave has not been examined greatly in the design community. To begin this conversation, I identify a small set of loose principles of how constraints grow around a system. And I propose Data Affordances as a way of considering how the technology we design today constrains or offers affordances for future design.