This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.
With the recent substantial growth of smartphone users, there is a need for mobile applications to be usable by all market divisions. This project looks into tailoring mobile application interfaces to the visually impaired smartphone user. We study the Android mobile operating system and technological challenges faced by the visually impaired, and further implement findings into a smartphone music player application. We look at the different techniques and features that can be implemented to decrease the cognitive load on the user, in order to simplify use of smartphones. Finally we identify the best practice for mobile application development for the visually impaired, and through results from testing we confirm its effectiveness.
Aims and objectives
The aim of this project is to perform an investigation into the use of smart phone features in order to make mobile applications and general usage of the smart phone more accessible to blind and visually impaired users. Previous approaches into mobile development for the disabled will be scrutinised and we identify strengths and weaknesses in these. In doing this it is hoped that future mobile application development for the blind and visually impaired will benefit from the findings, thus making smart phones more accessible and the smart phone market more inclusive. Findings are then, where possible, implemented into a music player application for smart phones running the Android Operating System. This is an application also designed for use by the general user market. An iterative development process was employed, with feedback at each stage for the prototypes.
In this project we aim to cater to the needs of the visually impaired users of Android smart phones in particular, as it can be observed from various sources that this is a pressing issue. "Even as every mobile-phone maker is attempting to come up with the latest and the most stylish version of a touchscreen phone, visually-impaired people seem to be largely ignored by the manufacturers â€¦only Apple's iPhone is fully accessible right out of the box to the visually impairedâ€¦ However, no other smartphone currently comes close to offering such technology for the visually impaired." 
Although present software systems are often very sophisticated and user-friendly, their use often poses an inconvenience for visually impaired people. This can be attributed to the graphical interface and absence of features fulfilling the specific needs of those with sight problems. Basic accessibility services are represented by speech synthesiser and screen magnification software, used to obtain information from computers. The present development in human-computer interaction and spoken language dialogue systems brings new prospects for improvement but also new problems. For example, speech recognition is notoriously error-prone. This unfortunate fact holds great importance for the visually impaired user, especially emphasised by the point that for this group of people, computers are one of the most important sources of information  .
Overview of the report
This report is organised asâ€¦[brief description of contents]
Traditional mobile phones offer a limited range of features for the user, often not falling far outside capabilities to send SMS, make calls and perhaps take photographs and play music. However a smart phone is perhaps better described as a handheld personal computer. Typically, CPU processing speed will range from 600MHz to 1.2GHz with RAM of around 600MB  . This is not dissimilar to specifications for larger personal computers found in the home. Smart phones will have both internal and external memory in the form of a memory card available in different sizes.
The choice of the Android operating system was largely due to the fact that unlike Apple's iPhone OS, Android allows developers to freely develop open source code without restrictions  . This means that developers can access and build on the work of others. Other factors also influenced this choice, as we will now explore.
Android is a mobile operating system developed by Android Inc., a firm later bought by Google Inc. It is based on the Linux operating system. Currently, approximately 70,000 applications are available on the Android Application Market. The Android software system consists of Java applications running on a Java based object oriented application framework.
Android accounts for 29% of all active smartphones in America (fig 2.2.1). With this success in the market, more and more smartphones are set to be released in the coming years.
[Fig 2.2.1, Source: The Nielsen Company]
2.3 Mobile Applications
Possibly the most popular selling point and unique feature of smart phones is their functionality to download and install applications (abbreviated to 'apps'). Most smart phone operating systems offer access to a market where applications made by commercial and independent developers are available for free or paid download. For example, the iPhone has its own app market, as does Nokia have the Ovi Store. The user is able to browse through, select and download various apps
The Android market in particular does not select apps to enter into the market based on their integrity and selling potential; rather it elects to use a user rating based system, where apps are labelled by their user rating and reviews. This is an incentive for both experienced and potential developers to produce applications which they can then share.
Security is a considerable factor when marketing applications. When installed, an application may have access to confidential information, as well as permissions to make calls and access the internet. With some application markets, an app will undergo rigorous security checks before it is released to the public. With Android's Marketplace, these security checks are not in place, instead the user is given the choice of whether or not to download an application. All permissions the application requires are listed, and the user makes their choice from this  .
Efficiency is a key factor in mobile development. This requires applications to load and run quickly. It also means that resources must be used with caution. Chong reinforces the importance of code being optimised as far as possible, since mobile phones being of 'small size, have limited memory  .'
Music Player Applications
Whilst Apple seems to control the market of portable music players  , consumers constantly look elsewhere to new, innovative means to listen to music. As the mobile phone market becomes more competitive, brands offer more and more features to customers. The media player feature has been common in mobile phones for many years now, however, space and size constraints often persuade the customer to invest further in a portable music player.
The recent entry of smartphones into the market sees customers with the handheld power to accomplish a great number of tasks, rendering a great number of other electronic devices superfluous. The ability to play music may be only one of the features of a smartphone, but still possibly stands as one of the most desired.
In an age where mobile phones are ubiquitous, the study of mobile phone music players is a worthwhile one. This is due to a number of factors. Continuous improvements of battery life, expandable memory, better sound quality and ability to play different music formats are all advancements that favour the replacement of portable music players with smart phones. Other features include the introduction of 3.5mm headphone sockets on smart phones, allowing the use of everyday headphones to listen to music, and not restricting this to the manufacturer's unique headset.
We look at the two most popular music player applications available on the Android Market. Popularity here will be measured by the number of active users at the time of study. Both applications have been released by commercial developer teams and as such are available at a price.
MixZing claims its music player application to be the "most advanced music player on any platform"  . It boasts a clean design featuring innovative features such as the "Mood Player" which automatically fills the playlist with recommended songs. Although described as clean and easy to use, it is evident at a first glance that the interface might be construed as fairly complicated. The main screen focuses on album art, and buttons are small and difficult to use on smaller smart phones. User feedback is generally positive, and any complaints are regarding the slow speed and occasional unresponsive controls, as well as complaints about the price (£3.99).
Winamp Music Player
Winamp is a media player first seen on personal computers before moving to mobile devices.  Also one of the most downloaded applications on the Android Market, it shares many of the same characteristics as the MixZing player. These include the intuitive playlist creator, as well as the somewhat crowded interface. Feedback for the application is generally positive, although some users comment on the interface, "buttons unresponsive at times..no lock screen controls."  The lack of lock screen feature is mentioned often.
Here we study previously completed research papers and articles relating to the project. We find that similar projects have been attempted in the past, and we will compare these approaches to consider the successful elements which will benefit the application.
Visual impairment is an umbrella term covering any type of visual disability. These can be partial blindness, loss of depth perception, colour blindness etc. Those who are completely blind cannot be categorised as visually impaired. There are various causes for visual impairment, such as loss of visual acuity, loss of visual field and ocular motor impairment. Visual acuity is a measure of the vision clarity, in each separate eye and in both working in conjunction. Visual acuity of 20/200 or lower is classified legally blind. (See Fig 3.1.1 for classification of visual impairment). Visual field is the range of sight without moving eyes or head. A visual field of under 21 degrees is classified as legally blind. Ocular motor impairment refers to the difficulty of the eye muscles in performing basic functions such as fixating vision, and following or searching after objects. In some cases the person is unable to see a 3 dimensional image  . Nordin mentions that visual impairment cannot be assessed simply in regards to visual acuity, but other factors which must be taken into account are spontaneous movement of the eye (ocular motility), colour sensitivity and colour blindness  .
Thus visual impairment can suggest a range of eye conditions including but not limited to: near sightedness, far sightedness, astigmatism and colour blindness. In this project we will be focussing on support for a majority of these conditions by adapting the user interface to be used with minimal visual interaction.
[Fig 3.1.1 Classification of visual impairment, Adapted from Colenbrander, 1999] 
Visual Acuity Score
(Near- )Normal Vision
Range of Normal Vision
20/12.5 - 20/25
20/32 - 20/63
Moderate Low Vision
20/80 - 20/160
Severe Low Vision
20/200 - 20/400
Profound Low Vision
20/500 - 20/1000
20/1250 - 20/2000
[No Light Perception]
Technology for the Visually Impaired
3.2.1 Basic Technological Needs of the Visually Impaired User
The system must enable comfortable control by means of combination of speech commands and keyboard (hot key commands). Graphics can be used only in a special way as an additional output for the users that are not completely blind. Other input/output devices can be used for a specific application provided that such a type of communication is effective.
Speech commands should be supported by speech (system driven) command dictionary that allows to express a command in several ways, making the control of the system more intuitive. This is always useful, but especially for blind users where the possibility of intuitive control of the system is even more important.
Easy customization and configuration is very important feature of the system, especially for users that often use the system for a long time. This is related to the control commands, mode and type of speech synthesis output, information data structure, and other properties and options of the system. It is very important to enable the user to obtain the information quickly and to allow them to get an informational overview.
As pointed out, one of the most important problems we meet when designing applications for visually impaired users is how to convey a variety of pieces of information(some of them can take basically graphical form) quickly and how to supply sufficient information providing full orientation of the user. The main way to manage this is to use sound. It can be done in the form of synthesized voice produced by the syllable based speech synthesizer. This type of sound output can be used for generating output messages and reading text data. The used speech synthesizer should concatenate recorded speech from a database clearly to enhance quality of the speech output and to distinguish various words. It should be also able to use various voice types that can be configured by the user. Various voice types can be used to distinguish various types of information.
3.2.2 Specific Demands on User Interfaces for the Visually Impaired
In some applications, there is almost no difference in using the user interface between sighted and visually impaired user. This is, for example, the case of dialogue systems that are accessible via telephone. However, many systems use graphics as an important output for information and they mostly also do not assume that the user is visually impaired and therefore they ignore specific needs of such users.
Mobile Applications for the Visually Impaired
"In the United Kingdom, there are currently around 380,000 people who are registered blind, and a further 2 million people who have sight problems or are visually impaired."  Fig 3.3.1 indicates that smart phone users over the age of 50 comprise a considerable portion of the market. "About 65 % of all people who are visually impaired are aged 50 and older, while this age group comprises about 20 % of the world's population. With an increasing elderly population in many countries, more people will be at risk of age-related visual impairment."  Kavcic confirms that people with disabilities represent a large share of the market, and that accessible software design is encouraged by national laws  . These figures reinforce the importance of adapting user interfaces for the visually impaired.
[Fig 3.3.1, Source: The Nielsen Company]
Next we analyse some of the most popular applications available today on various mobile platforms. Here popularity is measured by the number of users who have installed and are actively using the application. These figures are available on the Android Market page.
Digit-Eyes is a unique system which depends on the user to print labels for any item, which can then be read by the smart phone application and communicated back to the user via speech. The application is available at a cost of $29.99 [Digit-Eyes, 2008]. Digit-Eyes produces a unique 'barcode' for each individual item which can then be stored into a database within the memory card, and later decoded by the application using a simple barcode scanner. The square barcode pattern is able to translate to a maximum of 100 characters, or an audio file of length limited by the size of the memory card.
LookTel Money Reader is an iPhone application which, through use of an optical recognition system, is able to recognise US currency and communicate this back to the user through audio [LookTel, 2010]. The system depends on the iPhone's high resolution camera for its service. Contrarily to Digit-Eyes, LookTel is unable to work in conjunction with an already available stock barcode reader, and uses its own recognition techniques.
A Special Phone 2.0 [Muhiddine El Kaissi, 2009] puts emphasis on the simplicity of design and ease of use of the application. It claims to have a low learning curve such that 'the user can be as young as 2 years old' [ASpecialPhone.com, 2010]. The application, which makes use of the iPhone's accelerometer to provide an eyes-free dialler service, avoids voice recognition and instead employs use of gestures to operate.
Finally we look at specially engineered visual interfaces.
[Fig 3.3.2 Talking Dialer, Eyes-Free Project]
The Talking Dialer is a result of the Eyes-Free Project, which we will be looking into later. One drawback of this application is that it requires the user to download three other supporting applications. If any of those applications should be unavailable, the application will cease to function correctly. The controls are fairly straightforward- the user places a finger on the screen where they would like the '5' key to be and the rest of the keypad forms itself accordingly. Thus to press the '4 key, the user will place their finger on the screen and drag directly to the left, and release. First impressions of the application indicate that it could be slow to use with somewhat of a learning curve. This is because to dial '4', the user will intuitively place their finger on the left of the screen, and will then be unable to swipe further left, consequently being forced to dial '5'. Other potential shortcomings of the application include the inability to delete the last number input. The interface is innovative and with some small adaptations it could also be a suitable music player interface. Some user comments in response to this application were noted. One user responded to the fact that three supporting applications had to be installed first, "this basically means that if you are totally blind, and have bought an Android phone you will either need to have the shop set up the Eyes-free software for you, something that they may not be able to do while you wait; or you could have a friend or family member set it up for you. I feel that this is unacceptable  ." Regarding use of the application, "On attempt number 62 you will have dialed the number and thenâ€¦wait a few millennia for the app to activate the phone's own dialler to dial the number for you." Three important points can already be derived here; one that efficiency of the application needs to be improved, that the interface is not as intuitive as hoped, and finally that requiring third party applications to be pre-installed is impractical in many cases.
[Fig 3.3.3 Voice Pad, Blues Labs]
Voice Pad is essentially a notepad to allow the user to make quick notes by speaking to their phone. Voice Pad implements a relatively new feature of Android, speech recognition. While the technology is not yet perfected, in that it does not easily recognise all spoken words, it is fast evolving to become a revolutionary feature of all Android applications. Through testing the Voice Pad application it was found that speech recognition struggled to identify simple words such as 'cheese, bumblebee, fountain' and instead returned 'sees, umbrella, funny'. This lack of accuracy could possible render the application ineffectual.
We found some general applications designed to make the use of smartphones easier for the visually impaired, such as through screen magnification. There were also various music players for the Android platform. However, there were no specific music player applications dedicated for use by the visually impaired. Since this was the case, it was decided that the project would focus mainly on the development of a dedicated user interface for the visually impaired, and this would then be implemented into the music player application. The application will implement features which have had research and development invested into them.
3.4 User Interfaces
Developers employ several different techniques when producing applications for the visually impaired. It can be gathered that the common goal is to produce the application in such a manner that it essentially becomes 'eyes-free'. These applications are often also marketed to the general population as useful for use when driving or at other times when concentration on the screen is an inconvenience. StartTalking [AdelaVoice, 2010] is an 'entirely voice controlled' application, and advertised as 'the safer way to text message for people on the go' [StartTalking.com, 2010]. StartTalking is available on all Android 2.x devices, and uses Google's speech recognition service to carry out various tasks. Therefore while being used it does not even require the screen to be on.
From analysing these applications, it can easily be noticed that the focus of each lies in auditory interaction with the visually impaired user. Hence we will next study the use of audio in mobile phone applications.
Focus on sounds is advantageous not only because it allows the visually impaired user to interact with the smartphone with greater ease, but also because the sighted user is able to multitask. This can have a positive effect on the safety and time management of said user.
Identifying sound does not necessitate the user to be aware of the location of the device. Therefore for visually impaired people, sound is a powerful tool when designing user interfaces.
We can divide sounds into the two categories of speech and non-speech. Speech is implemented through the use of Text To Speech software (TTS), or voice recording. Below we look at some of the several types of non-speech sounds.
An earcon is a "brief, distinctive sound used to represent a specific event."  They are most familiar as warning tones in computer error messages. They are also used in various other situations, e.g. for dialogue boxes or for an incoming email message.
3.6.2 Auditory icons
Auditory icons employ "metaphorical mapping"  to convey actions to the user. For example, the user may be notified of a system failure with an accompanying auditory icon which plays the sound of an explosion. Garzonis asserts that as a result of tests, "Auditory icons performed significantly better than earcons in terms of intuitivenessâ€¦validating our choice of metaphors for the auditory icons." 
3.6.3 Text to Speech
Eyes Free TTS is a speech synthesizer, which is written entirely in the Java programming language [Willie Walker et al., 2005]. A small mobile speaking clock application was created with Eyes Free TTS. Unfortunately compared to a standalone java application with Eyes Free TTS, the mobile application did not give the expected results.
[More needed here on TTS systems]
3.7 Visual Features
Although we look at interfaces which requires minimal visual interaction, applications which are targeted towards sighted users also incorporate visual aids through pictures and icons.
3.8 Cognitive load
Cognitive load is the amount of effort the brain is put through whilst following instructions. This is essential to take into consideration when developing intuitive interfaces or a complex interface which requires some learning curve. Sweller tells us that "learning happens best under conditions that are aligned with human cognitive architecture."  This tells us that we can promote learning, whether it be of an algorithm or mathematics equation, through structuring the learning process most effectively for human learning. This structuring is discovered through a series of experiments. Ultimately this leads us to arrange information in a way that allows the user to effectively understand and remember it.
3.9 Mobile Operating system accessibility
There is enough scope for improving user interfaces for visually impaired users.
Some possible areas of improvements and inventions are listed below. Nordin recognises current approaches such as voice recognition software and text readers as successful. He also states that 'most systems have limited accessibility if learning requirements for user with visual impairment are considered.  '
3.9.1 Graphical User Interface (GUI) Manipulation
â€¢ GUIs can be magnified to suit the user's visual ability. This will include magnifying icons and fonts in the GUI
â€¢Dual mode GUIs can be implemented, where it is possible to have normal mode and magnified mode.
â€¢ Scalable icons which the user can resize according to their preference
â€¢ Automatic re-alignment and re-positioning of icons when the size is
3.9.3 Voice Components
â€¢ Voice enabled components to build the application, i.e. the application is voice enabled and has an alternate or accompanying control system.
â€¢ Implementing a different language in screen reading and speech recognition.
â€¢ We can have specialised visuals with integrated voice function.
3.9.4 Haptic Feedback
â€¢ Using vibrations on the handset for animations, warnings and special events.
â€¢ Various possibilities here, examples may include a periodic announcement of computer status, when the user is inactive for a long period of time.
During the course of the project, gathering feedback from the user group is particularly important. Four visually impaired technology users were willing to participate in the study, as described below. Each was given a HTC Wildfire running Android 2.2 (Froyo), and instructed on its use. For each application they were requested to test, each user was given 30 minutes to use the application before commenting.
Central Visual Acuity
Patient at Moorfields Eye Hospital
Patient at Moorfields Eye Hospital
These participants will be referred to comment and give constructive criticism.
4.1 User Feedback on Applications
Participant A: "Text was difficult to read, awkward colour scheme"
Participant B: "Buttons didn't always work as intended"
Participant C: "Generally awkward to use- various screens meant the buttons were constantly moving around"
Participant E: ""
Participant F: ""
Participant A: "Adverts often got in the way of performing basic operations, which made me connect to the internet unnecessarily"
Participant B: "Fairly difficult to understand how to use"
Participant C: "Multitude of unnecessary options were highlighted on screen, somewhat steep learning curve to use."
Participant E: ""
Participant F: ""
Participant A: ""
Participant B: ""
Participant C: ""
Participant D: ""
Participant E: ""
Participant F: ""
Participant A: ""
Participant B: ""
Participant C: ""
Participant D: ""
Participant E: ""
Participant F: ""
5 Design And Implementation
In this section we will be looking at the implementation of the music player application. The application was developed in Eclipse with built in Android SDK. The initial prototype was a simple music player application built with Java. It loads mp3 files from the memory card and employs three simple buttons to allow the user to play, pause and skip between tracks.
Below is a simple use case diagram indicating the main necessary functions of a music player application.
5.1 Choice of Structure
Since it has been decided to build a series of prototypes re-evaluating user requirements at each stage, the choice of structure is linear-iterative.
5.2 Development Process
In development of the application, an iterative method was adopted. Following this system, design, implementation and evaluation were repetitively performed to create the final application. Upon each iteration, requirements were reconsidered, to prevent the project from deviating from the original specification. Each prototype design was discussed in detail with visually impaired technology users, in conjunction with analysis of the research conducted. Several designs were considered, but the most simplistic of these were opted for, due to a significant opinion that it had greatest ease of use.
Initially, a prototype music player was built without a tailored interface:
This initial design was produced in order to gain an understanding of how the various classes in Android work together, particularly the Android MediaPlayer class. The simplicity of design was also chosen to act as an alternative music player application for use when testing the final product. This prototype implements Android.MediaPlayer to load all mp3 files from the memory card. There are three simple buttons, to play/pause, previous track, and next track. Two simple text views show track name and status of the player. There is an obvious lack of functionality from this player, but it gives a good foundation for the implementation of our proposed features.
5.3 Risk Assessment
Risk assessment is necessary to examine what could specifically go, allowing us to take the relevant precautions.
Risk falls into three categories:
Project Risk - where schedule or resources are affected
Hardware unavailable: the Android test device is not functioning correctly or unavailable. To avoid this likely occurrence, two Android devices were purchased, with same platform and technical specification (Sony Ericsson Xperia X10 running Android 2.1).
Requirements change: the requirements change to such an extent that the project changes entirely. Since an iterative development method was adopted, this risk has been minimised. Each stage of feedback is prompted by analysis of requirements and feedback from the last stage.
Specification delays: specification falls behind schedule. To allow for some flexibility, a rigid timetable has been created, with three weeks allocated after project closure for any extra work.
Product Risk - where quality or performance of product are affected
Size underestimate: system size exceeds expectation. Since there is a lack of previous experience in working in mobile software development, or with Android, this is a likely outcome. Again, to allow some flexibility, the timetable constructed is fairly generous with extra time in the implementation phase.
Technology change: the underlying technology is overtaken, rendering the application out-dated and useless. Having conducted research on the Android operating system, it can be said with confidence that this is very unlikely to happen in the near future.
Product competition: similar applications from competitors are released before project complete. Looking at the types of applications being released on the Android market on a day-to-day basis, this is relatively unlikely.
Business Risk - where the organisation developing the product is affected
Through prototypes and experimentation with the various Android services encountered, a set of requirements were determined. Again, this set was decided upon after careful deliberation with the study group.
5.4.1 Functional Requirements
Functional requirements of the application:
Collect mp3 files from memory card
Sort files appropriately
Control playback of files
Adaptable to work on all Android smartphones
5.4.2 Non Functional Requirements
Other than being accessible for visually impaired users, the music player application should ideally be:
Reliable - plays a variety of music file formats. Avoids crashing during tasks.
User friendly - there should not be complications to the user interface; it should be clean and intuitive.
Efficient - no lengthy loading times.
Safe to run - No modification of external files or applications.
5.5 Prototype Design
Designing the system involved merging four main components:
Music player with standard features
Eyes-free accessible interface
Audio and physical feedback integrated interface
Speech controlled interface
5.6 Visual Interface
Following participants' suggestions to implement a button free navigation system, the finalised design consists of a blank canvas whereon the user is able to perform a pre-programmed set of gestures to operate the music player. Other secondary features of the interface include a small title bar and speech button, and an exit button placed in the bottom corner of the screen. In the opposite corner is a link to the playlist screen, where the user is presented with the list of tracks sorted in the manner they have selected. The gesture sensitive canvas is maximised for greatest functionality. Gestures will be permitted anywhere on this canvas. Gesture sensitivity has been increased to be extra responsive to commands. Any gestures will be shown on screen with a pointer to help the user define direction and command. A press of the menu button will initiate an alternative song menu that is sorted by directory rather than mp3 tags.
Fig 5.5.1 Application 'splash screen' instructs the user of the commands corresponding to each gesture
5.7 Integration of Text to Speech
Here we exercised use of Android TTS libraries. As previously discovered, there are various text to speech libraries available. I have chosen here to use Google's standard Text to Speech library simply for the fact that it is shipped with all Android phones with Android 2.1 or higher installed, and users will not have to download a separate library (.jar file) to support the application. Although some of these external text to speech libraries are expertly crafted, with excellent voice capabilities, I believe accessibility is a fundamental issue here. External libraries may not always be available to the user to download, and may not be as well integrated into all Android applications.
Care has been taken to implement the speech function where necessary. Not every command necessitates being spoken out loud. For example, the 'Next Artist' gesture is pre-programmed into the application and instead of speaking 'Next Artist', the system will simply read out the name of the next artist.
5.8 Sorting the Music Library
The music library can be sorted in a number of different ways. Mp3 files contain several 'tags' which identify select pieces of information about the file. For example, there can be artist, album and bitrate quality tags. Most simple music player applications will use a straightforward mp3 filename filter, which selects all mp3 files from the memory card and sorts them by filename. However to give the Giggle player an edge over other players, and thus make it user friendly with fully sighted users too, I have decided to implement a tag structured song picker. This enables the user to sort their music library by select criteria. This places it on a par with more complex and popular intuitive players such as the DoubleTwist and PowerAmp players.
5.8.1 Tag Sorting
Where the song picker uses tags, it implements the TrackSelect class, an interface which provides the basic methods to get track and artist information, skip tracks, etc. This has been employed to create a system whereby the user can easily categorise their music library and select tracks intuitively. Each mp3 file may or may not contain tags to aid sorting. Where tags are available, at the users command the player will automatically sort the mp3 files from the memory card in order of artist, album and alphabetical track name, respectively. The system uses ID3 tags, which are most commonly used to identify mp3 files.
5.9 Speech Commands
Here a recently introduced Android feature has been implemented. Google Voice Search is pre-installed on all Android smart phones running 2.2 or later, and can be manually installed on earlier firmware. It has been taken into consideration that not all phones may have Voice Search installed, thus the speech control system has been implemented separately to the gesture command system. A tap of the upper right corner will activate the speech recognition service, and spoken commands will perform the corresponding action. For example, if the user taps the button and says 'Next Track', the player will skip to the next available track. For reasons of battery conservation and to avoid unwanted performance of the player, the recognition service is activated only when the button is pressed.
Fig 5.9.1 The voice recognition service is activated on a touch of the speech button
5.10 Accelerometer control
Again not every phone will be equipped with an accelerometer. This is a battery intensive feature but after some consideration was included as a feature. The addition makes this the only music player application to include fully integrated motion controls. There currently exist many stand-alone applications which offer motion control when used in conjunction with music players, but no music player applications exist that have this feature built in. The controls have been configured such that an upward shake of the phone will activate voice recognition, and a sideways/forward shake will skip to the next track.
5.11 Haptic Feedback
This is an experimental feature with positive feedback, and has thus been implemented into the final design. The basic concept is to assign a unique vibration pattern to every function of the music player. The user will instinctively learn these patterns, and this in turn makes the player easier to use eyes-free.
Testing is a fundamental part of any development process. In this project, the group of participants was requested to use the Giggle application in accordance with a guidance sheet. They were then asked to follow the same instructions for the first prototype application, the MixZing application and comment on their experiences. The guidance sheet can be found in the appendices.
Carrying out tasks:
Feedback: MixZing Player
Carrying out tasks:
Feedback: Giggle Player
Carrying out tasks:
Evaluation of the application was performed continuously throughout the lifecycle. Since we used the iterative development style, user requirements were periodically re-analysed and the prototype was evaluated alongside these. Each functional prototype was initially run on the Android SDK emulator to determine any compilation errors. However since the emulator does not promise correct functionality, the prototype was then installed and run on a Sony Ericsson Xperia X10. This allowed accurate testing of the application's functions, since there were often cases where the application would run on the emulator but not on the mobile phone. Reasons for this may include the fact that certain parts of the application such as the accelerometer and voice recognition cannot be emulated on the computer for obvious reasons. Here we will be looking at whether our requirements, both functional and non-functional, have been met.
Since the application essentially combines two components (an accessible interface with a fully functional music player), each component can be individually improved. With more time available, some improvements could have been made to enhance the application further. To appeal to a greater user market, the application should, in terms of functionality, be on par with the priced applications in the Android Market. Therefore some possible improvements are:
Include album artwork, if unavailable then download from internet
Detect and download track information from internet
Equaliser settings to adjust music according to preference (e.g. Rock, Classical etc.)
Ability to set track as ringtone
These must be implemented whilst maintaining the accessible interface. With respect to the interface, the following improvements could be implemented.
Greater voice control of the application, e.g. the ability to open the application by speaking its name.
Adaptability with all Android handset keyboards
Transferability. It is hope the application will be translated for use onto iPhone and Nokia smart phones.
Adjustable colour schemes
Android is a relatively new operating system, and as we have seen, it is fast becoming the most popular mobile platform. Thus as more developers work with Android, new and innovative features will be increasingly available. These will hopefully contribute to the visually impaired experience of smart phones.