Archive for March, 2015
Scope of the App
Posted by Taekyun Kim in Contextual Factors and Research, Design, Structure and Story on 17/03/2015
Introduction
An important consideration for the TravelSafe app is the scope of the intended area for its use. Although we fully intend for the app to be used on a global scale, this is not possible for a small group project with limited time. Therefore, we have decided to use the UK as a case study in which to test the app before its launch for use world wide.
Why the UK?
We have selected the UK primarily because all of the group work and live here, which makes tailoring the app and planning its stages easier for us. Also, we know the area very well, which will mean that app can be planned out very well. Along the same lines Miluzzo et al., (2008) reccommend that for apps which need testing in a smaller situation before expanding, a familiar area for the designers should be used which may then be scaled up.
Kangas and Kinnunen (2005) go on to further explain that user testing for an app should be tested in a single cultural and language zone first. Bigger areas should then be used so that easily identification of social, cultural and language barrier issues can be more easily identified and tackled (Kangas and Kinnunen, 2005). Therefore, this advice makes the UK the perfect area to demonstrate the usability of the TravelSafe app, as the area is small and the app can be adjusted before further use.
Limitations
By using the UK as a case study there will be limitations. One limitation is that in the UK there may be different demographics who may use the app, for example maybe more English people will use it when travelling to a different city rather than a different country. This should be fully considered in the qualitative testing in the future. Another limitation is that because of the previously mentioned one, the app may not be fully tested in different countries, therefore it may be difficult to know whether it works correctly. This will be addressed when the app is tested on a bigger scale. We suggest that future testing should begin in the UK, then expand to some other selected countries for example in Europe, and then if this works well, it should be scaled up once again. Finally this will be on a global scale.
Conclusions
The TravelSafe app should use a small area for extensive testing to make sure that any social issues can be addressed on a wider scale (Kangas and Kinnunen, 2005). The UK is the perfect starting point for the testing app as it is small, and the designers/engineers are english-speakers (Miluzzo et al., 2008). The aim of the project is to develop an idea that is at the stage of being able to be tested commercially and extensively, therefore the TravelSafe app at the end of this project will list future testing and technological considerations which may discuss how the app may be release on a global scale.
References
Kangas, E., & Kinnunen, T. (2005). Applying user-centered design to mobile application development. Communications of the ACM, 48(7), 55-59.
Miluzzo, E., Lane, N. D., Fodor, K., Peterson, R., Lu, H., Musolesi, M., … & Campbell, A. T. (2008, November). Sensing meets mobile social networks: the design, implementation and evaluation of the cenceme application. InProceedings of the 6th ACM conference on Embedded network sensor systems(pp. 337-350). ACM.
Expert Opinions and Advice for App Features
Posted by Briony Gray in Contextual Factors and Research, Engineering on 16/03/2015
With a global increase in the use of smartphones and tablets, there is an ever growing market for Applications (apps) and other specifically tailored features for these devices (Shin et al., 2012). Over the years these have evolved and adapted to a market of their own, and many boast specialised features, well-known brands and millions of users (Bellman et al., 2011). With such a vast and thriving scene one must look towards expert advice and opinions in order to identify gaps in the existing market (Lin et al., 2014).
Expert opinions may vary depending on the size and purpose of a company therefore it is import to select suitable individuals fitted for the scale of company and/or app. As our project is a university coursework and we will not release the app to the public, local experts in web design, features and devices will be suitable for guidance on the project. The features that the experts were asked to comment upon was produced by market research, user research, literature and group consensus. This list is as follows:
- 1. Safest Route Generator – This generates three safest routes from point to point in real-time2. Area Information Safety Rating – This is used for areas using open data crime statistics and social media3. Local Travel Information Updates – This provides local bus and train times, locations of these, and weather information Weather updates.
4. Safety Information – This is generated from locational based RSS feeds from embassies, social media and news feeds.
5. Emergency Contact Information – This is done through user input which an individual stores travel information such as flight numbers, travel insurance, credit card numbers, and emergency contact details.
6. Downloadable Resource Pack – This allows the user to choose a location and download above features (such as travel information or safety information) which can be accessed while offline. This combats roaming charges while travelling.
7. Blogging Features – e.g. photo and video with GPS location – Links to social media e.g. photo and video
post uploads, blog posts.
8. Family Alerts – This features a danger button to send location to designated contacts, and/or emergency services or the police.
9. Flight Information – This provides information from airport/airlines with notifications for specified Pack offline.
The designs that the experts were asked to select from has been posted in the ‘App Logo Designs’ blog post, which can be found in the portfolio. The experts were selected through purposive sampling, as the sample was required to be small and to produce in depth qualitative feedback. They were addressed via email as it can be recorded easily and any points further discussed with minimum effort. Each expert has consented to basic personal data (i.e. name and expertise area) to be disclosed in this feedback session, along with a copy of their answers.
In order to read the tables please click on the image to enlarge. Please note that you made need to zoom in to read the text more easily, this is due to a formatting error with wordpress.
Expert opinion number1 – Michael Gordon. Please click to read.
Expert opinion number 2 – Christopher Gutteridge. Please click to read.
Expert opinion number 3 – Andrew Day. Please click to read.
Expert opinion number 4 – Andrew Park. Please click to read.
Written by Briony and Taekyun.
This post represents that the group has chosen appropriate economic and social Contextual Factors that directly link to the marking criteria, and are vital to understanding what requirements the product will have in terms of useful app features. These are based on market analysis, evaluation of existing products, and identification of useful app features. These have been presented to experts to ensure further guidance and feedback for contextual factors. There is evidence that questions and the short-list of app features have been chosen intelligently (by reference to literature and analysis) to produce a conclusion of professional quality, leading to a successful product.
The feedback from expert opinions and the adaptation of the product based on this represents intelligent engineering choices. This tackles the weaknesses of existing app features and adds further appropriate engineering structure to the product.
References
Bellman, S., Potter, R. F., Treleaven-Hassard, S., Robinson, J. A., & Varan, D. (2011). The effectiveness of branded mobile phone apps. Journal of interactive Marketing, 25(4), 191-200.
Lin, Y. H., Fang, C. H., & Hsu, C. L. (2014). Determining Uses and Gratifications for Mobile Phone Apps. In Future Information Technology (pp. 661-668). Springer Berlin Heidelberg.
Shin, C., Hong, J. H., & Dey, A. K. (2012, September). Understanding and prediction of mobile application usage for smart phones. In Proceedings of the 2012 ACM Conference on Ubiquitous Computing (pp. 173-182). ACM.
Determning a Project Methodology
Posted by Po Ting Tse in Contextual Factors and Research, Design, Structure and Story on 13/03/2015
Introduction
The group are currently using Scrum (Schwaber,1997) for the software development process. This post is going to explain the group’s choice among existing methodologies, the advantages, and the possible issues the group may have with this approach. Determining a methodology that a group should follow is a vital part of producing a project that will fulfill the success criteria. This is due to the project requiring many steps and many contributions from different members. This means that in order for this to occur to a high standard the group must all follow the same method, understand that method, and be able to work as a group to achieve the same goals. Therefore choosing a methodology that suits both the group, the project, and the success criteria is important.
Traditional waterfall model
Traditionally Software Development Life Cycle, or commonly known as the waterfall model, has been adopted in software development. It is well known of its cascading development stages, in which the stages are be followed in sequential order, as shown in Figure 1 below. These include feasibility study, systems investigation, analysis, design, development, implementation, and maintenance ( E. Avison & Fitzgerald, 2003).
Figure 1 The waterfall lifecycle for software development (Vidgen, 2002).
Before starting the next phase previous phases have to be completed (hence the term waterfall), and each phase has a set of defined outputs or deliverables to be produced before it could be deemed complete ( E. Avison & Fitzgerald, 2003). As the world became fast-paced and technological requirements changed frequently, people soon discovered the weaknesses of this approach and start to embrace the agile methodology.
Weaknesses of the Waterfall model
Firstly, the waterfall model fails to meet the real needs of the business world (Avison & Fitzgerald, 2003) as the technological efficiency improvements are at the operational level, detracting from the business needs. Consequently the project sponsors also focus on the project investment, as well as the return and benefits through the system.
Secondly, over conservative systems design is an apparent limitation ( E. Avison & Fitzgerald, 2003). Since the model emphasises the existing system as a basis of the new system, there is limited creativity for developers to implement the new one. Thirdly, instability is apparent as the modeling of processes could be unstable due to changing businesses and markets. Subsequently it is difficult to develop a suitable and stable model. It becomes a burden for developer to implement the program as the modeling is varied.
In addition, inflexibility of the model, the inability to change requirements, leads to further limitation (Vidgen, 2002). The methodology makes a number of simplifying yet invalid assumptions (such as a stable environment, a well-documented business strategy, users knowledgeable about their own requirements, or that a consensus of requirements can be achieved). However, such conditions rarely exist in practice.
Next, user dissatisfaction ( E. Avison & Fitzgerald, 2003). According to problems with computer-oriented documentation, users are not allowed to browse the prototype of the system before it is completed. The user involvement is limited and they may feel uncertain since nothing could be seen when the system is incomplete. In addition to this the problems with documentation produce further limitations ( E. Avison & Fitzgerald, 2003) since the document is full of information, developers have to assume they understand what they need, instead of referring users’ needs.
Finally, application backlog is a tangible limitation ( E. Avison & Fitzgerald, 2003) as the maintenance workload can be large. As a result attempts are made to change the system in order to reflect the change of user needs. The above weaknesses raise the urge of methodology evolution. In order to fit in the fast paced environment, the group decides to adopt the agile methodology. The next paragraph will explain why the group choose agile for software development.
Agile’s advantages and limitation (Cohen, et al., 2003)
Unlike traditional waterfall model, agile software development is known as its rapid and iterative approach (Highsmith & Cockburn, 2002). It highlights the most important parts, which the crucial parts will be accomplished first. This can gain confidence to the team, and project sponsor will be easily satisfied with the project in the early stage.
A strength of agile is embracing change and continuous development. As customers are the essential part in the team, they can come up with their ideas and thoughts immediately to the team. There is no communication lag between developers and customers. Time is saved and a prompt responded development can be performed. Next, agile software development enables the team to work effectively as a cohesive unit, which can improve productivity by several times. Team work is highlighted as cooperation enables greater productivity. Team members show their various expertise, understanding of the schedules and work cohesively, so the burden or difficulties can be solved together quickly..
Agile software development is a simple, elegant and correct solution found by true domain expertise and experience. Under this aspect, software can be maintained efficiently,as everything is simple and intuitive. The new comer can easily come up with ideas of the development, which we think is better for maintenance than the waterfall model.
Why the group will use Scrum for the project
Among popular agile approaches, the group decided to use Scrum due to its substantial benefits in comparison to other methodologies. Scrum is an incremental, time-based development (Rising & Janoff, 2002) with frequent meetings (i.e. Sprint). It embraces requirement changes, and is suitable for small team that working individually. This methodology works the best for the group as group members prefer to discuss and contribute ideas and research, rather than one person focusing on a large part. The group will have one to two meetings each week. In each week, the group will decide the next parts and corresponding job division, similar to the basic questions required in every Scrum meeting. The group meetings will last between 30 and 45 minutes each, one of which the mentor will join the group.
Conclusion
After a comparison of different methodologies the group has adopted the Scrum methodology because of its advantages. Since the application is user-oriented, user involvement in the whole development process is crucial. The group hope the project can achieve success with Scrum.
This post represents that the group has chosen appropriate economic and social Contextual Factors that directly link to the marking criteria, and are vital to understanding how best the group works towards a joint goal. These are based on a literature review which explains why the outcome was chosen and how the group will implement it. There is evidence that the methodology has been chosen intelligently (by reference to literature and analysis) to produce a conclusion of professional quality, leading to a successful product.
It is also evident that based upon the Contextual Considerations, literature review and analysis that appropriate Design steps for the product have been chosen intelligently. This is shown by the conclusion of picking a suitable methodology for the group and explaining its choice and how it will shape product development. This choice further represents the Structure and Story of the portfolio by dictating the methodology used.
References
Avison, D. & Fitzgerald, G., 2003. Information systems development: methodologies, techniques and tools. 3rd ed. s.l.:McGraw Hill.
Cohen, D., Lindvall, M. & Costa, P., 2003. Agile software development. DACS SOAR Report, Issue 11.
E. Avison, D. & Fitzgerald, G., 2003. Where now for development methodologies?. Communications of the ACM, 46(1), pp. 78-82.
Highsmith, J. & Cockburn, A., 2002. Agile Software Development:The Business of Innovation. Computer, 34(9), pp. 120-127.
Rising, L. & Janoff, N. S., 2002. The Scrum software development process for small teams. IEEE software, Volume 17, pp. 26-32.
Schwaber, Ken. “Scrum development process.” Business Object Design and Implementation. Springer London, 1997. 117-134.
Vidgen, R., 2002. Developing Web Information Systems: From Strategy to Implementation. s.l.:Butterworth-Heinemann.
By Po Ting Tse
Target Audience and Pricing
Posted by Emily Pearce in Contextual Factors and Research on 12/03/2015
After the initial meeting where the group decided on the application to create, the next step was to look at the kinds of people who would use it and what they would use it for so that the group could further look into the features of our application and the potential price point for the application.
These are the main audiences the group have discussed so far:
- Tourists
- Locally: people who are visiting a new state or city
- Globally: anyone going to a new country
- People new to an area e.g. when you move house
- Travellers, such as groups of young people on a gap year
Tourists will be those on booked holidays, such as weekends away or two week breaks abroad and would mostly use features such as the ability to store their holiday information, maps of the local area and information on health concerns and local customs. People new to an area could use the application to discover local restaurants or entertainment venues, as well as find safe routes through the city. Travellers would use the features such as the ability to store their itinerary for the trip so they don’t have to worry about losing it, as well as plan where to go next. As well as this, they could use the application to provide basic translation so that they could speak the local language and ask for help.
Jeff Lewis states that “Travel is listed as the seventh most popular app to download with the most successful apps being planning, photography, social, deals and bookings, maps/navigation (particularly offline maps), TripIt, itinerary planning and recommendations” [1] and statistics show that “60 per cent of smartphone users downloaded travel apps, and 45 per cent used the apps to plan and research their trips”. With smartphone users forecast to surpass two billion next year [2], this provides a huge market for travel applications and in an already competitive market, it is important to stand out from the crowd. Because of this, the group has decided to match the pricing point of other applications – free.
The group did consider other options, such as free for a set period of time or set number of users in order to gain a user base, however this idea was discarded as it was felt that it would hinder word of mouth. This was the same case as freemium models, as the group thinks that it is important to not mislead the user and provide them with the best tool possible. Having said this, the freemium model is a fallback plan should the group decide to change our pricing structure.
This post represents that the group has chosen appropriate economic and social Contextual Factors that directly link to the marking criteria, and are vital to understanding what requirements the product will have in terms of target audience and product pricing. These are based on market analysis, evaluation of existing products, and identification of app features. There is evidence that these have been chosen intelligently (by reference to literature and analysis) to produce a conclusion of professional quality, leading to a successful product.
References
- Mickaiel, I. 2011, Mobile the new black for travel, ZDNet [Online] [Last Accessed Mark 2015] [Available at: http://www.zdnet.com/article/mobile-the-new-black-for-travel/]
- Curtis, S., 2014, Quarter of the world will be using smartphones in 2016, The Telegraph [Online] [Last Accessed: March 2015] [Available at:http://www.telegraph.co.uk/technology/mobile-phones/11287659/Quarter-of-the-world-will-be-using-smartphones-in-2016.html]
Written by Millie.
Meeting Summary 12/03/2015
Posted by Briony Gray in Meeting Summary, Structure and Story on 12/03/2015
Meeting Summary 12/03/2015
During this meeting the group discussed the progress that had been made with researching specific app features that would contribute to the product. Progress was evident, and the group extended the deadline for these tasks due to other module assignments occurring in parallel.
For the next meeting
For the next meeting the group will have posted individual posts regarding the specific features, with each containing a summary of how this may be utilised for the product. This may include differences in technical requirements or types of data that may need to be used. As a result the group has concluded that research into types of dataset that correspond to a free app should be conducted in order to allow the product to fit in with the market analysis.
This post represents that coherent structure and story are present in the portfolio which uses the entry and tags mechanism of the blog system. It tells the story of the project by explaining individual roles clearly, explaining why these were decided, and what outcome they will produce later on in the project.
Minutes by Briony.
Meeting Summary 09/03/2015
Posted by Briony Gray in Meeting Summary, Structure and Story on 09/03/2015
Meeting Summary 09/03/2015
During this meeting the group discussed the research that had been conducted in the previous weeks, and how that fit into the time scale decided by the planning posts. The group then discussed the short-list for app features based upon market research. It was decided that expert opinions should be asked in order to help determine which features may be more useful than others, and that group members should identify individuals that they feel were particularly relevant to our project and were willing to answer some questions. These individuals should be recorded communally, and made clear that consent would be required in order for the group to publish any feedback to the portfolio.
For the next meeting
It was decided that based upon the expert opinions, group discussion and literature review that each member should select a specific app feature and research this in more detail to further ascertain whether it would make a valuable contribution to the product, and would meet the success criteria. The short-list was narrowed down to five areas which were highlighted by existing market analysis to be important. These are:
– Safest Route Generator
– Safety/Reliability rating of area
– Travel updates information
– Location/safety tips
– Downloadable pack for offline use
This post represents that coherent structure and story are present in the portfolio which uses the entry and tags mechanism of the blog system. It tells the story of the project by explaining individual roles clearly, explaining why these were decided, and what outcome they will produce later on in the project.
Minutes by Briony.
Shortlist for App Features
Posted by Briony Gray in Design, Engineering, Structure and Story on 07/03/2015
The group is now in position where a wide range of background research has been conducted. This takes the form of Similar Applications, Market Research and Literature reviews for specific features. Consequently, determining a short-list of features which the TravelSafe app will utilise is the next design and engineering step of the project. As the project has the final objective of producing a fully researched and designed idea which is then ready to be subjected to qualitative and quantitative testing (which will require more funding and time than a group project is able to), we have enlisted the help of individuals who are considered experts in their field. In order to objectively evaluate the short-list of app features we have used purposive sampling to select a number of experts from ranging backgrounds. These include Engineering, Web Applications and Solutions, Web Master, and Senior Technical Advisor. This is a guidance solution regarding how we should structure and decide on the features of the TravelSafe app without breaching extensive qualitative and quantitative testing.
The experts were identified as being useful or relevant to our project interests, and then were contacted via email. This provided an easy medium for conversation without being formal. Initial contact with the expert explained our project scenario and requested that, if they were willing, should read the short-list of TravelSafe feature apps and answer 4 short questions regarding these. In addition we strongly encouraged any other thoughts or guidance throughout. Each expert gave permission to use their name, job title, expertise and answers in our portfolio. The feedback received can be found in the Expert Opinions post.
The short-list which the experts were presented can be found below:
1. Safest Route Generator – This generates three safest routes from point to point in real-time
2. Area Information Safety Rating – This is used for areas using open data crime statistics and social media
3. Local Travel Information Updates – This provides local bus and train times, locations of these, and weather information Weather updates.
4. Safety Information – This is generated from locational based RSS feeds from embassies, social media and news feeds.
5. Emergency Contact Information – This is done through user input which an individual stores travel information such as flight numbers, travel insurance, credit card numbers, and emergency contact details.
6. Downloadable Resource Pack – This allows the user to choose a location and download above features (such as travel information or safety information) which can be accessed while offline. This combats roaming charges while travelling.
7. Blogging Features – e.g. photo and video with GPS location – Links to social media e.g. photo and video
post uploads, blog posts.
8. Family Alerts – This features a danger button to send location to designated contacts, and/or emergency services or the police.
9. Flight Information – This provides information from airport/airlines with notifications for specified Pack offline.
This post also represents that the group has chosen appropriate design and engineering choices that directly link to the marking criteria, which are vital to understanding which features that the product will have. These are based on Contextual Factors such as market analysis, evaluation of existing products, and identification of app features. There is evidence that the design and engineering steps (app features) have been chosen intelligently (by reference to literature and analysis) to produce a conclusion of professional quality, leading to a successful product.
In addition there is evidence of Structure and Story, as the post explains why these were chosen, how they were chosen, and that these will shape the development of the project.
Written by Briony.
Meeting Summary 05/03/15
Posted by Taekyun Kim in Meeting Summary, Structure and Story on 05/03/2015
Meeting Summary 05/03/2015
During this meeting the group met and discussed the project with mentor Rob Blair for the first time. This included showing the progression the group had made since the initial meeting and the next steps which had been decided. Based on Rob’s feedback the group came to the conclusion that a number of planning and research posts would be useful in the development of the project.
1. Create planning layout for the project. This could include other media such as a gannt chart. It should also allow an extra line underneath the predicted time so we can record the accurate timings, compared to the times we set for each task. This requires planning out each of the tasks step by step before making the chart. This is important for the project as time management and the identification of tasks is vital for the completion of tasks in the time scale that the group has set.
2. A blog post about methodology we are going to use for meetings and producing work (for example, agile/scrum/life cycle). This should explain that we have looked at these and have selected one according to our task and how best we work as a group. We are currently using an agile methodology as we all discuss and contribute ideas/research rather than one person focusing on a large part. This is an important consideration as it may dictate the success of our project depending on how best group members work, therefore it should be identified early on in the project.
3. A blog post about the target audience, identifying specific types of people who would find it the most useful (for example, tourists/students/people new to an area). Using literature and market research the post should identify which types of people would be willing to pay for it a safety travel app and why. It should also consider whether every user has the same needs from the map/other features. It should conclude that based on the market our app should be free. This is an important contribution to the research as the success of the product may be depended on understanding what the target audience may want from our product which isn’t already on the market.
4. A blog post defining our success criteria. This should be a list of our goals and objectives based on the marking criteria. For example we aim to produce a project that should take X amount of time. This is important to the planning stages of the project as it will provide continual structure to the narrative and will ensure that the work out-put answers the marking criteria.
This post represents that coherent structure and story are present in the portfolio which uses the entry and tags mechanism of the blog system. It tells the story of the project by explaining individual roles clearly, explaining why these were decided, and what outcome they will produce later on in the project.
Minutes by Briony Gray
Similar Applications
Posted by Emily Pearce in Contextual Factors and Research, Innovation and Creativity (Idea) on 05/03/2015
As part of the research the group conducted into the market and the features we wanted to include, the group wanted to find out what is already out there. There are huge numbers of articles referring to the best travel apps, but below is a breakdown of some applications available on different platforms and that each have a different feature that is going to be incorporated into TravelSafe. At the bottom of this posts are links to related articles from a number of different sites and contributors identifying the top travel applications.
Journi [1]
- social network for sharing posts (pictures and notes with geolocation) to a shared timeline
- can invite friends and family and send them automatic updates in real-time via web/app/email
- further sharing to Facebook and Twitter
- Apple only, Free
- weaknesses: lack of geographical ties or tagging, no offline resources, no travel information.
StaySafe [2]
- GPS tracker app that emails or texts the users exact location to emergency contacts if you don’t check-in (e.g. after working, socialising, travelling alone)
- Works with “sessions” – need to have checked in by end of session
- Apple and Android, £4.99
- weaknesses: No offline resources, no user input to improve safety ratings, expensive.
AroundMe [3]
- finds nearest restaurants, banks, gas stations, book hotels
- Apple and Windows phone, Free
- weaknesses: No real time updated information, no travel information, no offline resources.
EmergenSee [4]
- With just a click of a button, you can transmit video, audio and GPS to your selected friends and family so that they can hear, see and track what’s going on. They can alert authority if you can’t
- Apple and Android, Free
- weaknesses: No user input to improve datasets, no travel information, no offline resources.
TripIt [5]
- consolidates all your travel reservations (hotel, air, car rental etc.)
- Can share itinerary with friends and family
- Apple, Android, Blackberry, Free
- could link this to travel alerts and updates?
- weaknesses: No specialised travel tool such as a route generator, no safety ratings.
AllSubway [6]
- maps for subway and metro in cities around the world
- Apple only, 79p
- weaknesses: No safety information or tips, no offline resources, competes with paper copies in a city.
Road Buddy [7]
- checks publically available police data on criminal damage, drugs offences, public disorder and violent crime and then plots a route avoiding as many as possible on Google Map
- Firefox OS only but planning to expand
- weaknesses: No offline resources, no user input to improve datasets.
SafeRoute [8]
- US only
- Android only, 60p
- provides GPS enabled crime statistics and safety levels for every city in US providing there’s enough crime data
- Provides safety levels for each zip code in some major cities
- Also has comments from users section
- Removed from app store due to pending patent infringements
- weaknesses: Not an original app, no user input, no offline resources, no travel information.
Conclusions
It is apparent through market analysis that a majority of travel and safety apps either do not charge for use, or charge a minimal amount. Therefore in order to keep within the trend of this market TravelSafe should do this is also, which will ensure that it fits the needs of the target audience. Another key trend with the apps evaluated is that often the name of the app corresponds to the basic concept of the project in a few words or less. Again, this is another consideration for the group’s own project, which the current name TravelSafe reflects well. Finally, a noticeable trend with the apps reviewed is that none of them feature more than a couple of definable features, such as emergency contacts input or travel information. This is where the TravelSafe app will find its niche market as it will combine multiple features where existing apps only combine two or three. In order to decide on these apps however, the group has asked for expert advice to help guide the project as the success criteria dictate that the project must not be subjected to extensive qualitative or quantitative tests at this stage.
Based on the weaknesses of these apps, the group are now in a position to create a short-list of app features which other apps in the market to not appear to fully meet. A large consideration for this list is for the TravelSafe app to utilise multiple features. The combination of these features will ensure that TravelSafe is unique, and offers something more than the others on the market.
This post represents that the group has chosen appropriate economic and social Contextual Factors that directly link to the marking criteria, and are vital to understanding what requirements the product will have. These take the form of market analysis, evaluation of existing products, and identification of app features. There is evidence that these have been chosen intelligently (by reference to literature and analysis) to produce a conclusion of professional quality, leading to a successful product.
In addition there is evidence of Innovation and Creativity which is shown via tailoring the group project to address existing weaknesses of app’s in the target market. Subsequently this shows that the product has gone beyond expectations by meeting a genuine gap in a market, which leads to a commercially viable product idea.
News Articles
“The World’s 50 Best Travel Apps” – David Clack (http://www.timeout.com/travel/features/1169/the-worlds-50-best-travel-apps)
“10 best travel apps for iOS and Android” – Jessica Naziri, 2014 (http://www.techradar.com/news/phone-and-communications/mobile-phones/best-travel-app-1278014)
“Best Travel Apps for 2015” – Alexandra Talty, 2014 (http://www.forbes.com/sites/alexandratalty/2014/12/11/best-travel-apps-for-2015/)
“Top 20 best travel apps: recommended by SkyScanner” – James Teideman, 2013 (http://www.skyscanner.net/news/top-20-best-travel-apps-recommended-skyscanner)
Written by Emily.
References
- Journi, 2015, Travel Blogging rediscovered [Online] [Available at: https://www.journiapp.com/] [Last Accessed: March 2015]
- Safe Apps Ltd, 2015, Stay Safe – Smart Personal Safety [Online] [Available at: http://www.staysafeapp.com/staysafe-personal/] [Last Accessed: March 2015]
- Flying Code Ltd, 2015, AroundMe – Because you’re going places [Online] [Available at: http://www.aroundmeapp.com/] [Last Accessed: March 2015]
- EmergenSee App, 2015, EmergenSee Personal Security System [Online] [Available at: http://emergensee.com/] [Last Accessed: March 2015]
- Concur Technologies Inc., 2015, Tripit – All of your travel plans on-the-go! [Online] [Available at: https://www.tripit.com/uhp/mobile] [Last Accessed: March 2015]
- AllSubway, 2015, AllSubway [Online] [Available at: http://carmat.altervista.org/AllSubway.html] [Last Accessed: March 2015]
- Warman, M., 2013, Road Buddy mobile app plots safe routes to walk home, The Telegraph [Online] [Available at: http://www.telegraph.co.uk/technology/news/10047029/Road-Buddy-mobile-app-plots-safe-routes-to-walk-home.html] [Last Accessed: March 2015]
- GeoOasis Inc, 2011, SafeRoute, [Online] [Available at: http://www.geooasis.com/SafeRoute/] [Last Accessed: March 2015]
Project Requirements
Posted by Emily Pearce in Contextual Factors and Research, Design, Structure and Story on 04/03/2015
Requirements Gathering
As the group has undertaken the research and design aspects of this project first, with the aim of completing market research and expert opinions before implementation, requirements gathering was undertaken in group meetings by developing ideas about the potential users of our application and the functionality that would be included in the TravelSafe application. Due to the way that this project has been undertaken, these requirements are to provide an idea of the functionality and limitations of our application and may change during the market research stages. This has been influenced by background research that includes the evaluation of Similar Applications. This lead the group to conclude the most important functional and non-functional requirements for the project, which are stated below.
Functional Requirements
The system shall be able to:
- allow a user to search and select a location based on GPS data
- allow a user to select a location from a list of saved locations
- For each location, it must be able to:
- generate three point to point safe routes using area safety ratings
- provide a safety rating of a user’s surrounding area based on publicly available crime data
- provide travel information from publicly available times and map
- provide safety tips using open data from Government and police service
- provide an updated news feed from RSS feeds of news source
- download a pack of the above data that can be accessed and used offline from on-device storage
- allow users to access and search through a list of Frequently Asked Questions (FAQs)
- provide translation functionality through use of Google Translate API
- have a section dedicated to user-input information as free text
Non-Functional Requirements
The system should:
- be a web-based application
- provide a comprehensive list of help and instructions for use
- use a consistent style, layout and colour scheme throughout the application
- take all reasonable steps to improve accessibility
- be intuitive for use
- be compatible with Internet Explorer, Google Chrome, Mozilla Firefox and Apple Safari to ensure compatibility with mobile browsers
Constraints
The application will be limited by/not be able to:
- the accuracy of the GPS hardware within a mobile device
- provide external backup of data
This set of finalised criteria were chosen from the extensive discussion of the merits and drawbacks of the potential features, combined with the research into similar applications as well as project constraints such as the time available and the skillsets of the developers within the group. The group feels that the finalised requirement are representative of the type of application that is being suggested, with the quantity of features providing the unique selling point to allow the group to target a niche in the market identified during research utilising both development and time management skills of the group as a whole.
This post represents that coherent structure and story are present in the portfolio which uses the entry and tags mechanism of the blog system. It tells the story of the project by explaining individual roles clearly, explaining why these were decided, and what outcome they will produce later on in the project.
This post also represents that the group has chosen appropriate economic and social Contextual Factors that directly link to the marking criteria, and are vital to understanding what requirements the product will have. There is evidence that these have been chosen intelligently (by reference to literature and analysis) to produce a specification of professional quality, leading to a successful product.
In addition design considerations for the project have been addressed in this post. This is evident through the layout of steps that the project should include, how these have been decided, and how this will be implemented to solve a problem.
Written by Emily.