Difference between revisions of "Remote Hand/alx"
Sfrancisco (talk | contribs) (Created pattern in alx) |
Sfrancisco (talk | contribs) (Edited source) |
||
| (4 intermediate revisions by the same user not shown) | |||
| Line 4: | Line 4: | ||
{{Infobox_designpattern | {{Infobox_designpattern | ||
|image= <!-- Provide the filename of the image to be displayed (e.g., Design_pattern.png) --> | |image= <!-- Provide the filename of the image to be displayed (e.g., Design_pattern.png) --> | ||
|contributor= | |contributor= [[Christian Köppe]], [[Joost Schalken-Pinkster]] | ||
|source= Köppe and Schalken-Pinkster (2013)<ref name="Köppe2013a">Köppe, C., & Schalken-Pinkster, J. (2013). [http://dl.acm.org/citation.cfm?id=2725697 Lecture design patterns: improving interactivity]. In Proceedings of the 20th Conference on Pattern Languages of Programs (p. 23). The Hillside Group.</ref><ref name="KÖPPE">Also mentioned in Köppe, C., Portier, M., Bakker, R., & Hoppenbrouwers, S. (2015). [http://hillside.net/plop/2015/papers/panthers/2.pdf Lecture Design Patterns: More Interactivity Improvement Patterns.] In Proceedings of the 22nd Conference on Pattern Languages of Programs (PLoP 2015). | |source= Köppe and Schalken-Pinkster (2013)<ref name="Köppe2013a">Köppe, C., & Schalken-Pinkster, J. (2013). [http://dl.acm.org/citation.cfm?id=2725697 Lecture design patterns: improving interactivity]. In ''Proceedings of the 20th Conference on Pattern Languages of Programs (PLoP 2013)'' (p. 23). The Hillside Group.</ref><ref name="KÖPPE">Also mentioned in Köppe, C., Portier, M., Bakker, R., & Hoppenbrouwers, S. (in press 2015). [http://hillside.net/plop/2015/papers/panthers/2.pdf Lecture Design Patterns: More Interactivity Improvement Patterns.] In ''Proceedings of the 22nd Conference on Pattern Languages of Programs (PLoP 2015)''. New York:ACM.</ref> | ||
|dataanalysis= <!-- If applicable, list of data analyses used for mining the pattern separated by a " , "comma --> | |dataanalysis= <!-- If applicable, list of data analyses used for mining the pattern separated by a " , "comma --> | ||
|domain= <!-- Learning domain the design pattern belongs to (e.g., General, Math, Algebra) --> | |domain= <!-- Learning domain the design pattern belongs to (e.g., General, Math, Algebra) --> | ||
| Line 56: | Line 56: | ||
''In a lecture on design patterns we applied {{Patternlink|Discover Your Own Pattern}} by giving the students a design problem and some initial questions. The design problem was that a file-system was needed whereby easily can be determined the number of files in a directory including all sub-directories. The intention was to work towards the {{Patternlink|Composite}} pattern<ref>Gamma, E., Helm, R., Johnson, R. & Vlissides, J. ( | ''In a lecture on design patterns we applied {{Patternlink|Discover Your Own Pattern}} by giving the students a design problem and some initial questions. The design problem was that a file-system was needed whereby easily can be determined the number of files in a directory including all sub-directories. The intention was to work towards the {{Patternlink|Composite}} pattern<ref>Gamma, E., Helm, R., Johnson, R. & Vlissides, J. (1995). ''[http://dl.acm.org/citation.cfm?id=186897 Design Patterns: elements of reusable object-oriented software.]'' Addison-Wesley: Boston, MA.</ref>. The lecturer opened a UML-editor and started with the first {{Patternlink|Carefully Crafted Questions}}: “Which general elements do we need?". Based on the answers of the students he modeled the classes they mentioned. Then the teacher asked how the classes (file and directory) are associated, thereby immediately modeling the answers in the tool visible to everyone. If there were alternatives mentioned, then these were modeled too, so that they were visible to all students, which made discussing them much easier. Then the teacher went on with asking for specific problems of the current state of the design and how they could be solved, continuing until the structure of the {{Patternlink|Composite}}pattern has been found by the students. In that case {{Patternlink|Remote Hand}} was a good combination with {{Patternlink|Student Miners}}.'' | ||
''{{Patternlink|Remote Hand}} was also applied in a course called “Structured Program Development", which is an introductory programming course. The course was designed using the flipped classroom approach, so the students had to work on assignments during the lecture and the results were discussed with the whole group. To make this discussion easier, the students had to copy their code to a collabedit-webpage. This way it was visible to everyone, both on the beamer projection and in the browser on their own machines. During discussion some students also made suggestions for improvement of the code, which was realized by the lecturer using {{Patternlink|Remote Hand}}.'' | ''{{Patternlink|Remote Hand}} was also applied in a course called “Structured Program Development", which is an introductory programming course. The course was designed using the flipped classroom approach, so the students had to work on assignments during the lecture and the results were discussed with the whole group. To make this discussion easier, the students had to copy their code to a collabedit-webpage. This way it was visible to everyone, both on the beamer projection and in the browser on their own machines. During discussion some students also made suggestions for improvement of the code, which was realized by the lecturer using {{Patternlink|Remote Hand}}.'' | ||
| Line 65: | Line 65: | ||
<references/> | <references/> | ||
[[Category:Design_patterns]] <!-- List of other categories the design pattern belongs to. The syntax for linking to a category is: [[Category:<Name of category]] --> | [[Category:Design_patterns]] [[Category:Full_Pattern]] [[Category:Lecture Design Patterns]] [[Category:Interactivity Improvement Patterns]] [[Category:Traditional Classroom]]<!-- List of other categories the design pattern belongs to. The syntax for linking to a category is: [[Category:<Name of category]] --> | ||
Latest revision as of 11:17, 6 June 2017
| Remote Hand | |
| Contributors | Christian Köppe, Joost Schalken-Pinkster |
|---|---|
| Last modification | June 6, 2017 |
| Source | Köppe and Schalken-Pinkster (2013)[1][2] |
| Pattern formats | OPR Alexandrian |
| Usability | |
| Learning domain | |
| Stakeholders | |
You want to demonstrate a tool during a lecture, where a tool can be any piece of software: graphics application, a programming language, a command line interface, etc. The students will have to use this tool afterwards or execute tasks similar to the ones you are going to demonstrate.
Presenting the tool all by yourself places the students in a consuming role. Yet it takes too much time and causes disorder to let different students try out the tool in front of the class so that everyone can see or understand what’s going on.
One common way of learning tools is by trial and error. But during teacher demonstrations often only the correct way of using a tool is shown, which is different from the naturalistic trial and error way of learning. When not showing errors during a demonstration, students do not learn to diagnose and fix common mistakes while using the tool.
Having all students trying out the tool during the lecture makes it hard if not impossible to help all individual students with learning the tool. Most of them will be missing feedback from you while trying the tool out.
Therefore: let the students tell you what to do and then execute it so that everyone can see it. Combine the tool’s feedback with your own.
All tools give feedback in some way. This can be either by doing exactly what you want and presenting a correct result, but also can consist of error messages or unexpected results. All of this tool feedback can be used perfectly for didactical purposes and the tool feedback can be combined with your own Feedback (Feedback) on the students’ suggestions, minimizing the chance of missing feedback.
Sometimes students ask things about the tool that even you as teacher do not know. In that case you can combine this pattern with Question Boomerang (Question Boomerang) and ask the students what they think how they expect it to work. Then do what they tell you to and examine collaboratively the feedback and results, therefore applying trial and error as whole group.
To optimize the learning experience, the teacher should summarize the correct way of tool usage after a trial and error demonstration, to ensure the students maintain an overview of the process of using the tool.
This solution might help to immediately address problems that students otherwise would have experienced later when working with the tool.
There is a chance that more experienced students will take the lead in such an activity and that other students start to see it as ’their game’. This might discourage these other students. It might also be that some of the suggested actions are too high-level or do not support the learning objectives of the lecture. In the latter case it might be better to use the Question Parking Space (Question Parking Space) and answer these questions after the lecture in direct contact with the students.
Remote Hand (Remote Hand) can be combined with Expose the Process (Expose the Process), as the students might explore the tool by themselves and discuss possible steps in a process while you’re executing them, visible for all. Making this pattern work requires some preparations. You need to Check Prerequisites (Check Prerequisites). A helpful list is as follows:
—The tool needs to run smoothly on the machine you’re using for the presentation.
—The projection area should be big enough and all elements on the screen should be clearly readable (or recognizable) for all students, including the ones in the last rows of the lecture room.
—You should make some preparations for guiding the students in this delivery form. Leaving the process completely open for the students might confuse them or increases the chance that the actions the students ask you to do are not going to help to achieve the learning objectives of the lecture. These preparations might include Carefully Crafted Questions (Carefully Crafted Questions) or a step-by-step guide towards a certain result (including enough room for variety).
—As it is sometimes hard to know upfront how much time a Remote Hand (Remote Hand) excercise will require (e.g. due to digressions), it is good to include some Buffers (Buffers) (as part of Lecture Structuring (Lecture Structuring)) when you select remote hand as delivery form.
Sometimes you want to use Remote Hand (Remote Hand) for a text-based artifact. If that is the case and all students in the lecture have access to the internet — either via their own laptop or when the lecture is held in a computer lab — then online collaborative editing tools can be used. In that case make the students type their answer into the shared document and copy this document to the text editor (like a programming IDE). Examples of suitable online tools are CollabEdit[3] and Google Docs[4]. These tools for online text editing can allow anonymous editing (like CollabEdit) or not (like Google Docs), remember that using an anonymous editing tool in combination with a less mature group of students can lead to unwanted edits (i.e. digital vandalism).
{[Patternlink|Remote Hand}} is a part of Make It Their Problem (Make It Their Problem), but more broadly applicable. It is also a good addition to both Test Tube (Test Tube) and Try It Yourself (Try It Yourself), as it offers a way for students probing the machine or trying something out without the need for a laboratory. Both Show It Running (Show It Running) and Show Programming (Show Programming)can benefit from Remote Hand (Remote Hand) too, as it adds some interactivity to them and therefore more actively involves the students.
In a lecture on design patterns we applied Discover Your Own Pattern (Discover Your Own Pattern) by giving the students a design problem and some initial questions. The design problem was that a file-system was needed whereby easily can be determined the number of files in a directory including all sub-directories. The intention was to work towards the Composite (Composite) pattern[5]. The lecturer opened a UML-editor and started with the first Carefully Crafted Questions (Carefully Crafted Questions): “Which general elements do we need?". Based on the answers of the students he modeled the classes they mentioned. Then the teacher asked how the classes (file and directory) are associated, thereby immediately modeling the answers in the tool visible to everyone. If there were alternatives mentioned, then these were modeled too, so that they were visible to all students, which made discussing them much easier. Then the teacher went on with asking for specific problems of the current state of the design and how they could be solved, continuing until the structure of the Composite (Composite)pattern has been found by the students. In that case Remote Hand (Remote Hand) was a good combination with Student Miners (Student Miners).
Remote Hand (Remote Hand) was also applied in a course called “Structured Program Development", which is an introductory programming course. The course was designed using the flipped classroom approach, so the students had to work on assignments during the lecture and the results were discussed with the whole group. To make this discussion easier, the students had to copy their code to a collabedit-webpage. This way it was visible to everyone, both on the beamer projection and in the browser on their own machines. During discussion some students also made suggestions for improvement of the code, which was realized by the lecturer using Remote Hand (Remote Hand).
References
- ↑ Köppe, C., & Schalken-Pinkster, J. (2013). Lecture design patterns: improving interactivity. In Proceedings of the 20th Conference on Pattern Languages of Programs (PLoP 2013) (p. 23). The Hillside Group.
- ↑ Also mentioned in Köppe, C., Portier, M., Bakker, R., & Hoppenbrouwers, S. (in press 2015). Lecture Design Patterns: More Interactivity Improvement Patterns. In Proceedings of the 22nd Conference on Pattern Languages of Programs (PLoP 2015). New York:ACM.
- ↑ http://collabedit.com/
- ↑ https://docs.google.com
- ↑ Gamma, E., Helm, R., Johnson, R. & Vlissides, J. (1995). Design Patterns: elements of reusable object-oriented software. Addison-Wesley: Boston, MA.