Viewpoint
Teacher Frustrators: Testing Takes Priority, Web 1.0-Level Internet
Our blog readers know this: we (CN &ES) are unabashed cheerleaders for the use of technology in the K–12 classroom. Computing technology enables learning activities that are simply not possible with paper-and-pencil technology. And, with the cost of a computing device plummeting – buy a Chromebook for the cost of a pair of gym shoes — yeah, yeah, yeah — enough cheerleading! Let’s get down to the real issues: policies. As anyone who has tried to make technology work in the K–12 classroom knows — and as we have said on other occasions — the technology per se is the easy part. It’s the policies that make using technology challenging and frustrating for teachers.
Here are two stories, then, about just such policies — stop us if you have heard these before (smiley face goes here):
Story #1: Setting: A small town, middle class school district — back East.
In September, two university researchers teamed up with two high school English teachers, from that small town district, to use new software developed by the university researchers. The new software supported students working together synchronously, as the students co-constructed multimedia documents, co-constructed concept maps, co-constructed drawings and animations, etc. As their contribution, the district purchased two classroom sets of Chromebooks for the project, one set for each teacher. Each teacher had five sections of high school English, and now each section would be 1-to-1.
In June, the pilot project was deemed a huge success. The teachers had put a tremendous amount of effort into creating new, inquiry-oriented curriculum materials that exploited the collaboration software. Student engagement in classwork was up — as was student achievement. The principal was pleased and told the teachers that they would be able to use the carts of Chromebooks again in 2016-2017. Yup, happy campers all around — especially the university researchers. (Venture a guess as to who the two university researchers were; duh.)
Spoiler alert — as if you needed a spoiler alert: Over the summer, the principal rethought his position on allowing the two English teachers to each have a cart of Chromebooks — a cart that each used virtually every period virtually every day of the school year. In the name of "equity" the principal said that the two carts of Chromebooks would join the pool of carts that could be checked out; that pool contained a small number of carts of other computing devices (e.g., 40-year-old laptops, iPad 1.0’s).
The principal apologized to the two English teachers but said he "had no choice." Hmm. Why did the principal change his mind? Did other teachers complain about special treatment? Was something else going on behind the scenes? Equity is a real issue; no question about it. But, the district is not a poor one; they were spending $400K on textbooks for 2016-2017. Surely the district could find $20K to reward and encourage two stand-out teachers, who were modeling behavior that the principal would want from all his teachers. No, no, no; no $20K.
Of course, there were all sorts of rules about when a cart could be signed out and for how long it could be signed out. The icing on the cake rule on cart sign out was this: Those using the computing devices for state testing purposes had priority. State tests, district tests, and even classroom tests had priority over curricular use of the computing devices. In effect, then, there was no way the two English teachers would have the kind of access in 2016-2017 to computing devices for their students that they had enjoyed in 2015-2016.
Teacher frustrator? You bet!
Oh, we forgot to mention this "wrinkle": Since typing is a skill that the students need to have in order to take the state tests, those teachers who wanted to use the carts of computing devices for typing practice also have priority. Typing practice? Typing practice gets priority over curriculum!
We told you would groan.
Story #2: Setting: Urban, city school district — again back East
A district scraped together money to buy a number of carts of Chromebooks for several middle schools. The Chromebooks were to replace the iPad 1’s. Now, Chromebooks run web-apps — apps that behave as if they are web-pages since web-apps run inside a browser, e.g., the Chrome browser. That is, on the iPads (or traditional laptops), the educational apps are downloaded once from an app store over the Internet and stored on the computing device. Then, when a student starts up a native app up — for example, an app that can be used to create a concept map — the app executes on the computing device. During execution, then, the Internet is not needed, by and large.
A web-app, on the other hand, is downloaded over the Internet each time a student starts it up. And, during the execution of the app, some of the computation can be done "in the cloud" — on big honkin’ compute servers — and delivered back to the student’s computing device over the internet – lickety split! If a student is using a web-app to create a concept map, say, and the Internet goes down, the likelihood is that the web-app will go down. (With clever programming, "off-line" computing can be done; but, by and large, this sort of clever programming is the exception, not the rule.)
For all intents and purposes, web-apps require fast, robust Internet connectivity. That’s not a bug, in fact; that’s a feature. By relying on web-apps — by relying on a fast, robust internet connectivity — for computing applications, low-cost, high functionality computing devices like Chromebooks are possible. Justifying this claim is beyond the scope of this blog; we point the interested reader to several articles. Inasmuch as Chromebooks are coming into K–12 by the truckload, K–12 appears to have bought the web-app/Chromebook argument.
It is instructive, in fact, to watch what happens when a student starts up a web-app, e.g., Collabrify Map, a free, concept mapping tool that we, at the Intergalactic Center for Mobile Learning, developed. Do this:
- Start up the Chrome browser. (You don’t need a Chromebook; you can run the Chrome browser on virtually any computing device — Android or iOS smartphone to Mac or Windows desktop. Web-apps are "device-agnostic"; that’s one of the powerful flexibilities afforded by non-native, web-apps.)
- Tap F12 — a "function" key at the top of the keyboard, probably on the right.
- Tap on the word "Network" at the top of the dashboard window.
- Type: map.imlc.io into the URL bar at the top of the browser. Now watch the dashboard window.
- Notice: Almost 30 elements — pieces of program, icons, style sheets, etc. — were downloaded from the internet into your computing device. Notice how long — in milliseconds, usually — it took to download the various elements.
- Tap the red button and sign in with your Google/Gmail address (A Google/Gmail address is required; we use lots of Google’s code to make our code work.)
- Notice that about another 40 elements needed to be downloaded.
- Tap the red button at the bottom of page called "New File."
- Notice that about 110 elements have now been downloaded into your computing device.
- Tap and hold for a second somewhere on the grid on the screen: the Add Node dialog box will pop up. Add a node to your concept map.
- Notice that perhaps another 20 elements needed to be downloaded in order to handle that user request.
- Now, sometimes a needed element isn’t downloaded in time. Why does that happen? The vagaries of a cloud infrastructure. (Whatever that means.) If that missed element is an icon, then maybe an X will appear on the user’s screen, but no other real harm will be done; but, if that missed element is actual programming code, well, then the app will probably not work properly. If the app is written well, the app may try again to get the recalcitrant element to load — in the proper sequence.
Enough, right? You get the point. Look how many elements needed to be downloaded quickly from servers, somewhere in the world, over the internet just to start up a simple app — a simple web-app. Click F12 to close the dashboard window.
Now imagine 30 students all typing in "map.imlc.io" at the same time. In fact, imagine all 10 30-student classrooms all typing in the address for a web-app such as map.imlc.io at the start of class. All those shiny, new Chromebooks, all those excited students, all staring at a spinning "app loading" icon — and staring at a spinning "app loading" icon — and staring at a spinning "app loading" icon. And then, all those students start staring, plaintively, at the teacher at the front of the room.
While the districts’ existing internet connectivity was sufficient to handle Web 1.0, web page viewing activity, the web-apps on the Chromebooks require Web 3.0-level connectivity. Unfortunately, the urban district didn’t upgrade their internet capacity after rolling out the Chromebooks. Hmmm. Why wasn’t an upgrade to the networking infrastructure undertaken? The best that we can piece together is this: The school board didn’t allocate the money for the networking upgrade because the school board thought that the only real difference between iPads and Chromebooks was that the latter had an attached keyboard. Apparently, no one had explained the networking needs of Chromebooks to the board.
Teacher frustrator? You bet!
Now it’s your turn. Tell us a story about a policy that is a "teacher frustrator."
Then, let’s work together to help those that make frustration-producing policies better understand what frustration they are causing — and help teachers realize the promise of technology in teaching and learning!