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



Download 239.28 Kb.
Page8/15
Date05.07.2017
Size239.28 Kb.
#22542
1   ...   4   5   6   7   8   9   10   11   ...   15

4.4Accessibility Considerations


During the requirements stage, Donaldson’s school for the deaf in Linlithgow were contacted to find out if adding sign language videos would be a useful feature to add. They thought it would be a good idea citing that 80% of the British Sign Language (BSL) signs were national signs and so most of the signs used in BSL should be readable by people from different parts of the country. They also suggested using bold subtitles in the articles with the BSL interpreter logo. The screen size on mobile devices can be quite small and so older, hearing impaired people may prefer to see/use sign language videos. A downside to using sign language videos was the video file sizes could be quite large, although with the availability of high capacity SD cards this would not be too much of a problem (as it would take longer to download the application, this feature may be more suited to when the application was being used by a tour guide at a specific place rather than being part of a general download). Figure 13. shows the sign language video being played.



  1. Sign Language video being played

The ability to easily change the font size was also added. From the settings menu, the user could select the “Text Size” option (the word “font” was avoided in the main description as it was felt some users may not know what that meant). Once users had selected this option, they could then choose small, medium and large text sizes.

As mentioned earlier, a setting was added into the application to allow the user to use “High Contrast Text”. In addition to lowering the battery usage, another benefit of using this mode was to make the text easier to read for people with poor eyesight (using white text on a black background).


4.5Help Hints


Since one of the goals of the project was to create an easy to use application, the concept of help hints was added (Figure 14.) to try and guide the user through the application (especially people unfamiliar with Android devices). When each Android activity was run after installation, a help hint would appear once for a few seconds explaining what the user could do at that particular screen. A preference file was used to store the fact that the help hint had been displayed so it would not be shown again unless it was reset from the settings menu. It was not perfect as somebody could lend the device to a friend and so the device would not show the hints but it was a small step done to make the application more user friendly (the “Reset Help Hints” option was added to help in this case).



  1. Application Help Hints

4.6Multi-Language Support


There were two types of text stored in the program: application text (text that was embedded and used by the source code) and content text (text about the places in the guidebook). Application text was stored in an Android resource file while content text (for example the text shown on the pages in Figure 11.) was instead stored in the guidebook XML file.

Separating the application text from the content text meant that potentially more guidebooks could be added at a later date without updating and re-compiling the code. If content had been embedded in the Android resource files then updates to the content would require re-compiling the code to produce a new Android application package (APK) installation file. Another reason was that a user may only be interested in one guidebook and so adding the content of all the guidebooks into the application APK would be wasteful as the user may not want them.

At one point a mistake was made in the guidebook XML file; content text was being copied into the XML and it was not spotted that there were quotation marks in the source text. This had the effect of stopping the guidebook from being loaded as the Android XML parser could not then parse the file correctly. It was felt this could easily happen again and so a change was made to allow the content text to be also loaded from a Unicode file specified in the XML file. There was another benefit in doing this; it kept potentially large amounts of text out of the guidebook XML file making it easier to read and edit. The files were Unicode encoded and not ASCII encoded since the latter could only hold 8 bit (English language) characters (and so it could not store languages such as Chinese or Russian).

Changing the language at runtime proved to be a bigger challenge than first thought. The method for creating multi-language applications in Android was to place all the application text in a “strings.xml” file. The text for other languages was stored in different resource directories (with names such as “values-fr” for French and “values-de” for German as shown in Figure 15.). During development, when the application was nearing completion, the “strings.xml” file was copied into these alternative resource directories ready to be translated. At runtime, the application would automatically choose the strings in the most appropriate directory depending on the locale of the running device (so if the device locale was set to French, it would use the strings in the “values-fr” directory) [34].





  1. The resource directories used in the application

Unfortunately normally to run an application in a different language in Android, the language for the whole device had to be changed [36]. This was a problem as it was considered that allowing the user to change the language easily (without affecting other applications) was important.

The approach taken was to add code to manually change the resource file used at runtime when the activity was started (in addition to this, code had to be written to go through the front screen text so the language change could be seen immediately). There were not many resources in the application (indeed there were only about 60 unique application text strings in the whole program) and so this approach only had a minimal effect on its performance.

When the user changed the current language, a stored preferred language index was updated. This index was used to calculate which Unicode text file to use when displaying content text to the user. For example if the application language was set to Chinese, it would try and use a Chinese version of the file (e.g. “info_netherbow_zh.txt”). If that did not exist then it would fall back to the default English version (“info_netherbow.txt”).







  1. Application shown in Chinese









  1. Application shown in German

To change the current language displayed users simply pressed the flags icon at the bottom of the front screen and a list of available languages would then be shown. As shown in Figure 16., example text was added so users could see the application in different languages (most of these were not actual translations but rather text taken from websites to show it could properly display character sets from these languages). To make it more accurate, the text displayed in the content list, however, did show actual translated text (using the babelfish website [39]).

Originally the language selection option was placed in the settings menu, but it was thought that a user unfamiliar with Android may not know about the Android Menu button and it was decided to allow the language to be changed from the front screen.




Download 239.28 Kb.

Share with your friends:
1   ...   4   5   6   7   8   9   10   11   ...   15




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

    Main page