Month: September 2021

In the past week I’ve entered the initial development stages of my project. I’ve decided to produce a prototype for an AR mobile application that attempted to resolve and scalability challenge in the Multimedia Centre at the University of Winchester. As courses continue to grow around the University, demand for training on different cameras is increasing. At points during each semester, training demands are so intensive that cameras are kept within the confines of the Multimedia Centre for training, rather than being taken out into the field by students. This hold on cameras is not something that staff intend to do, but is a natural result of cameras being booked in advance for training sessions. By creating an AR mobile application with virtual cameras, which allows students to receive some form of camera training, I’ve hypothesised that some pressures on physical camera training could be relieved. 

Being relatively new to AR, and only understanding it from gaming and sports experiences, I’ve carried out some initial research into it. From this, I’ve ascertained that AR systems follow three characteristics: 

“1) Combines real and virtual
2) Interactive in real time
3) Registered in 3-D” (Azuma, 1997)

Augmented Reality experiences also tend to come in a variety of forms, commonly involving a user’s handheld device such as a mobile phone or tablet, but can also involve kiosks or head-mounted displays (HMDs); they aren’t limited to particular types of devices. I feel that I’ve noticed that the form factor of these experiences is often dictated by the purpose, however; so for an AR app like Pokemon Go, smartphones might have been chosen as the distribution device because users often already have one in their pocket, and the device itself features a camera and navigational functionality already.

Benefits of AR

Mobile Augmented Reality appears to be most accessible for my end users, who are likely to be University students, although other benefits include: 

• “Mobile augmented reality is especially well suited to ideas such as ‘ubiquitous learning’ in which the plan is that every person learns all the time, wherever they are, when they need to.” (Craig, 2013)
• AR experiences can be relatively low cost when developed for smartphones or tablets (not for permanent, purpose-built devices however) (Craig, 2013)
• Users may already own the necessary hardware (smartphones and tablets), and even be willing to keep it up-to-date by completing software updates, or replace it by upgrading on an annual (or less frequent) basis

Constraints of AR

• Depending on the use case, augmented reality may require a specialist kiosk with sensors etc rather than using users own hardware (Craig, 2013)
• Mobile devices can offer a limited screen real estate, which can negatively impact user experience and the user interface (Craig, 2013)
• Mobile devices have other performance limitations such as their memory (Craig, 2013)
• Augmented reality experiences are at the mercy of environmental constraints such as lighting, humidity, and noise, as well as interference (Craig, 2013)
• Standardised interaction schemes are required to overcome any limitation in user understanding of augmented reality experiences, (how to launch the experience, how to place an object etc)

Having settled on creating a prototype for an AR mobile application, I’ve began my initial development with some ideas generation. Below, I’ve included a copy of my mind map, which includes thoughts on your mental reality experiences purpose, accessibility considerations, thoughts on distribution, and software opportunities. At this stage, I’ve made an assumption that my end users will be students, so I’ve also made some consideration for the educational benefit of an augmented reality experience. 

A final thought for this week comes from a discussion I had with my lecturer around the outcome for this project. When asked about suitable outcomes for submission, my lecturer informed me that a proof of concept would be a good option. I don’t yet know what one of these is, although for now I assume it is along the lines of a high fidelity prototype. Although I’ve produced one of these for my recent project, focused on mobile application development, I imagine that producing one for an augmented reality experience will involve using different software applications.

References

Azuma, R.T. (1997). A Survey of Augmented Reality. Presence: Teleoperators and Virtual Environments, [online] 6(4), pp.355–385. Available at: http://www.cs.unc.edu/~azuma/ARpresence.pdf [Accessed 28 Sep. 2021].

Craig, A.B. (2013). Understanding Augmented Reality: Concepts and Applications. San Diego: Elsevier Science & Technology Books.

This week I received the brief for my next module, DM7903: Design Practice, which appears to be heavily focused upon assessing my iteration and ideation techniques. The assessment criteria requests “breadth and depth of design sketches,” which show “clear progression… initial concepts to finished digital design visuals”, so it’s imperitive that I make use of the development techniques that I learned in my first year study, such as sketching, wireframing, and paper prototyping. I feel quietly confident about knowing the theory behind using these techniques, but I’m aware that I need to practice them more.

Upon reflection, my paper prototype for the DM7917: Emerging Media module was quite rudimental, so I’m keen to explore how I could push the boundaries of my knowledge in these area, and really explore the benefits of paper prototyping. Of course, to some extent this depends on the project I choose to complete.

In terms of producing a project for this module, I’m intrigued by experimenting with Augmented Reality (AR). I have never worked with AR before although have some knowledge of it (limited to Pokémon Go and football games on TV). I think that there’s potential for me to create a prototype of an AR experience, or something along those lines, but this will need a bit more exploration over the coming weeks. My intention to focus on producing an AR experience could even lead me to exploring some time-based visualisation techniques too, such as storyboarding, which could further strengthen my planning skills.

Based on my performance in prior modules, I’ve identified this module as an opportunity to implement some changes to my workflows:

Firstly, feedback from my most recent module stated that I may have included too much reflective writing on my online portfolio. A suggestion from my lecturer was to consider more creative methods of explaining my processes, such as animation. With this in mind, I may attempt to Vlog, or demonstrate at least some of my creative processes using Youtube. Despite attaining good grades in all previous modules, I can see my lecturers point – I need to find more efficient, engaging and appropriate methods of recording and communicating my learning.

I’m hoping to continue my focus on accessibility, which I’ve so far addressed in both DM7921 and DM7917. This is an area of study that I notice I’m beginning to feel quite strongly about, so it makes sense to lean in to this interest. Most recently in DM7917, I considered my application’s prototypes from the point of view of a user with a vision impairment. But unfortunately, I spent much of my time paying attention to colour contrast, yet neglecting other relevant features such as text resizing. Of course, the process was an education for me, but it definitely shows an area for improvement. For this reason I’m going to approach accessibility with an open mindset at first, hoping to narrow down my focus to a specific area of accessibility as the project continues. I think that this approach will allow me to learn a lot more about a very specific area of accessibility.

If possible, one other area I would like to explore is user feedback. If I decide to create an AR experience, perhaps via an app, it would be beneficial for me to collate user feedback of competing applications, to find common trends. Hopefully, these trends may identify limitations in other developer’s solutions, which I could rectify in my own.

Finally, as this module appears to be quite focused on iteration and ideation, I’d like to hasten my usability testing process, which I began in DM7917. Although the process was brilliant for gaining useful user feedback, it was a timely and inefficient process, limiting what I could achieve within the module’s timeframe. As a strategy, I intend to only employ usability testing when I am purposefully testing the prototype, such as when I’m integrating a new feature or testing the interaction between the user and the experience. Each usability test will be focused on one or two specific tasks, and prototypes will be built to only achieve those tasks, rather than being a broad and ‘open’ experience.