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

Agile versus Waterfall

        main-qimg-58816439e3c075a5b8bebbba6131cf5b-c

Figure 1. How Projects Really Work

In this post, we would like to discuss how we envision our development process philosophy and which approach we plan to use. As can be seen in Fig.1, the vision of a project is not always the same (completely different) to its final release. Thus, it is very important to choose the appropriate development strategy and stick to it during the project’s lifecycle to deliver the best solutions.

Different approaches

In the case of web development process, there are generally two approaches: waterfall and agile. What are the main differences between them?

  • Waterfall process is when each part of the project is done sequentially by a team member and passed along the assembly line after the part is finished.
  • Agile process is a simultaneous working approach when each member of a team contributes to the project in the same time frame.

In short, here is a simple explanation of both:

 Video 1. Workflows: Agile vs. Waterfall

After considering the pros and cons of given approaches, we chose the agile model for the following reasons:

  • Short iterations (time frames) of development work mean fast delivery and constant up-to-date with current issues. Our product is for young and innovative people and we need fast solutions for emerging problems, and small increments of work provide convenient development pace for our product.
  • Our small team has representatives from all stakeholders, so conducting Scrum meetings would be an efficient collaborative process where interests from each side are not neglected.
  • Feedback is prompt and corresponds with each iteration directly.

Q. How does it work on a daily basis?

A. Scrum Power!

Video 2. Short explanation how Scrums work

We will be using the Scrum Agile methodology as it has proved to be effective and applicable to various project types.

Basically, each of our sprints (a specialized term for iterations) will consist of several steps:

  1. A product owner  –> creates –> a to-do list with noted priorities which is a product backlog.
  2. The team –>takes–> a small piece of that to-do list from the top, and discusses implementation.
  3. Our sprints –>last–> 3 to 4 weeks to complete that piece.
  4. Meanwhile, the team—> has –> daily scrum meetings to discuss and assess the progress of work to be done.
  5. The ScrumMaster —>is–> the master brain behind those organised scrum meetings. They keep the team aligned and focused on the goals.
  6. Each sprint —>ends —> with a deliverable product, thus showing an achieved goal to a stakeholder.
  7. A sprint review and retrospective —> complete the cycle of each sprint and maximise the feedback effect in order to improve a next sprint delivery.
  8. A new chunk of backlog is taken into work and the iteration cycle starts from Step 1.

 

In our vision, Scrum is a flexible and efficient web project management framework which enables the team to react more quickly and respond more accurately to the arising issues. Scrum’s holistic nature minimizes marginal risks and allows our App product to adapt to changes just in the right time.

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.