App Feature: Safest Route Generator

During the initial designing phases for the TravelSafe app we came up with the idea of a ‘Safest Route Generator’ as a prominent feature which no other safety apps on the market offer. The idea is for a map routing algorithm to take into account other data sets, such as crime statistics of an area, before generating a suggested route path from A to B. It would then use social networking to generate it’s own data using a user’s experience to rate the routes, thus generating a ‘safety’ rating that could be incorporated into the algorithm. However, for this feature to work comprehensively there are a number of considerations to take into account which this blog post will explain and evaluate. These include a literature review to understand the mapping market in greater detail, what limitations exist for mapping algorithms and networks, existing examples of route generators, how routes may be ranked, a proposed methodology for our Safest Route Generator and finally a discussion of the network and predicted outcome of the feature based on all of the above.

 

1.0 Map Routing Algorithms

During the ‘Information Age’ the functionality of mapping Applications (apps) has increased dramatically (Pascalau, 2011). The range of uses that computing is applicable to is largely responsible for this, which extends to logistics planning, traffic simulations and shortest-path queries (Pascalau, 2011). Route generators were originally based on adapted simplified algorithms, such as Dijkstra’s algorithm in 1956, which finds the shortest path between two nodes in a graph (Jasika et al., 2012). As technology evolved along with our understanding of the more complex aspects that may shape a route, such as traffic or vehicle type, so did the algorithms used to calculate them (Jasika et al., 2012).

Modern algorithms take into account huge volumes of data and metadata (Sander and Schultes, 2007). Unlike Dijkstra’s basic algorithm they aren’t looking simply for the shortest route anymore – they’re looking for the best route available (Sanders and Schultes, 2007). This allows for companies and individuals to tailor their mapping software and route generators to a specific use or cause by placing a higher priority on the influencing aspects that they consider essential to their own project (Quercia et al., 2014). As mapping is a vast industry there is a multitude of factors that may potentially be considered for any one project, these include:

  • Length of route
  • Geographical features
  • Understanding what the target audience needs from the map
  • Ease of use from the platform
  • Type and quality of supporting datasets
  • Form and complexity of route instructions
  • Type of vehicle/on foot options and impacts
  • Off-limits or privately owned land taken into consideration

In addition to routing, networks play a key role in the generation of map routes in mapping apps (Bishop et al., 1998). Networks are the connections of nodes and links that form graphs, and similarly they have developed over-time to incorporate the evolution of algorithms, consumer need and technology (Bishop et al., 1998). Nodes specify which links connect to them and vice versa, which then creates a graph to traverse (Bishop et al., 1998). Particularly in the mapping industry, geographic Face Routing is commonly used, shown in figure 1 below.

Georouting_face_routing.svg

Figure 1.

In this example, a message is routed along the interior of the faces of the graph, with face changes at the edges crossing the S-D line (shortest distance). The final path is shown in blue, illustrating how the network deciphers the shortest route based on that particular network (Finn, 1987).

 

2.0 Problems and Limitations

Despite a number of general and more specific routing methods currently employed in the mapping market, it is important to note that the dominating players, such Tomtom, do not publish the intricacies of their software or methodologies (reference). As such a majority of companies who wish to produce a similar product or app are forced into three main categories: They can either buy the research and information from an existing company or product, invest large amounts of money and man-power into researching and building a network for themselves (which holds no guarantee of being better than the existing ones), or utilise free open data and open access software such as OpenStreetMap (reference). In addition to this problems also arise from the inconsistencies of geographical data that are being used (Kray et al., 2003). This may due to a number of issues, such as:

  • Maps are very complex, diverse and sometimes full of geometrical inconsistencies.
  • It is difficult to define what a “relevant manoeuvre” is. Some users might want to hear a “Go straight” instruction at each crossing, whereas other would not.
  • Lack of consistent network data
  • Lack of interoperable networks between countries
  • Lack of off-road networks which makes some transport methods difficult to create

Despite a number of these problems being applicable to a large number of mapping applications, there are projects that are continuously working to solve these limitations (Kray et al., 2003).

 

3.0 Existing Examples on the Market

There is a plethora of existing apps and sites that create, use and demonstrate route generation in a mapping software. They do this through varying methodologies, datasets, networks and algorithms, which all aim to tailor their own service for a specific task (Kray et al., 2003). In order to understand how the TravelSafe app can compete in this market, three contrasting products or services have been chosen to evaluate with regards to the previous literature review. These are, TeleAtlas (TomTom), HappyPaths (Yahoo) and OpenStreetMap (Google).

 

3.1 TeleAtlas (TomTom)

TeleAtlas is a patented software that was bought by TomTom, the satellite navigation company, in 2008. They have released a diagram illustrating the process of data collection from multiple sources that is shown below in figure 2 (www.tomtom.com/en_gb/licensing/).

tomtom-data-collection_tcm131-22215

Figure 2

As shown above the company generated the data for TeleAtlas themselves using significant investment and man-hours in a diverse range of methods. This generated the basis for a wide selection of maps and services that the company offers on their site, of which a majority are pay-for-access only. TomTom specialise in simplifying travel for vehicles, which ranges from everyday use for the public to larger cliental who use the software and technology for shipping goods. This model works well for TomTom, as they rely on selling technology, such as SatNav’s, with their software pre-installed on devices. In contrast, TravelSafe is not intended to be installed on devices before they are to be bought, rendering this business model insufficient for our needs.

 

3.2 HappyPaths (Yahoo)

Yahoo’s new project, HappyPaths, is designed to build on the development of shortest route maps, as they believe routes with the option of highly extensive tailoring will be the future of the mapping market (Quercia et al., 2014). The goal of HappyPaths is to automatically suggest routes that are not only short but also emotionally pleasant. To achieve this they have used data from a crowd-sourced platform that shows street scenes in London (as the example city). A user then votes on which route looks more visually appealing, turning these votes into quantitative measures of locations in the network. The locations are then arranged on a graph which highlights the most visually pleasing routes.

Although this methodology places highest priority on route aesthetics rather than the shortest distance, Yahoo found that the recommended routes are only marginally longer than the shortest ones on average. This corresponds to similar study by Duckham and Kulik (2003), who discovered that placing the highest importance on path simplicity rather than shortest route produced routes that were on average only 10-16% longer than the shortest route available. This would be a valuable and applicable methodology for the Safest Route Generator for the TravelSafe app, and would allow for the aspect of Safety Rating to be the prioritised influencing factor in the route generations.

 

3.3 OpenStreetMap (Google)

Arguably Google are the dominant player when it comes to mapping in the modern age. Unlike a majority of the mapping market, Google’s OpenStreetMap is a collaborative project to create free editable maps in order to combat the dominance of closed, licenced or patented data and data processing (Haklay and Webber, 2008). It does not seek a profit, but does not however offer a tailored service for a specific target audience. Rather than the map itself, the data generated by the OpenStreetMap project is considered its primary output. This data is then available for use in both traditional applications, such as Craiglist, OsmAnd, Geocaching, MapQuest, Open JMP, and in uncommon uses such as to replace Google Maps, and to replace default data included with GPS receivers. For software in order to generate the Safest Route Maps, OpenStreetMap is the most viable solution to the problem of funding.

If the project were to use one of the two other options for mapping (either buying the research and information from an existing company or product, or investing large amounts of money and man-power into researching and building a network for oneself) we would severely impair the reach and commercialisation of app. By utilising open data and software the app would be virtually cost-free, and in a market where the majority of mapping apps are free this would be an extremely important aspect to the target audience.

 

4.0 Our Feature Proposal

Taking into account the literature and existing examples in the market, the TravelSafe Safest Route Generator is not only a plausible idea, but represents a transition from shortest-route mapping to the innovative trend of tailored routes and networked data. In order to keep the app free it will utilise OpenStreetMap software from Google, which will then be tailored using methods employed by Yahoo’s HappyPaths. The tailored routes will take into consideration safety rating as the highest priority, which will initially be generated from existing open data such as Direct.Gov.UK’s locational crime statistics. At the end of a route, a user will be prompted to answer the question ‘How safe did you feel while travelling along this route?’ answerable by a score out of 10. This data can then be anonymously collected, generating more accurate networks for the route generator to incorporate.

The Safest Route Generator will take into consideration ethical aspects regarding the use of the app, as it is possible that an individual may use the app to pinpoint locations where travellers are being directed, making it easier to commit a crime. Consequently, the generator will produce three possible routes for the user to take, making safety tips and warnings clear, such as ‘Do not always select the shortest route of the three calculated routes’. Further ethical aspects have been considered regarding the cost of the app, which will be free for use. Not only does this fit in with a majority of the mapping market, but also promotes good company and individual ethics which does not charge and individual for wanting to feel safe.

It is important to bear in mind that the platform specifications, clarifications of external data sets, and how user-generated data sets will update in real time are to be discussed in future posts, after further research.

 

5.0 The Networked Aspect

By encouraging a user to input data regarding the safety of a route, TravelSafe is incorporating a social networking solution to the problem of static and basic route generation in apps – this is something which no other mapping app on the market offers. Furthermore, the database generated by user input will form an intricate socially influenced network, allowing for a more complex and tailored route generation system that takes into consideration specific user needs. This will improve the nature of social network infrastructures in both travel and mapping apps in an innovative way, and encourage the shaping of technology by social need.

The generation of user input will develop aspects of trust associated with social media and human/computer networking, which is becoming an increasingly prominent feature of apps and websites (Gligor and Wing, 2011). The formation of user trust (also emotional trust, and similarities to yhprum’s law covered in the lecture materials) in knowledge transfer within the network of the app will cultivate a strong image of reliability, which studies argue is a necessity for the creation of viable and reliable knowledge, and the transfer of this (Levin and Cross, 2004).

In keeping with the findings of Duckham and Kulik (2003), user interaction will be in the simplest format thus warranting a larger number of participants.  Once the generated data set regarding safety ratings has reached a reasonable size, the app may potentially offer a more in depth review process in a similar format to TripAdvisor in future developments. We anticipate the more in depth review process to be an aspect offered between 9 and 18 months after the launch of the app, as Kray (2003) suggests this is the optimal time for mobile-based apps to generate enough usability and social networking connections.

Written by Briony.

 


 

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 a specific app feature has. This is based on market analysis, evaluation, and expert opinions. There is evidence that questions that the app feature has been chosen intelligently (by reference to literature and analysis) to produce a conclusion of professional quality, leading to a successful product. 

This post additionally represents Engineering and Design decisions. These are based on the Contextual Factors and literature review which the group have tailored the product to incorporate. This means that the app feature has considerable research, fluent design and well planned out engineering steps. All of which are apparent in this post, and are also illustrated with media. This app feature dictates future engineering steps, illustrates how and why the product has been influenced in its design, and shows how engineering this app feature will solve problems. 


 

 

References

Bishop, C. M., Svensén, M., & Williams, C. K. (1998). GTM: The generative topographic mapping. Neural computation10(1), 215-234.

Duckham, M., & Kulik, L. (2003). “Simplest” Paths: Automated Route Selection for Navigation. In Spatial information theory. Foundations of geographic information science (pp. 169-185). Springer Berlin Heidelberg.

Finn, G. (1987). Routing and Addressing Problems in Large Metropolitan-Scale Internetworks. University of Southern California, ISI/RR-87-180.

Gilgor, V., Wing, J., (2011) Towards a Theory of Trust in Networks of Humans and Computers. 19th International Workshop on Security Protocols, Cambridge, UK

Haklay, M., & Weber, P. (2008). Openstreetmap: User-generated street maps.Pervasive Computing, IEEE7(4), 12-18.

HappyPaths (2014) [online] available at http://arxiv.org/abs/1407.1031

Jasika, N., Alispahic, N., Elma, A., Ilvana, K., Elma, L., & Nosovic, N. (2012, May). Dijkstra’s shortest path algorithm serial and parallel execution performance analysis. In MIPRO, 2012 Proceedings of the 35th International Convention (pp. 1811-1815). IEEE.

Kray, C., Elting, C., Laakso, K., & Coors, V. (2003, January). Presenting route instructions on mobile devices. In Proceedings of the 8th international conference on Intelligent user interfaces (pp. 117-124). ACM.

Levin, D. Z., & Cross, R. (2004). The strength of weak ties you can trust: The mediating role of trust in effective knowledge transfer. Management science,50(11), 1477-1490.

Pascalau, E. (2011). Towards TomTom like systems for the web: a novel architecture for browser-based mashups. In Proceedings of the 2nd International Workshop on Business intelligencE and the WEB (pp. 44-47). ACM.

Quercia, D., Schifanella, R., Aiello, L. (2014) Social and Information Networks (cs.SI). Computers and Society (cs.CY); Physics and Society

Sanders, P., Schultes. (2007) Engineering Fast Route Planning Algorithms. Universitat Karlsruhe, Germany.

TomTom satellite navigation company website (2014) [online] available at http://www.tomtom.com/en_gb/licensing/

 

 

, , ,

No Comments

Determining the App’s Platform

Web-based or mobile-based application?

A vital consideration to our project is determining which platform to use, as it is generally considered that this has strong implications on usability, ease of use and who might use the app [3]. Based on market research and evaluation of similar apps, there tends to be a wide range of platform usage. This means we are free to choose a platform that suits our app the best, rather than being restricted by what is considered to be a market normality. Firstly, we should compare platforms, and secondly we will conclude with which suits our project the best.

A web application is a piece of software that runs on a web browser (mobile and desktop), written with any of various browsers supported programing languages [1] while mobile applications are software designed to run on mobile devices [2]. Mobile applications are required to be installed and usually platform or operating system specific; mobile apps designed to run on one OS cannot run on another OS without significant changes to the software due to difference of source code programing language etc.

One of the main advantages of web applications is that they run without distributing or installing any software[1], mobile applications on the other hand provide access to the innovative features of mobile devices such as location services, network services, camera, microphone etc. that extends the operability of the application in more useful ways than it is, on a web app. The ubiquity of mobile computing which has shown no signs of slowing[5], makes it important for applications to have mobile versions, while this can be capital and resources intensive it also has the potentials to reach a maximum number of users.

After a careful research of the deliverable features of TravelSafe, the group decided to start it off as a web application with APIs that mobile versions of the application will be incrementally built around. An Application Programming Interface (API) is a way for an application to use and/or exchange data with other applications over the internet [3], some applications like Facebook open their APIs for free while other are rather closed for reasons beyond the scope of this post. TravelSafe will make its data available via an API, which will be used to design the mobile versions of the app for all the popular mobile operating systems as well as extending the functionalities of the web [4].

The TravelMate Web based application will serve as a data and user configuration repository, a separate post has been made on this blog about TravelMate’s data sources (click here), please refer to that post for more details. We are aware that the web version of this application will be limited in implementing the neat granular “Nice to have” features such as voice commands, location detection etc. however it will implement all of the important features such as safest route generation, Alert Pushouts etc. The mobile version of TravelMate will then use the data provided by the web version’s API to extend the functionality of the application by adding all the “nice to have” features listed above, this way we reach a wider population in a very limited time.

 


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 technological platform. This is based on market analysis, evaluation of existing app technology, and identification of platform limitations. 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. 

This post additionally represents Engineering decisions. This is based on the Contextual Factors and literature review the group have tailored the product to incorporate a platform which has been identified as being useful, technologically reliable and with ease of access. This dictates future engineering steps, illustrates how and why the product has been influenced in its design, and shows how engineering may help solve problems.


 

Written by Ashiru.

 

References

[1] Wikipedia, ‘Web application’, 2015. [Online]. Available: http://en.wikipedia.org/wiki/Web_application. [Accessed: 07- Mar- 2015].

[2] Wikipedia, ‘Mobile app’, 2015. [Online]. Available: http://en.wikipedia.org/wiki/Mobile_app. [Accessed: 07- Mar- 2015].

[3] Toptal Engineering Blog, ‘Developing Mobile Web Apps:  When, Why, and How’, 2015. [Online]. Available: http://www.toptal.com/android/developing-mobile-web-apps-when-why-and-how. [Accessed: 05- Mar- 2015].

[4] Apievangelist.com, ‘API Evangelist ·’, 2015. [Online]. Available: http://apievangelist.com/. [Accessed: 05- Mar- 2015].

[5] Cambridgescholars.com, 2015. [Online]. Available: http://www.cambridgescholars.com/download/sample/58105. [Accessed: 26- Apr- 2015].

, , ,

No Comments

Meeting Summary 19/03/2015

Meeting Summary 19/03/2015

During the meeting the group discussed with Rob the app feature posts that we have made in order to receive some feedback and improvements to make. Rob provided some grammatical corrections and layout suggestions that each member will change for the next meeting.

For the next meeting

Following on from the corrections individuals have made to the feature posts, each member should put a copy of their post to the shared googledrive in order for the rest of the group to proof read. Each member should also think about what tasks would contribute most to the success criteria when considering planning the design steps for the product. This may include how usability can be illustrated through design, existing design theory for apps or consider wider tools, papers or theories on design.

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.

, , , ,

No Comments

Determining the TravelSafe App Features

Based upon the literature review, expert opinions and advice, and group consensus we have made a shortlist of the features the App will have. The list below represents the features that are deemed to be the most important and useful for a travel safety app:

  1. Safest route generator (with an option for an individual to rate the route)
  2. A safety rating of the area (used to calculate the safest route)
  3. Travel information updates from other services (e.g. bus timetables)
  4. Safety tips for travelling based on location (e.g. taking into account cultural differences)
  5. A downloadable travel pack for offline use
  6. Web and Mobile based application

Consequently, each member of the group has selected a feature that they are interested in, or have knowledge about, and will write a literature outlining the current market of the App, its functionality, and how it will be utilised to best effect in the TravelSafe App. It is important to bear in mind that each of us have deadlines for other modules during this period, and so posts to the blog may be staggered.

 


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 app features, 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. 

Based on the Contextual Factors and Expert Opinions the group have tailored the product to incorporate app features which have been identified as being useful, innovative and original. This dictates future engineering steps, and illustrates how and why the product has been influenced in its design. 


 

Written by Briony

, , , ,

No Comments

Scope of the App

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.

, , , , ,

No Comments

Expert Opinions and Advice for App Features

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. 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.

1 opinion

Expert opinion number1 – Michael Gordon. Please click to read.

 

 

2 opinion

Expert opinion number 2 – Christopher Gutteridge. Please click to read.

 

 

Expert opinion number 3 - Andrew Day. Please click to read.

Expert opinion number 3 – Andrew Day. Please click to read.

 

Expert Opinion 4

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 Marketing25(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.

, , ,

No Comments

Determning a Project Methodology

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).

 

METHODOLOGY - FIGURE 1

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

, , ,

No Comments

Target Audience and Pricing

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

  1. 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/]
  2. 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.

, , ,

No Comments

Meeting Summary 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.

, , , ,

No Comments

Meeting Summary 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.

, , , ,

No Comments