A historical audio and video guidebook for an Android smartphone/tablet John Reid September 2011 Dissertation submitted in partial fulfilment for the degree


Conclusion 7.1Summary and Evaluation



Download 239.28 Kb.
Page13/15
Date05.07.2017
Size239.28 Kb.
#22542
1   ...   7   8   9   10   11   12   13   14   15

7Conclusion

7.1Summary and Evaluation


Overall, the historical guidebook application was well received with all of the reviewers saying it was easy to use, interesting, reliable and quick. Many liked the fact that no Internet connection was required when it was running and that it required little or no training to use. The multimedia aspects of the guidebook were also seen to work well together with the historical maps. Based on this feedback, it was considered that the Android application created for the project achieved all its main objectives.

This rest of this section will present a critical evaluation of the project; discussing both the strong and weak aspects of the application and its development.


7.1.1Application Design


One strong aspect of the design was the use of XML files for the storage of data. As development progressed and more information needed to be stored, it was seen that this provided a scalable, easy to view and edit mechanism upon which to build each of the guidebooks.

One part of the project that didn’t work out as well as expected was the multi-language support. Although this did work, the solution chosen was ultimately not seen as being particularly elegant. It was hoped that application resources could be easily changed at runtime (but this was not fully supported by Android), instead of manually loading up the other language’s resource file.


7.1.2Development


One aspect of the project development that went well was the choice of development tools. The support in Eclipse for writing and testing Android applications helped to advance the project with the only problem encountered being the speed of the Honeycomb emulator when a problem was encountered and debugging had to be done.

The coding aspect of the project also went well; many comments were added to the source files to make it more maintainable and the use of a design notes document helped to keep all the information about the project in one location. Another good aspect of the methodology taken was the research done before coding was started; by investigating and reusing existing components time was saved during development. Using online resources helped, with solutions to issues that occasionally occurred being found on developer’s websites.

One aspect of the project that would have been improved if more time had been available was the user trials; it was felt it would have been better to get a much larger sample of users.

7.1.3Android Programming


During development, several good and bad features of Android were seen. One good feature was how easily powerful components could be used in the application with little effort; tasks such as viewing a PDF file or using/installing the “Text to Speech” component were all easily achieved using intents.

Android had its weaker aspects as well; at one point the "layout_width" and "layout_height" elements in an activity’s layout file were accidentally deleted which caused the activity to continually crash (that was fun to find)!

At the start of the project it was hoped that gesture recognition (the ability to support the pinch-in and pinch-out gestures) could be implemented on the map page. At the time of writing, however, it was seen that gesture handling in Android was unreliable [12] and so could make the application prone to crashing. On that basis, it was thought better to leave that feature out as being too risky and not worth compromising the stability of the application, especially in the short development time needed for the project.

7.2Future Work


Several extra features could be added to the application to make it more complete; the device could suggest walking tours (as were done on other applications) and, in the case of Edinburgh, an outline of the old city walls could be drawn on the maps. This would not be especially hard to do; an extra overlay could be added onto the maps to superimpose these lines on. Another change that could be made (which could be seen on other applications) would be to add a slider to the map page to allow the user to blend one map into another (to see how an area had changed over time).

Guidebooks for other towns and cities could be added in; an interesting city to add in would be London with its rich and varied past or even a scenic train journey (like the West Highland line) to display old maps of the areas being travelled through and to describe what people were seeing out of the window (using the user’s current location).

Since the application concentrated on historical content, a custom timeline widget (view) could be created. This would allow the user to scroll through a timeline and zoom into a particular period of history on the screen to see important events that happened in the city or area on those dates. This could be based on the “WheelView” widget already used in the application. A mock-up of what this could look like is shown in Figure 31..



  1. Mock-up of possible timeline widget

Another interesting feature that could be added to the application would be “Augmented Reality” [74]. This technology could be used to superimpose the images of the old buildings used in the application onto the live images streamed by the camera on the device. As the user moved the device around, the image displayed would be repositioned on the screen showing the buildings where they would have been (or as they looked like) many years ago. At the time of writing, there were several Augmented Reality toolkits available for Android devices, including “Qualcomm AR” [74] and the open source “ARToolKit” [74].

If the application was being used as a tour guide companion then the ability to send its current location and other information on start-up to a central server would be interesting. This would be of use in gathering statistics or indeed if the device was stolen then its location would be known when the application was started.

With the success of the Apple platform, some consideration was given as to how the application could be run on this platform. As mentioned earlier, some parts of the source code were more portable (cross platform) than others and one of the most Android specific parts was the osmdroid map package. However, a similar open source package called “route-me” [68], [69] was found that ran natively on the Apple iOS platform. That map library was already designed to use both online and (database backed) offline map tiles so would seem to be an ideal choice.

With the inclusion of Near Field Communication (NFC) [77] in a growing number of mobile devices (including Android [78]), the ability to pass data between devices could be an interesting area of research. Using this technology, tourists at a historic building could potentially download the content of a guidebook onto their mobile device by tapping their phone against an NFC enabled terminal.




Download 239.28 Kb.

Share with your friends:
1   ...   7   8   9   10   11   12   13   14   15




The database is protected by copyright ©ininet.org 2024
send message

    Main page