How to Study Programming on Mobile Touch Devices – Interactive Python Code Exercises Petri Ihantola, Juha Helminen, and Ville Karavirta Department of Computer Science and Engineering Aalto University Finland
[email protected],
[email protected],
[email protected] ABSTRACT
1.
Scaffolded learning tasks where programs are constructed from predefined code fragments by dragging and dropping them (i.e. Parsons problems) are well suited to mobile touch devices, but quite limited in their applicability. They do not adequately cater for different approaches to constructing a program. After studying solutions to automatically assessed programming exercises, we found out that many different solutions are composed of a relatively small set of mutually similar code lines. Thus, they can be constructed by using the drag-and-drop approach if only it was possible to edit some small parts of the predefined fragments. Based on this, we have designed and implemented a new exercise type for mobile devices that builds on Parsons problems and falls somewhere between their strict scaffolding and full-blown coding exercises. In these exercises, we can gradually fade the scaffolding and allow programs to be constructed more freely so as not to restrict thinking and limit creativity too much while still making sure we are able to deploy them to small-screen mobile devices. In addition to the new concept and the related implementation, we discuss other possibilities of how programming could be practiced on mobile devices.
Today, mobile devices are ubiquitous and provide an attractive platform for consuming all kinds of interactive material on-the-go. Indeed, these devices also have great potential as an environment for learning, regardless of time and place. The challenge is how to effectively create or adapt content to meet the requirements and overcome the restrictions of this quite a different learning space. Learning sessions may be very short in time and sporadic in frequency. Thus, the learning applications must be able to deliver brief self-contained learning tasks. How can mobile devices be used to learn programming? Such devices can be used for reading tutorials – perhaps accompanied with some visualizations – but based on previous research it seems likely that a more active role than mere viewing would lead to better results [4]. Indeed, some programming-related online tutorials utilize in-browser programming environments where users can experiment without installing anything extra on their computers (e.g. Runestone Interactive Python [11] and Learnpython1 ). Although excellent in desktop environments, the usability of these is lacking on mobile touch devices where the screen space is limited and where typing is more challenging as there is no physical keyboard. If typing code with touch devices is challenging, then how can you practice programming? For Windows Phone users (and as an HTML5 app for many other platforms) there is TouchDevelop [14] – a programming language and environment designed explicitly for these devices and where much of the code is created by tapping through menus. A different, but related approach would be to use environments where programs are constructed visually by dragging and dropping blocks of code. Scratch [9] is a well-known example of this. So-called Parsons problems (or puzzles), program construction exercises where the task is to select and arrange code fragments in order to compose a program that meets some set requirements, are another example [12]. Here, a code fragment is typically a single line of code but may comprise multiple lines as well. If there is no extra code and blocks cannot be defined on-the-fly, the problem reduces to that of reordering the code. Most blocks languages as well as TouchDevelop support only some special programming languages designed together with the system whereas Parsons problems can be used to practice any programming language (e.g. Java or Python). The existing exercises that are available on mobile touch devices and deal with programming topics, like the program
Categories and Subject Descriptors K.3.1 [Computers and Education]: Computer Uses in Education—Computer-assisted instruction (CAI), Distance learning; K.3.2 [Computers and Education]: Computer and Information Science Education—Computer science education
General Terms Human Factors
Keywords Programming, Mobile Touch Devices, Python, Teaching, Learning, Mobile Learning, mLearning, Parsons Puzzle, Parsons Problem Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than the author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from
[email protected]. Koli Calling ‘13, November 14 – 17 2013, Koli, Finland Copyright is held by the owner/author(s). Publication rights licensed to ACM. ACM 978-1-4503-2482-3/13/11 $15.00 http://dx.doi.org/10.1145/2526968.2526974
1
51
INTRODUCTION
http://www.learnpython.org/
construction of Parsons problems, are fairly limited in terms of what kinds of learning tasks and goals are feasible. For example, the existing implementations of Parsons problems do not allow any modifications to the given code fragments and thus strongly limit the way programs can be built, and assignments designed. Indeed, it would be useful to have something that falls between text as input and the immutable blocks of pre-written code – something that is more akin to the core task of designing and creating programs instead of merely reading and answering questions about them, or attempting to piece one together somewhat like a puzzle. Influenced by observations from an analysis of students’ submissions to programming exercises, we designed a new type of exercise aimed at mobile touch devices. Our approach bears resemblance to existing work on block-oriented graphical programming environments but intentionally skews closer to code as text instead of visual elements. This is in order for the practice to better benefit and the skills acquired to better translate to the actual task of writing code in a widely-used general-purpose programming language (Python). In this paper, we present the design and implementation of a new type of exercise as an extension to the MobileParsons [6] learning application for practicing Python programming skills on mobile touch devices. Self-study is facilitated by the availability of immediate automatic feedback. Furthermore, we also discuss existing solutions and other alternatives to (learning) programming on mobile devices.
2.
def f i n d l a r g e s t ( a , b , c ) : i f a >= b : i f a >= c : return a i f b >= c : return b else : return c
def f i n d l a r g e s t ( a , b , c ) : i f b >= a : i f b >= c : return b i f a >= c : return a else : return c
def f i n d l a r g e s t ( a , b , c ) : if b < a: if c < a: return a if c > b: return c else : return b
DESIGN AND IMPLEMENTATION
Different solutions to a programming assignment can be the result of using different language constructs. On the other hand, very similar lines may also lend themselves to different approaches, as illustrated in Figure 1. The types of lines in the figure can be used to construct many different kinds of attempts at solving the problem of finding the largest value, both correct and incorrect. More precisely, the solutions in the figure can be constructed from four line types – the signature line (def find_largest(a,b,c):), if statements (if VAR CMP-OP VAR:), else statements and return statements (return VAR), where VAR is either a, b, or c and CMP-OP is . To get a better understanding of this phenomenon, we examined whether students’ solutions to small programming exercises could indeed be constructed by selecting lines from a relatively small pool of lines – the pool of lines being different for each exercise. To investigate this, we analyzed all submissions to, in total, 11 small automatically assessed introductory level Python programming exercises from two different programming courses. The courses were the first introductory programming course (CS1) and Web Software Development (WSD) at Aalto University, Finland. CS1 and WSD are both large courses with ca. 600 and 150 students, respectively. In selecting the exercises we considered that we would like at least some of the solutions to fit on the screen of a typical touch device when using the MobileParsons environment. This implies programs of around 10 lines for handheld devices and 20–25 for tablets. We only considered the last correct submission for each student and searched for sets of common codelines from which as many students’ solutions as possible could be constructed with the idea in mind that then these lines could be the building blocks in the respective Parsons problem. For this, we went through students’ solutions searching for similar
Figure 1: Different solutions, all based on nested if-else constructs, to the programming assignment where the task is to find the largest among the three arguments given.
lines. We ignored all empty lines and comments, and lumped together all variable names and string literals. Indeed, with Parsons problems, we would be able to use some canonicalized names for all the occurring variables. Moreover, string literals could also all be equated because they did not affect the adherence to the given specifications in any of the exercises but were either debugging code or strings whose actual phrasing did not matter in terms of the functionality. After canonicalizing all the lines, we got the set of all lines that occurred in students’ solutions – one set for each exercise. In some cases, we were able to identify groups of often used lines that even after the initial canonicalization were only slightly different from each other. If in addition to positioning lines, a user was allowed to reuse and edit some small parts of the lines, a smaller set of lines could allow a much larger number of different types of solutions to be constructed. After that, we processed all the lines so that all identifiers, boolean literals (i.e. True, False), number literals (e.g. 0.1, 1, and 3), mathematical operators (i.e. +, -, *, /, and //), comparison operators (i.e. , and !=), and logical binary operators (i.e. and and or) were lumped together under an umbrella term like COMP-OP for a comparison operator. After the canonicalization, we applied a heuristic search to find subsets of (editable) lines from where one could select lines to fully cover as many students’ solutions as possible.
52
For each exercise, we selected the set of lines whose relative expressive power was best by finding the one where the number of lines divided by the number of solutions covered was at its minimum. These are reported in Table 1. Set size column in the table describes how many lines were needed to cover n solutions, where n is given in column coverage (c-all). Although the number of fully covered solutions (line coverage c-all in the table) is relatively small, it is better than where we can get with traditional Parsons problems (line coverage c-id-str in the table). What this means is that having around 11 partly editable lines would allow 46 percent of students’ solutions to assignment CS1 12 to be constructed while this number of non-editable lines could cover only 15 percent of the solutions.
Figure 2: Example of an assignment in MobileParsons. Line return b is being inserted into the program.
Table 1: The number of solutions that could be fully covered by N prototype lines for both canonicalizations. N is selected so that the fraction of set size and coverage with all canonicalizations is at its minimum. CS1 11 CS1 12 CS1 21 CS1 22 CS1 23 CS1 31 CS1 32 CS1 33 WSD1 WSD2 WSD3
set size (c-all) 10 11 23 26 27 21 19 24 10 16 12
coverage (c-all) 170 (36%) 209 (46%) 79 (17%) 219 (47%) 206 (49%) 188 (40%) 241 (52%) 83 (20%) 46 (31%) 27 (18%) 14 (11%)
to discourage trial-and-error behavior, feedback is automatically disabled for a period of time if used too frequently. Previously, no execution-based feedback was available in MobileParsons but this feature was added as part of the extension we implemented. Figure 3 shows what this feedback looks like.
coverage (c-id-str) 140 (29%) 67 (15%) 5 (1%) 54 (12%) 21 (5%) 49 (10%) 86 (19%) 20 (5%) 46 (31%) 21 (14%) 13 (10%)
Implementation Influenced by our observations, we decided to implement a new type of Python exercise that allows limited editing of lines by providing parts where you can toggle (i.e. click or tap) between alternatives. We implemented this on top of js-parsons [5], or more precisely its mobile fork called MobileParsons [6]. In the original MobileParsons, students are to use some of the code given on the left side (in landscape mode) to build a program on the right without forgetting appropriate indentation which is significant in Python. Lines are positioned by drag-and-dropping. An example of an exercise in MobileParsons is shown in Figure 2. The assignment description is available in a tab on the left. Similarly, after requesting feedback, another tab appears on the right which shows the previously requested feedback. In the underlying js-parsons, there are two different types of feedback: line-based and execution-based [2]. The type of feedback is defined when the exercise is created. Line-based feedback indicates the lines that should be repositioned. For this feedback to be possible, there needs to only exist a single correct arrangement of the given lines. In execution-based feedback, the code is executed and run against predefined tests. Feedback is given to the student as failed/passed assertions. Python code is executed in-browser using the Skulpt library2 , a JavaScript implementation of Python. Feedback is given whenever requested by the student. However, in order 2
Figure 3: Example of execution-based feedback in MobileParsons.
The main difference between MobileParsons and the new type of exercise is that in the latter, the given code fragments can include parts where the learner needs to select a piece of code from a set of options in order to complete the codeline. An example of a possible set of editable lines for the previously described task of finding the largest item of the three arguments (Figures 1 and 2) is shown in Figure 4. Initially, the blocks show only the type of the missing content. This is in order to help learners think about the possible solutions before starting to change the pieces. We did not want to make one of the options show by default, as we felt that would too easily fixate learners on that value. However, when an exercise is created, a default value can be specified if need be. Learners interact with the changeable parts of the code by tapping (or clicking) them. That changes the piece to the next option. If the prototype lines can be duplicated, this allows constructing larger solutions with the given selection of prototype lines. For example, the partial solution shown in Figure 5 could be constructed from the lines in Figure 4. A complete example of a partially solved exercise in the mobile application is shown in Figure 6. The options for a changeable piece of code can be specified
http://www.skulpt.org/
53
Figure 4: The prototype lines sufficient to solve the find_largest task in Figure 1. Whereas the task in Figure 1 has only one correct ordering of the lines, these prototypes allow constructing multiple correct solutions.
Figure 5: A partial solution to the example exercise.
Figure 7: Android default keyboard layout with three different layout windows. Typing, for example, foo(a[1]) requires switching between all of these layout screens.
Figure 6: A complete example of an exercise with toggleable parts in MobileParsons.
platforms but, in general, there are similar tools available on other platforms as well.
as a list when creating the exercise. Alternatively, only the type of the piece can be specified in which case the options are determined by this. The supported types are boolean (True, False), comparison operator (, =, ==, ! =), math operator (+, −, ∗, /), logical binary operator (and, or), and numeric range. The numeric range is specified as in the form field type specification of HTML53 , that is, with minimum and maximum values as well as a step used to increase the value.
3.
3.1
One reason why typing source code with the on-screen keyboards of touch devices is difficult, is that special characters such as curly braces and brackets, often used in programming, are hard to access. Thus, several programmer-friendly soft keyboards have been created. The obvious trade-off is between having a smaller number of larger keys so that they are easier to hit and having a larger number of smaller keys in order to avoid switching between multiple keyboard screens while typing. The difference is highlighted in Figures 7 and 8 where the former presents the default keyboard layouts on Android and the latter is the layout provided by an app called Hacker’s Keyboard4 . This keyboard is similar to traditional
RELATED TOOLS
In addition to many mobile applications providing textbooklike static content on programming topics, some also provide interactive elements such as multiple choice questions, Parsons problems, and IDEs designed especially for handheld devices. In this section, we present examples of these. The selected examples are skewed towards the Android and iOS 3
Tools for Composing Programs on Touch Devices
4 https://play.google.com/store/apps/details?id=org. pocketworkstation.pckeyboard
http://drafts.htmlwg.org/html/master/forms.html
54
QPython6 , just like many other similar tools, provides an editor and an interactive console separately as illustrated in Figure 8.
Figure 8: Hacker’s Keyboard soft keyboard used in QPython shell on Android.
Figure 10: A screenshot from HTML5 version of TouchDevelop on Android.
keyboards and allows typing many special characters by first tapping shift and then some other key. Another example of a keyboard for typing programs – that does not even require tapping two keys to get the special characters – is shown in Figure 9 from the Textastic5 text editor for iPad/iPhone. In Textastic, tapping on the keyboard buttons on top of the traditional keyboard adds the character in the middle of the button, whereas swiping the button towards its corners adds the character displayed in that corner of the button.
However, this and other applications like it are designed for programming in general – not for learning or teaching it. Aside from native applications, there is still also the Runestone Interactive Python [11] that is an interactive web-based book for learning Python. As shown in Figure 11, the interactive content works on mobile devices as well. Learnpython is another similar website. It can be used with tablets but the usability with phone-sized devices is limited.
Figure 9: Keyboard in the Textastic application on an iPad. Features like predictive typing [8] and auto-complete make typing software on mobile touch devices even easier but they still do not utilize new interaction methods enabled by these devices. Despite recent interest (e.g. [3, 10, 13]), most publicly available mobile programming tools lack natural interaction [15] mechanisms (e.g. use of gestures). Although TouchDevelop (Figure 10), makes creating small programs on mobile devices easier, as they are are created by tapping through dynamic menus on the screen, it does not support, let us say, Python.
3.2
Figure 11: Example of textual content and a program visualization in Interactive Python on an iPhone.
Tools for Practicing Programming on Touch Devices
On the other hand, when practicing programming, being able to execute and experiment with the code is equally important as typing code. Correspondingly, there exist many mobile IDEs, interpreters and compilers for mobile devices. 5
Although we have built our extension to an environment designed for Parsons problems, the work we have done can 6 https://play.google.com/store/apps/details?id=com. hipipal.qpyplus
https://itunes.apple.com/app/id383577124
55
also be compared to blocks languages such as the pioneering BLOX [1] or later Scratch7 , Snap8 , Blockly, and others. Some of the latest blocks language environments are browser-based and thus can be used even on tablets. The screen layout of all the environments we have tried, however, is such that the tools are in practice unusable with phone-sized devices (Figure 12 shows an example of Snap on a tablet device). In blocks languages, the arrangement of code fragments is supported visually by the jigsaw metaphor where pieces can be linked together only in certain ways. Languages often allow small edits to the pieces just like switching through options in our implementation. Most blocks languages, being fully expressive programming languages, support more versatile editing of blocks than what is currently possible in our implementation. For example, it may be possible to insert an editable block inside some other blocks.
Figure 13: Example of a problem in SingPath.
Questions in Quiz&Learn Python are all about the behavior of short programs. In addition to showing the correct answers, it gives the learner the possibility to step through the program line-by-line and inspect its behavior.
4.
DISCUSSION
There are several aspects of the proposed type of exercise as well as the whole concept of learning programming on mobile devices that we would like to see discussed by computing education researchers and practitioners. In the following, we raise these questions, as well as provide our own opinions as a starting point for the discussion. Figure 12: Example of a program in Snap. Is learning programming on mobile touch devices worth pursuing? If yes, what kinds of tools are available (or missing) to practice programming on mobile touch devices? How should mobile learning tools be integrated into courses? Is it enough for them to be available for self-study?
Our work falls somewhere between simple Parsons problem systems and more complex blocks languages. Both Parsons problems and blocks languages have been used to lower the barrier to programming [7, 12]. Our primary goal, however, has been to bring Python programming tasks with automatic feedback to mobile touch devices. Nonetheless, the system we have developed can also be used with browsers on desktop machines. Closest to what we had on our mind, and what was already available on a mobile platform, was the SingPath9 mobile environment for simple Parsons problems. An example of a problem in SingPath is shown in Figure 13. It should be noted that, unlike js-parsons and MobileParsons, SingPath automatically indents the added lines correctly. In addition to the program construction environments, there exist some quiz applications that deal with programming, for example, the iOS applications Java Quiz10 and Quiz&Learn Python11 . Java Quiz asks questions both about program behavior and different constructs of the language.
Despite some pioneering work to edit source code through gestures [13], existing programming tools for mobile touch devices seem to be based on static material, multiple choice questionnaires, visual (blocks) languages, Parsons problems, or exporting IDE concepts and environments directly from desktop environments to the mobile context. Visual editing of textual source, where our work aims at, seems to be missing. In addition, combinations of static and interactive content are also missing. Some browser-based solutions like learnpython can be used with tablets but are quite difficult to deal with on phone-sized devices. This kind of combination of easy to read tutorials accompanied with small exercises is something that we would like to see on mobile devices in the future. However, because of sporadic and brief usage sessions, editing the source code should be faster than where typing with soft keyboards appears to get us.
7
http://scratch.mit.edu/ http://snap.berkeley.edu/ 9 https://itunes.apple.com/us/app/singpath-mobile/ id567470737 10 https://itunes.apple.com/app/java-quiz/ id464249097 11 http://www.bythemark.com/products/ quiz-learn-python/ 8
Does the proposed type of exercise provide benefits compared to existing systems? Although our code exercises may allow some freedom while also making use of interaction methods natural to touch
56
devices – dragging, dropping,and tapping – the approach still significantly restricts learners’ program implementation options. Some of this can be educationally justified. For example, when teaching if-else constructs, it is better to guide students towards constructing program like in Figure 1, instead of producing quick one-liners as in Figure 14. When teaching some specific concepts, we would like to provide building blocks exactly with those in mind. However, in some cases the blocks languages approach of being able to insert blocks inside other elements would help us to produce exercises that would better match the different solutions students would create without the restrictions of our system.
which kinds of building blocks students construct their programs, would help teachers to create good exercises. This might even be useful on blocks languages, where on Blockly it is also implemented.
5.
CONCLUSIONS
In this paper, we have discussed different existing approaches to providing learning content for programming on mobile touch devices and raised some questions about possible future directions in this area of research. To address the needs for programming exercises on mobile touch devices and the shortcomings of existing learning environments on such platforms, we have designed and implemented a new type of exercise dealing with programming. It has been implemented as an extension to the existing MobileParsons application that provides exercises where students drag and drop given code fragments to construct a program. The key idea is to try and allow more choice in how programs are constructed by allowing some choice in and modifications to the given code through toggleable elements in the code fragments, such as, designating a part of a line as a comparison operator which would then allow switching through the different alternatives. The exercises may be designed both to less restrict the choice of implementation for the solution and to be more complex and challenging. A core feature, which enables effective self-study, is the availability of immediate automatic feedback. This feedback is based on running unit tests on the constructed program as previously only available in the desktop equivalent of MobileParsons.
def f i n d l a r g e s t ( a , b , c ) : return max( a , b , c ) Figure 14: An alternative solution to the programming assignment where the task is to find the largest the three arguments given.
Indeed, we made the design choice of requiring Python as the language in our mobile code exercises. While Scratch, for example, would be an interesting approach to learning programming concepts on mobile devices, in order to eliminate the extra cognitive load of switching between languages, we preferred an environment that is based on the same language used in our programming courses anyhow. For our needs, the blocks language environment would thus have to support constructing programs in Python. We chose not to make use of the jigsaw metaphor known from blocks languages. On the one hand, we wanted to minimize the effort of grasping additional visual metaphors beyond actual Python code and programs and, on the other hand, this approach allows students to create syntactical errors. Adopting the jigsaw approach to our work would prevent students from doing and learning from these mistakes. Instead, we give similar automated feedback that a Python interpreter would when a student tries to execute the erroneous code. Finally, in our analysis of students’ submissions, we focused on the correct solutions in order to examine the variance in correct implementations. We could also investigate typical errors by analyzing all submissions and then consider adding respective erroneous lines in the exercises. Such lines in Parsons problems are called distractors. Allowing students to modify lines, as we have, will in practice create many distractors and therefore make exercises more difficult. Indeed, if the goal is to allow different correct solutions, instead of merely making the exercises more difficult, it should be carefully considered which modifications are allowed. Informed decision by the instructor is always a choice. Another is mining the submissions of automatically assessed programming exercises, as we did in order to ensure the proposed exercise approach is meaningful. However, in future research, it might be better to exclude the solutions of lesser quality instead of using all the submissions. Thus, although original Parsons problems force the students to reproduce the teacher’s answer, more research is needed to understand how toggleable Parsons implemented in this work affect and how the toggleable values in different exercises should be selected to best support learning. Further research is needed to verify our assumption that controlled scaffolding, that is the ability to fully tailor from
6.
REFERENCES
[1] E. P. Glinert. Towards ’second generation’ interactive, graphical programming environments. In Proceedings of the 1986 IEEE Computer Society Workshop on Visual Languages (VL’86), pages 61–70, 1986. [2] J. Helminen, P. Ihantola, V. Karavirta, and S. Alaoutinen. How do students solve parsons programming problems? – execution-based vs. line-based feedback. In Learning and Teaching in Computing and Engineering (LaTiCE), 2013, pages 55–61, 2013. [3] M. Hesenius, C. Orozco Medina, and D. Herzberg. Touching factor: Software development on tablets. In T. Gschwind, F. Paoli, V. Gruhn, and M. Book, editors, Software Composition, volume 7306 of Lecture Notes in Computer Science, pages 148–161. Springer Berlin Heidelberg, 2012. [4] C. Hundhausen. A meta-study of software visualization effectiveness. Journal of Visual Languages and Computing, 13:259–290, 1996. [5] P. Ihantola and V. Karavirta. Two-dimensional parson’s puzzles: The concept, tools, and first observations. Journal of Information Technology Education: Innovations in Practice, 10:1–14, 2011. [6] V. Karavirta, J. Helminen, and P. Ihantola. A mobile learning application for parsons problems with automatic feedback. In Proceedings of the 12th Koli Calling International Conference on Computing Education Research, Koli Calling ’12, pages 11–18, New York, NY, USA, 2012. ACM. [7] C. Kelleher and R. Pausch. Lowering the barriers to programming: A taxonomy of programming
57
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
environments and languages for novice programmers. ACM Comput. Surv., 37(2):83–137, June 2005. I. S. MacKenzie and R. W. Soukoreff. Text entry for mobile computing: Models and methods,theory and practice. Human–Computer Interaction, 17(2-3):147–198, 2002. J. Maloney, M. Resnick, N. Rusk, B. Silverman, and E. Eastmond. The scratch programming language and environment. Trans. Comput. Educ., 10(4):16:1–16:15, Nov. 2010. S. McDirmid. Coding at the speed of touch. In Proceedings of the 10th SIGPLAN symposium on New ideas, new paradigms, and reflections on programming and software, ONWARD ’11, pages 61–76, New York, NY, USA, 2011. ACM. B. N. Miller and D. L. Ranum. Beyond PDF and ePub: toward an interactive textbook. In ITiCSE’12: Proceedings of the 17th annual joint conference on Innovation and technology in computer science education, pages 150–155, 2012. D. Parsons and P. Haden. Parson’s programming puzzles: a fun and effective learning tool for first programming courses. In ACE ’06: Proceedings of the 8th Austalian conference on Computing education, pages 157–163, 2006. F. Raab, C. Wolff, and F. Echtler. Refactorpad: editing source code on touchscreens. In Proceedings of the 5th ACM SIGCHI symposium on Engineering interactive computing systems, EICS ’13, pages 223–228, New York, NY, USA, 2013. ACM. N. Tillmann, M. Moskal, J. de Halleux, and M. Fahndrich. Touchdevelop: programming cloud-connected mobile devices via touchscreen. In Proceedings of the 10th SIGPLAN symposium on New ideas, new paradigms, and reflections on programming and software (ONWARD ’11), pages 49–60, 2011. D. Wigdor and D. Wixon. Brave NUI World: Designing Natural User Interfaces for Touch and Gesture. Morgan Kaufmann Publishers Inc., San Francisco, CA, USA, 1st edition, 2011.
58
