Assignment 5 Report - Port Arthur AR Application

Port Arthur AR Application » Devlog
1 year ago by megans
Share this post:

1. Introduction

Elevator pitch

This application will allow visitors of Port Arthur to see the site as it once was and learn in more depth about the people who were there during its use as a convict settlement. It will leverage AR’s strengths to enhance the interactions already present at Port Arthur.   


Changes Made Since Assignment 4

  • Added 3D models for penitentiary, coal mine, and jail cell.
  • Added marker interactions at each landmark. 
  • Updated UI. 
  • Added unique interaction between character cards. 
  • Fixed numerous bugs / usability issues.
  • Added voice acting.


Demo Video




2. Technical Development


Most of the work done since the initial technical development has been focussed on adding the landmark models / interactions and adding polish to the current UI and audio. Each image target has its own UI in world space in order to have a stronger connection to the physical world. There are two types of image target pre-sets: characters and landmarks. Each have their own set of components / parent-child hierarchy.  


General Purpose Scripts:  

ScreenRaycaster: This script is held by a game object of the same name and fires off rays when the user clicks on the screen (at the click position). These rays are only fired on a layer called “Marker”, where the landmark markers are exclusively on. This allows the rays to only hit the desired targets.  

AudioManager: This script was created to address the issue found in user testing of audio overlapping. Each character had their own audio source, which caused the issue. This was solved by removing those audio source components and creating a game object which holds this script and an audio source component. This script follows the singleton design pattern and is accessed by the dialogue manager of a character when they wish to speak (if no other character is currently ‘speaking’). This has resolved the dialogue overlap issue.  

UIsize: This script was created to address user feedback about the UI being too small. This script holds float variables called “small”, “medium”, and “large” that can be edited in the inspector. Users can then press a button on the UI which will change the scaling to the corresponding value. This fixes the issue of users finding the UI to be too small.  


Person of Interest (POI) Card Related Scripts: 

Dialogue: This is a scriptable object that holds the text and audio for individual dialogue sequences.   

DialogueManager:  This is attached to each character image target and manages dialogue objects that are passed through to it. It displays the dialogue text on the character’s UI and plays audio using the audio manager object.  

DialogueTrigger: This is attached to each character image target and detects when the character is close to another object. It then sends the corresponding dialogue object for the collision to the dialogue manager component. 

Bio: This is attached to each character image target and displays their biographical information to the UI and hides the ‘next’ button when the character is not ‘talking’.  


Landmark Related Scripts: 

LandmarkBio: This stores the default text to display on the landmark UI when no markers are currently selected.  

Marker: This script is held by the clickable red markers on the landmark model. This script holds a string to display on the UI when it is detected by the screen ray caster. When selected it sets itself to be the active marker in the “MarkersManager” script. 

MarkersManager: This script is held on a game object of the same name which is the parent of all marker objects for a landmark. It holds a reference to the current active marker and can be used by a button on the landmark UI to deselect the current active marker. This allows users to go back to the main landmark bio information.  

MarkerEffect: This script is used to animate the markers to give visual feedback to the users. It uses Mathf.sin() to fluctuate a variable between two values. This variable is then used to give a pulsing effect to the marker with both transparency (alpha value on material) and scale. This indicates to the user that the marker is interactable. This script also reads the active marker from the “MarkersManager” script and makes the marker material green if it is currently selected, or red otherwise. If selected, the marker also stops changing scale in order to visually reinforce that it is currently selected.    

SwapModel: This swaps out the main landmark model for another model when the function SwapTo() is called. It then swaps back when the function UndoSwap() is called. This script can be optionally added to a marker to allow for this functionality and does not conflict with the other scripts on the marker. This is only present on the cell marker in the penitentiary in this prototype, as we only had time to create one extra 3D model to showcase the swapping interaction.   




3. 3D Content

It was important to create a 3D model of the Port Arthur landmarks to allow users to explore these sites virtually. This has a benefit of making the application more accessible, as people can explore parts of the building that they otherwise could not access. For example, a visitor with a disability or an elderly person may be unable to climb the stairs to reach the second level of the penitentiary, so the 3D model would allow them to do so virtually.   

This prototype features 3D models of the coal mine and penitentiary that depict the landmarks as they look today. This was done to make the modelling process easier, as it is more difficult to find good reference images of what the landmarks looked like in their prime. The full application would allow users to switch between a ‘past’ and ‘present’ model of each landmark, which would each have unique markers. This would allow people to virtually explore the landmark’s past as well as its present, making the overall experience feel more meaningful. We also modelled a cell for the penitentiary to showcase the interaction of clicking on parts of the main model to ‘tunnel down’ and see a closeup of a key location within the landmark. In this prototype, users can click on the marker at the main cell to view the cell model, which takes advantage of AR’s strength of allowing different virtual models to be overlaid on the physical world.  


Coal Mine Model:



Penitentiary Model:




Jail Cell Model:




4. Usability Testing


Step 1. Design and Plan 

As this is an early prototype, we wanted to focus on showcasing the key interactions of the application and determine if their inclusion as well as the use of AR is justified for the interface solution. Users would be asked pre-experiment questions to gather data of their past experiences with Port Arthur / AR and compare this to their testing impressions, which could uncover useful information. 

When designing relevant tasks for the users to perform, we wanted to emulate the experience that the user would have with the final application. As such, we planned to spread the landmark image targets around the room and ask the tester to role play as a visitor of Port Arthur. We would then take on the persona of a tour guide and walk the tester to each landmark. This approach would emulate the experience users would have with the app while allowing the tester to experience all the important interactions. Testers would then answer post-experiment questions, with two separate sections for Likert-scale and worded-answer questions. The aim of this was to receive quantitative data to allow for an effective statistical analysis, and qualitative data to find additional information. 


Step 2. Recruitment 

Ideally, we would test participants from different backgrounds / ages / technology competency levels. However, due to the time restrictions of the testing, most results were obtained from friends and family. This did provide us with a diverse age range between 18-56yrs old, which mimics the target audience for this application, as people of all ages visit Port Arthur. All participants were told to be as truthful and critical as possible, but their relationship to the group members introduced a level of bias that needs to be considered when viewing the results. Fortunately, we were able to find 15 testers, meaning we had a large pool of statistics to analyse, which can help uncover more useful information and minimise the effect of outliers.  


Step 3. Protocol of the testing 

Ideally our test conditions would have been stricter in order to reduce noise in the collected data. Protocol of the testing was not strict as we mostly tested on friends and family, which made the environment informal. We also did our testing separately as a team and therefore were not able to determine how much assistance each of our members were giving to their testers. In future we would set more formal protocols for testing to produce more reliable / high quality results. 


Step 4. Report of the findings 

Pre-experiment Questions: 

  • Almost none of our participants had previously used AR technology, and if so it had been limited to either “Pokemon Go” and similar gaming applications, or tech demonstrations in classes or science museums.  


  • This question was useful to our study as we could see how the user's past experience at Port Arthur compared to using the application.


Post-experiment Questions: 

1 = Strongly disagree

5 = Strongly Agree


  • This question was asked to find the suitability of the character card interaction.


  • This was asked to determine if our AR interactions elevated the learning experience.



  • This was asked to find if the model interactions were satisfying.


  • The following questions were asked to determine if the 3D models were effective.





  • This was asked to determine if our application solution was appealing to users. 



  • The worded questions arguably provided the most useful feedback as the users were able to help us pinpoint the application's strengths and areas that need improvement. 





Step 5. Analyse the findings 

Some of the tester's favourite aspects of the application were reportedly; the audio recordings, 3D models /  images alongside descriptions, and the interaction between the two character cards. Every Likert question had a majority positive result. This is a very encouraging outcome, as it indicates that the core ideas of the application are appealing to users and there is a potential market for it.  

Points for improvements were found to be the font and readability of the user interface. Additionally, glitches that resulted in shakiness and overlapping of our 3D models with the character card user interface were reported. Some users also noted that there should be more instructional information included. These points of criticism are largely side effects of this being a rapid prototype. With further iteration, the usability of this application can be significantly improved, which should resolve these issues.  

It was also recommended that we include more historically accurate voices for a further immersive experience. However, we chose to not to, as more standard English accent rather than a historically accurate voice would be more easily understood by ESL speakers, making it more accessible to the broader community. 




5. Addressing Results of User Testing

Most of the criticism was directed towards the usability of the application rather than the core ideas of the interactions, which means our focus will be towards iterating on the current systems to be more user-friendly. We will use an AGILE methodology and develop the project in sequential four-week sprints. We will also conduct user testing at the end of each sprint. This will allow us to consistently utilise user feedback in the design process and plan each sprint accordingly. Completing these iterative AGILE cycles will ensure that the application is suitable for users and help create a viable product. Our goal is to complete the project and present it to Port Arthur by October of 2023 (13 sprints). 

UI: 

The primary issue with the UI that people had was difficulty reading the information text. This has already been addressed by changing the font to be more readable as well as adding buttons to change the UI size.  

Instructions: 

Whilst most people found our directions relatively easy to follow, some suggested that clearer in-app instructions would have been preferable. This issue can be solved by including a short tutorial at the start of the app.

Addressing Bugs: 

A major bug users faced was objects not disappearing once the card was placed out of the camera’s view. This has been resolved by changing the visible status from “extended tracked or tracked” to “tracked” in the Vuforia event handler script. Additionally, the problem of users being unable to exit out of the character dialogue has been solved by calling the EndDialogue() function in the “DialogueManager” script when the character card is removed from view.  Finally, the bug users faced of multiple audio tracks playing at once has been resolved by creating an audio manager object that follows the singleton design pattern.   




6. References

Textures 

 

Historical Information References


Technical Development References

  • Dialogue System Tutorial: Brackeys 2017, 'How to make a Dialogue System in Unity' Youtube, available at: 

Files

boyd.jpg 45 kB
Oct 20, 2022
coal mine.jpg 38 kB
Oct 20, 2022
penitentiary.jpg 89 kB
Oct 20, 2022
Margaret Image Target.jpg 56 kB
Oct 20, 2022
PortArthurAR_test_build.apk 72 MB
Oct 22, 2022
PortArthurAR_final_build.apk 81 MB
Oct 27, 2022

Get Port Arthur AR Application

Port Arthur AR Application

Add Game To Collection

More posts