By Michael Taylor, Learning Technologist and Project Developer at University of Nottingham.
Any successful project requires good planning, progress tracking and review to ensure project costs, scope and deadlines are met. To this end, the Health E-Learning and Media team (HELM) at the University of Nottingham have devised the ASPIRE development framework which also importantly supports pedagogical design methodology and has been applied by the team over many years in their development of Reusable Learning Objects (RLOs).
The challenge now is to see if ASPIRE can be used successfully as a framework for 360 video development or would experiences learned when producing 360 video content highlight the need for major revisions to the ASPIRE framework, or even lead to the adoption of a totally new design methodology to cater for 360 video and other immersive technology development.
Why use ASPIRE?
One reason why ASPIRE was developed by Helm and used instead of other available development frameworks, is because we believe it fully supports a community participatory design approach to development.
When developing resources, we understand that including as many project stakeholders as possible is key. Such stakeholder involvement helps to identify and align the requirements of all the focused learner groups, this in turn helps to shape resource content and the way it is represented.
The ability to share stakeholder knowledge and expertise helps ASPIRE to assist the development of quality resources, which are fit for purpose and can be shared not only directly by all project stakeholders but also ultimately with the wider Open Educational Resource (OER) community. For example, the Community Nursing Scenario developed by the Nottingham team as part of the 360ViSi project may benefit from ASPIRE’s two step peer review process, which would allow experienced UK community nurses to review content for accuracy before starting development.
A second technical review could be carried out after the development and prior to release. Such quality assurance steps would help identify potential resource bugs before release.
What is ASPIRE?
ASPIRE is an acronym of all the development framework steps involved during resource development and after release.
- Aims – helps project teams to focus on getting the right learning goals and objectives
- Storyboarding – allows the sharing of initial ideas for resource content and enables a community-based approach to resource design
- Population – combines storyboard ideas and allows the content author/s to write a fully formed specification, which includes a narrative and multimedia elements
- Implementation – a specification/content peer review is provided by a suitable subject expert not yet involved in the project, allowing for suggestions and concerns to be raised and addressed before starting/implementing resource development.
- Release– a second technical peer review is applied, and any issues are addressed and approved before resource release
- Evaluation– using data tracking and feedback forms to collect data for research and development purposes to assess the resources impact.
An Online toolkit to support ASPIRE framework
A number of bespoke tools have been developed and implemented to help support the procedures and requirements of the ASPIRE framework within any given project. They co-exist alongside off-the shelf commercial applications to deliver a full online toolkit supporting all ASPIRE development steps.
The toolkit proved invaluable during the recent pandemic when meeting in person was not possible and allowed online group participation and development through tool use. The toolkit includes an off the shelf storyboarding application which allows numerous participants to simultaneously access, review, discuss and record project ideas.
There is a bespoke specification tool that allows content authors to build on ideas raised at the storyboard stage and create, populate and implement an online development specification, which can be accessed and shared by the whole development team. The specification tool further helps with versioning issues which can arise when working with large stakeholder groups.
Can 360 video methodology and other immersive technologies use ASPIRE?
It was fully anticipated from the onset of this project that the ASPIRE framework could successfully be used for 360 video and future immersive technology development. However, there was an expectation by those experienced in applying the ASPIRE methodology that some adaption would be required.
Recent Helm collaborations with international development teams on sister Erasmus+ immersive 360 VR projects such as CEPEH and CoViRR had identified certain limitations when using ASPIRE framework and associated tools. For example, our bespoke Specification tool required manual modifications from each of the content authors to cater for 360 video and VR content development.
Employing Need Analysis methodology
To help understand how the development needs of 360 video content differed from that of more traditional multimedia content a need analysis was carried out by the 360 visi partners. This ensured that all development requirements were recognised and recorded at the project start to help identify any potential adaptations required for the ASPIRE methodology and associated tools.
A team of 12 developers and academics from all partners met regularly at the early stages of the 360 Visi project to set some overall project guidelines and create working practices. During one meeting the Nottingham team showcased their developed online ASPIRE specification tool, which had the capability of being accessed and shared.
The need analysis involved the review of four 360, VR specifications belonging to each of the partners for suitable use in the project. The results of these reviews and specific requirements and recommendations from each team are presented below. (See Table 1).
Results
It immediately became apparent that each partner specification asked for slightly different data input. For example, the form used by the University of Stavanger had text fields to enter such information as the duration of each scene and camera placement. This differed from the Universidad Católica de Valencia who wanted to record further information about each individual medical case.
Nottingham’s specification document asked for detailed prop information and the TUAS form was focused more on completing a simulation scenario as part of their bespoke tool development.
A decision was made by all partners to design a standard specification form that would include features that each partner deemed necessary for the development of immersive content. Although each partner recognised the ASPIRE specification tools potential, it was primarily designed to be used with Nottingham’s more traditional RLO format and it was agreed that it required amendments to fit immersive project needs. The results are entered below.
| Project partner | Critical review and suggestions |
| University of Stavanger | · Pre-production section – common case understanding for all team members · Technical preparation – required equipment and how it should be used in project · Communication – documentation – consent forms · Community of practice – inform all relevant parties about project. · Post production – brief information on tools to develop content after the film shoot · Area to view test footage · Room description · Observation view – Where to place camera · Scenario description · Audio, hotspot text and narration if required · Rationale for producing in 360 instead of 2D video |
| The Catholic University of Valencia “San Vicente Mártir” | · Specification learning outcomes · Case description (background information provided to student prior to accessing 360 video) · Hotspots – with or without static photos |
| The University of Nottingham | · Required props · Required filming/lighting equipment · Cognitive learning outcomes · Scene description – signs, external sound etc. · Filming approach – camera settings – formats |
| Turku University of Applied Sciences | · Required props · Simulator setup/manikin preparation · Observer tasks · Scenario lifesavers – case briefings · Pre-material required · Major problems encountered · Non-technical co-operation – staffing |
A visual representation of intended additions to the specification tool can be viewed in the illustration below. The sections in green represent the current functionality available in the tool including the adding of:
- text in the form of a narrative
- multimedia assets
- author ‘further comments’ pop-up box
The subsequent blue sections represent the additions recommended as part of a basic need’s analysis through a series of meetings/consultations with 360 Visi project stakeholders.
Detailed explanation
The following section explains in more detail the suggested tool functionality that each segment represents in the illustration.
Filming Equipment
Description of cameras, microphones, lights etc. required for each shoot. This is an essential checklist for all the production teams.
Prop Listings
Detailed list of everything required in each scene e.g., from uniforms to nursing equipment through to everyday items such as bicycles, cars etc. Everything required in shot to make the scene as realistic as possible.
Scene Area / Description
What is to be highlighted in each video clip, e.g., streetlamp to highlight lighting security at night, or key safe to support access issues.
Observation View (Camera placement)
Not always easy to predict, especially if the production team are unfamiliar with the area that is to be filmed. However, it does help focus production team on task at hand and gives a valuable guide on camera placement whilst on location.
Audio Description
Used for narrative description of each scene. It helps guide user to where the action is located when using 360 clips.
Scene Duration
Estimated length of scene, very useful whilst out on location and during post-production.
Scene Learning Objectives
What leaning objectives will be met in each scene, they are broken down into Skills, Knowledge and General competence.
Hotspot Learning Element Placement
Used mainly in post-production to show editor where each hotspot is required, this also very useful during filming sessions, as a potential hotspot could become lost in 360 camera’s stich line. This will lead when considering the camera placement for every scene.
Hotspot Text
This information-based text is often overlooked by content authors and is left to the developer to write and include. This section would specify if an image, 2d video or audio clip is to be added as part of the hotspot for the learner.
Discussion
There is an overall necessity highlighted through our work with immersive technology for the adaptation of some stages of the ASPIRE framework. For example, a recent project undertaken by HELM on the repurposing of case-based learning helped introduce a modification to the Storyboarding stage of the ASPIRE process. The aim of modifying the ASPIRE process was met, as the Storyboard stage was changed from previous collaborative visual idea generation to decision-making tree, and content driven discussion. [2].
The content creators need also to realise that a VR, XR or interactive 360 video resource is more immersive and therefore training around both understanding the differences on the design with more traditional web based educational resources, but also how to describe the content is needed. [3].
Early adopters of the ASPIRE framework on 360 videos for clinical skills [4] identified the need of adapting the ASPIRE framework and for more concrete tool functionalities. This is in line with the recommendations that are made in this discussion.
In conclusion, the ASPIRE process is a recognised development methodology for creating high quality digital resources. [1] The needs analysis carried out during this project provided an opportunity to adapt our existing bespoke specification tool currently used in the ASPIRE process. 360 and VR technologies are the next generation of media and will be increasingly adopted for use within learning resources. Creating robust specifications prior to creating the media for these resources is crucial to ensure future high quality and efficiency in development.
Future developments
Adaptation of existing paper-based tools is currently under review and our peer review forms will shortly be joining the other bespoke tools available in supporting the online implementation of the ASPIRE process.
Acknowledgments
This work was supported by the ERASMUS+ Knowledge Alliance “Increase access to training in European health education through 360o video simulation technology, 360ViSi,” and the ERASMUS+ Strategic Partnership in Higher Education “Co-creation of Virtual Reality reusable e-resources for European Healthcare Education CoViRR” (2018-1-UK01-KA203-048215) projects of the European Union.
References
1. Wharrad, H., Windle, R., Taylor, M.: Designing digital education and training for health. 10.1016/B978-0-12-813144-2.00003-9, (2021).
2. Pears, M., Henderson, J., and Konstantinidis, S.: Repurposing Case-Based Learning to a Conversational Agent for Healthcare Cybersecurity. 10.3233/SHTI210348, (2021).
3. Konstantinidis, S., Wharrad, H., Nikolaidou, M, M., Antoniou, P., Neokleous, K., Schiza, E., Matsangidou, M., Frangoudis, F., Hatziaros, M., Avraamides, M., Bamidis, P, D., and Pattichis, C, S.: Training the Trainers Curriculum on Co-Creation of Virtual Reality Reusable EResources: 12th International Conference on Education and New Learning Technologies, (Edulearn20). 5752-5761. (2020).
4. Schiza, E.C., Hadjiaros, M., Matsangidou, M., Frangoudes, F., Neocleous, K., Gkougkoudi, E., Konstantinidis, S. and Pattichis, C.S.: Co-creation of Virtual Reality Re-Usable Learning Objectives of 360° video scenarios for a Clinical Skills course. IEEE 20th Mediterranean Electrotechnical Conference (MELECON) (pp. 364-367). IEEE. (2020).
