Archive for June 2014

Don’t Make(r) a New Computer Lab

Our Makerspace is, as with many schools, located in the room which used to house a computer lab. The transition from pull-out lab-based computing to immersive 1:1 environments has left a variety of spaces available to be used in creative ways. Schools looking to offer Maker and tinker-oriented programs (including robotics or other tech-based activities) can make a natural transition of that space by adding maker tech, and it even makes some logistical sense– these are rooms which are often designed to offer easy access to power and network outlets, and may have lockable storage for peripherals or laptops which can be repurposed for tools and supplies. But in the rush to revise the computer lab, have we recreated “The Computer Lab?” At the Independent Schools Educators’ Network dinner at ISTE 2014, I spent some time chatting with Kelsey Vrooman of the Urban School and Bill Selak, now at Hillbrook, about this very question.

I believe that the most important reason for 1:1 computing in schools is context: students using computers in Language Arts creates a context of use for the computer which places it within that discipline. The message of this style of use is clear: you have a variety of tools that you use to discover, experience and demonstrate the discipline of Language Arts– your computing device is one of them. The computer lab model decontextualized technology use by creating an abstract space, time and skill set for computing use, and we have abandoned that model because it no longer fits with our view of technology an integrated, immersive, just-in-time resource.

The goal of adding a Makerspace is either implicitly or explicitly expressive of some of the same desires and goals of 1:1 computing– “soft” skills or ideals such as creativity, collaboration, problem-solving and authentic work, or concrete curricular goals such as STE(A)M or 21st Century Computing/Technology Skills. As we asked with 1:1 computing, we should ask the same ideological questions about the location or environment of a Makerspace: pull-out, or push-in? Standalone, or immersive? Remote, or classroom-based?

Seymour Papert described the computer lab through the lens of systems and schools in “The Children’s Machine” by calling the lab a school’s attempt to control and homogenize a resource that it didn’t know how to adopt. The lab, he argues, is a construct borne of the school system’s need to clearly delineate expectations, input/output and “expertise” (in the form of a responsible teacher). Many of his observations about the “unknown” nature of tinkering-based learning hold just as true for the Makerspace as they do for computing. To be sure, there are logistical concerns which lead to a separate Maker space (just as, in the pre-mobile days, it wasn’t reasonable to put 1:1 device ratios in a classroom using only desktops): a Laser cutter has to be installed with specific air circulation needs, for example, and isn’t going to be rolled into a class on a period-by-period basis. That doesn’t mean, however, that many of the elements of the Makerspace can’t be mobile: materials, tools, (and more importantly:) skill sets and challenges can be pushed in to classes and contextualized just as we are now doing with 1:1.

We have reached a compromise on our campus of the personalization and contextualization of 1:1 computing for most needs, with specialized resource centers of computers for unique needs beyond that which a personal device may cover. Our publications classroom has specialized software and additional computing power for photo and image processing. The same goes for an art classroom. When Middle School students, armed with iPads, embarked on a MinecraftEDU project, we supported them with a collection of classroom laptops to run that software. The challenge in building our Makerspaces is to strike the same balance: what are Maker activities which require a specialized and purpose-built space, and which deserve to be pushed-in and integrated into class contexts?

My Watch Thinks Everyone Should Learn to Code

untitled (2)

(img: The Very Excellent DC Rainmaker)

Outside of my Education vocations and avocations, I am an avid triathlete. Triathetes have a bit of a reputation already as being tech- and data-geeks of the sports world, and being a technologist by day and triathlete by night, I’m probably not helping the curve. My tool of choice up until recently was the Garmin 910xt, a training computer which helped me analyze all of the various metrics of my training and performance. When the Wall Street Journal asked recently why so many “mere mortals” were conquering athletic feats like the Ironman, training computers like the 910xt were a large factor in their narrative.

Sadly, my “training brain” fell off my bike during a race earlier this year and was lost to the tri deities (or a very lucky course official). It got replaced by the Suunto Ambit 2S, a newer multisport (fancy word for triathlon) watch. Disclaimer: My wife works for a sister company of Suunto. We purchased the Ambit as a replacement in order to “keep it in the family.”

Two Paths Diverged

The Garmin has a feature built into its website that allows you to enter a workout plan ahead of time (e.g. certain distances, speeds or times). The watch will then cue you when it’s time, for example, to run, stop or change speeds. The ability to create and enter these kinds of workouts is a huge part of what makes training technology so appealing– based on modern training science, building more complex but specific and targeted workouts is more effective than “go run for an hour.” Side note: If you want to know more about this, you should contact my wife. She has her MS in this and trained people at the Olympics. I read some magazines and am not going to be in the Olympics. Garmin made this very easy.




 All of the hallmarks of a modern web-based application: Drag-and-drop editing, drop-down menus, bright friendly color-coded interface. This is designed to let you do what you want to do as quickly and easily as possible and get you on your way without ever having to see (as a dear former colleague liked to say) “into the belly of the beast.” So when I was setting up my new Suunto, one of the first questions I asked my wife was how to enter interval workouts like this.


“You write an app for that,” she replied.


Suunto’s entire backend service for their watch is not the slick “nothing-to-see-here” recipe of the Garmin interface. It’s an Integrated Develop Environment. Users develop “apps” for particular workouts, publish them to an App Store (“App Zone”), download and modify other apps– It’s some part App Store, GitHub and gym locker room swirled together.
This is how Suunto envisions creating workouts. ("Sleep Monitor," by PPIIOOTTRR)

This is how Suunto envisions creating workouts. (“Sleep Monitor,” by PPIIOOTTRR)

To really drive this home: that screengrab above is not from any hidden backend– that’s from the main App Zone page for this App. Suunto is upfront and loud-and-proud about showing you that this is a pile of code, and here’s how this App runs.

Once an App is developed, you have the ability to play with the variables in the App Zone before you download it to your device and execute the workout. If someone has the backbone of a workout that you’d like to do, for example, but you want to change the number of repeats or the amount of time, you are presented with a series of slider bars to customize it for your purposes.

(Customizing "High Intensity Intervals," by Movescount)

(“High Intensity Intervals,” by Movescount)

Again, note the Slider bar labels– those aren’t “plain English”– those are the variable names from the code. Does your average user know what “INTDIST” is?

I’ll admit that I got a little “new device whiplash” when I saw this. As with many rough device transitions, this was an issue of planning and time– I wanted to be out the door in 10 minutes on my run. I did not have time to deal with this new paradigm. So I went through the standard stages of Inconvenience (“I don’t have time to deal with something new!”), Anger/Annoyance (“Why can’t this work like my old tech?”), Dismissal (“This new stuff is ridiculous. Who needs these features?”),  and finally arrived at Open-mindedness (“Okay– What can this do and how does it work, and does it match a need or interest for me?”). Thinking a little more clearly, I can see what Suunto’s going for here– their App Zone is filled with thousands of apps that are far beyond the stock “off the shelf” capacity of the Garmin (or even of what the Ambit ships with). Even just the basic interval workouts have more flexibility than the Garmin template builder, and there are definitely times when I was using my Garmin and got frustrated at wanting to be able to get it to do something that it wasn’t an option in their interface. Suunto’s market differentiation here is giving users the keys to the entire hardware package– all the sensors, monitors, transmission protocols and output, and saying “Go nuts, people.”

With technology in general, there is a continuum which pits convenience/usability versus customization/flexibility. The operating system battles, Internet platforms, EdTech platform/program decisions and user tool choice often boil down to the essential question of “Do I trust somebody else to decide how this technology should work for me, or do I want to invest the time and energy in making it my system?” Neal Stephenson argued passionately in “In the Beginning… was the Command Line” (great short summer afternoon read!) that as a society of computer users we are abdicating the power and willingness to bend the tool to our will and instead making ourselves adapt to dumbed-down versions of consumer tech in the name of convenience. Here’s the alternative, if users are willing to accept the learning curve.

This is Not a Drill

This is not a Kickstart project or a fringe startup trying to muscle into an existing marketspace. Suunto is a well-established fitness technology company. They’ve looked at the market, though, and clearly decided that their direction is going to be in favor of customization and flexibility over ease-of-use and user learning curve. While we debate the role that a universal skill of coding has in our students learning, Suunto seems to have already decided that it’s coming and there’s a widespread enough talent and interest base to support a major product line. Honestly, I wish them luck, but… while I’m ideologically on-board with their plan, and I’m probably pretty far to the tech-savvy side of their user base, I gagged a bit at the idea that I had to either a) write an App myself or b) find and modify an existing one, just to go out and do the workout that I had planned for the afternoon.

This is the first major case that I’ve seen of a piece of consumer tech from an established major company banking on the “codeability” of their user base. As such, I think it’s a fascinating test case for the Internet of things and how hackable manufacturers will make their devices, as well as whether a consumer base will adapt to seeing scripting languages appear in everyday life. If this is indicative of a growing trend, or if this training device has legs (ha!), it may signal that the “should every person learn to code” argument has already left the academic sphere and that the consumer technology market will answer the question for us.

Say That to My Face?



A common concern of Digital Citizenship and online bullying is that many people view the “culture of the Internet” as one riddled with negativity and behavior that’s anti-social (if not outright sociopathic). The trolls and “lowest-common-denominator” debates that run below your favorite news site or online magazine scare away many teachers from using online publishing, forums or discussion boards in class. Why is it that behavior norms are so different online? An interesting structure came through this morning from 99U: “Born Hatin': Why Some People Dislike Everything.”

Psychologist John Suler proposed what is perhaps the best known analysis of the phenomenon in the Online Disinhibition Effect. It lists six primary factors as to why we may treat others differently online than we do in person:

  1. You don’t know me. Anonymity protects the critics “real life” reputation and shields them from retaliation and owning their actions.
  2. You can’t see me. Face-to-face interactions tend to have more empathy because we can see the person we are engaging with. It’s hard to feel ashamed when you don’t even know who’s affected. You’re just a screen to me, not a person.
  3. See you later. I don’t have to deal with your instant response, or even wait for it! I can dump my thoughts on you and never return.
  4. It’s all in my head. Suler argues that online interactions can distort reality. I can make up whatever attributes about you that I want, justifying my actions.
  5. It’s just a game. The overused response of critics who do sometimes get called out: “It’s just the Internet, man!”
  6. Your rules don’t apply here. This is the internet, where closing out a live chat isn’t rude, despite the fact that leaving in the middle of a conversation would be rude in real life.

Being able to lay these out for students could open up lots of interesting ways to engage with the norms of digital culture– role-playing, for example, or acting out example comment threads could be a great way to confront the gap between online speaker and listener (albeit a bit dangerous– manage this activity carefully). Using imagery or posters to create responses or counter-arguments to these points could form the basis of a school digital citizenship campaign.

These rules aren’t just about being online, though– I see some of these in play on a regular basis in the interactions between bike commuters/cyclists and drivers, for example (which got a great treatment in this Norwegian public safety video). Furthermore, the article presents this theory in context of a larger finding: some people are inherently “likers,” who are more inclined to respond positively to new ideas, while some are inherently “haters” who will find a reason to rate things negatively. “It paints a very clear picture: no matter what you create, a small group of people will hate it, often without reason.” This is another, equally important lesson at the root of all culture and society, digital or face-to-face: You manage your own behavior, and accept that you can’t be responsible for how some people act. The balance is to accept meaningful, productive or informed critique while recognizing and discarding the trolls and haters.

Do Suler’s six factors translate to your observations or experience with online publishing and discussion? Can you see a way in which you might want to use these as a coaching tool with your students? How do you coach giving and receiving online feedback? Join in the comments below!