Carleton University CU Maps Author: Angel Hernandes Dr Michel Barbeau, School of Computer Science April 2nd, 2014

Transcription

1 Carleton University CU Maps Author: Angel Hernandes Dr Michel Barbeau, School of Computer Science April 2nd, 2014 Page 1 of 33

2 Abstract Contained in this report is the information relating to the CU Maps android application. To start, an introduction is included to outline what the general idea of the CU Maps application is. Afterwards, needed background information and general objectives for both the report and application are given. Following this, a run through of the completed application is given. Following that, the various procedures gone through for the completion of the application are explained. These procedures include basic setup for developing android applications, what's required for an application to run, and the development of the CU Maps functionality itself. It also goes over usability tests performed that were used in revising the application for ease of use. Finally, a conclusion about the application and any future potential development is outlined. Page 2 of 33

3 Acknowledgments I wish to thank the various professors at Carleton University for their valuable lessons throughout my studies at Carleton University. Special thanks should be given to Dr. Michel Barbeau, my research project supervisor for his professional guidance and valuable support throughout the development of the application and this report, as well as Dr. Frank Dehne for providing knowledge regarding Dijkstra's Algorithm through the COMP 3804 course. I also wish to thank the various online sources which provided plenty of information in learning about basic development information for Android, as well as those which provided images and icons used throughout the report and application. These are listed below: Android Information and images: Dijkstra Graph Image: Icons used in the application: NFC Tag Image: Page 3 of 33

4 Table of Contents 1. Introduction Context/Background Definition of the problem Summary of the result Outline of the report Detailed Background Information Completed Application Overview Procedures Setup Android Manifest Activities Graphical User Interface (GUI) Map Display Path Finding Near Field Communication (NFC) Integration Usability Testing Revisions Conclusion References Appendix - Usability Test Results...30 Page 4 of 33

5 List of Figures FIGURE 1: Welcome Screen...10 FIGURE 2: List View...11 FIGURE 3: Building Information...12 FIGURE 4: Map Route Example (Path is in green)...13 FIGURE 5: NFC Page...13 FIGURE 6: Android Emulator...15 FIGURE 7: Example of Contents within a Manifest file...16 FIGURE 8: Application Life Cycle and methods called during transitions...18 FIGURE 9: Eclipse's Android GUI Tool...19 FIGURE 10: Example of an Action Bar containing various icons/buttons and a navigation menu...20 FIGURE 11: Example of a portion of the map being split into tiles...21 FIGURE 12: A map and overlay contained within HTML is loaded via a webview...22 FIGURE 13: An example of a run-through of Dijkstra's Algorithm...23 FIGURE 14: A metallic NFC tag and a phone with an NFC chip...25 Page 5 of 33

6 1. Introduction 1.1 Context/Background This is a report based on an application called CU Maps. CU Maps is an application that can be used to mainly find visual path directions on the Carleton University campus, as well as information relating to the various buildings on campus. It is an application that is developed for Android, and uses NFC in order to add extra functionality on top of the base application functionality. The objectives which this application aims to accomplish is it consists of a fully functional system capable of displaying a map which contains two different views, and allowing for map routing capabilities. One view being a satellite view which contains detailed imagery of the campus, while the other is a general map view only containing roads and paths. The map routing capabilities include the implementation of an shortest path finding algorithm called Dijkstra's algortihm in order to find shortest available paths. The objectives also include the usage of near field communication, and its integration within a map routing system in order to provide quick and relevant information. Finally, the application also includes information about the buildings on the Carleton University campus, and a way of navigating through the information via a list. The application is also meant to be completely offline, without any need for a connection, or anything to be retrieved online. 1.2 Definition of the problem Throughout the Carleton campus, many maps can be found that help give directions to new students and lost visitors to where they may want to go. Though it is helpful, it can be made even more convenient with NFC. If things such as NFC tags were built into these maps on campus, users could simply place their phone over their destination on the maps (located on campus), and directions to the Page 6 of 33

7 location would be given to the user based on their current location found within the tag, as well as information about their current location such as what the building is mainly used for. 1.3 Summary of the result The intended features of the CU Maps application have been achieved. This consists of the map navigation and map routing capabilities fully functioning, NFC being integrated, and displaying building information to the user. 1.4 Outline of the report Detailed background information is provided in Section 2. The results of the work accomplished are presented in Section 3. The process used in the development of the application is presented in Section 4. Conclusions and future development plans are presented in Section 5. References used are presented in Section 6. Page 7 of 33

8 2. Detailed Background Information The application was developed for the Android operating system. While Android has various development tools for different languages such as C, C++, and Java, the one used to develop this project was the officially supported integrated development environment (IDE) from Android that uses Eclipse as a base IDE and simply uses the Android Development Tools (ADT) plugin to allow for development. Another feature that the application takes advantage of is near field communication (NFC). NFC allows for a device to transmit data to another device within close proximity of a few inches, without any kind of prior connection or set up. There are two separate type of devices which utilize NFC. One is a passive device. Passive devices are capable of transmitting data without their own power supply, but they are incapable of processing information or interacting with other passive devices. An example of a passive device is an NFC tag. The other type of device which utilizes NFC is an active device, these are devices which are capable of both sending and processing received data, as well as interacting with both another active or passive device. An example of an active device would be a phone with an NFC chip. NFC is a subset of radio-frequency identification (RFID). RFID is a technology which operates via electromagnetic induction, or more specifically, radio frequency waves. RFID can operate at a large range of radio frequencies, typically between 120 Hz 10GHz, these ranges corresponds to scan distances ranging 10 centimetres metres. Within these ranges, the various frequency bands have their own respective standards and protocols. The most important of these frequency bands to know for this application, is the High Frequency (HF) band which corresponds to MHz. RFID generally allows for only one way communication between devices. Just like High Frequency, NFC operates at Mhz because it is an extension of the RFID standards established for High Frequency. This means that NFC has many similarities to High Frequency. Page 8 of 33

9 However there are key difference between NFC and High Frequency. For Example, NFC limits the allowable range of communication between devices to a range of only about 10 centimetres, while High Frequency can operate at a much larger distance. NFC also allows for two way communications, as opposed to the one way communication of High Frequency. This allows for peer-to-peer sharing as well as generally more complex interactions between devices. All of this allows for NFC to be utilized more in situations where security is required as the short range of communication aids in preventing unwanted communications. NFC is what allows for the core functionality detailed within the report to function. Lastly, the device used in conjunction with development for this application was a Samsung Galaxy Nexus phone. The device runs on Android 4.3 and has an NFC chip built in. Page 9 of 33

10 3. Completed Application Overview This section goes through and takes a look at the completed functionality of the application, and shows screenshots taken of the application for each respective major feature. Starting off, when the application is launched, a welcome screen is shown to the user (see figure 1). The welcome screen simply acts as an introduction to the application for the user, and just goes through the general outline of what the application is, and how it functions. Within the application, navigation through the various pages can be done via a page selection tab menu located near the top of the screen. FIGURE 1: Welcome Screen Page 10 of 33

11 First of the completed functionality available is displaying maps. This is done by simply selecting the map tab located at the top of the screen. The map is then displayed and allows the user to simply scroll and zoom around in it. By default, the map displayed is simply the general map view, but it can be easily switched to the satellite view by hitting the "switch map view" button. If in satellite view, it can also be switched back to the general view again withe ease by hitting the "switch map view" button again.(see figure 4) FIGURE 2: List View The application also contains is a list view (see figure 2). This list view contains a list of the buildings located on the campus. Selecting an item in the list will bring up a page which contains information about the item selected. This page also allows for the user to set the building as either a starting point or a target for finding a path on the campus. (see figure 3) Page 11 of 33

12 FIGURE 3: Building Information The next thing that the application provides is map routing capabilities. This can be used by either selecting the search icon at the top of the screen which provides a list of locations in a drop down menu, using the building list, or from the NFC page. Once the starting point and target have been specified, the map page will display the map containing the generated path (see figure 4) and scroll to the starting point such that the user is able to easily follow the generated path without having to scroll around themselves and find where it begins. Page 12 of 33

13 FIGURE 4: Map Route Example (Path is in green) Finally the last large feature that the application provides is interaction with NFC. By default, the NFC page will tell the user whether their device is capable of utilizing NFC. If the user brings an NFC tag close to the device, information which the application can read from the tag will be shown through the NFC page. (see figure 5) FIGURE 5: NFC Page Page 13 of 33

14 4. Procedures Setup Before development of the application could begin, an SDK had to be acquired. Luckily, Android offers a free, fully supported SDK on their website, so that was installed and set up so that work could commence. Setting it up was only a matter of extracting the archive contained within the zip file to the desired location, as almost everything else had already come configured. After everything had been set up and ready for development, time for actual development had begun. Creating an Android project was simple. It was only a matter of selecting to create a new Android Project in the Eclipse IDE and specifying where the directory for the project would be. Doing so, generated various files. The most important of these files being the Main Activity, a default layout XML file, and an app manifest file. Various other basic libraries and required files were also automatically generated. After these files had been generated, a simple test run was done to ensure everything was functioning as needed. In order to do this, a device had to be selected on which the application would be installed and run on. The eclipse IDE provides means of emulating various devices with many customization options as figure 6 demonstrates, but an external device was used for testing the development of the application instead of the provided emulators. The reason behind this was because unfortunately the speed at which the provided emulators ran were not sufficient for quick development, and also because it simplified other issues such as not having a dedicated device for reading NFC tags. The device used throughout the development of the application was a Samsung Galaxy Nexus phone. After it was verified that application ran and displayed what a Page 14 of 33

15 newly created application should, research was done into what the files contained within an android application actually were, and how they effect the application. FIGURE 6: Android Emulator Page 15 of 33

16 4.2 Android Manifest The first of the files which are important in running an Android application is the manifest file. Within android, every application must have an AndroidManifest.xml file. It is used to present information about the application to the Android operating system. This is because the manifest contains information about the application relevant to Android that it must have before it is capable of running any of the code contained within the application. This information are things such as the minimum API level required for the application to run and permissions required to access components of the device. It is also used for specifying which file contains the main activity and the identifier given to the application. Within this particular manifest file, information was added in to let it know that the minimum API levels required is 18, it would have access to external storage, and that it would be utilizing NFC if available. (see Figure 7 for example of contents within a manifest) FIGURE 7: Example of Contents within a Manifest file After a general understanding of what manifests were used for was learned, next came time to understand what the purpose of an Activity was and how to use them. Page 16 of 33

17 4.3 Activities To start developing code on Android, knowledge about how exactly applications run on the Android system had to be acquired. This soon led to information provided by Android on their website about Activities within android. The most important activity within an application is the main activity. The main activity is somewhat similar to main methods in various other programming paradigms. Though that begin said, there is a big difference as to how activities work in comparison to main methods because of how Android handles applications. In order to explain this, some information regarding the life cycle of an application and how it's handled by Android is required. A quick summary as to how this works, is that there's a pyramid of what states an application is currently running in (see figure 8). Within this pyramid, the lower levels correspond to states where the application is not directly active, and the top of the pyramid is where the application is the current application being displayed and actively run. As an application is created or resumed, it will move towards the top, while if it is paused or stopped, it will move towards a non active state. Eventually, non-active applications will automatically be disposed of by Android. Each of the calls to move towards a different state each have their own calling method, these calling method dictates what is done at each stage. All of these methods are contained within the main activity of the application. The most important of these methods to implement being the oncreate() method. The oncreate() method dictates how everything is initialized when an application is launched. The other various methods do not need to be explicitly made as they are optional. Page 17 of 33

18 FIGURE 8: Application Life Cycle and methods called during transitions 4.4 Graphical User Interface (GUI) Now that the basics behind how applications run had been understood, next thing was time to learn about development of graphical user interfaces (GUI) in Android. The first thing done was getting a feel as to how to develop a GUI on Android. The reason behind development of the GUI so early on was important for this application as opposed to developing other core logic functionality was because it would allow for an easier time debugging and overall knowledge about issues that could potentially arise that could be caused by the interface. A few basic things were learned throughout this process. One important thing is that the basics of setting up a GUI in Android is via XML files. The XML files must contain code that defines how the various elements in a layout are displayed and handled, such as buttons and labels. Fortunately, the Eclipse SDK allows you to easily modify the layout of an XML file via a built in graphical tool. (see figure 9) Page 18 of 33

19 FIGURE 9: Eclipse's Android GUI Tool This tool makes the development of various parts of the GUI a very simple task. Another thing learned was how to access and modify elements from an XML file from the code within an activity. This was simple as it was just a matter of assigning an id to elements created within the xml file such as buttons and labels, and then simply finding these elements via the ID and casting them to the appropriate object. After being casted, they could then be modified with ease. Along with learning about basic GUI elements, was learning about how various other GUI related features in Android, such as the Action Bar. The action bar is a piece of the GUI which helps to maintain a familiar interface across applications and screens, it is generally located at the top of an application, and can contain various different elements (see figure 10 for action bar example). These elements can range from various things such as a search bar, settings list, navigation menu, and various other things which can be customized. Page 19 of 33

20 FIGURE 10: Example of an Action Bar containing various icons/buttons and a navigation menu 4.5 Map Display After learning about some basic things about the GUI, came learning about how to display and switch images on the fly in order to show a map. To display images, a webview was used. Webviews are mainly used for loading and displaying HTML webpages, but they come in handy for images as well as they have built in panning and zoom functionality. Unfortunately, webviews come with their own set of problems. The problems encountered in this particular situation was that the resolution is not preserved caused by scaling that is applied for images whose resolution exceed a certain threshold. A workaround for this issue that was discovered online [Anon, 2013] was that by simply splitting the high resolution into a large amount of tiles and having them displayed via an actual HTML page, the resolution is preserved as the webview loads each tile separately when needed thereby preserving the resolution. (see Figure 11 for splitting example). This was applied to both the satellite and general map images so that both map types available would have their resolution preserved. Page 20 of 33

21 FIGURE 11: Example of a portion of the map being split into tiles Next was actually modifying the image to have an overlay with the path found. Since the application displays both a general view as well as a satellite view, this overlay would have to be shown on both images. At first, testing had been done to try to have the overlay directly to each of the bitmaps for each set of map images. Unfortunately, because of the high resolution of each map, and the processing time that would be required to apply an overlay to each set of bitmaps, it was found that this would not be the ideal method for this application. In response to this, instead of modifying the image to display the overlay directly, a separate transparent image is used, and then the overlay is drawn onto the bitmap of that image. That image can then be overlayed on to the HTML pages for both maps, allowing for the overlay only needing to be generated once but allows for it to be used for both maps. (see Figure 12 for example of a map with an overlay applied). This change also makes it such that if any new map views were to be implemented, there would be no additional work required as the path would have already been generated. Page 21 of 33

22 FIGURE 12: A map and overlay contained within HTML is loaded via a webview 4.6 Path Finding After the basic map display functionality had been accomplished, the next big thing was implementing the actual path finding algorithm that would be utilized for displaying paths in the application. For this step, I decided to use Dijkstra's Algorithm. Without going into too much detail, the concept of Dijkstra's algorithm is to find the shortest distance from a source node, to every other node within the set of all nodes. This is done by setting the initial distance of the source node to 0, and the other nodes distances Page 22 of 33

23 to infinity. After that initial set up phase, it's only a matter of recursing from the current node and checking the distance contained within each adjacent node. If the distance of the current node, plus the distance of path to the adjacent node is shorter than the distance contained in the adjacent node, the adjacent node's distance is updated to the new distance. After doing this for all adjacent nodes to the current node, a new current node is selected by picking a node which has not yet been selected and also contains the shortest path out of all non-selected nodes. Figure 13 demonstrates dijkstra's algorithm being performed on a set of nodes. FIGURE 13: An example of a run-through of Dijkstra's Algorithm This was implemented without much difficulty in this application. It was only a matter of creating classes which corresponded to the various elements of a node graph. These elements being the nodes, edges, and a class which contains all of the nodes. Furthermore, a class called Dijkstra which would contain the actual implementation of the algorithm was made. There are some difference between a classic implementation of Dijkstra's algorithm, and the one made for this application. A large one is that the nodes contains x and y co-ordinates, and a list of all adjacent nodes to it. The co-ordinates are then used to find the distance between adjacent nodes instead of being Page 23 of 33

24 supplied the distance between nodes initially. The reason behind this is that this allows for new nodes to be added in at a much quicker rate, it helps in lowering any mistakes in linking nodes as it is simple to visualize how nodes would be drawn in an actual x-y plane, and it also allows for the main application to simply utilize these co-ordinates when drawing the paths on the map. The final step here was to create nodes which contain all the map points that would be utilized for finding directions. These nodes corresponded to the buildings located at Carleton University, as well as all the viable paths which link the buildings to each other. 4.7 Near Field Communication (NFC) After completing the implementation of Dijkstra's Algorithm for path finding, Implementation of NFC functionality was the final step in order to complete the core functionality which had been outlined from the start for this application. Android is capable of interacting with various devices and objects which have NFC features. Figure 14 demonstrates an example of devices where you might typically find NFC technology. Thanks to an online resource [Wondratschek,2013], the implementation of NFC was not too difficult. As various devices and objects may utilize different chip technology for NFC, it was decided that this application would only focus on interactions with a single chip technology. The type selected is called NFC Data Exchange Format (NDEF). The reason NDEF was selected is because it is the most common chip technology available, and thus has a greater chance at supporting more devices and objects. After the type utilized for the application had been confirmed, the manifest file was modified such that it would contain permissions for handling NDEF related intents received from Android. This more specifically being the NDEF_DISCOVERED as it is the most vital one for this application. The way which Android handles interactions with NDEF tags at the operating system level, is that once coming within detectable range of an NFC device, Android will generate an intent. An intent is essentially a message that is passed between components. In this case, Android checks for available installed applications which are capable of handling the intent. As the manifest for this application Page 24 of 33

25 specifies that it will handle the NDEF_DISCOVERED intent, it is the main focus. Once all the set up relating to the manifest was done, it was simply a matter of handling the intent once the application receives it. This is done by simply getting the intent from the activity given by Android, and then simply retrieving the information contained within the ndef message. An issue encountered was that when a NFC tag is detected and even if the application is already open, Android would bring up a list of applications which could handle the intent, rather than simply utilizing the one which is already running. To resolve this issue, android provides the nfc adapter object in Java with a method for setting up foreground dispatches. The foreground dispatch basically utilized for intercepting the intent. This was used such that once an NFC tag was detected, it would not attempt to open another application, but rather utilize the intent directly in the application already active. FIGURE 14: A metallic NFC tag and a phone with an NFC chip Page 25 of 33

26 4.8 Integration After all the basic features within the application were developed and functioning, finally came time to integrate everything. Integration involved the integration of the interface with the path finding algorithm, map display, and nfc reading functionality. The first to be integrated was the path finding algorithm and the map display. This simply involved writing a function which would use strings containing the path source and path destination and call the dijkstra's algorithm on them. The algorithm would then go through all nodes and return a list of nodes on the shortest path. A loop would then go through each of the nodes contained in this list, and draw a line between each consecutive node on the overlay bitmap. This bitmap would then be compressed and written to external storage. Once written to storage, the html file containing the map and the overlay would be loaded into the webview and then displayed. After this had been done, a location menu had been created. This menu contained a list of the various buildings located on the Carleton University campus. When a building is selected, the application would then display information pertaining to the building, as well as options to set that location as a source or target destination. Next up was integration of NFC. A separate NFC page was developed that appears when an NFC tag is scanned. This screen would contain the building code and allow for more information about the building to be viewed upon press of a button. Once the NFC page was created, code was written such that once an NFC tag was detected, the application would assign variables which contained the information within the tag. The actual format of the data contained within the NFC tag is "AABB~" where AA corresponds to the building code of the starting point, and BB corresponds to the building code of the destination. This information would then be passed into the NFC page such that it could display it and allow the user to select relevant Page 26 of 33

27 options. After this was accomplished, various minor additions were added in, such as a main welcoming screen, as well as a settings menu and "about" page. 4.9 Usability Testing After the main functionality of the application and everything had been integrated, usability tests were performed (Appendix, pg. 30) on the application. The basis behind the majority of the usability tests was to test out the functionality of which the application offers. The usability tests were performed with 3 different individuals. The main reason behind these tests being done was to receive feedback on the application, and potentially find any bugs or major issues present in the application. This feedback was then taken and used for improving the ease of use of the application, and anything else that had been taken in from the usability tests Revisions After the usability tests were completed, changes were made to the application. These changes were mostly cosmetic changes, as well as adding more ease of navigation. For example, a search bar was added to the top of the screen. This allows for users to quickly select a path they want to find, and then it is displayed. Another addition was a progress bar. This progress bar is displayed while a map is being generated, it allows for the user to know when a map is being generated such that no confusion arises about whether the application has frozen. Finally after the changes to the interface, a bit of optimization was done. These optimizations were mostly related to the time required for generating paths and displaying them to the user. Page 27 of 33

28 5. Conclusion All the intended functionality was implemented. The application is capable of displaying two separate types of maps for users. Map routing capabilities are also implemented, with various forms of selecting the paths present such as a search bar or building list. A building list also allows for users to view information regarding the various buildings located on campus. Finally, NFC has been fully integrated and functioning, allowing users to scan NFC tags of a particular format to quickly find any information located on them. Further work that could be done for the application includes a more extensive and detailed map system, such as having height differences between locations factor into the map routing capabilities, as well as refining the interface and features in order for it to be more user-friendly and more oriented towards being able to display maps as best as possible with little processing time. Another addition would be for a separate application which could be developed in order to develop maps, and plot points which correspond to nodes with simplicity, such that the CU Maps application could simply import the generated file from said application, and allow for maps of other locations to be made easily and viewed within the CU Maps application. Page 28 of 33

29 6. References Wondratschek, Ralf. (2013) Reading NFC tags with Android. Retrieved from on April 11th, Anon. (2013) Stack Overflow. Retrieved from on April 11th, Page 29 of 33

30 7. Appendix - Usability Test Results In order to evaluate the core functionality and the usability of the product three participants were enlisted. The knowledge of Android varied between each participant, ranging from no experience to being a proficient user. The test cases were broken down into four separate components or tasks, the first was to determine if the location directory screen was simple, or intuitive to use. The second set of test cases focused on using the application to find directions, the third task consisted of simply utilizing the maps presented and giving feedback, and the fourth and final task was to utilize an NFC tag to also find directions and information contained within. For each of these tasks, the participant was given a phone in order to test the functionality. For the first test case the participants were directed to use the application to navigate through the location directory and provide feedback on its usability this was primarily a think aloud session and notes were taken about their comments. The second test case was also a think aloud session. The participant was asked to demonstrate whether they were capable of inputting a path to locations provided and demonstrating the path on the screen, and providing feedback on the usability of this. The third test case was also a think aloud session. The participant was asked to simply use the maps on the map screen and the path generated from the second test case, and simply provide feedback on the ease of navigation, as well as any issues in switching between the two set of map types available. The fourth test case involved giving the participants a set of three NFC tags. These tags were embedded with information that the application uses to generate a source destination and target. The participants were given an explanation that touching the NFC tag to the phone would display information, but nothing else. The participants were then asked to give information regarding what the tags contain and to demonstrate that they were capable of generating a path utilizing it on the map. Page 30 of 33

31 Results Test Case 1: Location Directory User 1: The user was familiar enough with Android that navigation was considered simple and intuitive. However they did note that the information presented once selecting an item was messy and could be improved. User 2: Noted the same comments as User 1. User 3: The user had no experience with Android, though they did comment they were able to navigate with ease coming from a background of utilizing ios. This user also noted that information was a mess and could be presented in a nicer fashion. Test Case 2: Path finding User 1: The user attempted to find a path but did not understand where it was displayed after selecting the locations provided. After being demonstrated where to find this, the user stated that it would be much easier if buttons were more clearly labeled, as well as introducing more buttons that help in providing path inputs quicker. Page 31 of 33

32 User 2: Had the same difficulties as User 1 in not understanding how to find a path. Stated that they had thought the application had frozen because it seemed to be unresponsive since no indication that a map being generated was displayed. User 3: User 3 was capable of finding a path without help. Though they did state that it would be much simpler if there was some kind of drop down list to be able to do this, as well some kind of indication that the application is generating the map. Test Case 3: Map Usage User 1: The user commented that scrolling around the map was simple, but stated that they wished the last scrolled position and magnification was maintained when switching between the two map types. They also suggested changing the text on the button for switching once the map type was switched so that it was more easy to understand which type of map was currently displayed. User 2: The user suggested for different colors to be utilized in displaying the path as it was sometimes hard to see. User 3: The user stated that they had no issues. Page 32 of 33

33 Test Case 4: NFC Usage User 1: The user was familiar with NFC tags and easily used one. They were able to quickly retrieve information and stated they had no issues. They did comment again that it would be better if things had more clear labels and a way of displaying the path quicker. User 2: The user stated that they had no issues performing this task. User 3: The user was unfamiliar with how NFC tags functioned. The user quickly came to understand after a demonstration, and was able to retrieve information quickly. The user stated that there was no real issues they could think of at the time with this feature. Page 33 of 33