There were six opportunities for groups to produce a video throughout the semester. In total, 57 videos were produced out of a possible 96 (refer to
lmd.computing.dundee.ac.uk/?page_id=171 for examples), which we believe is a reasonable response rate for a voluntary set of activities. However, there was an inevitable tailing off of video creation over the course of the semester. In the first few weeks, all groups produced videos, but this decline to around 20% of groups towards the end of the semester. However, there was an interesting ''spike'' during week 6 as part of the ''pressure project'' in which students were required to rapidly design and build a simple, playful, system using a randomly assigned sensor. At this stage, 75% of the groups produced a video, which may suggest that students are more motivated to put in this extra work when they have produced something they want to ''show off'' and have put a significant amount of effort into, rather than midway through a project.
In terms of feedback, many of the benefits highlighted in the previous workshop were further confirmed. Students commented that they shared their videos not only with their classmates, but with those outside the course such as family and friends. Students also identified the potential peer mentoring benefits by commenting on the ability to learn from what other groups were producing and what they could learn from them. Additionally, several students mentioned that the process had brought them closer together as a group, as the process of preparing and recording videos involved all group members. Finally, several students commented on the potential for using the videos as a reference and revision tool.
On the downside, technical constraints were once again highlighted. For example, several participants commented that uploading videos to Vimeo was extremely time consuming.
Again, embarrassment associated with the video medium - for example, being in front of a camera or hearing one's own voice - made for an uncomfortable process amongst some students; however, some groups compensated for this in imaginative ways by, for example, placing their project at the centre of the video (so that their faces were never on screen) or, in one case, through the use of sock puppets! Finally, some students struggled to see the point of the exercise, commenting that this is not an activity they would expect programmers to do. However, we would counter this by suggesting that, while they may not be tasked with producing videos in their future post-education careers, the experiences gained from
critically reflecting and communicating the results of their work will lead them in good stead.
took place in March 2012. In the sessions, students were asked to note down requirements for the system on sticky notes, which were then discussed as a group and pulled together into formal functional and non-functional requirements. Subsequently, a set of ''mock-ups'' for the system were produced. Example outcomes from the sessions are shown in Figure 2:
Figure 2 - The left image shows some of the requirements generated by the student advisory group, while the right shows a "mockup" screenshot subsequently discussed
4.2 Technical Design
A prototype of the system has been built using the open source Ruby on Rails web application framework (www.rubyonrails.org) running a PostgreSQL database. This
framework was chosen as it provides the ability to manage large amounts of data safely and securely out of the box with minimal extra configuration, and is both customizable and extremely well supported through packages known as rubygems (third party add-ons developed by individuals which allow extra features to be added, such as user
authentication, tagging facilities and so on). As a result, the framework offers many advantages over writing a bespoke framework from scratch, a process which would be significantly less cost and time effective. The system uses the ImageMagick
(www.imagemagick.org) library for image compression, and the ffmpeg (www.ffmpeg.org) library to deal with the uploading of and conversion of videos to the dedicated server.
Additionally, given the School's background in accessible web design, the system has been designed with accessibility in mind - for example, Nomensa's Accessible Media Player (www.nomensa.com/services/accessibility-and-inclusive-design/accessible-media-player) was chosen to act as the video player, as the controls are keyboard accessible and therefore do not solely rely on the user being able to use a mouse, while the states and properties of videos (e.g. current position of the video) are conveyed to assistive
technologies such as a screen reader for blind users. The application is also designed using a responsive layout, which means that the interface changes based on whether the user is interacting with the application through a laptop, a desktop or their smartphone (see Figure 3 for an example).
Figure 3 - The left image shows the interface for the application as it appears on a desktop, while the image on the right shows the interface as it appears on a smartphone, such as an iPod or Android phone
Currently, the prototype is installed on a dedicated server (Ubuntu 10.04 LTS) at the School of Computing, and can only be accessed from inside the School to reduce potential
concerns over data protection and to ensure the student-produced content is safe and secure.
4.3 Functionality
The system allows a student to upload, tag, and comment on videos, similarly to public video-based sites such as YouTube and Vimeo. However, unlike the latter sites, students cannot add themselves to the system - only an administrator (e.g. a departmental IT manager or academic member of staff) is able to add a new user. This is to prevent non- students from adding content (whether videos or comments) to the system. Figure 4 shows an example video page:
Figure 4 - Example video page showing a sample video, tags, and comments 4.4 Development Challenges
In developing the LMD application, the predominant challenges we encountered can be put down to time and technical constraints. In terms of time constraints, and while functionality which is often time consuming to achieve is already built into the Ruby on Rails framework, developing a project of this size requires a significant amount of effort and capacity, which was not always available. Therefore, some of the features students proposed, such as allowing students to tag each other's videos, could not be implemented within the project's timeframe.
Technical challenges were predominately encountered when dealing with the uploading of video files. In keeping with the non-public nature of this project, content is hosted on a university server which, while a sensible concern in terms of data protection and security, added significant complexity (often already built in to existing video hosting services such as YouTube and Vimeo) to the website architecture. Although the application works reasonably well as a bespoke solution, the video functionality that we have implemented cannot
compete with the usability and functionality of the more mature video hosting services. For example, the server often struggles to deal with unusual video formats, multiple uploads, and different aspect ratios, leading to ''unfriendly'' system error messages being presented back to the user. Additionally, we noted that, due to the third party tools we used, videos cannot be played in the Safari browser predominately used on Mac computers and the i- range of Apple products (iPhone, iPod and iPad), which is of course not ideal. Future versions will therefore concentrate primarily on the development of the unique pedagogical
and commercial aspects of the site, while allowing established services to handle video uploading, conversion, and hosting. This would also reduce the load on the server hosting the LMD application, since the video would be embedded rather than hosted locally. As noted in the semester long study, many of our students were happy to post their work publically, so it can be argued that the privacy concerns we had for this project are
potentially unnecessary. This is an area we plan to investigate further in the coming months.