Maria Knobelsdorf, University of Dortmund, Germany - Didaktik der ...

More documents

Recommendations

Info

One complication with the algorithms topics is that a closely related standard (AS91075) on designing a computer program used the term “algorithmic structure” to describe the design of the program. This appears to have been confused with the use of “algorithm” in the AS91074 standard; some online postings from teachers indicate that they regarded them as describing the same thing, and at least one student stated that an algorithm is a program plan, which is essentially correct, but confusing in this context. Thus some submissions on algorithm “cost” are based on a student’s own design of a program, which typically doesn’t have any interesting behaviour to analyse, and in fact may be O(1) since the program does a very routine task. For example, several programs simply read in a value, did a calculation and printed the result. The use of the word “algorithm” has since been removed from the AS91075 standard to avoid this confusion. 4.3 Programming languages The criteria for programming languages centre around the role of programming languages, high and low level languages, and how high level languages are translated to low level ones (i.e. compiling and interpreting). Most of the students described high and low level languages and compilers abstractly, but at most a third attempted some sort of concrete demonstration of a compiler being used. A demonstration is much more convincing of student understanding because the student has personally had the experience of converting a program to a low level language and running it. Even better than demonstrating the process on a given program, students could have used their own program (for example, one done for AS91076) as the example, showing how it is compiled and/or interpreted. Because the standard discusses both interpreted and compiled programs, it’s unlikely that students would be familiar with two different languages and thus only one of the examples could reasonably be personalised, although some languages have both compiled and interpreted versions (e.g. Basic) and these could be contrasted. Another approach would be for students to learn the bare minimum of a language e.g. write a “Hello world” level program but substituting their own name. None of the submissions seemed to have taken this approach, and it would be interesting to evaluate, since it forces students through the process of getting the program to run. Using the student’s own program was risky for the algorithms topic, but for the programming languages topic it provides good personalisation and shows an awareness of the process, and it isn’t sensitive to the quality of the program (as long as it runs or compiles). Despite this, we observed few examples in our sample where students had obviously used their own program. In the student work analysed, the main languages mentioned as examples were Visual Basic/Basic (in about 18% of reports), Scratch (13%), Pascal (5%), Flash/Actionscript (4%), C (4%) and Alice (3%). Other languages used included C++, Java, JavaScript, Picaxe, and Python. About a half the reports didn’t use an example in a specific language, and these generally didn’t reflect a lot of understanding since the concepts were explained in very abstract terms. Projects that compared a compiled and interpreted language 16 mainly used Visual Basic, C, Pascal and Java as examples of compiled languages, and Scratch, VBA in Excel, Alice, JavaScript and Python as examples of interpreted languages. The situation isn’t always simple, as modern languages can blur the distinction of compiling or interpreting (e.g. Java compiles to byte code, which is then interpreted). One student mentioned how Scratch can run as a Java applet itself, so it is interpreted twice and compiled! If students can fully understand these complexities then they will have a good grasp on the issues intended, but it will be important for teachers to provide guidance on the languages to explore. Another example used in several reports was Visual Basic (compiled) compared with Basic (VBA) macros in Excel (interpreted). The contrast is effective because it is essentially the same language and focuses the student on the different way it is run rather than the difference in language; the examples we observed using this contrast all appeared to meet the criteria for Excellence in the programming languages requirements. We would note that JavaScript is a useful language to explore because it is definitely interpreted, readily available, and is not confused by the drag-and-drop aspect of Scratch, whereas it is problematic to use HTML as an example of an interpreted language (as one project did) since it is not at all clear that HTML is usefully viewed as a programming language, even if it is a formal markup language. Some students presented their work on programming language as posters. This approach has potential since the student is writing for a particular audience (probably other students), and thus might be expected to focus the explanations and examples more. It also seemed to discourage paraphrasing, perhaps because they were thinking of it as communicating to peers rather than trying to write something that a teacher would recognise as correct. 4.4 Usability The criteria in the standard emphasise factors of a user interface that contribute to its usability. Unfortunately many reports seemed to confuse usability with functionality, or focussed on the physical layout of the interface. For example, a student might comment that a cellphone can take photos (the functionality), but miss the point that the typical task that a user has (such as taking a photo and transferring it to an online photo album) might involve pressing mysterious key sequences, dealing with incompatible devices, and using a time-consuming procedure that is difficult to remember (usability). The better work focussed on typical tasks done by the user, and any problems encountered completing those tasks. Using a personally owned device and talking about the student’s own experience gives a clearer demonstration of understanding than writing about interfaces abstractly. About 61% of the reports provided a suitably personalised report. Those that didn’t discuss a personal device mainly gave general usability principles that appeared to be paraphrased from standard sources. In these cases, where illustrations were given they tended to be standard examples of usability issues, and once again it is hard to hear the “student voice” when this approach is used. The students who reported on experience with their own dig-
ital system used a variety of interfaces as examples: about 29% of the reports evaluated some sort of mobile phone (simple phones, smart phones and iPhone related devices) or some feature of one (such as sending a text message or taking a photo). The main other commonly chosen devices were an iPod/Touch device, used in about 7% of the reports, and a video game controller (5%). Other interfaces appeared less frequently, including a calculator, CD player, DVD player, DVD recorder, email software, games, web browsers, web sites, an mp3 player and a tape player. Even a toaster was used to provide a reasonable evaluation. Ten students reported on an interface that they had written themselves. These generally weren’t good as examples: few of them appeared to meet the criteria, and the remainder were focussed on describing their interface without discussing it from the user’s point of view. It would appear that these students had tried to combine this standard with work done for the design and programming standards. For user interfaces this makes it difficult for the student to provide an objective and critical evaluation. An important step in usability assessment is to identify the tasks that the device is to be used for, which helps to take the focus away from features and layouts, and put it onto the sequence of operations that a user would perform to achieve their goals. It is not unusual for a device to be frustrating to use because in practical situations the functionality of the device can be difficult or slow to access, and this is revealed if a task is evaluated instead of just a feature of the device. Only about 36% of the submitted reports described the task that a user might do. Another useful approach that can pick up usability issues is observing another person using the interface. Only 9 students did this, and all these projects clearly met the criteria; a third-person observation would apparently make it easier to report on usability, although the sample is too small to draw firm conclusions. Some of the students who observed another person took notes of every step the person took. This approach was particularly convincing when the student described their observations, and it set the student up well to meet the Merit criterion for usability, and Excellence if they compared another device. In general it seemed that the students had little teaching on HCI and usability evaluation. Although not required at this level, introducing usability heuristics (e.g. from useit. com) provides a tool for students to analyse systems. Another approach is the cognitive walkthrough, which is described for high school students at www.cs4fn.org/usability/ cogwalkthrough.php. This encourages students to observe someone else using the system, which makes the evaluator more aware of the steps being made. 4.5 General writing issues A key phrase in the title and wording of the standard is for students to “demonstrate understanding” in order to meet the criteria. It is tempting to respond to criteria such as “explaining the need for programs to translate between high and low level languages” with abstract textual explanations that are paraphrased from books or online sources (and in fact the instructions for the report explicitly say that para- 17 phrasing is acceptable). Although the general instructions allow paraphrasing, a more compelling way to show understanding would be for a student to provide a worked example using a context unique to themselves (for example, analysing the interface of their own mobile phone, or running experiments on the speed of an algorithm on their own computer). In many cases we found that “showing an understanding” was interpreted as simply explaining the concept. In this case the process could end up grading Wikipedia’s knowledge, and any slips in the paraphrasing process only served to show that the student didn’t understand the concept! A common problem in the student reports is giving poor explanations of what they had done. For example, in explaining sorting, one student wrote that B is bigger than A, and A is bigger than C, but we weren’t told what A, B and C were — quite possibly they were sorting weights or labeled envelopes, but this wasn’t mentioned at all. Another problem was assuming that the marker would know things that the teacher did (perhaps because students are used to internal assessment); for example, referring to the “method that was used in class” rather than describing it. Many reports showed a lack of scientifically convincing reporting, such as drawing conclusions from just one speed measurement from each of two algorithms, or having results spread around the document and not explicitly comparing them. It was also not unusual for the student to assume that the reader would go to the trouble of finding patterns in the results for themselves; for example, one student had a table of execution times that showed a clear difference between selection sort, bubble sort and quicksort, but they never articulated that they had noticed the difference, and thus got credit for measuring the algorithms, but not for showing an understanding of the different costs. The work on the programming languages topic overwhelmingly used paraphrased quotes. This is largely because it is a lot harder to personalise (there are only so many compilers and machine languages that students are likely to encounter, and the role of interpreters and compilers is fairly well defined). A similar situation arises with the requirement to discuss the relationship between algorithms and programs; there are only a few ways to describe this accurately. In these cases the criteria aren’t ideal for a report and it would be better if they prompted examples rather than factual information. 4.6 Guidance for students The nature of the standards is such that teachers can direct student work in a variety of ways to enable them to demonstrate their understanding. Many of the projects reproduced questions and rubrics from teachers, and the nature of these instructions had an influence on how easy it would be for students to produce work that met the criteria. Several sets of the sampled reports had identical questions heading each section, which either would have come from the same teacher, or a group of teachers who had shared teaching ideas. Because the quality of student work depended a lot on the tasks that were set for them, we have attempted to identify
Page 1 and 2: Fakultät für Mathematik, Informat
Page 3 and 4: Program Committee Michal Armoni Wei
Page 5 and 6: Challenge and Creativity: Students
Page 7 and 8: Challenges in Computer Science Educ
Page 9 and 10: These echo a 2008 report from the N
Page 11 and 12: examples, and in practice teachers
Page 13 and 14: Figure 3: A trace of bubble sort fr
Page 15: either their own program or another
Page 19 and 20: computer science, and with the less
Page 21 and 22: effect of different factors on the
Page 23 and 24: (GE) and freshmen CS and Lyceum (GR
Page 25 and 26: Performance Expectancy (PE) Satisfa
Page 27 and 28: for active CS teachers. Furthermore
Page 29 and 30: participants change between the roo
Page 31 and 32: Altogether 830 participants visited
Page 33 and 34: 7. ACKNOWLEDGMENTS The initial equi
Page 35 and 36: • self-concept in science • ins
Page 37 and 38: mean at t0 mean at t2 mean at t0 me
Page 39 and 40: survey at the time t0 time of surve
Page 41 and 42: characteristics mean m (regarding t
Page 43 and 44: technology subjects in senior secon
Page 45 and 46: aim to react on these topics, exper
Page 47 and 48: the educational programs and ration
Page 49 and 50: y choice of handset, choice of netw
Page 51 and 52: 8. REFERENCES [1] Bell, T. et al. 2
Page 53 and 54: Agile Projects in High School Compu
Page 55 and 56: ited time, heterogeneous student ab
Page 57 and 58: the target audience. This phase is
Page 59 and 60: longer than one to two weeks (which
Page 61 and 62: e.g. assessing individual achieveme
Page 63 and 64: Conceptual Change and Epistemologic
Page 65 and 66: einterpreted, or excluded, for exam
Page 67 and 68:
How Teachers in Different Education
Page 69 and 70:
attended by about a 33-40 % of all
Page 71 and 72:
The assumption of sphericity was no
Page 73 and 74:
[23] Huynh, H. and Feldt, L. S. 197
Page 75 and 76:
Ways of Planning Lessons on the Top
Page 77 and 78:
other topic. The reasons given vari
Page 79 and 80:
Promoting Computational Thinking wi
Page 81 and 82:
algorithm or a product is viewed as
Page 83 and 84:
Preparing Teachers for Teaching Inf
Page 85 and 86:
However, even when such learning th
Page 87 and 88:
Grand challenges for the UK: Upskil
Page 89 and 90:
first two questions. We maintain th
Page 91 and 92:
(Some) Grand Challenges of Computer
Page 93 and 94:
ecoming more student-centered. Inde
Page 95 and 96:
[13] OECD. (2006). Are students rea
Page 97 and 98:
in the world, for example, as descr
Page 99 and 100:
The aims of the case study were to
Page 101 and 102:
Figure 8: Acquisition of programmin
Page 103 and 104:
The focus group girls were more con
Page 105 and 106:
tool for teachers and students in t
Page 107 and 108:
eledSQL - A New Web-Based Learning
Page 109 and 110:
create and manage teacher accounts.
Page 111 and 112:
ABSTRACT Bringing Contexts into the
Page 113 and 114:
3.1.1 Greenfoot as a framework for
Page 115 and 116:
Real-world context Views of Computi
Page 117 and 118:
Real-world context GP Context Artif
Page 119 and 120:
i. e. theories, models, frameworks,
Page 121 and 122:
number P-156 in Lecture Notes in In
Page 123 and 124:
1. Context-based education in compu
Page 125 and 126:
Figure 1. Network traffic for authe
Page 127 and 128:
A weak point of the Vigenère algor
Page 129 and 130:
We have learnt that we can both loo
Page 131 and 132:
Comparing CSTA K-12 Computer Scienc
Page 133 and 134:
grade 4, 5, 6 or 8, depending on ch
Page 135 and 136:
Table 1. Scoring Scale for the Impl
Page 137 and 138:
the highest rate of implementation
Page 139 and 140:
Information Theory on Czech Grammar
Page 141 and 142:
of information in a message M, repr
Page 143 and 144:
Data modeling and database systems
Page 145 and 146:
the knowledge about ICT and CS (see
Page 147 and 148:
The Mindstorm Effect: A Gender Anal
Page 149 and 150:
Exploring the processing of formatt
Page 151 and 152:
Teachersʼ Perceptions Of The Value
Page 153 and 154:
Technocamps: Bringing Computer Scie
Page 155 and 156:
Abenteuer Informatik - Hands-on exh
Page 157 and 158:
Gaming and Mathematics: A Cross Cur
Page 159 and 160:
Turi: Chatbot software for schools
Page 161 and 162:
ABSTRACT Learning Fields in Vocatio
Page 163 and 164:
ABSTRACT This study examines the po
show all

Maria Knobelsdorf, University of Dortmund, Germany - Didaktik der ...

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?