Ahoy internet, I’d like to quickly introduce myself and explain my purpose here. I’m Ryan Scott and I’m a Purdue University Electrical Engineering senior. I’m working with Dr. Matei this semester on research and development for his gWiki project – specifically, I’m working to develop an iPhone application which connects to the gWiki backend. I worked on the project last semester and helped get the application in the App Store.
I’ll be posting a weekly worklog throughout the semester so you can follow my progress, problems, and (hopefully) successes. My first task this semster was to learn the MediaWiki skinning system and to create a simple mobile theme to display way point information to the user in a WebView. One feature I had implemented and removed was the presence of a Google Map embedded in the WebView. Upon testing though, the Google Map significantly slowed down the loading of the page and the feature was removed. The time for loading the details of a way point is now mere seconds over a 3G connection.
This week, I’ve been reading Map-based Mobile Services: Design, Interaction and Usability, which can be found on Amazon or via the Purdue Library. I read four chapters that I selected: The State of the Art of Mobile Map-Based Services, User-Centered Design of Landmark Visualizations, Mobile Maps and More – Extending Location-Based Services with Multi-Criteria Decision Analysis, and Geographical Data in Mobile Applications Uses Beyond Map Making. In the first chapter, The State of the Art of Map-Based Mobile Services, Meng describes the genre of a gWiki-like application as a “You-Are-Here” app, which graphics are dynamically loaded so that the user’s location and surroundings are always visible. With this in mind, we want our map to start with the user’s location centered on the screen and constantly updating when the user moves. As a result, we will constantly poll for the user location and when movement is detected, the screen will update and the center of the screen will be again focused on the user location.
Another location-based issue I have run into conceptually is deciding how many way points are displayed on the screen to the user, as we don’t want to overwhelm the user or create so many way points it’s impossible to select one in particular. The solution that we’ve decided on using when the feature launches will be a set radius in which way points will load which will be editable from within the program. A more elaborate solution would be to set a goal amount of points to be displayed to the user, say 20. If the first bounding radius, say 10 meters, doesn’t encompass 20 way points, then the box could be expanded to twice its size recursively until the box contains at least 20 points, at which point the application would load the map at the correct size with the proper amount of way points.
Soon I will be posting screen shots of the upcoming map feature in the iPhone app – stay tuned!