I continue to believe that pedagogy should drive any learning technology implementation, but every once in awhile it is important to drill down on the nuts and bolts of the technology implementation. This post is about that, the various idiosyncrasies and peccadilloes one confronts in working through such an implementation and the compromises that have to be made along the way to get things to work, more or less.
We’ve recorded a seminar with a few students, are now in the process of taking those recordings and chunking into clips, more or less aligning the clips with subsections in the textbook and with the instructor’s PowerPoint presentations, and then displaying those clips along with other course content. Below I’m going to ask a series of questions that you might think of as determining requirements for the solution we’ve come up with.
Q: Where do the video clips reside, on a College server or an external host?
A: The decisive factor here was having complete control of content. We opted for having the College host. One implication is that our video is being delivered in Windows Media Format. The solution is also related to the next question.
Q: Are the videos password protected or open access?
A: We anticipate students coming from the LMS to see the videos and are designing that way. The students have already authenticated to get them into the LMS. We don’t want them to have to authenticate again, so for this coming semester the videos will be open, though we will try to make it impossible for Google searches to find them. In the future *perhaps* we can develop a trust relationship between the LMS and the Video host so we can get the higher level of protection yet with students not having to put in another password, but we won’t have that for this fall. I should note that the pay version of blip.tv has the nice feature that you can make the video private but nonetheless embed it in a another Web page, such as this blog. (You can’t do this with YouTube.) This is the functionality we want but we opted for College hosting anyway because it is a big deal to go off campus with content that we want to control.
Q: How are text descriptions and related metadata of the video rendered? What software is used for that?
A: We toyed with using a new product called Ensemble, but ultimately we opted for embedding the videos within a discussion post in the LMS. (See this screen shot for a look.) One reason for this is that Ensemble in its current version links to a player that launches separately. We wanted to allow for an embedded player, to seem similar to other video experiences students are likely to have had.
Q: If students want to make a comment or ask a question about a particular video clip, how do they do that?
A: This is another reason for using the discussion post as the Web page where the video clip is embedded. A student can simply hit reply and ask a question right there. Otherwise, we’d have to have one area for the videos and another play for Q&A and it would be harder to tie the two together.
Q: How will students find the appropriate content for them to access?
A: For a first pass through at the content we will use the learning module structure that is in Blackboard Vista to arrange the content. When students want to review, however, they’ll likely find content via search rather than by browsing for it, particularly if they want only one clip or bit of content. Some of the content for the course will reside on a publisher’s Web site. There is no search solution that we are aware of that allows one search engine to find that publisher content as well as content inside the LMS site for the course. So we knew we’d have to deal with at least two search engines. We opted to go for two and no more. This is yet another reason for using the discussion posts. The search engine in Blackboard Vista does find the text in these posts.
Q: Any other tips of adjustments you want to mention at this point?
A: We found the ShowStatusBar attribute of Windows Media player and enabled that. In the screen shot it has text in pale blue on the left saying “Paused” and on the right indication the time played so far and the total time of the clip. This is a nice functionality that we think is important, particularly letting the student know how long the full clip is. Unfortunately, it doesn’t seem to function well. The status bar sometimes doesn’t appear. I don’t know why.
Q: How is accessibility being managed for the video content?
A: We’re still working on this. The current thought is to produce and open caption alternative that is launched in a separate player, and produce the captions below the video rather than as an overlay. But captioning is a time intensive activity – about 8 to 10 minutes per minute of video. So we may not have the content fully captioned when we roll this out for the fall.
Q: Are there other accessibility issues to be considered?
A: The previous screenshot shows content that is rendered via a Table. Current Accessible Web Design suggests use of Cascading Style Sheets instead of tables. Here is an example using CSS as an alternative. Looks at where the Reply and Forward Buttons appear. Also, look at how the tan background is all broken up. We’ve not yet figured out how to use CSS without producing this sort of result. And if we can’t solve this, we’ll use the Table formatting and then perhaps post the caption video in a different message that just has that has a simpler layout.
Q: I see that you are doing a rate the video with an external polling tool, polldaddy.com. What is that?
A: First, YouTube has a simple rating scheme for each of its public videos, and most other video sites have imitated that. So we thought we’d do that too. We’re curious to know whether the students take the time to click that. Second, we wanted the students to rate the videos but not rate the comments of the other students. There is a built in rating scheme in the discussions within Blackboard Vista that could have been enabled, but if it is, it is active for all replies to posts.
Q: Are there any final thoughts you want to mention?
A: We’ve designed this to a screen resolution of 1024 x 768. It should work ok at higher resolutions, indeed the CSS screen shot was taken at a higher resolution – it just means everything will seem smaller and there will be more stuff on the screen. But someone who wants a lower resolution may be disappointed. Also our videos are rather large – 640x480 when they were capture, shrunk to 600x450 as they are rendered. This makes the managing screen real estate problem harder. Smaller videos would be easier that way, but we think they’d be less compelling to watch.
Further, it is clear we’ve not yet reached the point where an instructor could do all of this on his own, unless he was quite technically proficient and had a lot of time on his hands. There are a lot of small detail things that need to get decided and most instructors would give up before they’d have a satisfactory solution. Let’s hope it gets easier in the future.
No comments:
Post a Comment