Storyboarding & Conceptualisation
I thought the story was quite clear and easy to deconstruct since it did not pose a complex order of events. I broke down the story into “text order” that helped me to put it back into “story order”. While doing so I identified the changing point of views as the defining characteristic of the narrative. Consequently I thought the text represented a multiple story line model …
After having deconstructed the story and knowing what the plot was all about we had to answer the following questions..
- What elements should be interactive?
- What type of role should the VURP have?
Since we thought the different perspectives were a key element in Kafka’s story we decided on allowing interactivity on the character level. The user can switch between point of views but not influence the events taking place. It might seem obvious at first but we felt we had to respect the author’s logic.
Time is another interactive element in our product. Besides choosing characters the VURP can stay in once scene/map as long as he wants in order to reconstruct the story line.
The VURP is an observer and watches how the story develops by changing POVs and exploring different maps. We changed our initial idea to unlock each stage after the user had solved small puzzles, since those challenges did not really add anything to the storytelling. Instead we included the maps and extras to add a more explorative character to our interactive narrative.
Group Production Techniques
Roles were as follows:
- Dieter: project manager, video (editing)
- Regine: video (recording), presentation content
Unfortunately we did not have one single usability leader meaning we all were involved in testing. Nevertheless we gained valuable results out of the paper prototyping.
Like in previous projects everyone tried choosing responsibilities they were unfamiliar with. I for my part was interested in creating the interactive storyboard and editing the music for our story.
Production Planning & Scheduling
After assigning roles to each member we had a rough idea of our production plan :
11th – 17th Jan: Brainstorming, conceptualisation, paper prototype production.
18th Jan: Paper prototype testing.
19th Jan: Play-doh modeling and set scenery production.
20th – 21st Jan: Filming
22nd – 23rd Jan: Video editing, compression and sound editing
24th Jan: Combining video and interactive elements in Flash Lite
25th Jan: Final product usability testing
26th – 27th Jan: Compile findings and practice presentation
We did not meet the last deadlines since Emily and Dieter had trouble with Flash Lite. During the last weekend they dealt with the last issues with Flash Lite and Usability testing, while Regine, Lee and I prepared the presentation.
Technical Prototyping & Testing
Our paper prototyping turned out to be quite effective. After every single test we would make the changes to see their immediate effect during the next test. I definitely believe it is a good way of testing mobile applications.
Even though our group did not have a designated usability person I feel we’ve learnt quite a lot when it comes to incorporating the user into the design process of an interactive application. Throughout the entire design process it is necessary to think of the needs and wants of the users.
If I look back at our paper prototyping I believe we gathered several findings that made us improve our concept. Even though our final product remains a bit buggy because of technical reasons we’ve tried our best to make the navigation as intuitive as possible.
If I had to redo this project again I would definitely insist on having someone responsible for all the usability research.
Software Inter-relationships
Throughout the project most of the group members worked with different software. Regine created the animations with Quicktime Pro. Dieter used Final Cut Pro to edit the videos, while Emily was working with Flash Lite. I used Audacity to edit the songs and iMovie to preview the sound files with the animations. As far as I know there were no problems with the compability of files except Flash Lite not accepting the Illustrator files Regine had designed for Emily. As a result the maps had to be redesigned in Flash Lite.
Asset Management Strategies
Everyone in the group used similar asset management strategies, i.e. having separate folders to organize all sorts of files (docs/ai/flas/mp3/mov/html etc), in order to keep everything well organized. When changing names of prototypes and structures we decided on giving them version numbers. All this enabled us to exchange files without any trouble.
Compression Techniques
As far as I know Dieter did not have any major issues with the compression of the video files. Even though we were quite restricted by our platform (mobile device), he managed to find codecs that would reduce the file size without loosing too much of the quality.
Once I passed him the mp3s I had edited on Audacity the file size increased considerably it was still possible to run the application on Device Central.
Scripting Efficiency & Product Optimisation
After the usability testing I gathered further ideas on how to optimise the product
- Automatically pre-select an option such as “start” on first screen. Alternatively add a border that is blinking.
- Make maps more distinguishable. So far time on the top right is the only thing that changes. Therefore change background colour.
- Show the user he can choose between different POVs.
Debugging & Modification
Our decision to work with Flash Lite turned out to be quite a challenge. Cliff had warned us about the restrictions of the application but it was still frustrating to experience it ourselves. Emily spent a lot of time adding the videos to the navigation and found several bugs during the debugging phase. If Dieter hadn’t helped her we would not have finished our product in time.
