Once the user selected a place of interest from the map or from the “Places of Interest” list, a series of pages would be displayed (Figure 11.). To keep it simple, it was decided that each page would either show text and buttons (in a “ScrollView” Android component so a large amount of text could be displayed) or an image. An enumerated type called “hguidePageType” was created to elegantly differentiate between the two in the source code. Another reason for separating the text from the images was because originally the images in the pages had buttons and text placed on top of them, but it was found to be obscuring the images too much.
After advice from the project supervisor, messages were added to the bottom of the screen to guide the user through the pages. For example, the message "swipe left to see more" was displayed on the first page if there were additional pages that the user could see. On subsequent pages the “<<” and “>>” markers were displayed. This touched upon the idea of helping the user as much as possible through the application (another example was the text on the front screen informing the user to "Touch here to change" if they wanted to change the guidebook). Using the gesture functionality of Android (swiping a finger on the mobile device’s screen) was considered to be a natural way to navigate through the pages on touch sensitive displays.
To achieve the message bar shown at the bottom of the screen (Figure 11.), a “RelativeLayout” component was used in the “hguidepage_t1.xml” layout file used by the activity. This container was coloured black to help it stand out and the "alignParentLeft" and "alignParentRight" options were used to put two TextView components (coloured white and created inside the container) at either side of the screen.
-
Messages displayed on the content pages of the application
A new Android view class was created (called “HGuideT1PageView”) to display all the components easily on a single page. This new class was extended from the “RelativeLayout” Android class and made it easier to make layout changes in the code.
Unfortunately, early in development, it was seen that when users were swiping between pages they would often “overshoot” past the intended page onto the next one. With practise users would become better but since the application had to be easy to use, a decision was taken to mostly keep the number of pages in a chapter to two (typically showing an illustration or image on the first page and a text description on the second). A title was added to the top of a text page to clearly show the location or building being discussed in the text.
The buttons were made large enough so that older people could still use it easily and (to make it easier to support multiple languages) no text was placed inside the buttons (apart from the standard sign language icon). As shown in Figure 12., the buttons displayed on the page were, from left to right; the Map location button, the video play button, the audio play button and the sign language video button. If a particular page did not support that content, the associated button would not appear.
-
The buttons shown on the content page
Before displaying text in the page view, a search of the text file was performed to replace any "#" characters with newline characters. These characters were added to break the text up into paragraphs since any text stored directly in the XML file was being stripped of its newline characters. Other small touches were added to make the application more useable: if the user was reading the last page in the chapter then the message “Press the "Back" key to return to the previous menu” was displayed at the foot of the text. This was added after one of the testers (they were unfamiliar with Android) queried how they could return back to the previous screen.
The orientation of the pages was (at first) deliberately locked to stay in landscape mode. This was done initially because it was felt that the images should always be displayed at full screen (to maximise the screen area used) but also to hide a white line at the left hand side of the screen (a screen artefact caused by the pale background on the next page). All the images were rotated in Photoshop to a landscape orientation and the activity’s orientation was locked to landscape (in the Android manifest file). However, it was considered that locking the activities’ orientation in this way was not an elegant solution to the problem. Feedback from the user trials also showed this to be an unpopular aspect of the application and no other part of the application did this. During the last week of the project it was decided to resolve the issue. After a few experiments, it was seen that repainting the page background in black resolved the screen artefact issue. Additionally, the landscape orientated images still looked acceptable when they were shrunk to fit into a portrait orientation on the device (which was a major relief).
A button was added to the content pages to display the location of the site in the historic map (this would be useful if users wanted to see where a place was located and had not gone through the map page). It was decided that when the user selected the Map button from a page, the pin markers would be deliberately hidden so multiple instances of the map activity would not be run on the Android activity stack (i.e. the user could not then start another instance of the map activity which could confuse the user and slow the device).
Share with your friends: |