New modes of interaction for Flip videos Pt. 2

This semester in addition to teaching, I am a SIR (Something-in-Residence) at ITP, NYU-Tisch’s art/design and technology program.My mission for the next 3 months is to experiment with new modes of interaction for video: both for the flip video and live events. (Two very different fish!)

User Study No. 2

I recently wrote about my first User Study with students from Dan Shiffman's Nature of Code class. A couple of weeks ago, 3 students from Shawn Van Every's class, Always On, Always Connected volunteered to watch 4 videos. In this class, students design and build new applications which leverage the built-in sensor and media capabilities of mobile devices.

The Setup

Again, there were no computers involved. We screened the videos movie-style in a classroom. Instead of asking for 2 modes of interaction (Yes that was super clear! versus Help!), I asked for a single mode of feedback: "Raise your hand when you've come across something you want to return to."The 4 videos introduce students to developing for the Android OS. It's important to note that simply by virtue of working in the Android development environment (as opposed to Processing) the material covered in these videos is much more difficult than what was covered in the Nature of Code videos the previous week. However, the students' level of programming experience is about the same.

What happened...

Video 1: Introduction to logging

Zero hands. But from the looks on people's faces, it was clear it was not because everyone was ready to move on. A few things to note:

1. For screencasts, watching a video movie-style is extra not-helpful as it is difficult to read the text.
2. The video begins promptly after a 20s intro. With instructional videos, the emphasis is always on brevity (the shorter the better!) In this case however, I wonder if 20s isn't enough to allow you to settle down and settle into the business of trying to wrap your head around new and alien concepts. I'm sure #1 made it harder to focus as well.
3. Reading code you didn't write is always challenging and I think even more so on video where we're much more tuned into action (what's changing) and much less likely to notice or parse what's static.
4. Unlike before, when I asked after-the-fact, "Where in the video do you want to go back to?" the students were unable to respond. Instead the unanimous response was, "Let's watch the entire video again." This is where collecting passive data about the number of times any given second of a video is watched by the same person would be helpful.
5. In general, questions had to do with backstory. The individual steps of how to log messages to the console were clear. What was missed was what and why. First, what am I looking at? And second, why would I ever want to log messages to the console? I say "missed" and not "missing" because the answer to those questions were in the videos. But for whatever reason, they were not fully absorbed.
6. Last but not least, I have to imagine that this watching as a group and raising your hands business feels forced if not downright embarrassing.

Hopefully, a software interface for doing the same thing will elicit more free-flowing responses from students as it will provide them with a way to ask questions "in private."

Videos 2-4

Everyone was more settled in after watching the logging video. Each subsequent video built on the momentum accumulated in the previous one. With Video 2, I started to get some hand-raising starting with video 2. when we returned to those points in the video, people were very specific about what was confusing them."Why did you do that there?" or it's converse, "Why didn't you do that there?" was a common type of question as was "What is the significance of that syntax?"

Another way to look at it is: There were never any issues with the "How." The steps were clearly communicated and video is a great medium for explaining how. The questions almost always had to do with "Why?", which makes me wonder if this is the particular challenge of video as a medium for instruction.

Does learning "Why?" require a conversation initiated by you asking your particular formulation of "Why?"

Video 2: Toasts

Video 3: Lifecycle of an Android App Part 1

• @2.00: What is the significance of @-id? Why aren't you using the strings file for this?
• @6:50: Why did you change arg0 to clickedView?

Other syntax questions included:

• What's the difference between protected versus public functions?
• What's extend and implement?
• What's super()?
• What's @override

All of these syntax questions pointed to a much larger / deeper rabbit hole having to do with object-oriented programming and encapsulation, a quick way to derail any getting started tutorial.In general though, I don't think these syntax questions prevented you from understanding the point of the videos which were about creating pop-up messages (Video 2) and the lifecycle of Android apps (Videos 3 and 4) (when do they pause versus stop, re-initialize versus preserve state).

Video 4: Lifecycle of an Android App Part 2

In Video 4, there were a lot of nodding heads during a section that shows the difference between pausing/resuming and killing/creating an Android app. The demonstration starts around @2:20 and goes for a full minute until @3:23. Epic in online video terms. It's followed by a walk-through of what's happening in the code and then reinforced again through a perusal of Android documentation @3:50 where an otherwise impenetrable event-flow diagram is now much more understandable.It's also important to note that both the demo which starts at @2:20 and the documentation overview @3:50 are preceded by "downtime" of trying, failing and debugging starting the Android emulator and navigating in the browser to find the flow diagram.In general there's a lot of showing in these videos. Each concept that's explained is also demonstrated. This segment however was particularly lengthy and in accordance with the law of "It-Takes-A-While-To-Understand-Even-What-We're-Talking-About" (#2 above), my completely unverified interpretation of events is that the length of the demonstration (far from being boring) helped everyone sink their teeth into the material.

What's Next and Learnings for Design

As we head into testing actual software interfaces, this 2nd session gave me more concrete takeaways for workflow.

1. You lay down "bookmarks" on the timeline as you watch to mark points you would like to return to.
2. You lay down "bookmarks" on the timeline after you've watched the video to signal to the instructor what you would like to review in class the next time you meet.
3. You can expand upon "bookmarks" with an actual question.
4. You select from a set of question tags that hopefully help you formulate your question. (More to come on this.)

While it's important to break down the videos into digestible morsels, it's also important to make it easy to watch a few in a row as the first one is always going to be the most painful one to settle into. There are ways to encourage serial watching with user interface design. (e.g. playlist module, next video button, preview and auto-play the next video.)  But perhaps something can be done on the content side as well by ending each video on a so-called "cliffhanger."