Table of Contents Introduction Purpose Scope Overview Design Thinking Process Description Empathy Define Ideate Prototype Test Design Thinking Requirement Analysis Empathy Define Ideate Prototype Test Thorough Documentation of Process Comprehensive Project Summary Architectural Choices and Corresponding Pros and Cons Android Pros Cons ios Pros Cons PhoneGap Pros Cons Selected Architecture PhoneGap Architecture Software Requirements for Development Java JDK NodeJS Cordova CLI PhoneGap CLI Android SDK API 19 Apache ANT Implementation Notes XML HTML
CSS JavaScript General Implementation Preloading Preloading in the Design Thinking Process Preloading in the Summary View Android UI Design Design Requirements Main Menu Wireframe Empathy Step Wireframes Define Step Sketches Ideate Step Sketches Prototype Step Sketches Test Step Sketches Summary View Design Notes Signatures/Sign Offs
1. Introduction 1.1. Purpose The purpose of the Design Thinking Process is that it is difficult finding solutions to different problems that occur around peoples lives. The Design Thinking Process exists to assist people in finding solutions by helping them stay in a quick thinking, intuitive state of mind. This way, people would be able to come up with unique solutions that they would never have thought of before. The Design Thinking Process consists of different steps that would be hard to follow without guidance, so the Design Thinking Application will be used to effectively guide users through the process. 1.2. Scope This document is a technical overview of the major components of the project. This document will include key design features and implementation designs. 2. Overview 2.1. Design Thinking Process Description The Design Thinking process involves a client and a problem solver. There are five steps listed below that the client and problem solver of the Design Thinking Process go through in order to target the main reason for the client s negative experience or problem. Each step is timed so that the client feels a sense of urgency and is required to give as many answers as they can to the questions that are asked of them. 2.1.1. Empathy 2.1.2. Define The user asks their client about their target experience that is creating a problem. The user has to ask questions that pinpoint pain points, so the user focuses on the negative side of the story. Open ended questions should be asked rather than questions that require only a Yes or a No. Asking open ended questions allows the client more freedom to answer and the time limit will push the client to tell the first story on his or her mind. If that story is a bad experience then the problem solver should ask more questions related to this bad experience to find the root of the problem. The problem solver should have a good grasp of the situation in this step now. He or she should define the ultimate problem that the client faced and specify why. Multiple problems can be created and feedback should be generated from the client to confirm which one is the real problem.
2.1.3. Ideate The problem solver should come up with a solution to the client s problem that was defined in the Define step. The problem solver is encouraged to use sketches and not to dismiss the impossible. Creativity is key. Then the problem solver should present these solutions to his or her client and figure out which solutions are good. Next, the problem solver should come up with a final solution that combines the good elements of his or her previous solutions together and maybe some features missing that the client wants. 2.1.4. Prototype 2.1.5. Test Using whatever materials are available, the problem solver should create a prototype of his or her solution from the Ideate step. This prototype can be symbolic and does not necessarily have to have all of the major features presented in the solution in the Ideate step. Creativity is also key here. Creating a prototype that looks unique can help create new features. The problem solver should present his or her prototype to the client and show how the prototype works or how the problem solver envisions the prototype to work. The client gives his or her feedback and a new product may be born. 2.2. Design Thinking Requirement Analysis The Design Thinking Application requires several key elements that will assist the user in going through the Design Thinking Process, which is a human centric schema that helps designers craft meaningful solutions to real world problems. The application will be organized into the steps of this process (Empathy, Define, Ideate, Prototype, Test) to help the user better understand the methodology. All steps will be timed and the user of the application is encouraged to use the application to save all sketches, notes, and prototypes for reviewing later. 2.2.1. Empathy Requires camera to take picture of notes in case users want to take notes with pen and paper. Requires video and/or voice recording to record the things that the client says when asking questions Requires general questions to be overlayed in video recording to help give the problem solver sample questions to ask his or her client. This cannot be obtrusive and should not draw too much
attention away such that the user is more focused on reading than asking the client questions. Requires tool box with different activities that the user can use. For example, a mind map can be used to jot down what the client think and feels, hears, sees, says and does, pains, and gains. Source: http://cdn.business2community.com/wp content/uploads/2012/03/empathy map2. png 2.2.2. Define Requires camera to take picture of notes in case users want to take notes with pen and paper. Requires video and/or voice recording to record the things that the client says when checking to see if the problem is accurate
2.2.3. Ideate Requires camera to take picture of notes and sketches. Requires tool box with tools that help the problem solver brainstorm ideas for solutions to the client s problem. Example, use a mind map to brainstorm. Source: https://info.examtime.com/files/2012/11/how to create a mind map mindmap.jpg Requires video and/or voice recording to record the client s thoughts on the problem solver s created solutions. 2.2.4. Prototype Requires camera to take pictures of the prototype 2.2.5. Test Requires video recording to show the functionality of the prototype and to record the client s reaction to the prototype. 2.2.6. Thorough Documentation of Process The app will allow the user to document the process at every step, by either taking photos/videos, such as that of a prototype, or by writing descriptive notes. The user will be able to view his/her documentations in the form of a gallery for each step of the Design Thinking Process or a gallery for the project as a whole. This can be accessed after completing the Design Thinking Process and should be stored in local memory or cloud so that it can be viewed later. 2.2.7. Comprehensive Project Summary All of the media recorded by the user will be compiled into a project summary. The summary will be shown as a slideshow, which will allow the user to view the different steps of the process (e.g. Ideate) and
what he/she generated during those steps. The summary should be exported into its respective HTML, CSS, and JS files. 3. Architectural Choices and Corresponding Pros and Cons 3.1. Android 3.1.1. Pros User base is increasing day by day. Can develop on most PCs. Contains emulators to test the application on a wide range of emulated devices. 3.1.2. Cons Has a wide range of devices and some of these devices may not be fully compatible with certain features of the application. Some devices will ultimately not be supported. 3.2. ios 3.2.1. Pros Has an established user base. App will run efficiently on ios phones. 3.2.2. Cons Requires OSX to develop on. Requires ios to test upon. Must adhere to strict UI standards. 3.3. PhoneGap 3.3.1. Pros Can create cross platform app. Web development languages may be easier to learn. 3.3.2. Cons Platform specific issues, e.g. UI looking different on IOS vs. Windows. Slow when dealing with more graphically heavy designs. 4. Selected Architecture 4.1. PhoneGap PhoneGap enables us to to cater to a larger audience because it allows us to create an application that is easily portable to both Android and ios. Cross platform development is important to the client, so this is also their prefered architecture. 4.2. Architecture Software Requirements for Development 4.2.1. Java JDK On windows, install from java.com. Under System Properties add an Environment Variable linking to the default directory of the Java JDK.
4.2.2. NodeJS 4.2.3. Cordova CLI On windows, install from nodejs.org. On windows with NodeJS installed, open command line interface and type npm install g cordova. 4.2.4. PhoneGap CLI On Windows with NodeJS installed, open command line interface and type npm install g phonegap. 4.2.5. Android SDK API 19 On windows, install from developer.android.com/sdk/. Open SDK manager and install API 19. Add the platform tools directory (containing ADB) and the tools directory (containing android) into the Environment Variables in System Properties. 4.2.6. Apache ANT 5. Implementation Notes On windows, install from ant.apache.org. Add the install directory into the Environment Variables.in System Properties. 5.1. XML There will only be a single XML file which will store the paths to icons to the application. This is required to manage all of the plugins required to access device specific functions. For example, camera, video, and voice are all in different plugins that will be included in this XML configuration file. This XML file will also be used to keep track of the current version of the file. 5.2. HTML The HTML files will be used to link the used plugins into the desired page and to set up the different elements within the page. The HTML files will contain the main content of the application. Each page will be created in the HTML file at startup and unnecessary pages will be hidden from view. The IDs of each page of the flow will start with the letter s and end with a number to denote the step number. 5.3. CSS The CSS files will be used as a style sheet for each page. These files will manage things like fonts types, font colors, background colors, and advanced styling of the layouts in the HTML file. We will also use CSS to create page transitions and animations.
5.4. JavaScript 5.4.1. General Implementation The JS files will be where our algorithms are written for managing file, camera, voice, and video capabilities. This will also be used to store helper functions to simplify implementation, as well as controlling the general flow of the application. This includes hiding all pages except for the main menu (with id == s0 ) at initialization (function in variable ez with name init ). Event listeners are created within the JavaScript file to control buttons. A single variable s keeps track which screen the user is currently on. Every button that continues onto the flow is created with batchclick which simply hides the current screen, increments screen number s, and shows the new screen. Since the screens were already created during startup and simply hidden, then revealed on demand, this would incur minimal loading and would effectively allow us to mimic the feel of a native application using this web interface. This is effective because there are different steps where the user may want to use the tool box. Instead of having to create a different tool box for each possible screen that can access it and create a button to return to the appropriate flow, we would have one tool box that simply uses the screen variable to return to the appropriate screen. This would help simplify management of these unique screens that could be accessed anywhere during development. As an alternative implementation, we may also try to have give each page a unique id name, and hard code each button to show the proper pages. 5.4.2. Preloading Images may use a lot of memory so they must be loaded only before they are needed. Images cannot be loaded on demand because they can take a while to load, so they must be preloaded in order to fully mimic the look and feel of a native application. There will be two different implementations of preloading listed below. 5.4.3. Preloading in the Design Thinking Process Each screen that has an image could be noted in an array. Everytime the screen changes, it will check to see if the next screen is in this array, so that it can preload the image. It will also be necessary to check the previous screen to see if it is in this array so that unused images will be unloaded to preserve the device s memory. 5.4.4. Preloading in the Summary View Create a div container containing the previous image, a div container containing the current image, and a div containing the next
image stored in an array of size 3 ( slide[] ). At the first image, only the current image will be in the previous image. Also create a variable to store which part of the array that is being used as the current slide ( var current_slide ). Swiping backwards will move the slide back one. Hide the current div container ( hide(slide[current_slide]) ) and show the div container that has the previous slide ( show(slide[current_slide ]) ). Then this will delete the image on the div container containing the previous next slide and load the image of the next previous slide on this same div. For example, the current slide is 0, next slide is 1, and previous slide is 2. Swiping backwards will move the current slide variable to 2 (slide[2] unchanged), previous slide to 1 (will have to remove the slide in slide[1] and load the new previous slide here), and the next slide will now be 0 (slide[0] unchanged). Make sure that the current slide variable stays within the 0 to 2 range. Swiping forward will move the slide forward one. Hide the current div container and show the div container of the next slide ( show(slide[current_slide++]) ). Then delete the image on the div container with the old previous slide and load the image for the new next slide. For example, the current slide is 0, next slide is 1, and previous slide is 2. Swiping forward will move the current slide variable to 1 (slide[1] unchanged), previous slide will now be 0 (slide[0] unchanged), and the next slide will be 2 (must remove old image in slide[2] and preload new next slide). Make sure that the current slide variable stays within the 0 to 2 range. 6. Android UI Design 6.1. Design Requirements The application is required to be enjoyable and similar to a game to keep users engaged and interested. Thus the color scheme of the application should include warm colors. A step counter should be included on each page to show the user which step they are on and how many steps are left.
6.2. Main Menu Wireframe Clicking the NEW PROJECT button will lead to the second screen shown below. 6.3. Empathy Step Wireframes Some of the wireframes shown below may be reused in other steps that require it. The wireframes below generally go in left to right, top to bottom order.
6.4. Define Step Sketches
6.5. Ideate Step Sketches
6.6. Prototype Step Sketches 6.7. Test Step Sketches
6.8. Summary View Design Notes Want the user to be able to swipe left to go to previous slide and swipe right to go to the next slide. Each slide will consist of an image or a video in a target step. When transitioning between each of the five steps, a splash screen showing the step should be shown. If the image does not fit onto the screen then maintain aspect ratio and center the image. 7. Signatures/Sign Offs This section is intended for the Goldilocks & the Three Squares and founder of Lead Mind Ltd. to give approval for various revisions of this document. These digital signatures will only be considered if they are specifically done in order of the Goldilocks and the Three Squares team then the founder of Lead Mind Ltd. Optionally, the CTO of Lead Mind Ltd. may also give his or her approval for the revision of this document to ensure quality. Name Title Version Date Alan Tai Goldilocks & the Three Squares v01 2015/04/01 Joanne Arboleda Goldilocks & the Three Squares v01 2015/04/01 Peter Chim Goldilocks & the Three Squares v01 2015/04/01 Samuel Lin Goldilocks & the Three Squares v01 2015/04/01