home



**﻿****Presentation Design** Chris Blais, Robin Halbert, Jeannette Jackson, Vanita Gupta EDER 679 Dr. Michele Jacobsen

** Presentation Design: Virti-Cue Social Modeling Application ** The purpose of this paper is to describe the Presentation Design of the Virti-Cue Social Story Prototype. To create a context for the Presentation Design, summaries of the Information Design and Interaction Design phases are first presented. Following these summaries are descriptions of our usability testing, including information on what and how we tested (purpose); limitations of the selected testing methodology; results of testing; and finally the implications of those results for our design decisions. ** Information Design Summary ** The information design stage of product development is “the process of clarifying your communication goals and arranging your content into a design that serves those goals” (Kristof and Satran, 1995, p. 7). In this phase of the design process, we investigated the social problems that children with Asperger’s Syndrome have, specifically the inability of children with Asperger's to read and respond appropriately and confidently to social cues. Our goal was to help these children negotiate their social worlds by creating an interactive product that was "easy to learn, effective to use" and would provide "an enjoyable user experience" (Preece, Sharp, & Rogers, 2007, p. 2).

We researched existing solutions and found that the development of social stories is a well-documented and empirically proven method of developing social skills in children with Asperger’s Syndrome. We investigated video-self modeling as a way of developing social stories and found that, although proven effective, the process was lengthy, and involved many steps and various hardware and software supports. We found two applications that provided some, yet not all of the options we were looking for and at this stage decided to develop an alternative design that would meet our requirements (Preece et al., 2007, p. 17). Our idea was to take video-self modeling a step further and to create an application that would be able to handle both the hardware and software requirements in an all-in-one device. We considered various contexts where such an application and/or device might be applicable and practical. Essentially our discussions revolved around several questions: Who would use the product? How would it be used? Where would it be used? What activities would be involved in interacting with the product? (Preece et al., 2007, pp. 5-6)

Conversations with potential users confirmed our direction as they indicated ease of use through an ‘all-in-one’ application would be desirable. In addition, users indicated that although social stories created with still digital images were effective, they would be very excited to be able to use video-self-modeling in the form of a quality, interactive social story application.

Initially, our idea was to build on the interactivity displayed in the Xbox 360 Kinect gaming peripheral. With this device, users would be ‘recognized’ by the system and would be able to converse with in-game characters. However, we continued to value the ‘ease of use’ factor, including being able to capture images from social scenes wherever and whenever they may occur. Although the idea of video-self-modeling in the gaming forum was attractive, we soon realized that in going this direction we would be limiting the portability and ‘all-in-one-ness’ that we were trying to achieve. Kinect is also a new product designed specifically for one video design system. In addition, we considered the install base of the Xbox 360, cost of purchasing hardware, and uncertainty around the future success of the Kinect product. The decision was then made to limit the application to hand-held devices (smartphone, iPad, iPod) or laptop/desktop computers.

At this juncture in our deliberations it was clear that we would benefit from, as Preece et al. (2007) state, "bringing together people with different backgrounds and training", which would provide for "more ideas being generated, new methods developed, and more creative and original designs being produced" (p. 11). This meant not only pulling together our small group's ideas and pooling our strengths, but also sharing our ideas informally and formally with colleagues, subject and technology experts, friends, family members, and anyone whom we thought could bring a perspective to bear on our initial thoughts and ideas. Again, according to Kim in Preece et al., "what one person values as important others may not even see" (p. 11).

Although our application is intended to benefit children with Asperger’s Syndrome, the target users for our application are the parents, educators, and caregivers of children with Asperger’s. Nevertheless, we needed to keep the specific needs of the children in mind and be cognizant of the fact that the children would be present and active during the creation of social stories. Following the guiding principles concerning usability goals outlined by Preece et al. (2007, pp. 20-29), we limited the ‘flashiness’ of the interface and decided to create screens that were attractive, clear, and simple, yet not distracting to children with Asperger’s who have the tendency to become fixated on subjects/objects of interest. At this point in the design process we developed our conceptual model using a flow chart framework that mapped out the envisioned interactive path that users would follow and the junctures at which the user would be presented with choices (Preece et al., pp. 51-53).

Through consultation with design experts, we concluded that external storage of stories would be a key element in our design. By integrating video into the creation of social stories, we understood that file sizes would be increased. As an added benefit to users and in order to free up memory, we provided the choice of saving in a ‘cloud environment’, or on the user’s own device. An extension of the ‘cloud environment’ is the creation of a community of users that have the option to share social stories amongst themselves. Plans for the online community include chat rooms for users to consult each other on issues of concern. We presented our Information Design to our classmates and received valuable feedback that would inform our decisions in the Interaction Design phase, discussed in the following paragraphs.

** Interaction Design Summary ** Preece et al. (2007) describe interaction design as “designing interactive products to support people in their everyday and working lives” (p. xvii). The goal of our interaction design was to articulate and communicate the intended user experience with the Virti-Cue Social Story Prototype. Throughout the interaction design, we took the necessary steps to ensure that our product would be easy, effective, and engaging to use (Preece et al.). A starting point in our work was to consider the feedback from our classmates and instructor on our Information Design presentation. The ideas of 'cloud storage and retrieval' and a possible ‘online, interactive, sharing community of users’ became two of the main issues that elicited feedback and discussion. Another aspect of the design that needed clarification was the intended audience, as well as how social stories could be created depicting behaviours that children were not yet capable of performing.

Based on feedback from the Information Design, we took steps to clarify our user group. Although the application is for the benefit of children with Asperger’s syndrome, it will primarily be their parents, caregivers, or teachers who interact with the application and carefully sequence videos and/or images to ‘create’ social interactions that their children are not yet capable of performing in their entirety. A sample social story was written to illustrate the way in which an adult could ‘patch together’ a realistic representation of a targeted behaviour.

We began to examine both the conceptual design and the physical design of our application. We considered different colours, icons, and screen layouts that would comply with the needs of our users. We designed the elements of each screen to be clean and clear, allowing for easier navigations (RBWD&UG, 2007, p. 45) and reducing the potential for distraction or overstimulation that children with Asperger’s Syndrome often encounter (MacKenzie, 2008). Issues concerning the physical design were discussed and guidelines suggested by Preece et al. (2007) were kept in mind. For example, we considered the way information was to be presented; interactions with the interface; combinations of media to use; the kind of feedback to provide users; and the kind and format of help to provide.

In order to assess and evaluate our design, we created an interactive version. As Preece et al. (2007) explain, “interaction design involves interactive products. The most sensible way for users to evaluate such designs, then, is to interact with them. This requires an interactive version of the design to be built” (p. 429). To create an interactive version, we used the Mockingbird online wireframe tool, which reflects the interactive nature of our design. Our intent in creating the mock-up was to get a sense of what it would be like to interact with the product and to gather feedback from potential users. We also wanted to identify problems at an early stage of the design process (Rubin & Chisnell, 2008). As Norman (2004) cautions, “good behavioural design has to be a fundamental part of the design process from the very start; it cannot be adopted once the product has be completed” (p. 83).

A user case was created to convey the user experience. Screen shots from the mock-up were captured and incorporated into the user case to create a realistic representation. Screen shots and clipart were also used to create a short video depicting a sample movie that reflected the completed social story of our user case. The process of creating the mock-up and writing the user case scenario allowed us to carefully examine the layout of screens, ensuring that users would be easily able to find what they were looking for, and “perform tasks in the same sequence an manner across similar conditions” (RBWD&UG, 2007, p. 11).

The three main tasks that users may engage in when using Virti-Cue were clarified and detailed in the Interaction Design: Get Story (to read/view), Edit Stories (that already exist), and create a New Story. As we mapped out the navigated pathways for each of these tasks, we worked to ensure that the choices given to users at each juncture were intuitive and logical. Based on feedback from the Information Design stage, we carefully laid out the online community and ‘cloud architecture’ aspects of the application. The decision was made to create a ‘tagging’ system for stories that were shared in the cloud, consisting of frequently occurring social scenes, such as sharing, playing with a friend, or asking permission. We also decided to create a filtering system that would serve to flag inappropriate content.

Finally, a part of our Interaction Design was to determine the best platform for our application and the decision was made to exclude laptop and desktop computers while focusing on hand-held devices. This decision was made to ensure the ‘all-in-oneness’ and portability of the application. Although the application is not intended to run on computers at this time, the social stories that are created can be exported from the authoring device and viewed on computers.

** Presentation Design ** For users/clients to effectively evaluate the design of an interactive product, designers must produce an interactive version of their ideas (Preece, Rogers, & Sharp, 2002). According to Kristof and Satran (1995), the purpose of a presentation design is to determine how a product should look, which involves defining the “style and layout of the elements in the storyboard” (p. 5) and the production of a prototype. A prototype is a working model of the envisioned product and is used to conduct early user testing before launching into full development of a product (Preece et al., 2007). As Norman (2002) states, “there is no substitute for interaction with and study of actual users of a proposed design” (p. 155).

** Usability Testing Purpose, Methodology, and Limitations ** The goal of the peer review and testing phase of our project was to determine the intuitiveness and functionality of the Virti-Cue Social Story Prototype. In addition, we wanted to “identify any usability problems, collect quantitative data on participants’ performance, and determine participants’ satisfaction with the product” (Usability.gov, p. 188). Preece et al. (2007) emphasize that by testing a product with a small sample of users with these goals in mind, designers can “concentrate on what data to look for and what to do with it once it is gathered” (p. 292). In addition, “observing users interacting with software, even casual observing, can tell you an enormous amount about what they do, the context in which they do, how well technology supports them, and what other support is needed” (Preece et al., 2007, p. 359). Through think-alouds, observing, documenting usability with a tracking sheet, and a post-use questionnaire, we hoped to gain a better understanding of the challenges and successes our users encountered to inform improvement upon our design.

Our data gathering methods reflect triangulation, a strategy that provides “different perspectives and corroboration of findings across techniques, thus leading to more rigorous and defensible findings” (Preece et al., 2007, p. 293). First, think-alouds will facilitate “understanding (of) what is going on in a person’s head” (Preece et al., 2007, p. 336). By documenting the thinking pathways of our users, we gained an understanding of how intuitive our prototype was to navigate through. Observations were intended to support “how well the developing prototype supports these tasks and goals” (Preece et al., p. 321). How well our users perform on creating, editing, and viewing an existing social story would reveal any functionality issues with the product. As noted by Jakob Nielsen, “to discover which designs work best, watch users at they perform tasks with the user interface” (Alertbox, 2001/05/05). Last, the post-user questionnaire contained open-ended questions and was worded to “resolve any ambiguities or misunderstandings” (Preece et al., p. 308). Information gathered on areas of success and suggestions for improvement of our product will inform the direction of our design.

Employing Mockingbird software as a prototype platform, Virti-Cue users were asked to complete a series of tasks aimed at functionality and intuitiveness. Choosing from three main icons on the home page, users traced a number of pathways to complete each task. Users selected a story from the local device or cloud architecture, edited an existing story, and created a new story incorporating video, audio, and text. Observations were recorded in a checklist format (see Appendices A & B) documenting user reactions and experiences pertaining to functionality and intuitiveness. A think-aloud process also generated valuable feedback on the user experience. When the testing phase was complete, users were asked to complete a short response form with open-ended questions requesting additional feedback (see Appendix C). While we were pleased with the breadth and overall quality of responses we received, we encountered a number of shortfalls in our methodology. First, the linearity of Mockingbird made it difficult to replicate the authentic user experience we had intended with this product. Second, the checklist format was difficult to navigate and a free-flowing documentation style was substituted in its place. Third, some users expressed discomfort with the think-aloud process. We tried to ease their discomfort with an explanation and rationale of the process, however, it was not something users were particularly at ease with. Last, we felt users would have benefitted from a completed exemplar to demonstrate the end product and what we were asking users to envision.

** Usability Testing: Results ** ** Ease of navigation. ** Observations of users interacting with the prototype reflected an overall ease of navigation. Users proceeded smoothly through the screens and completed tasks with relative ease, in a reasonable amount of time. Nelson (as cited in Preece et al., 2002) notes, “a criterion for assessing whether a system is easy to learn is to apply the ‘ten-minute’ rule” (p. 369). Comments gathered in the questionnaire supported this observation as users indicated that one of the things they liked about Virti-Cue was the ease of navigation. **Functionality.** As we observed users interacting with the prototype, we began to see some limitations in the mock-up that would bear consideration in future design iterations. For example, some users were confused about the use of the ‘back’ button, and found the similarity between screen titles and functional buttons to be confusing. In addition, one user indicated that she did not understand the meaning of the buttons labeled ‘Record Movie’, ‘Story Board’, and ‘Local Device’. This same user also indicated uncertainty regarding the difference between the functions of the ‘search’ and ‘browse’ buttons. We were pleased to note that users appeared to be enjoying themselves as they interacted wi th the prototype, making comments such as “that was fun”, and “oooh, cool!”

**What users liked.** Users indicated that they enjoyed being able to create their own personalized stories. The many options presented in Virti-Cue, such as creatingone’s own story, accessing a story from the cloud, using still images, or video images, were also seen as positive features. Users commented on the ease of navigation, clear screens, and liked having the opportunity to share movies. One user commented, “the design is clean and clear and the buttons are precisely named”. ** What users did not like. ** One user felt that there were many “layers under each of the buttons”, which sometimes led to confusion. Another user commented on the back button and suggested, “it is better if there is one to the main ‘home’ page, rather than going back to e ach of the stepsthat you already did to get to your main menu”. The lack of colour in the design and absence of graphics was noted by users, yet it was explained that the nature of the mock-up environment did not allow for the addition of these elements. ** User suggested improvements. ** Our users gave several useful suggestions for improvements, including providing options to share stories online, or through email with friends; ensuring that pictures/videos are on-screen when users are adding text or sound; creating a sign-in screen for users of the cloud; differentiating between screen titles and functional buttons; and incorporating a function that would allow users to notify others/friends of newly published movies. In addition, one user suggested that we incorporate a congratulatory message to be sent to users upon completion of a social story, and another suggested that we include a tutorial as a guide for first time users.

** Usability Testing: Design Implications ** Based on the feedback in our usability testing, we are satisfied in general with the ease of navigation in the Virti-Cue Social Story Prototype. Issues that we will give consideration and inform future designs include the placement of ‘back’ and ‘home’ buttons; and the names of buttons/options (such as ‘Record Movie’, ‘Story Board’, ‘Local Device’, ‘Search’, and ‘Browse’). Issues surrounding the ‘back’ button may have more to do with the linearity of the mock-up environment, yet nevertheless warrant a closer look as we progress through our development. Following an iterative approach, we would like to engage in further usability testing targeting the names of option/buttons to help us determine if the labels are unclear and need to be changed in some way. As noted in RBWD&UG (2007), “generally, the more iterations, the better the website [application]” (p. 188). We feel that the confusion between screen titles and functional buttons was due to the mock-up situation and will be clear in the intended ‘touch screen’ format that we envision for our product.

We were pleased with the feedback regarding the options provided in the prototype and will ensure that these features are retained in future designs. Users indicated that a more colourful display, including images/icons would serve to make the prototype more attractive. Plans for our design include adding simple colours and graphics, as reflected in our user case presented in the Interaction Design phase.

Suggestions for improvements made by users that we will incorporate into our design include: providing options to share the story with others (e-mail, or online), ensuring that pictures/videos are displayed on screens when users are adding text/sound, creating a sign-in screen for users of the cloud, incorporating a function that would allow users to notify others of newly published movies, and ensuring that ‘back’ buttons function effectively and efficiently once we move out of the linear mock-up environment.

Suggestions for improvement that we have chosen not to incorporate include: sending a congratulatory message to users upon completion of a story – our feeling is that the story itself will be the reward; and creating a tutorial for first-time users – we feel that the sample story included in the application will provide a good model, and the ‘help’ buttons will provide sufficient guidance as needed at various stages in the application. ** Conclusion ** From its inception, the goal of Virti-Cue was to create an immersive, interactive, and intuitive social modeling experience that would best meet the needs of children with Asperger’s. We acknowledge the complexities inherent in our design, however it is our hope that although complex, the structure and functioning of our application will not be //complicated// or confusing, but rather exhibit an “appropriate complexity” (Norman, 2011, p. 30). As Norman (2011) explains, “complexity is part of the world, but it shouldn’t be puzzling” (p.4), and “some complexity is desirable; when things are too simple they are also viewed as dull and uneventful” (p. 13). Each stage in this iterative design process has provided valuable feedback in altering the design trajectory of our product. Rubin & Chisnell (2008) claim that this process serves to “inform design by gathering data from which to identify and rectify usability deficiencies” (Rubin & Chisnell, 2008, p. 22). Information gleaned from the usability testing session will ensure creation of a product that is “useful to and valued by the target audience”, “easy to learn”, effective and efficient in helping people do what they want to do, and is “satisfying (and possibly even delightful) to use” (Rubin & Chisnell, 2008, p. 22). We believe that as we move forward into the building phase of this project, we will realize our vision to support Asperger’s learners with an engaging, intuitive, and multi-faceted social story experience.

[|Mockingbird Mock-up link]