Week 2.2 Context, Meaning, and Narrative (Initial Plan and Storyboards)

In class today we began a workshop exercise paper-prototyping our idea through a mobile phone medium. Below are some of our sketches exploring how we might lay out our app.

We finalised these ideas, then gave them to another team with the only context that they're trapped in a building after an earthquake. They ran through a scenario and gave us feedback on what they couldn't understand/ thought we could improve in our layout.

The main feedback was that we simply didn't need the third 'Menu' screen. We could easily incorporate that either as a hamburger menu or find another way to integrate it into one of our other screens. We also got feedback questioning the visibility of our text in the scenes. After some discussion we've decided to look into some examples where text is used in a 3D MR space and go from there. Below is us starting to refine our ideas including changes we're making with the feedback.

Our final concepts from this exercise:

We've been thinking about splitting our idea into two parts: from the victims perspective, and from a rescuers perspective. We would have the same product technology, but through two different mediums.

For a victim in an earthquake, we want a device that's easily accessible, something on hand and easy to use. So logically we'd focus this through a smartphone or any device that can use apps (we could take this further by 'collaborating' with Apple/Samsung to get our app onto the control panel as part of the phone's main system, like the torch/camera etc...)

For a rescuer in an earthquake, a more complicated, larger piece of tech would be available. Therefore this could be an opportunity to upgrade a piece of uniform first responders already have. Our initial thoughts on this are to design safety helmets that incorporate an interactive visor that overlays our products visuals onto their normal view.

-Ruth

Ruth: Rescuer-Helmet/Visor

So our potential product for this would be based off the stereotypical safety helmet with an added visor.









We plan to make our videos from a first person perspective to add intensity and realism to our scenarios. This would mean that in editing we could overlay a 'visor' over the

Initial Storyboard for the Rescue/Helmet Visor Concept:

• MUST: A requirement that must be satisfied.
-Identify hazards, provide information
- Register movable and unmovable items 
-Wayfinding in an earthquake situation
-Prior training with the product before event

• SHOULD: An item that should be included in the solution if possible. 
-Interactive, using gestural movement.
-Identify/register victims

• COULD: Desirable but not necessary. If time and resources permit.
-Larger map function
-Locate other responders/ link information between teams

• WON'T: Users really don't want it, so why put it in?
-Be accessible to untrained responders

-Ruth

Gen: Victim-Phone/App

The device that would be used is the phone where there would an automatic built-in feature for emergency purposes. Motion detection would activate this when violent movement/shaking is felt.

Initial Storyboard for the Victim/Phone App:

• MUST: A requirement that must be satisfied.
- To facilitate their evacuation out of a building after an earthquake or request for assistance from a proffessional
- To keep them calm and focused in the event of a distaster

• SHOULD: An item that should be included in the solution if possible. 
- Identify hazards in the path
- Register movable and unmovable items 
- To see hurt victims that need help through heat signals
- Be activated from updates from government civil defense 

• COULD: Desirable but not necessary. If time and resources permit.
- A satellite map part of the app that helps them when out of the building to reach a safe zone
- Have a motion detector to sense a violent shake to activate the system
- A feature that notifies friends and family when in a safe zone, or get out of the building
- Additional information for the prevention of injury during disasters  

• WON'T: Users really don't want it, so why put it in?
- Display or app that is too complicated
- Have a log in page
-  Too ask the user to many unnecessary questions
- To be too costly when purchasing the app

-Gen

SaveSave