Introduction

An emphasis on scientific action supports students in the construction of scientific knowledge and helps students to understand how to apply their knowledge at individual or community levels. Thus, there is a need for science educators to incorporate scientific action in their curriculum (McNeill and Vaughn 2012). Although, there may be a few ways to define scientific action, we follow Birmingham and Calabrese Barton (2014) in describing scientific action to mean developing capacities and behaviors in students to make actual positive change and impact in their environment, such as reducing food waste or increasing local recycling efforts to lower the community’s carbon footprint (Authors). When promoting scientific action among students, research has shown that it is important to contextualize the content (Buxton 2010), provide motivation to learn the content (Skamp et al. 2004), and engage with tools that enable knowledge to transfer into action (McNeill and Vaughn 2012). However, it can be difficult to design learning environments that engage learners in authentic investigation of science content while creating motivating tasks that will encourage action without compromising learning goals (Allchin et al. 2014). In this study we tackle the challenge of providing a context, motivation for learning, and means to transfer knowledge into action among middle school students by creating an environment that integrates socioscientific issues (SSIs) with the construction of mobile apps. Here, we provide a lens to understand educational challenges by describing the tradeoffs that we encountered in designing such a learning environment. Previous research has suggested that designers need to discuss the affordances and constraints unique to design iterations so that educators and curriculum designers can be informed about important changes and rationales for these changes that take place (Peppler et al. 2016).

Theoretical Considerations

We draw on three areas of scholarship to support the study goals–the use of SSIs in science education (Barton and Tan 2008), mobile learning (Price et al. 2014; Sharples and Pea 2014), and the programming of digital learning tools (Resnick et al. 2009; Werner et al. 2012).

Socioscientific Issues

Socioscientific issues are topics that encompass the products or processes of science that are typically controversial (Sadler and Zeidler 2005) when they are considered in light of both human and environmental impacts. Common socioscientific issues that have raised debate in society include the applications of cloning technologies, the causes of global warming, and the safety of genetic engineering. Teaching science through SSIs represents what we know best about how people learn. It makes science personally relevant (Karahan and Roehrig 2015); enables the use and practice of domain specific skills such as scientific reasoning and argumentation (Sadler 2004); supports collaborative inquiry-based instruction (Yoon 2008, 2011); and enables awareness of complex scientific issues that impact social and environmental conditions from multiple perspectives (Burek and Zeidler 2015). In addition, the notion of action has also been highlighted as an important goal for SSI instruction (Lee 2015). This moves students out of the place of “arm chair critic” (Hodson 2003) to a place where they can work to improve the communities they live in. However, action is challenging to enact as students are not exposed to ways in which they can apply their reasoning skills to real world activity and are given limited opportunities to demonstrate their content knowledge beyond capstone presentations and classroom debates (McNeill and Vaughn 2012). A recent content analysis of 122 SSI-themed studies in the top 5 science education journals found that less than 2% were focused on engaging in citizenship work which can be interpreted as an action orientation (Tekin et al. 2016). To address this issue, we build on an emerging trend in SSI education that enables students to create personally relevant tools (Karahan and Roehrig 2015) to provide them with mechanisms through which action can be taken.

Mobile Learning

The recent trends in mobile learning have also revealed mechanisms for students to take action. The unique affordances of mobile learning platforms such as the ability to move to different locations along with technology-enabled affordances like location-aware sensors have been leveraged to engage learners in contextualized learning activities (McQueen et al. 2012; Sharples and Pea 2014). Consequently, research in using mobile apps to support learning has shown promising results in promoting student engagement and motivation in STEM (Grover and Pea 2013; Ni et al. 2016; Price et al. 2014). For example, Ni and colleagues (Ni et al. 2016) found that engaging students in making mobile apps for socially beneficial purposes proved motivating to them because they could have a direct hand in encouraging change in community behavior that they believed was important. However, many mobile learning initiatives have tended to put the learner at the user end of mobile app engagement rather than allowing learners to construct the apps themselves (Kearney et al. 2012). In this learning scenario, only the designers of the mobile app have control in determining how the app will function in addressing specific purposes whereas users have little control over function or purpose (Burrell 2016). A specific goal of this study was to engage students in designing mobile apps that could serve students’ own chosen function and purpose.

Programming Digital Artifacts

Relatedly, designing and then developing the mobile app requires programming ability. Programming can help to develop confidence in learners to deal with complex phenomena, work through challenging problems, and promote the setting and achieving of goals (Barr and Stephenson 2011). Creating digital artifacts has been shown to develop learners’ reasoning skills while simultaneously embedding knowledge in relevant cultural and personal activity (Resnick et al. 2009; Werner et al. 2012). Furthermore, where collaborating on designing and constructing digital artifacts has been shown to help student learning particularly when pairing less experienced students with more experienced students (Denner et al. 2014) this approach aligns well with socioscientific issues instruction. With the advent of blocks-based programming platforms such as Scratch (Resnick et al. 2009), novice programmers are supported with computational logic that is built into the programming environment thereby eliminating frustrating syntax errors. This has, in part, influenced the marked increase in interest in helping all students become programming literate such as Hour of Code, which offers web-based coding lessons and tutorials (https://hourofcode.com/); and Girls Who Code, which provides summer, school year, and after-school programs (https://girlswhocode.com/). Yet, a major challenge exists in terms of finding authentic ways to integrate computer science with more mainstream subjects such as Science and Math in order to contextualize and make computer programming more relevant (Sengupta et al. 2013).

Solving Local Socioscientific Problems by Constructing Mobile Apps

In this study, we aim to address the challenges in the aforementioned literature through the design and construction of mobile apps that investigate a local socioscientific issue that has importance in the students’ local environment. In selecting the technological platform, we considered a few mobile learning apps such as the SKIES Mobile App (http://www.skieslearn.com) and the App Lab (https://code.org/educate/applab). In most cases, these applications lacked some functionality that could support our study’s goals. The SKIES Mobile App, for example, allows students to share information such as self-recorded videos, experimental results, or drawings in response to classroom activities. However, only portions of the app are free, and accessing the complete service would cost money. Additionally, this tool does not allow students to revise or remix the app, which ultimately would not allow students to learn how to program. While the App Lab is a programming environment where learners can create apps, this tool limits users’ abilities to perform tasks essential to real-world inquiry, such as data that can be collected through embedded sensors (e.g., GPS, accelerometers, cameras).

Thus, we decided to use the mobile learning platform called App Inventor to support our goals of programming an app to conduct local investigations. The App Inventor platform uses a graphical programming language similar to Scratch in which computational procedures are built into easily assembled blocks (http://appinventor.mit.edu/explore/front.html). Grover and Pea (2013) highlight several benefits of using tools like App Inventor to promote computational thinking, interest, and access. They write that such tools are underpinned by the principle of “low floor, high ceiling,” which means that the environment has a low threshold for learning the initial programming language but embeds opportunities for more advanced computational investigations (Pokress and Veiga 2013). In addition, the App Inventor platform itself, has embedded blocks that users can program for mobile data collection purposes such as location awareness.

The broad goal of the project was to understand the extent to which building mobile apps with an SSI focus could motivate students toward scientific action with content specifically anchored in science. Through two design iterations, we found several important trade-offs to consider in the design of curricular activities that appeared to have an impact on student learning and participation outcomes. In this paper, we first describe the design of our curricular activities in the two design iterations that encompassed a spring and a fall elective class with 7th grade students. We discuss changes that were made in each class’s design in order to improve student learning and participation outcomes and we describe the tradeoffs that similarly-minded designers should consider when developing learning programs with these educational goals.

Methods

Design and Intervention

In this exploratory study, we use a design-based research (DBR) methodology. DBR studies require interventions to run through cycles of conceptualization, design, implementation, evaluation, and redesign until results show promising outcomes in learning measures (McKenney and Reeves 2019). Both elective courses ran twice a week for 45 min each day over a 12-week cycle. The curriculum was delivered in 3 blocks. In the first iteration, block 1 focused on helping students learn the App Inventor programming language. Students were given tours of code, asked to create mini-apps such as how to make sounds and how to create an action by shaking the mobile tablet, and introduced to app cards that taught students more nuanced programming functions. During block 2, students explored the meaning of socioscientific issues first by learning about global challenges such as climate change, hurricanes, and the overabundance of garbage. They were then asked to think about their local community and issues related to science that they could examine. They brainstormed issues that they wanted to solve or that they could relate to, and that could be amenable to integration in an app. Next, in teams of two, students built paper prototypes and constructed their apps. Finally, in block 3, students tested and revised their apps. Based on results from the first iteration, several design changes were made in the second iteration. First, the topic of SSIs was presented before any App Inventor programming instruction. We differentiated roles between teams of students to focus either on the programming or on the science. And we limited the number of programming ideas that students could use in the construction of the app.

Participants

We recruited 25 seventh-grade students who chose to participate in our study as an elective course in the spring and fall of 2016 from a public school located in a large urban school district in the north east part of the United States. In the spring semester class, 13 students (6 female and 7 males) participated and in the fall semester class, 12 students (4 females and 8 males) participate.

Data Sources and Analyses

Data collected in the study included a pre- and post-intervention survey with questions that asked about students’ knowledge of socioscientific issues and programming, and interests in the application of science and technology. The survey included 10 Likert-scale questions with open-ended questions added for students to explain their ratings. Questions included:

  • Do you think science is useful in your everyday life?

  • Do you think learning science helps you to take action in solving problems in your community?

  • Do you think learning how to make apps helps you to take action in the community?

  • Do out think you will use the mobile app you have developed?

  • Has you interest in science and technology improved based on your participation in this course?

We conducted individual 20-min post-intervention interviews with students. The interview probed their ideas related to the research goals as well as students’ opinions about how the class was structured. There were 13 semi-structured questions with multiple subquestions. Interview questions included:

  • Tell me about your experience building your final app.

    • What does your app do? What motivated you to choose the topic of your final app?

  • Can you tell me what socioscientific issues are?

    • Is the problem that your app solves a socioscientific issue?

    • Has building the app helped you see why these issues are important in your life? How?

  • What would you have changed in the way the class was taught?

In addition, the 14 apps that were constructed in teams over the two iterations were analyzed to understand what students had created, what they had learned from the programming activities, and how they applied it in their project. Observation field notes taken by members of the project team were also kept throughout the course. These observations were focused on understanding the extent to which students were engaged and experiencing challenges both in content and interpersonal interactions. Since the methodology was exploratory and design based in nature, all data sources for this study were mined qualitatively and discussed among the project team.

Results

The majority of students were able to produce a working app in both iterations of the course but we found that what kind of app they produced and the apps ability to function in terms of our research goals varied between iterations. We also found that student interests and knowledge of SSIs and programming differed between the two iterations. In Table 1, we list the apps that students created and a brief statement of the purpose of the app. These descriptions have been summarized from what students said in their final presentation of their app project and in their post-intervention interviews. We follow the table with a detailed discussion of the design challenges and associated tradeoffs that are hypothesized to have impact on the study goals.

Table 1 App project descriptions (1-team from first iteration; 2- team from second iteration)
Full size table

Programming or Socioscientific Issues First?

Recall from our description of the first design iteration of the project, that we worked with students first to learn programming and then to integrate this with SSIs. This proved to be very motivating to students. From observation notes, we saw that students started on their app project as soon as they came into the classroom even before the lesson began. However, this happened at the expense of students’ learning what SSIs were and what constituted local SSIs that they could help to improve. Despite continual redirection away from tinkering with the code, students remained disengaged from the science content in the second block where instruction of SSIs occurred. This resulted in student teams choosing to make apps that had little to no local SSI content. For example, one team created The Distraction App (1–3 Table 1) that monitored how much time they spent surfing the internet rather than doing their homework. If they managed to stay on task for a period of time, an emoji appeared to congratulate their effort. Another team created an app that would enhance imagination through an exploration of unicorns and griffins–The Magical Creatures App (1–5 Table 1). While there appeared to be some personal relevance embedded in these artifacts, there was little that could be said to encourage action in a local SSI. Furthermore, in response to the survey question, “what are socioscientific issues?” only four students out of 13 were able to provide a coherent and accurate definition that included knowledge of SSIs as social issues with scientific content and that SSIs could be found in local contexts and addressed through local activity. Nevertheless, in their interviews, the majority of students said that their interest in science and technology improved as a result of participating in the course.

Based on these results, we wanted to see if we could improve on student understanding of SSIs by manipulating the design of the course. Rather than beginning with the App Inventor programming activities, in the second iteration, we started with a lengthy investigation of SSIs. This enabled a more in-depth investigation of the SSI content. We also limited the topic to investigating one’s carbon foot print in the local environment so that we could scaffold instruction with essential scientific information rather than having to address content in idiosyncratic student-chosen topics. In the end, all artifacts addressed issues of environmental impact which were social, scientific in nature, and included some action that could have local impact. For example, one group designed an app that identified high or low carbon packaging used by local restaurants (2–6 Table 1). This information could be crowd sourced, shared, and used by community members to make choices about where to eat. Survey and interview responses from students in the second iteration also showed a deeper understanding of the science content and the relationship between science and human activity and the environment. On the topic of how foods exhibit a carbon impact, one student commented, “I didn’t know cottage cheese had carbon dioxide, like just pure CO2. I knew like fizzy drinks had [it] cause that is what they are…carbonated drinks, but I didn’t know cottage cheese had [it]. I think it is a shelf-life thing. A lot of companies do that…they are more worried about the products than [the] environment.”

However, with the delayed introduction to the App Inventor programming activities, students in the second iteration discussed challenges to this design change. In response to the question about what they would change about how the class was taught, one student said, “Listening to more about programming rather than listening to how climate change is affecting our world.” Another student said that, “the beginning wasn’t really that fun.” This sentiment was captured as well in the observation notes during those classes focused on delivering the SSI content such as the following comment, “GregFootnote 1 asked me three times now, when they would start making and programming games (Day 4)”. However, despite students’ obvious interest in programming over learning about SSIs, they were able to reflect on how their actions and daily choices could make a difference for the environment. In his interview one student said,

I learned that throwing away plastic bags has an effect on the environment, because like when you throw away plastic bags they can go to a landfill and they all just sit there and it takes them years to go away so it’s not good for the environment and if they are burned they can produce a lot of like you know toxic chemicals that can pollute the air. So, like my family we have this bin where we keep all the plastic bags in and I have always wondered like why my mom doesn't just throw away the plastic bags and now I see why she does that. (Post-interview, ID 7, Marco)

Interestingly, in the pre-intervention surveys, this student said that he couldn’t readily see what he was learning in school science as all that applicable to his everyday life. The data reported here provide evidence of students’ preferences for app programming over learning the science content. It is a useful tradeoff to consider especially if time is limited, or when considering what the content goals are.

Differentiating Collaboration Role

Collaboration was emphasized throughout both courses. However, how teams organized their work differed across iterations. During the first iteration, students were given the freedom to decide how to distribute project tasks between themselves. We thought that by allowing students to direct their app design with little instructor monitoring, this would create a less intimidating environment for the teams so that they could choose where to apply their respective strengths and interests. However, this happened at the expense of both members equally engaging critically with programming or with SSI content. With little exception each team had one member who took charge of all the programming. For example, the PAS app (1–2 Table 1) was mainly constructed by Pete. His partner Craig did not do any programming until the fifth week of the class and only did so because Pete was absent. In their respective interviews, Pete and Craig offered differing evaluations of their contributions. When asked what they saw were the benefits of working on a collaborative team, Pete responded to the exit interview question,

I think there are pros and cons of both [working alone or working together]. One of the cons [you face] is you could get a teammate who doesn’t really do much but there is nothing you can really do about that. Pros is if you have someone that is working then it can be a lot less stressful as you both contribute to a big project as you split the work 50/50.

Craig said that he preferred “working in teams, so that one person wouldn’t have to do all the work and it would be equally divided.” He described his contribution in this way, “I had figured out the nutritional value and [Pete] had programmed the screens linking it to the menu.” From observation notes, we saw that while Pete was working hard each week, Craig spent most of the time socializing and distracting others in the class.

In the second iteration we decided to formalize the contributions in such a way that the work could be perceived as more equally distributed. With the added emphasis on SSIs, we instituted roles that different members of the team could take charge of. These roles were the science driver or the coding driver. We also introduced a pair-programming rule such that the team members switched every half hour between building the app and researching the science materials. Indeed, in all the exit interviews, students said that they felt there was equal participation among team members. However, despite continued effort in the instruction to insist that every member took a turn to program, for the most part, the team members remained in their respective roles throughout the course with little switching. This led to a clear disadvantage for those students who could become more adept at programming. For example, in his exit interview, Emmet said, “Knowledge expert, yeah I’m clever, I wouldn’t say I’m smart but I’m clever, I know how to get around things. Well, so I like knowledge more than I like [programming]...[if] I find something I know I’ll never get the hang of, I’d rather someone else do it…trying to do a Scratch project once...woh”. He also mentioned that he signed up for the course because all of his friends were talking about computer science and he wanted to improve his programming skills. However, as he admitted in his interview that he was more comfortable with science content, given the choice, he decided to remain in his comfort zone rather than challenging himself in an area of lesser strength and interest.

Similarly, for those students with a clear interest in the programming side, deeper level exploration of the scientific content was given short-shrift. For example, about the science content, Mike discussed the following in his exit interview:

Well there were things that I didn’t really understand and honestly didn’t go out of my way to understand. I just felt like I said I didn’t enjoy it enough to use it at home. So, there were some stuff I didn’t understand, I probably could figure it out, but I think there are more people more knowledgeable than me in that area.

James, who was Mike’s partner, thought that the delineation in roles was a good design choice because as he discussed, “one of us had to be working, we couldn’t work on the same thing at the same time…um but we got twice as much done.”

In these data, we see an instructional issue with no clear-cut rationale in terms of whether more or less control over how the collaboration task is structured will benefit participation and learning outcomes. In the first iteration there was a perception (with good reason) of an unequal distribution of work. Correcting for this in the second iteration where we defined roles, this led to, for some students, preemptively limiting the depth of understanding they could have acquired in either of the two content areas of science and computer programming.

Computational Components Versus Computational Concepts

The graphical programming language in App Inventor was used as a catalyst for students to transform their scientific knowledge into actionable artifacts, i.e., mobile apps that helped to address local SSIs in both iterations of the course. However, how programming instruction was delivered differed across iterations. For clarity, we differentiate between computational components and computational concepts. In this paper we define computational components as the various features of the App Inventor interface such as embedding videos or programming data collection using sensors; and computational concepts as more universally established knowledge of computer programming such as variables, procedures, conditionals, and loops. Given that many components are prepackaged for App Inventor, in the first iteration, we made the design decision to teach about the different possible components that could be programmed into the app, for example the camera or voice recording components. We hoped that understanding App Inventor functionality would trigger ideas for app construction on an SSI topic. We found that the apps constructed in the first course varied in both functionality and the usage of App Inventor features. However, this happened at the expense of students critically engaging with the computational concepts themselves. The analysis of the programming showed that students only engaged with computational concepts at a superficial level. For example, the PAS app (1–2 Table 1) used eight types of components to create their mobile solution. In the four screens that they programmed, they used the components of Activitystarter, Accelerometer, Sharing, Buttons, Table Arrangement, Label, Textbox, and Canvas. However, we can see in Fig. 1, that no significant computational concepts were used in the app. This figure shows that in each of the five event handler blocks, they did not use variable values, conditional operations, or procedures for code organization. The blocks were simply used to open other screens or to link to a web address.

Fig. 1
figure 1

Sample programming logic that shows only simple use of components

Full size image

To address this issue, in the second iteration, we constructed four mini-apps based on common types of app activities (i.e., a quiz app, a game app, a memo app, and a drawing app). Through these mini-apps, we modeled how computational concepts could be applied through various App Inventor features. For example, students were asked to practice making a different quiz on a blank screen by cutting and pasting code. Learning first principles of computer programming in addition to the affordance of remixing the mini-apps resulted in the majority of apps in the second iteration showing applications of computational concepts less complex notions (e.g., variables and lists) to more sophisticated ideas (e.g. conditionals, procedures, and databases). For example, Fig. 2 shows the Paper Toss Race app (2–2 Table 1) in which the computational concepts of variables, lists, procedures, conditions, Boolean logic, and data created the various functionalities of the app such as the selection of game goals, a point system, and adding items to and picking items from a list in addition to 18 types of App Inventor components.

Fig. 2
figure 2

Sample programming logic from the second iteration showing more sophisticated use of computational concepts such as variables in the “Quit” button, and the use of if/then conditionals in the “Notifier1” component

Full size image

One trade-off to note here however is a lack of diversity of the kinds of apps constructed. Most apps were modified versions of the apps that were modelled for them. For example, five out seven apps included remixed versions of the Low Carbon footprint quiz feature.

Discussion

Capitalizing on the growing trend in using artifacts to promote action in SSI education, our goal was to investigate design iterations of curricula that combined instruction in SSIs with constructing mobile apps to encourage local action. We analyzed student data from both iterations to look for positive and negative design features and we found that there were a number of trade-offs in each case.

In this paper, we outlined three primary trade-offs. First, we found that with a curricular model of programming first and SSI instruction second allowing complete student choice of SSI topic, this led to increased student engagement but decreased knowledge of the science. On the one hand, the programming first model establishes an environment where making is fun (Peppler et al. 2016) and allows for students to engage in topics that are most proximal to their interest. On the other hand, the apps that were created in the first iteration were arguably devoid of real local action in the community. Where the focus was on SSI instruction first to strengthen their science content, students exhibited less interest. This creates a conundrum for instruction as students with heightened awareness of SSI but with decreased interest are less likely to transfer the knowledge into action (Burek and Zeidler 2015).

Following research that demonstrates the importance of collaboration in socioscientific issues instruction (e.g., Yoon 2008, 2011) and programming with novices (Denner et al. 2014), in this study, we examined how best to support it. We found that instituting collaboration rules presented challenges (Werner et al. 2012). Allowing students’ collaborative choices to emerge in place of enforcing them through instruction resulted in unequal distribution and ownership of work among group members. In the second iteration, an environment for co-creativity emerged as students distributed the task of researching the science content versus programming the applications among the various members of the group (Lubatkin et al. 2001). However, while it was clear that there was more equal distribution of work, students more inclined to focus on one or the other of assigned tasks did so, which prematurely limited opportunities to learn new content and skills.

The last trade-off pertaining to how programming instruction was delivered demonstrated that when students were taught app components first without detailed description of the computational concepts embedded in the components, students showed relatively weak application of computational concepts, which corroborates previous research findings (Grover and Basu 2017). Conversely, when students were given pre-programmed model mobile mini-apps to remix, students demonstrated greater sophistication of computational concepts in their code such as the Paper-Toss Race app illustrated in Fig. 2. This might be an obvious win for the latter design choice, but we also saw that the second set of apps showed much less diversity in functionality and purpose.

We highlight these design trade-offs to illustrate curricular features that will impact the desired goal of enacting action in the world through applied scientific content. We can see this information as potentially valuable for similarly minded learning scientists who may need to a priori establish which aspect of this action will take primacy. This is important because one consideration to note is that this instruction occurred in a course with a finite limit of about 18 h of instruction. Overall, these trade-offs may fundamentally come down to how much choice students are given. In our study, we found that with more choice, there was greater interest but less content or skill development; and with less choice for the most part, the opposite was true.