How Might We Build User Trust?

15296042291_e118c5ecda_o

As has been shown through many studies from psychology, sociology and through to philosophy, trust takes many forms but is mainly developed through the building of social relationships. Trust is therefore a huge factor when creating a social network related app and making sure individuals feel comfortable when using it.

In order to encourage users to download our app instead of many others, building trust through using a myriad of tools is important, without trust in an app there is no foundation and there is also no drive to download and to keep using an app. There needs to be some ‘proof’ that the app works, does it do what it says it is going to do and what others think it will do. Users need this added protection and reassurance that what they believe is good is actually good, as people are naturally interested in their own welfare.

The use of a social network platform for information searching and for finding travel companions must consider the emotion and behaviour associated with trust. Lewis and Weigert discuss trust as a social reality, a unitary social experience combining cognitive, emotional and behavioural facets. A Social network relies on relationships between people and trust is attributable to relationships with and between social groups such as friends, communities and organisations, therefore the need for trust arises from our interdependence with others, in a social network such as this users depend on others to help them obtain their outcomes. Rousseau defines trust as a “psychological state comprising the intention to accept vulnerability based upon positive expectations of the intentions or behaviors of another” users of the app have interests with other users that are intertwined, creating an element of risk, therefore trust is very valuable in a social network as it is associated with cooperation, information sharing, and problem solving; key features of NaviGap.

All factors must be taken in to consideration in building trust in a social web environment, these include policy-based trust, provenance-based trust and reputation-based trust. In terms of the social network NaviGap, a combination of approaches to trust need to be taken:

1.Policy-Based Trust – This approach provides security to users accessing services via signed/trusted certification authorities to verify credentials and access. Within NaviGap, we provide a privacy Policy which a formal legal agreement for protecting users information and data, that if broken can lead to prosecution. Secondly, we utilise security protocols such as public key encryption system and HTTPS protocol.

2.Provenance-Based Trust – NaviGap will employ a provenence based trust system in terms of allowing users to assess the trustworthiness of the content posted based on the history of its generation and propagation. This will mean users will have transaparancy of  who created and edited information and who reccomended and/or shared it.

3.Reputation-Based Trust – This approach establishes trust based on personal experience of users. NaviGap incorporates user ranking functionality related to their posts and recommendations, the higher the ranking of a user, the more trusted they can be provide accurate and appropriate information. It also possible for users to flag inappropriate behaviour and/or users.

Though all are important in their own right, this post will mainly be focused on reputation based trust. In order to fully gain reputation-based trust an app will need to have a reputation, it is important to build up a positive reputation in order to successfully advertise, market and then progress the app.

Some factors to consider when gaining trust from users = competence, integrity and ability.

In order to show this the app will have to be tested and critiqued. Negative reviews are not great, but they can be just as important as positive reviews if handled correctly. The way app creators deal with their negative reviews show a lot about how well they can be trusted and indeed their integrity. This will help to side-step any negative influence if it is used as critique.

 

Practical Steps

  1. Reviews

It is important for NaviGap to get app store reviews which will help to build up user confidence in the app and what we are portraying to the public. This is imperative to a new app such as ours and can really help boost our profile in the app market.

 

  1. NaviGap Logo and “About us”

 

Having a Logo will ensure that NaviGap will appear professional and trustworthy and help to show that we take ourselves and our app seriously. Also when we connect through any other app  such as Hotmail or Facebook, it is important to ensure that this is mentioned in order to also show creditworthiness through bigger and trustworthy sites.

Also it is important to be transparent with users and to show who JAMR is and why we created the app to also convey that we are credible and our not ‘faceless.’

  1. Credentials and statistics.

 

Show any credentials we have and that we are certified in areas, which will help to build trust and reliance. Also important to showcase any user surveys results and our user statistics to show that we are open with our users and that we our proud of our users and how many we have gained in a short amount of time. Can also include followers on any social networking site we gather.

 

  1. Advertisements 

Ensuring that we are well known and build up a good user base, to show potential users that others believe in our products and create social interaction and attention.

 

  1. Making sure that Legal and other Policy issues are up to date.

Ensuring user protection is paramount to ensuring trust and being open and clear about what our obligations are and how we will protect our current and potential users.

 

 http://www.huffingtonpost.com/himanshu-sareen/7-ways-to-build-an-app-th_b_7025536.html

 

Moreau. The foundations for provenance on the web. Foundations and Trends in Web Science (2009)

 

Fogg, B. J. and Tseng, H. (1999). The elements of computer credibility. In ACM CHI ’99, pg 80–87, New York, NY, USA.

 

Rousseau et al. Not so different after all: a cross-discipline view of trust. Academy of Management Review (1998) vol. 23 pp. 393-404

 

Rotter, J. B. 1967. A new scale for the measurement of inter- personal trust. Journal of Personality. 35; 615-665

 

Berg and Dickhaut. Trust, reciprocity, and social history. Games and Economic Behavior (1995) vol. 10 (1) pp. 122-142

Lewis and Weigert. Trust as a social reality. Social Forces (1984) vol. 63 pp. 967-985

NaviGap UML diagrams

In this part, we will talk about our development model views described in Unified Modelling Language. UML is a language which we will apply to describe use cases meaning the interactions of an actor (user) and a system to achieve certain goals. This is an in-between process: after we gathered all requirements and shaped our agenda and before we actually started coding.

Our app users

In previous posts, we identified our user personas. Now we can proceed and implement those personas into our interaction use cases. It helps us to identify the functionalities we want to offer to them. We don’t have to cover now the scenario of a registered or authenticated user, but we will treat as a seperate diagram.

Our app functionalities

Now we identify general functional blocks we offer for the actors (personas) aligned with activities they perform.

The First Persona is identified as a novice who comes for social value and expert advice. is clearly interested in

The Second Persona is an expert who was a novice at the beginning, but after a certain amount of contribution (posts, advice, photos etc.) became an expert (high degree of centrality) and can provide help/advice/guidance to novices.

Finally, the Third Persona is a commercial partner type of user who is interested in business add-on value.

Three iterations are needed to reach the outlined use case scope.

Figure 1. Use Case Diagram: NaviGap interaction

At this point, we can augment the Persona 1 case by expanding each functionality. For example, ‘Seek travel inspiration’ functionality:

Figure 2. Use Case Diagram: Augmented functionality

Through each augmentation iteration, we ask ourselves: is it enough? have we listed all possible functionalities that we can release? Step by step we will augment our UML layout and add blocks to each functionality. After each functionality has a detailed list of sub-functionalities we can look at it critically and think of additional features that will give us a competitive edge.

Our app communication diagram

As an example of UML communication diagram, we show the scenario when a user wants to login into their account. That provides a model-view-controller perspective of interaction.

 

Figure 3. Communication Diagram: Login

Our app state diagram

State diagrams can be seen as the essence of object-oriented programming (OOP). Those diagrams are good when we want to describe the behavior of a single object. In general, those diagrams define various states of an object during its life cycle.

A state diagram represents the actual changes in state, not the particular processes/commands creating those changes.

Figure 4. State Diagram: Novice User object

 

Why we need all those diagrams?

We assume that our team should have a clear understanding how the users interact with the App, what functionalities we are planning to offer to them and in what way they can access them. Overall, each diagram builds up a clear understanding of what is expected from the app, what role the users and other actors play in it, and helps to shape the outline of the UI design.

 

Model-View-Controller framework

When choosing a system architecture design framework for our app, we picked the Model-View-Controller model and we will explain the reasons behind that.

Historically MVC was the earliest example of Graphical User Interface design approaches since its introduction by Trygve Reenskaug  MVC into Smalltalk. It solved the problem of user control over large data sets. The idea was to create an illusion for the user that they control the data domain.

Screen Shot 2017-03-20 at 10.53.53

Figure 1. The original concept behind MVC

 Although originally developed for desktop software, MVC became largely popular for web/mobile applications architecture design.

What does MVC mean?

Model is the knowledge domain.

View is the visual representation of the model.

Controller is the link between a user and the system. Provides means for user input and produces means for user output.

MVC-basic

Figure 2. Basic MVC interaction diagram

This structure splits the architecture of an app into three interconnected parts, so that the internal representation of information and user representation of information can be separated.

For example, we can look at the Web from the MVC point of view. The model is HTML that communicates the knowledge to a user. The view is a CSS that makes the information readable and nicely represented. The controller is a browser that renders the HTML and CSS and produces an output and translates the user input into script code. From the evident statistics of the Web usage, we can conclude the MVC model works fine.

The pros of MVC

  • Simultaneous development. Because the components are separated, different teams can work with different components of an app without blocking the work of others. For example, development can be divided into back-end and front-end, whereas the latter do not need the server-side data structure to design the user interface and vice versa.
  • Reuse. Again, because of independent components, the components code can be easily reused in other applications.
  • Multiple views of a model. New features and business entities can easily fit into an existing pattern.

The cons of MVC

  • Learning different techniques. Developers have to be skilled in different technologies and multiple coding techniques.
  • Complex design pattern. Although the main concept is quite straight-forward, the structure of each component can get very bulky and complex.

We conclude that the MVC design pattern is aligned with our design and development core.

Screen Shot 2017-03-20 at 10.47.26

Figure 3. The NaviGap MVC design pattern

We have chosen to use Django python web framework because it is open-source, free and is targeted at highly-loaded database-driven applications. Django web framework is viewed as an MVC architecture. The Model is an object-relational mapper assisting connection between data python classes and a relational database. The View is a system processing HTTP requests and the Controller is the URL dispatcher. Also, we will be using AngularJs to extend the capabilities of declaring dynamic views in our mobile app.

In short, we have a layout of planned works to be done.

Process plan:

  1. Building RestServices using Django & DjangoRestFramework
  2. Building MobileApp
  3. Integration of AngularJS and Webservices
  4. Deployment

Using open-source frameworks and environments not only reduces our costs of production, but provides opportunities for collaboration, and expertise from the developers’ community.

NaviGap Development Costs

NaviGap Development Costs:

The primary factors that we see as influencing the development costs of NaviGap include:

  1. Monetisation Model
  2. Platform
  3. Functionality
  4. Design
  5. Research
  6. Developer

1.Monetisation Model

It would be easier and more straight forward to create an app that is simply sold for a fixed, upfront price as opposed to one with In-app purchases that will require continuous updating to the software. We have decided on a blend of models that will include in app purchasing therefore long term costs of development need to be factored in.

2. Platform: Android Or Apple

iphone mapIt is possible to build an app that is accessible on a number of devices: iOS (iPhone and iPad), Android, Windows Phone, the Web or one that can be used on all of them. The price of development will vary accordingly. At this stage we are only considering mobile apps however, and therefore our options are either Android or Apple. We have determined that our app is to reach a demographic of 18-25 years olds so JAMR researched which platform would best suit this.

Image from blog.mobiscroll.com.

Each one of the aforementioned platforms requires a particular programming language, different development environments and programming models based on platform-specific APIs. For example, developing applications for Android requires Java, while developing applications for iOS requires Objective-C. It is apparent that, if a company decides to support both Android and iOS platform, there is a constraint to maintain two versions of a single product: one version implemented with Java for Android and a second version implemented using Objective-C for iOS. Mobile cross-platform tools (CPTs) provide an interesting alternative to native development. Cross-platform tools aim at sharing a significant portion of the application codebase between the implementations for the different platforms. This can drastically decrease the development costs of mobile applications. (Willocx ,Vossaert , Naessens, 2016).

JAMR intends to use a CPT to generate an app for both IOS and Android.

 

3. App Types & Functionality

The technical specifications of the app will be the single biggest factor in its cost. App types down into the following four categories:

  1. Table/List – designed primarily to display a relatively simple collection of information
  2. Database – designed to allow users to find, sort, and display data from data sets
  3. Dynamic – designed to cooperate with other platforms and software via APIs.
  4. Games- designed to be dynamic and have advanced features.

The more complex the functionality, the expensive the corresponding development cost will be. Quotes will need to be solicited from multiple developers, however, JAMR plans to develop the app ‘in house’ using our teams software development skills thus reducing the cost of development.

 

4. Design:

The design is an important feature of the App, particularly in terms of attracting a user to the initial download since customers are attracted by an icon and/or design. Similarly, design can make them want to use the app more, NY Times 2015.

A compelling design generated from a proven design team with a consumer-tested portfolio, could be very expensive. JAMR need to budget and prioritise based on the young person target audience who potentially are very design sensitive, therefore priority will be given to a high end design.

 

  1. Market Research:

The traditional questionnaire survey incurs a great human and financial resource. Whereas an online survey system could immensely cut the costs of questionnaire printing and labour in terms of service fees for interviewers, travelling expenses and data entry fees with a fixed cost will be paid that includes questionnaire design fees, network expense and data analysis service fees.

Other advantages of web-based questionnaires are:

  • Automation and real-time access.  Analysis is easier, and available immediately.
  • Convenience.  Respondents can answer questions when they want.
  • No interviewer.  No influence from the interviewer, means less bias.
  • Target PopulationThe sample may prefer just online surveys.

Therefore, a web-based questionnaire could replace the traditional paper questionnaire with minor effects on response rates and lower costs, potential disadvantages being a lack of respondent cooperation in terms of internet uses receiving lot of feedback requests, and the lack of interviewer to clarify respondent queries could mean that data collected is less reliable. (Hohwü, 2013).

 

6. Developer: Freelancer vs Agency

Different apps vary widely in developmental cost and there are 3 basic categories of developers you can choose from:

  1. Freelancer – affordable option
  2. Small agency – specialists in specific areas
  3. Large agency – big brand guarantees

Clutch surveyed representatives from 12 leading mobile application development companies to determine cost ranges of building an iPhone app and the key variables of cost and found that the median cost  range is between $37,913 and $171,450, but could be as much as $500,000.

NaviGap however will be using JAMR’s ‘in house’ software developer on this project.

 

Hohwü, L., Lyshol, H., Gissler, M., Jonsson, S. H., Petzold, M., & Obel, C. (2013). Web-Based Versus Traditional Paper Questionnaires: A Mixed-Mode Survey With a Nordic Perspective. Journal of Medical Internet Research15(8), e173. http://doi.org/10.2196/jmir.2595