Lehigh Walking Wizard Final Report Steven Costa & Zhi Huang Table of Contents I. Executive Summary II. Introduction & Motivation a. What is the Problem? b. Why is it interesting/important? c. How do you propose to solve the problem? d. What are the merits of the proposed solution? III. Project Planning a. Organization b. Technical Requirements c. Project Management IV. Software Design a. Components b. Design Techniques Used V. Implementation Results a. Results b. Algorithms c. Project Schedule VI. Verification & Validation a. Verifying Correctness b. What Was Learned VII. Documentation VIII. Future Work a. Work Unfinished b. Next Steps IX. Discussion I. Executive Summary The objective of our project was to create a smartphone app that gave specific walking directions from building to building on Lehigh s Asa Packer campus. In order to accomplish this, we chose buildings and intermediate points on campus to make up our weighted, undirected graph. We obtained GPS coordinates for each point and used those to calculate the distances of the edges in between two adjacent nodes. We provide the user the ability to input their initial location and their destination and using those values we run Dijkstra s algorithm to determine that fastest route in the graph to get from the initial location to the destination. The app then displays step-by-step instructions for the user to follow, including distances, for them to walk to their destination. The app was programmed in HTML, CSS, & JavaScript and packaged into an Android smartphone app using PhoneGap.
II. Introduction & Motivation a. What is the problem? On numerous occasions per semester, students hurrying to class are stopped by campus visitors or new students and asked where certain buildings on campus are. It may sometimes be difficult to provide directions to the person since they can either be a lot to remember or sometimes the building they are looking for is not in direct view which may cause them to get confused later on in their journey. Our goal was to try to provide a solution to this that is easily accessible and user-friendly. b. Why is it interesting/important? This problem is interesting because, as a student, I see many on-campus visitors looking confused and/or distressed while touring around campus without a tour guide. Rather than these people having to wander around not knowing where they are going or stop a student who may be in a hurry and seem unfriendly, which can tarnish the student body s image, we can provide the user with an app that is right at their fingertips to get them around campus. c. How do you propose to solve the problem? We proposed the idea of creating a smartphone app for visitors and those unfamiliar with campus to easily download to help them find their way. The way we wanted to accomplish that was to also provide the user with the quickest route to their destination. The way to do that was by using Dijkstra s algorithm. The user enters their start location and their destination and our app records that information. The app then proceeds to run Dijkstra s algorithm by computing the shortest distance to each of the other nodes in the graph. That information is then used to populate an array with the edges that the fastest route consists of. The directions are then retrieved for those edges and displayed to the user. d. What are the merits of the proposed solution? Our solution gives the user organized and accurate instructions on how to travel around campus to get where they need to go. The app is well-organized and easy to navigate without any confusion so it can be used by a wide range of users from those not tech savvy to those who are. It also eliminates the need for the user to have to stop a student to ask for help and then have to remember each of the directions clearly to get where they need to go. Other apps, such as Google Maps, do not give such specific walking directions within campus and in order to get those directions to begin with the user would have to have the address of their destination which is then more work to retrieve. No other map app knows how to navigate through Lehigh s campus better than two students who have attended the university for years. III. Project Planning a. Organization Client:
Professor James Femister and any students or visitors to Lehigh that are unfamiliar with the Lehigh campus. Who Interfaces with the client: Steven and Zhi both interfaced with the client in Professor Femister s office during weekly meetings. Any additional help that was needed by either member was conducted through email involved either one or both members. Client Meetings and Status Updates: - Progress reports were completed before class on Thursday of each week, usually by Wednesday afternoon. - Deliverables were due for Project Planning on 9/27, Project Design on 10/16, Project Implementation on 11/13 - Face-to-face meetings were held on a weekly basis. Both members met with Professor Femister in his office typically on Wednesday of each week. Some meetings were arranged for earlier in the week if a deadline was approaching or if it had been a while since the last meeting. b. Technical Requirements Development Platform: We developed our project on PCs running Windows using the NetBeans IDE. The app itself runs on Android devices. Development environment/software/languages: The project was programmed in NetBeans. The languages that were used are HTML, JavaScript, and CSS. We will also used PhoneGap, which is a mobiledevelopment framework. Performance Requirements: The Lehigh Census states that there are about 7000 Undergraduates and Graduates at Lehigh, so in the worst case, the app should support about that many people at once. It s unlikely that there will be that many people using the app at the same time, though. The response time of the app should be less than 10 seconds. It should take less than 10 seconds from when a user inputs his location and destination for them to receive directions from the app. Our current plan is to have the app work on Android devices. Testing Methods: - The app was first tested using an emulator for Android. The test was conducted by first seeing if the app will run. The test was successful if the user can select an initial location and destination and receive the correct walking directions between the two. - Additional testing was done on actual Android devices
c. Project Management Brief Description of Project Execution: - A campus map was chosen to work off of - A list of buildings and intermediate points was determined - Directions were written between each point on the map - The app was written in HTML, CSS, & JavaScript using NetBeans and packaged by PhoneGap Enumeration of Customer Requirements: Minimum Scope - Create a working app using HTML, JavaScript, and CSS - The app provides step by step walking directions around campus - Allow users to input their current location and their destination Desired Scope - Provide a map of Lehigh - Highlight the route that our directions provides - Allow the user to use GPS to determine the user s current location - Determine the distance the user will have to travel if they use the route that is provided to them - Include pictures of buildings and information regarding the building, such as the departments Risk Areas: - The main risk was that we would be unable to program a working app. Since this was our first time programming an app, we had no experience with it and did not know how it will turn out. - Another risk was that we were not sure how we would gather the distances for the edges in the graph - We relied on PhoneGap to package the app to properly run on Android devices. If PhoneGap did not work properly then the app might not have run on the Android device. Interfaces: The interface is a mobile Android interface. PhoneGap packages the code and creates the app and interface itself, however we designed how the interface works and looks ourselves. The interface is clearly labeled and user-friendly. Self-Evaluation of Progress: We evaluated our progress using our Gantt chart and the schedule provided by the syllabus for the deliverables. The Gantt chart had to be changed slightly due to delays due to lack of power, etc. As long as we had completed everything in the Gantt chart we felt like we would have succeeded in creating a working app that provides directions around campus.
IV. Software Design a. Components We ve divided the app into three components. One component is for the user interface screens. There are two screens. One screen will prompt the user to select from a dropdown box their initial location and their destination. Once they click submit, the app calculates their route and displays it as a sequence of instructions and lists each instruction s distance. The second component is the weighted, undirected graph. The graph consists of all of the nodes we plotted on the map as well as the edges between them. The final component is a distance calculator for each of the edges by retrieving the GPS locations of the two nodes on each end of the edge and using a distance calculation algorithm. b. Design Techniques Used One of the most important design techniques is to make sure the problem is well defined. Having a well-defined problem is the backbone to the application. The programmer needs to decide what needs to be done and what features are going to be implemented in the future. Having everything carefully planned out before implementing it will facilitate the coding process by knowing what is essential to the application and what features can be left to implement later on. Another important technique that is particularly important for our project is to create UIs that promote clarity and simplicity. Since the app will be used by a wide range of people, it needs to be easy to navigate between pages and the directions need to be neatly organized and numbered to avoid confusion. V. Implementation Results a. Results The result of our implementation turned out well. We successfully built a smartphone app programmed with HTML, CSS, & JavaScript that was correctly packaged by PhoneGap and run on an Android phone. The app accepted user input for their initial location and destination and displayed a set of directions. It was then by testing various routes that we had to determine that the directions that were displayed were indeed correct and that they displayed properly and clearly. Below is a sample of user input and directions:
b. Algorithms The main algorithm that was implemented in our project was Djikstra s algorithm. The way it worked for our program was an initial helper function called shortestpath was given the start node as input. It then initializes the nodes in the graph to have a shortest distance of infinity in order to get to it from the start node. The start node is given a distance of 0 because that is where the user is located. The algorithm then proceeds to find the shortest distance from the start node to all other nodes in the graph and recording that number in an array called pathlengths. The index of the array would be a node in the graph and the value stored there would be the shortest distance it would take to go from the start node to the node of the index. The algorithm also records for each node which other node it was accessed by. Then a second helper function called constructpath, given the information from the first helper function and the end node, is called to populate an array called path with the nodes in the route. Starting with the end node, the algorithm works backward to retrieve the node that was visited prior to that one and doing so repeatedly until it reaches the start node. Using that information, we create an array edgelist that holds the order that the edges are visited so that we can retrieve the directions. Finally, the app retrieves the directions for each edge, any turn directions that are encountered, a destination specific instruction, and the distance for each instruction and displays them to the screen for the user to read. c. Project Schedule Initial:
Final: The Gantt chart we initially had done got changed around slightly. One of the things we had to change was how long we actually had until the end of the semester to work on everything. There were also some things that we thought were necessary or had initially planned on doing but we found them to not be crucial to including. One of those we found unnecessary was choosing whether to use JQMobile or JQTouch as a framework to style the app. While it would give the app more of a traditional app look, with regard to time and necessity we deemed it to be an unnecessary component to implement. We also added in some subtasks that begin and end within the project implementation deliverable that were part of implementation but required more time and effort to complete. We stayed on par with the Gantt chart for the most part and completed everything within the time that we allotted. VI. Verification & Validation a. Verifying Correctness The first step in verification we had to take was successfully getting the app to run on the Android emulator. After confirming that the app correctly ran in the emulator we began testing the routes. After testing our app using many test locations, it seems that we have successfully implemented the Lehigh Walking Wizard app. The first routes we tested were those that were special cases that we implemented in our code and we wanted to verify that they displayed the proper way. For example, there are a select few nodes that have only one way to go once they are visited so we needed to verify that the directions displayed properly for those. Another area we needed to verify worked correctly was not displaying directions repetitively such as when the user has not made a turn, they do not need to keep being instructed to continue on the same path. After working out whatever bugs we came across in those instances we then checked other routes to make sure that they were in fact the shortest paths and that
everything was correctly displayed. Professor Femister also installed the app onto his Android smartphone to confirm that the app could also run on actual Android hardware. The app successfully ran and he also tested out various routes. His testing with his own choices for starting and ending locations also verified that we did not manually display directions for routes that we had chosen prior to the meeting. b. What Was Learned We learned that it was best to test out the code we had written after writing each new function or any smaller piece of code that was important to the entire app working. Fixing those bugs early and working with that smaller area of code where the error occurred helped us to pinpoint where something went wrong and allowed us to fix it quickly. The validation process also served as a reminder to check back with the requirements to make sure we were fulfilling them like we had initially planned. VII. Documentation Because we made our app very straight forward, we did not provide documentation to the user. The only documentation we completed was within the code itself for us or anyone else who chooses to build on it. We documented each function as well as other pieces of code that required clarification of what its purpose was and how it worked. VIII. Future Work With respect to our minimum initial requirements we have successfully completed our project. We also implemented a secondary requirement by adding the feature for the user to use their GPS location as their initial location. There were other secondary requirements that could have been useful but because of time constraints we did not get to implement them. Most software today has updates released periodically to address bugs or add new features which, if we implement anything more to this project in the future, an update with the new content can be provided. A future group can build on our project by fulfilling those secondary requirements or even implementing more ambitious features such as spoken directions by tracking their progress on their route or rerouting if they go off course. Extending directions to include Lehigh s other campuses is also a possible way to add onto what we have done. Implementing new features isn t the only possible way to expand on this project. Providing it for all different smartphone platforms would be beneficial. Also, since it is programmed using web programming there is also the possibility of creating a website version as well. If there is time next semester, even with other school work or projects that have to be completed, there is a possibility that we could come back to this project and start by polishing the code a bit and then work on other features as well. IX. Discussion The big take home message is that now people unfamiliar with Lehigh s campus can now get around campus more easily if they download our app. We tried to make it as userfriendly and readable as possible. Choosing a project like this also opens the possibility of it actually being available for download through Lehigh s website so that it could be more than just a project and something that actual people use as their easy way to get around on campus.
The major thing we could have done differently is include a map. Many of the people who tried the demo had requested a map with the app. Along with that, we could have also gotten some people to test out the app and use their feedback on things we could include that time would have permitted or for feedback on the clarity on the directions. Another thing we could have done differently is store all of our JavaScript in the same file. We put some JavaScript in the HTML page for the direction screen because the code for that wasn t for the route calculation but for displaying the directions so we decided to put it there. It s not a recommended practice to have JavaScript mixed with HTML so that is something that could be polished.