Tuesday, August 2, 2016

Starting again with the balloon

This project actually started a year ago in another UCD ILT course. It was an experiment in using storytelling to teach a physics concept. I used Twine to build the non-linear story. I only got the story started - the assignment was meant to just introduce us to new tools. But I always wanted to finish it, so I took advantage of another class - Mobile Learning - to finish it, or almost.

The story, called Start With a Balloon, ended up having 15 pages, or passages. After finishing the storyline and all the text and design and all the links, etc. I made 15 little audio files, one per passage. I used a Shure SM57 microphone attached to a USB converter/pre-amp and recorded directly into Audacity for editing and exporting as mp3's. I set up a folder in Google Drive to host all the audio clips and the Twine story (which outputs as an html file). I discovered that, thank God, Twine's html was already responsive.

Ultimately I would like to change all the audio clips to little videos. I did finish four of them, for the first four passages. I used Moovly (which is pretty fun) to make the animated videos, attached the audio files, downloaded the videos and did a little more editing in Filmora.

Then came a real battle - what to do with the video files? I experimented with hosting the videos in Google Drive, which meant using the browser's video player to play the video. This turned out to be really slow and wonky on my various devices. So I uploaded the video files to YouTube (which has its own wonkiness) and then discovered that YouTube's embedded video player is notorious for not being responsive! I discovered a crazy workaround (using html and css) which actually worked.

UPDATE August 15, 2017

This project just keeps growing! It has played a role in two different courses, and I am now working on it independently. It has also been influenced by a third course - the so-called "Captivate" course. Making a self-paced learning module with Captivate allowed me to understand how this project (and almost any digital interactive program I create) is based on or informed by all the principles I learned in that course.

This summer I had to address the fact that Google Drive no longer hosts html files. I needed to find a solution and update my entire base camp/portfolio. The solution ultimately was to move files over to Google Cloud and host from there. It's not free, but it's not expensive either - so far it has cost me 1¢ of my free-trial $300 budget.

Then I discovered that Moovly was changing its platform and pricing, and that the animations I had made were not going to be available anymore. Of course, the video files belonged to me, and I had those up on YouTube, but I wasn't going to be able to make any more of the same animations. I would have to start from scratch. A couple of things had bothered me about Moovly. The animations themselves were never downloadable (and thus didn't really belong to me), and the application that made the animations had to be accessed and worked with online. I prefer having an application sitting right on my machine, so I don't have to worry about the quality or cost of my internet connection. And I definitely want my work product available for me to archive where I want. Yes, I had the videos, but not the original animations. The change at Moovly freed me to consider other options.

It turns out that Google is experimenting with creating html animations, and has a free download available called Google Web Designer. It is marketed as a design application for creating animated advertisements to use in your Google ad campaigns. Of which, of course, I have none. But using a drag-and-drop interface quite similar to Moovly, Google's Web Designer creates animations and outputs them as html files. I can't begin to tell you how cool this is, and fun to work with (if you think animating is fun - a professional animator I know calls animation "the slowest fun you'll ever have"). You don't have to worry about how to host or play the video file, or what format or codec to use, because there is no video file. The animation can stand free as a web page, and is playable on any modern browser (HTML5 compliant). Or it can be inserted in any web page in an iframe. There are tricks to make the output responsive, but for anything complicated you'll have to dig in and make changes to the css.

The application development is in the beta stage, so it still has growing pains. Though the interface is drag-and-drop, it definitely helps to understand how html and css interact. So it's not nearly as simple to use as Moovly. But there's so much more control. And it's HTML!

By now I've duplicated the four animations I had made with Moovly and am working on more. Heaven knows how long this will take. In the meantime, I'll leave the audio files in place.

Sunday, July 17, 2016

Let's Make a Rocket!

After all the reading for this unit, I wanted to create something that really took advantage of a smartphone's strengths while avoiding its weaknesses. Since I'm pretty handy with websites, I created a web app (essentially a single-page website).

First I used Photoshop to create a collection of graphics. I've always admired the high-contrast, simple, cartoon-like graphics you see in mobile apps, but I've never made them. It involves using vector paths for drawing, something that Photoshop can do but which is what Illustrator is really designed for. I don't have Illustrator, so I went with Photoshop, but I've never really tried to do anything with vector paths before. Whew! One learning curve to climb!

Second, I wanted to design a tall, thin web page, something that would involve no horizontal scrolling to view. I wanted to tell a story that had minimal text, mostly graphics. I wanted the end product to be in html. HEY EVERYBODY, get this free download - a program called Macaw that uses an Adobe-like interface to design visually with graphics and text (kinda like Captivate) but which outputs automatically to html and css. You don't need to know any code (though knowing a little will allow you to get the full benefit). It's fantastic, and it allows you to build a responsive web app that will scale correctly on any device (using something called breakpoints, which was also new to me). Another learning curve, but well worth it.

Third, I've always been intrigued with scrolling animation. This involves graphics that are animated, and the animation is triggered by the vertical scrolling. Here's the most involved example of this I've seen - NASA: Prospect, a graphic story with music, and all the animation is driven by the vertical scrolling. It's very cool, but unfortunately it's only partially responsive. Look at it on a big screen, it'll be frustrating with a smartphone!

Scrolling animation has always struck me as perfect for mobile, and I've always wanted to try it. Alas, there's no software I've found out there yet using drag-and-drop for scrolling animation, so you'll need to know html, css, and a little JavaScript. I coded my animation using Animate.css. Just visit the site and play around! Then I used the Waypoints JavaScript library. Yet another learning curve.

Then I packaged the web app into a container that made it a mobile app. Apparently many mobile apps are packaged this way. This was very easy to do using the MIT App Inventor.

If I were going to take this project further, I would add buttons that, when clicked, would add additional explanatory text and various options. I would also record audio snippets, also triggered by the scrolling, of me explaining certain things. And background music (it's sounding more and more like a Captivate project). Someday.

The mobile app is hosted on Google Cloud and can be downloaded from there. I've tested it on my Galaxy Grand Prime smartphone and my old Nexus tablet. The web app is also on Google Cloud, and can be viewed with any browser. I've tested it on my Nexus tablet and my Surface tablet (portrait and landscape). You can even view it on a big screen. Enjoy!

Sunday, July 3, 2016

Lily the Labrador

Here she is, Lily the Labrador. Is she really from Labrador? Is "labrador" really a word? Find out!

So many new tools . . . The video was shot with a hand-held Samsung smartphone, the first time I've ever done that. And the additional audio was recorded with an SM57 mic routed through a brand-new Shure adapter gizmo that turns it into a plug-and-play USB device. It's amazing! Further editing of that audio was done in Audacity. The music was played by yours truly.

I spent a bunch of time trying to get VirtualDub up and running on my new 64-bit computer. VirtualDub is a great video editor, but it can be tricky to work with. It does not shield you from the technical craziness of video filters and codecs! But I ended up not needing to use it. Instead all the editing was done with Filmora. And yes, I liked it enough to pay the $50. I'm used to using Windows Movie Maker 1.2 (the old version) which I really liked and which Filmora resembles. On my new computer I installed Movie Maker 2012, and came to really hate it. I gave up and went with Filmora. The video came out shorter than I thought it would be. I uploaded the video file to my YouTube channel.

I hope you enjoy it!

Sunday, February 21, 2016


Here at the ILT program at UC Denver there is an emphasis on effective design. There is a set of basic design principles taught in each class, summed up with the acronym CARP. It stands for Contrast, Alignment, Repetition, and Proximity. Go ahead and Google it – there are a zillion ways available to describe, explain, and illustrate these principles.

But why CARP? CARP is certainly shorthand for something – the premise is that by following these principles, your design will be “correct” or “good” in some sense. There must be some fundamental mechanism at work, though, undergirding these principles.

Consider any document that you design. What are you trying to do with it? You are trying to communicate, at least initially. Perhaps you are trying to sell something, or convince someone of something. In my case, I am always trying to teach something. I need to consider how a person learns and try to align my document with how learning works.


There are two aspects of learning that I want to address here. One is the broad principle of engagement. Without engagement, your document is effectively ignored. Without the right kind of engagement, your document will be less effective as a teaching medium. Visual clutter and confusion, for instance, creates a kind of anxiety as the eye tries to figure out where to go. This is not conducive to learning. Nor are extraneous visual elements which can be entertaining or decorative but also distracting or confusing.

Garr Reynolds presents the CARP principles in the first edition (2008) of his Presentation Zen (p. 153). I think it’s telling that he replaces CARP in his second edition (Presentation Zen Design, 2013) with principles related to beauty, balance, and harmony, states of mind conducive to learning (p. 221). Not coincidentally, these principles are applicable to digital modes of presentation, like video, audio, and synchronous eLearning, for which the CARP principles may not apply as readily.

Coherence and Structure

The second aspect of learning I want to address is an aspect that concerns me as a physics teacher. It is possible to teach physics as a collection of vaguely related topics and practices, but I prefer to teach physics by constantly referring back to the coherent series of basic concepts on which it is built. When I design a document for my students, I try to be careful about what my design implies. Is it implying a connection where there is none, or is it implying levels of organization that do not, in fact, exist? Or does the design reflect the coherence and structure in physics that I hope my students can sense?

Microsoft’s PowerPoint is a common document format, a tool that seems to result in notoriously incoherent design. A classic critique of PowerPoint design is Edward Tufte’s essay, The Cognitive Style of PowerPoint (2006). Tufte explains in detail the kind of structural incoherence that can come about when a designer does not pay attention to structural levels of information.

A designer needs to know that all graphic elements carry information, not just in the literal sense (these letters form a sentence which can be understood) but in a structural sense. When a font changes color, for instance, the brain is alerted to the possibility of a new level of information for the literal text. Consider, for instance, what happens when text in a blog post changes color to indicate that the text is a hyperlink. Or consider, as Tufte does, what it means to create bullet points. Bullets are not just a graphical device for separating text. Bullets are like the headings in an outline. They indicate levels of organization arranged coherently according to some principle or concept. Hinting at organization when in fact what you are presenting is arbitrarily arranged causes confusion. It does not create a frame of mind conducive to learning.

It can take a lifetime to discover and absorb the principles of how a person learns from a document, and how that learning can be augmented or interfered with by the graphic design. With the easily remembered principles of CARP, a designer at least stands a chance of producing attractive and effective presentations without having to become a metaphysician of design, communication, and learning.


Reynolds, G. (2014). Presentation zen design: Simple design principles and techniques to enhance your presentations (2nd ed.). Berkeley, CA: New Riders.

Tufte, E. R. (2006). The cognitive style of PowerPoint: Pitching out corrupts within (2nd ed.). Cheshire, CT: Graphics.

Sunday, February 7, 2016

A Critique of My First Webinar (Attended)

Project Based Learning for Every Classroom
2/4/16, 5PM – 6PM EST
Facilitated by Kimberleigh Doyle, Nureva (corporate sponsor)
Presented by Rachel Langenhorst, K-12 Technology Integrationist and Instructional Coach

Project Based Learning is a specific approach to using projects in the classroom. This webinar was an introduction to PBL, with details about the specific approach of PBL to classroom projects, and summaries of and links to various resources and tools.

There were over 450 participants(!), so there was no interactive learning. Sadly, the webinar was pretty much a narration of a bunch of slides. It occurred to me that a webinar was the wrong tool for this kind of presentation - pretty much any kind of asynchronous medium would have been better.

The presenter was very professional. Her voice was pleasant and practiced, but not particularly engaging. She was, in essence, simply narrating a collection of uninspiring slides. The room she was in was a pretty boring modern office, but at least it wasn’t distracting. The slides were easy to read, and the overall design was simple and reasonably consistent. The graphics used were arranged haphazardly and were not particularly engaging, but they were at least relevant.

The facilitator, on the other hand, was clearly not practiced, or even very organized. She was not paying attention to her voice quality or projection. Sunlight was coming in through the windows behind her which caused the camera to lower the exposure, making her harder to see. The miscellaneous clutter on the wall behind her was a bit distracting.

It was useful that the slides had live links in them – I could have clicked on them and opened them up if I wanted to. Because the webinar was recorded and is available to me to review, I was OK with the fact that there were no handouts.

I have to say that the experience was rather dreadful and a bit demoralizing. I would use this experience as an example of what NOT to do with a webinar. I felt exactly the way I have felt during some professional development sessions at my school workplace – information that I could have read and understood in about 10 minutes or watched in a 20 minute video being stretched out into a 2-hour presentation with relatively meaningless interaction.

I was thankful that the presenter did not narrate the slides verbatim at least. But otherwise, I am perfectly capable of viewing and reading a slide presentation on my own. I also thought it was ironic that the presenter referred to Project Based Learning many times as an alternative to lecture/explanation/presentation-based education, when what she was doing was essentially lecturing to me for an hour.

I did come to understand that with over 450 participants this webinar was going to have only minor interaction. Pretty much all the interaction was going on in the chat window. It seemed that the instant the webinar began there also began non-stop chatting among the participants. It was weird – everybody chatted as if they all knew each other and were maybe just carrying on a conversation that had been going on all day. It was incredibly distracting. I couldn’t understand how any of the chatting participants were able to pay attention to the presenter or to the slides. I understand the concept of a back channel, but this was ridiculous. And comments arrived right on cue, too – “Oh, that’s a great resource, I use it all the time!” And when the webinar ended, there were dozens and dozens of “Thank-you! It was so informative!” when in fact it hadn’t really been that informative. I actually began to suspect that most of the comments (and maybe the participants) were planted by the webinar sponsor.

This webinar made me think a lot about synchronous versus asynchronous learning/teaching. In particular, it seems to me that if something can be presented asynchronously, then it probably should be. The synchronous presentation should be saved for a smaller audience, allowing for real interaction and active learning.

I’ll finish with a final note about the webinar presentation tool. It was called AnyMeeting, and I guess it used to be called InstantPresenter. The program did not have a particularly attractive interface, but I was able to figure out the various tools (and the facilitator provided some instructions too, which I appreciated). There was one full window divided into 4 frames, which could all be resized. The video window and the slide window, when resized, also changed the size of the contents, which was great. Frames with text (like the chat frame) did NOT increase the size of the text. Because I was using a tablet, the text font-size was about 6 or 8 pt, way too small for me to read easily. Using the browser to increase the size of the window elements only caused AnyMeeting to resize the text back down, which was very annoying.