Achievement Table
List of Known Bugs
Below is a list of all our known bugs alongisde their importance.
Contribution Distribution Table
Below is a summary of how each team member contributed to this project.
Critical Evaluation
UI/UX
Throughout developing the UI for our project, we have continued to critique and improve upon our design.
What started out as a basic vision of a UI, has slowly transformed and become a fully interactable UI which
fully utilises the features of the Hololens. Our finished design includes 3D objects, set in multiple depths of field;
holographic textures which fit seamlessly into the real-world environment; multiple methods of interaction including voice
and motion control; and many others. All of these features have allowed us to create an incredibly immersive application
which allows uses to fully utilise the potential of the Hololens while also being able to effectively control it.
On top of design aspects of the UI we also took into consideration the user experience of the UI. Our priority was to ensure
the UI was easy to use within its designated environment of a hospital. This meant utilising universal AR guidelines which
detail an interval of depth and height for object placement, among other aspects. For example, the Microsoft Design Academy,
recommend objects be placed within 1.25m to 5m away from the user for comfortable viewing. Moreover, further research lead us
to understand the high restrictions of AR. Objects must not be placed too high or too low as detailed in the image below.
Functionality
The functionality of our project is both extensive and efficient. Each feature has been meticulously implemented to ensure it fulfils its role. As of finishing our functionality based off of our requirements is high. The key function goals of our project were to display data and content in a way which was interactive but not distracting to the user while utilising the features of the Hololens. Interactivity: Users have the freedom to interact in the way which is most convenient for them during a given scenario. They can utilise the methods of interaction specific to the Hololens such as voice control, and one or two-handed manipulation. Data Display: We have two forms of data display, one being from an external API and one being from a JSON file. We can display data live from the API to the Hololens and also create custom data visualisations using data from a JSON. This proved incredibly effective, as the Hololens has many ways of implementing data visualisation and meant we had much freedom and creative potential when it came to this. Ultimately, we created visually stunning, interactive and simplistic graphs for out project. Utilisation of features: Through extensive research and exploration, we were able to grasp and integrate an incredible number of features of the Hololens. From spatial mapping using world anchors, to voice control using a phrase recogniser, we implemented many features to ensure out project effortlessly blended into the real world.
Stability
Stability is : Characterises the sensitivity to change of a given system that is the negative impact that may be caused by system changes.
For the most part, our project is developed using the Holotoolkit which is the primary developing tool kit for Hololens 1. Meanwhile, for Hololens
2 development a new development toolkit the ‘Mixed Reality Toolkit’ (MRTK) is used which has some breaking changes within it. At the time of developing
our project, due to the ever changing and newness of the resources, we were not able to develop using primarily the MRTK as it would have been too
complex and subject to much breakage (errors). However, at the same time there are many resources now available on the differences between them.
As a result, it may be relatively simple to update the project to improve stability.
At the time, we felt using the more solid and integrated Holotoolkit would allow us to make a more stable, and high functioning project. Our project
is stable for the device it was designed for. It was not designed for the Hololens 2 as this was released well into the start of our project.
However, aside from this aspect of stability, when it comes to the code we did implement we believe this does possess high stability. We
followed a simple set of practices to ensure our code could be changed and enhanced without causing faults or damage. We ensured to emphasise simplicity
and implemented a comprehensive set of tests to allow for this. By implementing design practices such as inheritance, reuse, and polymorphism, we created
a codebase where changes would be localised rather than spread throughout the system. As a result, it minimises the changes needed to add new or to alter
functionality and increases stability.
Efficiency
Code efficiency is a broad term used to depict the reliability, speed and programming methodology used in developing codes for an application. Code efficiency is directly linked with algorithmic efficiency and the speed of runtime execution for software.
For the most part, our project is extremely fast and responsive. When operating and navigating the project, the response time is satisfactory. This
allows user to comfortably use the application without worrying about response time. Below are images taken from the device portal in unity and windows
which detail the CPU usage, frame rate and memory use. The framerate can be seen to be around 60fps which is optimum for an application such as this and
allows for immersive viewing.
Generally, our application runs very stably and efficiently. Though, when carrying out API calls for medical extraction, we do see a rise in
usage as this is quite computationally intensive. Overall, the performance of our program is very effective and smooth.
Compatability
This project has been entirely created within Unity, using the HoloToolKit assets provided by Microsoft for
the Hololens 1. As a result, this application is currently compatible with the Hololens 1 and also the Hololens
Emulator. However, the emulator must be run on a windows machine in order to be used.
As the Hololens 2 has
recently been released, we have been looking into the compatibility of a Hololens 1 application being ported
to the Hololens 2. However, the Hololens 2 uses a newly released version of the HoloToolKit, the ‘MRTK 2’ which
has updated many of the scripts and other features previously used. As a result, some features may not work if the
project was to be ported onto the Hololens 2, but it is possible to alter it so that it can.
Maintainability
As mentioned above, the project can be updated to reflect current practices for the Hololens by simply updating
the changed scripts / features. Aside from this, we also wanted to ensure our code was fully extensible. This
included ensuring variables were public to reduce coupling and making the code less complex using tags.
Moreover,
the code is also extremely organised to increase clarity. As a result, the code can easily be updated and changed
if necessary. Meanwhile, we also make use of external code bases through APIs. APIs have the benefit of being highly
efficient and offer much freedom for personalisation. Consequently, APIs allow us to efficiently retrieve data for our project.
Project Management
From start to finish for the project, by word of the team leader, all aspects were planned and split accordingly.
Goals and milestones were constantly being reached and updated, to ensure remained either on or ahead of target. As a
result of this it allowed us much time to refine our work; evening out any design or functionality issues to further improve.
We also utilised development tools such a Trello as a means of adopting a ‘dev-ops’ style way of managing out project. This
ensured we constantly thought of new changes and put them into production. Moreover, it meant we had strict deadlines and did not
fall behind.Below is screenshot of our Trello board during the early stages of development. Deadlines are divided into categories,
with a date, description and an assignee.
On each deadline we detailed what needed to be done and included a link with a guide on how it could be completed. This allowed us
to get on with tasks right away, as we were clear in what needed to be done and how it could be achieved. Moreover, we also assigned
it to a specific member of the team, added a date and could write comments beneath if need be.
Aside from Trello, we also had to implement a way of sharing our files. Unity does offer a method of version control, however it was
not free and thus we did not have access. Instead, we opted for a free and simple to use method of a google drive with labelled files.
This allowed us to upload labelled version of the large unity files for safe and easy acces, while also allowing us to keep track of changes.
