Recon Rally. The User Experience Design Behind the Rally. By Michael Grubbs, Tiffany Milano, and Daniel Rotondo

Transcription

1 Recon Rally The User Experience Design Behind the Rally By Michael Grubbs, Tiffany Milano, and Daniel Rotondo

2 ABSTRACT The Recon Rally application aims to provide alumni, new and current students, parents, and other visitors to campus with an interactive campus experience. Through the use of industry leading technologies, design practices, and institute direction, Recon Rally will create a unique branded campus experience for mobile device users. The services and associated functions to be defined and supported are as follows: Service Related Functions Interactive Campus Events (Rallies) Encourage structured exploration Inform users of campus history and interesting facts Get alumni involved Have users connect or reconnect with RPI Social Media Integration Connect alumni, students, and other users with each other and campus events The paper The User Experience behind the Rally will walk through the user experience development process throughout the creation of the application. 2

3 TABLE OF CONTENT RECON RALLY BACKGROUND... 4 RECON RALLY TEAMS... 4 TEAM RESPONSIBILITIES... 4 CLIENT NEEDS...4 THE HISTORY OF RPI...4 RECONNECTING WITH RPI... 4 RESEARCHING OUR AUDIENCE... 5 TARGET AUDIENCE... 5 OUR MAIN TARGET... 5 OUR SECONDARY TARGETS...5 WHY WAS DEFINING THE TARGET SO IMPORTANT?...5 BENCHMARKING OTHER APPLICATIONS...5 FACEBOOK...5 GOOGLE+...5 FOURSQUARE...6 BEQURIOUS...6 CAMPUSTOURS...6 VIRTUAL MUSEUM TOURS...6 DECIDING WHAT TECHNOLOGIES TO USE...6 NATIVE VS. WEB VS. HYBRID...6 NATIVE...6 WEB...7 HYBRID... 7 TECHNOLOGIES... 7 APACHE CORDOVA...7 HTML5 & CSS3...7 JAVASCRIPT & JQUERY & HAMMER.JS...7 TWITTER BOOTSTRAP

4 DRUPAL & PHP & MYSQL...7 WORKFLOW CREATION - MAIN EXAMPLES...7 WORKFLOW EXAMPLES... 7 CREATING AN ACCOUNT...7 LOGGING IN...8 HOME PAGE...9 RALLY EVENT PAGE...9 MOCKUPS AND PROTOTYPES...10 MOCKUPS...10 PROTOTYPING STYLE GUIDES...10 CONCLUSION

5 RECON RALLY BACKGROUND Connecting with the campus at Rensselaer Polytechnic Institute (RPI) when you are an alumnus, new student, or parent of a student can be a challenge. Campus changes, history is made, and buildings get updated. Along with being able to find buildings due to campus updates or lack of knowledge of campus, the traditions of different buildings around campus are not widely known. At an institute that prides itself in its rich history it is imperative that this history is readily available. Coming to campus as a returning alumni or a new student can be a daunting task; having a paper map allows the person to explore the campus but does not track their location or store a database of information about the buildings the person is exploring. A physical map is also incapable of allowing the students to play a game in which they will learn about the campus and have fun doing it. Recon Rally is being developed as a tool for people who are unfamiliar with the current RPI campus. Checkpoints, which are all part of a Rally, will be placed throughout campus. The system utilizes physical Recon Rally checkpoints that are placed inside every building on campus. These checkpoints have Near Field Communication (NFC) tags which allow NFC enabled smartphones to get information from the tag that pertains to that specific building. In addition to the NFC tags, the checkpoints will also have Quick Response (QR) code backup for users with non-nfc smartphones. Recon Rally gives users the chance to learn information about buildings on campus as well as play games and earn points. Throughout this paper we will explore the team that works on Recon Rally as well as the extensive user experience research that has gone into developing the application. With an application like Recon Rally, the user experience team needs to be focused on the end result: getting users to participate with and understand the application. RECON RALLY TEAMS For the Fall 2012 semester there are three teams of RPI students working on Recon Rally. The first team is the User Experience (UX) / Project Management team, the second is the Database Development Team, and the third is the NFC Development Team. The UX team consists of four members with two of them acting as Project Managers, the Database Team consists of two members, and the NFC Team consists of one member. These three teams have worked together 5

6 through an agile structure to create a functioning application based on iterations planned out by the Project Managers. TEAM RESPONSIBILITIES The team members on the User Experience Team currently consist of Michael Grubbs, Tiffany Milano, Daniel Rotondo, and Ben Vreeland with Dan and Tiffany acting as Project Manager and Assistant Project Manager. The Project Managers are responsible for the documentation as well as the iteration steps for the whole team. The Database Development Team is in charge of the back-end of the application and consists of Andrew Fasano and Jeff McElhannon. Creating the database that will store information about each user, each checkpoint on campus, all the facts that are gathered about each building, while maintaining the security for our users. This team also created the connection between the developed front-end and back-end. Max Wooding is the only person on the NFC Development Team. This team does not just work on NFC but also works on the QR code back-up the application will use. Max is responsible for the ways the user will interact with the application using their smartphone. He is also in charge of picking out the correct NFC tags to be used for the checkpoints. CLIENT NEEDS The development of Recon Rally is being funded by the Rensselaer Alumni Association (RAA). Our team has had several meetings to discuss what they, the RAA, want out of Recon Rally. We can break down the RAA s needs into two parts: the History of RPI and Reconnecting with RPI. THE HISTORY OF RPI The History of RPI began in Since its establishment, many significant things have happened with the campus and its alumni. The RAA wanted a way to share the extensive rich history behind the campus and every building that has ever been built at RPI with people. The first concept that the RAA came up with in an attempt to share this knowledge was a virtual museum however; the approach for Recon Rally has shaped into something much larger than that. RECONNECTING WITH RPI The second need from the RAA for Recon Rally was to have it be a resource to reconnect with RPI and RPI s community. Alumni often do not return to campus for several years and within 6

7 that time, new buildings are built, faculty have left, and departments have changed. After being away from campus for several years, it is easy to understand how alumni may feel disconnected. With Recon Rally, the RAA is hopeful to aid the alumni in getting reconnected with what is happening and what has happened on campus since they last saw it. In addition to the actual application providing a way for the RAA and other alumni a way to reconnect with RPI, the RAA s involvement with the project provides a bridge for the RAA and RPI. The RAA has encouraged our team to use them as a resource and involve them in the project as much as we want, while still giving us freedom to explore our interests and enhance our skills. After speaking meeting with the RAA we were able to clearly define our target audience and research their needs. RESEARCHING OUR AUDIENCE TARGET AUDIENCE One of the tasks done early on in the development of Recon Rally was defining the target audience for the application. Having the correct target audience was essential to the features that would be developed and helping to eliminate extraneous features. We decided to define our main target audience (with the input from the RAA) as well as a few secondary target audiences in an attempt to further the reach of the project. OUR MAIN TARGET Our main target audience is alumni coming back and visiting campus during events such as Alumni Reunion and Homecoming or other alumni focused events. Since alumni are the foundation of the institute s history they are the main focus and audience that will get the most out of the application once it is completed. Alumni enjoy walking around campus looking at buildings they had class in, ate meals in, and lived in as well as learning about the new buildings and changes that have been made since they graduated. While alumni are our main target we also defined a few secondary target audiences that we considered during our design process. OUR SECONDARY TARGETS Our secondary target audiences are new students and their parents. Our secondary target would directly benefit from an application that gives tours and teaches RPI s history while they are learning the campus themselves for the first time. The benefits that our secondary target audience would have from this application allowed us to not only explore them as an audience but gave us the ability to increase our reach with this application. This target audience already 7

8 goes on campus tours through the Admissions department and would be a prime candidate for testing the application. WHY WAS DEFINING THE TARGET SO IMPORTANT? Defining the target audience was extremely important to the development and design process. Being able to tailor specific functions to our target audience helped decide what features were essential to complete within which iteration and what features were not needed at all. The target audience helped us reduce our scope and create a more focused iterations. BENCHMARKING OTHER APPLICATIONS Since our application is designed with a mobile-first approach, we have a lot options to benchmark our application against. Specifically, we looked at applications that have checkpoint functionality as well as taking a look at other types of virtual tours which allowed us to understand standards that are used across these type of applications. Understanding the standards that applications of a similar structure use will help our target audience become familiar with the application upon first use. A few of the websites/applications benchmarked were Facebook, Google +, Foursquare, beqrious, CampusTours and museum virtual tours. FACEBOOK Facebook s mobile application is one of the most popular apps available in the mobile market. 1 Since so many people use the Facebook application often, we constantly considered what Facebook does for all aspects of our own app. For instance, one of the main design concerns initially was our main navigation within our application. What we discovered in our research that Facebook, as well as many other mobile applications, have a hidden left menu

9 In an effort to help familiarize our application to a user on its initial use, we decided to use this as well. GOOGLE+ For our current iteration of the application, we ve decided to primarily focus our design for Android users. With that in mind, we felt that the Google+ application would be a great benchmark to use for Recon Rally. As mentioned before with Facebook, Google+ also has the hidden left menu. In addition, we were inspired by Google+ s design of their posts. Specifically, how each post has content contained in a designated rectangle. FOURSQUARE Foursquare is likely one of the most similar to Recon Rally mobile applications currently used. With Foursquare, one of its main functionalities is to be able to check-in to places. Due to its wide use and vast similarities, our team thought it was a great application to use as a benchmark. Although designed much differently, we liked the idea of having a Stats section of the application like Foursquare has. 9

10 In addition to those three specific applications, we benchmarked our application various virtual tour websites and applications, as well as other mobile applications and standards. BEQURIOUS2 BeQRious is an application that uses QR codes and NFC to run mobile treasure hunts. This application shows that NFC is a great emerging technology but it is not ready to be the only way a user is able to interact with a product. NFC capability is not in enough smartphones to have a big enough population to use an application. While this is true now the way the trend is heading NFC will be in most smartphones in the next few years, but until then there needs to be another way around this issue. QR codes are used as more of a back-up for people that do not have NFC capable smartphones. CAMPUSTOURS3 CampusTours is a company that creates campus tours using video, photorealistic interactive campus maps, mobile walking tours, and custom data-driven multimedia applications for higher education

11 Above is one of the maps they generated for Architect s Virtual Capitol, the user has the option to choose to discover, explore, or learn each having different map interactions. VIRTUAL MUSEUM TOURS The last thing we benchmarked was virtual museum tours. One of the main points of the RAA was to create an application is that it is a museum of information for people to view when they visit campus. Even though this was not the direct approach Recon Rally decided to take seeing what virtual museum tours did gave some insight on what people would expect. The main things we learned here were that people could follow the tour on their own and still get the information they would from a tour guide. This is similar to if a prospective student took the virtual tour of campus using Recon Rally instead of taking a tour of campus with the Admissions Office. The information should be richer since the user is able to take in a lot more of their own time and with more freedom for exploration. DECIDING WHAT TECHNOLOGIES TO USE When starting the Recon Rally project, we quickly realized we have several important decisions to make that would shape the entire development of the project. Before we started doing any developing, the one question we had to decide on was what type of application we wanted to make. NATIVE VS. WEB VS. HYBRID NATIVE Native applications have several major advantages over hybrid and web. First, building native applications allows you to use the native OS User Interface components. In addition, there are 11

12 definite performance benefits. Having access to the native app store/marketplace is also a major benefit. However, there are several disadvantages to developing native applications. Many of the mobile OS require using very specific programming languages and SDKs to develop native applications. In addition, porting a mobile application to another mobile OS is very often difficult and time consuming. WEB Mobile based web applications are another option for developing for mobile devices. Mobile based web applications allow you to use a diverse range of different programming languages and tools. In addition, cross-os becomes a much smaller issue as long as the user has a mobile web browser. Lastly, it is often quicker to implement mobile web based applications with being able to use common web technologies. The drawbacks for developing mobile based applications are also very large. Developers cannot use native UI components and there are issues with performance. The issues with performance include the application being more dependent on connectivity than native applications are. Lastly, developers have to consider differences in the different mobile browsers as they would for desktop web development with there being more mobile web browsers than internet browsers widely used. HYBRID Hybrid applications are often thought to be the best of both worlds. Hybrid applications allow you develop using common web technologies (HTML, CSS, JS), port to multiple mobile OS s, and be in native mobile app stores/marketplaces. In addition, hybrid applications have access to many of the phones hardware such as NFC, GPS, and camera. However, there are still some drawbacks for developing hybrid applications. Some of these drawbacks include the fact that they still performance less than native applications, you often cannot use native UI components, and typically they are more difficult to set up and developed than with mobile web based applications. Even so, given the current skills and interest of our team, we decided to take the hybrid approach with Recon Rally. TECHNOLOGIES APACHE CORDOVA Cordova, formerly known as PhoneGap, is the platform that Recon Rally is being built with. Cordova allows us to make a hybrid application, designing it with HTML5, CSS3, and JavaScript, while still access the phone s hardware capabilities. HTML5 & CSS3 12

13 HTML5 and CSS3 are the latest versions of the web markup and styling languages. While neither is the standard currently, almost all mobile browsers support most of the features from both. HTML5 and CSS3 take care of the front end look and feel of the application while the functionality of the front end utilizes JavaScript and JQuery. JAVASCRIPT & JQUERY & HAMMER.JS JavaScript and jquery are used for the scripting aspects of Recon Rally. jquery is popular JavaScript library that includes several helpful functions. Hammer.js is another JavaScript library. We are using Hammer.js is used to detect touch events include swipes and taps. With time being a constraint for the development we decided to utilize a framework that was already set up with a wide array of JavaScript, HTML, and CSS components. This framework is called Twitter Bootstrap. TWITTER BOOTSTRAP Twitter Bootstrap is a popular front-end framework. Its primary use is to help expedite the development of the UI. Twitter Bootstrap also helps us make our application responsive. In other words, Recon Rally s design responds to the viewport (or screen size) the user has, and adjust the styling accordingly. HTML5, CSS3, JavaScript/JQuery, and Twitter Bootstrap all make up different components of our front-end development the next stage is to explore the components of our back-end development. DRUPAL & PHP & MYSQL We are using Drupal and PHP for all our backend development. Drupal (via MySQL) is our content management system (CMS) and PHP is used to create our API functions and to communicate with our database. Before we could even begin to develop any aspect of Recon Rally we needed to take a look at some workflows the users would be exposed to while using our application. WORKFLOW CREATION - MAIN EXAMPLES In order to further our understanding of how the users would interact with the application in the most efficient way, we created workflows of different tasks the user would partake in. The workflows included Creating an Account, Logging In, Home Page Navigation, and Rally Event Page. The purpose behind these workflows was to try and place ourselves outside of the small circle of developers and artists who would be so closely tied with the project. In this way, we are able to establish a mindset founded in the client s needs. 13

14 WORKFLOW EXAMPLES CREATING AN ACCOUNT The creating an account workflow: Landing Page - User clicks Create Account Button User sees fields to input information Address Password User clicks Submit sent to user asking if it was them who created the account If it was them the user does nothing If it was not them the user can disable the account from the The application returns to the homepage This workflow walks through the process the user will be in when they create an account and helps in developing the functionality to know exactly what the application should be doing at which time. Knowing what inputs the user has to put in ( and password) and what should happen on submit makes it clear to the developer on what to create. One of Nielsen s Heuristics that was absolutely critical to this page s workflow and design was the adherence to standards. User expectations in a society saturated by amateur developers are high and creating a landing page that meets the expectations for a professional application is a great way to establish immediate credibility. LOGGING IN Landing Page user types in and password o User hits login o The users profile is displayed o HOME PAGE 14 Their name Their completed rallies Their currently in progress rallies Screen returns to Home Page

15 Display of Active Rallies Active Rallies user is participating in Clickable, brings the user to a Rally Event Page for the Rally List of Upcoming / Nearby Rallies Clickable, brings the user to a Rally Event Page for the Rally This workflow is deliberately simple. As the central hub for accessing rallies (past, present, and future) it needed to display enough information to establish itself as the main location for accomplishing tasks while still being simple enough that the user will not get lost. One section of theory that was applied to this page in particular dealt the Stakehold and Value Conflicts. Direct Stakeholders in this example are the users (alumni, students, parents, etc) who will be using the application directly. Indirect Stakeholders include: developers, content creators, and designers. The conflicts here primarily focus on the designers desires vs the needs of the users. An alumni, as postulated by our test cases, would be looking to join a specific rally on the rally page, thus he or she would prefer it not to be cluttered and difficult to navigate. A content creator is trying to get the most information across as they can and may want to place as much information as possible on that main screen. There were a number of refinements made in designing this 3 tab workflow system (past, present, future rallies) that were directly influenced by considering the direct and indirect stakeholders. RALLY EVENT PAGE Display Rally Info o Name of Rally o Location of Rally User Progress o How many checkpoints they have completed o Time spent (if this is a timed rally) Map of Rally Checkpoints o Visited Checkpoints marked off Checkpoint List o Clickable, brings the user to Checkpoint info Page Event Links (if any) 15

16 After the creation of workflows and an understanding of how the application and user will interact we moved onto developing mockups and prototypes that would be referenced during the development period. MOCKUPS AND PROTOTYPES MOCKUPS The UX team created mockups to show what the design of the application would look like prior to actually implementing the design using HTML / CSS. Creating the mockups in Adobe Illustrator, the UX team was able to easily change colors, fonts, and other aspects of the design without having the hassle of redoing everything after the code was created. Mockups, while perhaps not the final design s actual appearance, present not only a visual reference but also a conceptual aid for the programmers to work with. Having a visual aid takes some of the abstractness of the workflows and puts it into a realized form, allowing connections between tasks that may not have otherwise been available. Pictured above are the landing (splash) screen and the rally homepage. The graphic identity of Recon Rally is immediately recognized on the landing page and simple, standard and password input fields are followed by a sign in button as well as an account create link. 16

17 Mockups were placed within a phone-like frame to help gauge the feel within a confined space rather than looking at a rectangle against pure white. The homepage is overlaid in the picture by the menu section of the app. This section will be accessible at all times by clicking on a button in the top left of the page as well as the standard menu button on android phones. PROTOTYPING In Spring 2012, a prototype of the NFC checkpoint was created to show what would happen when a user puts their NFC-capable smartphone up to the checkpoint. The prototype had limited functionality and only pulled up information for one building when the user checked into it. This prototype was used to simply demonstrate how easy it was for a user to check in using an NFC-capable phone. The prototyping phase is still not yet fully realized in terms of physical models, though by creating digital models it is possible to visualize how the interaction would take place in a physical setting. 3d models, created in Autodesk Maya, help to serve as a visual aid that can help to place the checkpoint within a setting and evaluate the practicality of certain checkpoints in different environments. Pictured below is the 3D model of the checkpoint within a room and the 2d illustrator file that serves as the graphic feel for the checkpoint. This checkpoint, slated to be constructed from high-density polymers, would resist weathering but would be easily implemented indoors as well. Exact figures as to cost of production are unavailable at this time, though estimates place each checkpoint tag at $1.25 STYLE GUIDES For consistent mock-ups and consistency in app creation a style guide was created to be followed by all the designers and developers of the application. Pictured below are the style guide (fig 1) and alumni presentation aid examples (fig 2). 17

18 Figure 1 - Style Guide Figure 2 - Alumni Presentation Aid The style guide, containing symbols, font styling, and color guides was used to establish consistency across the app. The Alumni presentation, in which we demonstrated our progress on the application to the client, was assisted by slides such as the one above to create a collaborative environment between producer and consumer. CONCLUSION The Recon Rally Team spent a lot of their working time researching our users, other applications, and even our own designs. All of this research was done to ensure the design of the application was usable by our target and was branded to Recon Rally for high identification and cognitive connection when the user was within the application. 18