Archive for category Mockups and Ideas

Blog Summary – Sami

  • This blog has been categorised according to the mark scheme.

The table below shows which blogs we believe apply to each different area:

Blog List

Blog Posts

Welcome and project brief

A New Intelligent Way of Managing Events – Sami

Analysis of existing similar tools

Analysis of existing similar tools Part 1 – Why our idea has a unique perspective! – Someah & Sami

Analysis of Existing Tools – Part 2 – Sami

Related academic work

Related Academic Work – Sami

Links to related news items in the tech media

Links to Related News Items in the Tech Media: Events Everywhere – Jokha & Sami

Interviews with users or focus groups

Survey Design – Sami

Using a Qualitative Method to get Feedback on our Social Networking Application Idea – Sami & Someah

Survey Results – Sami

Mockups and Ideas

Application Refined Version 2.0 – Sami

Business Model – Jokha & Sami

Application Refined Version 3.0 – Sami

Data Legal Challenges – Someah, Jokha & Sami

System Flow Diagram – Sami

Branding – Sami

Mockups – Sami

Application Refined Version 4.0 – Sami

Application Refined Version 5.0 – Sami

Scenarios and Personas

Business Events – Sami

Pleasure Events – Sami

Business Use Case Scenarios & UML – Sami

Pleasure Use Case Scenarios & UML – Sami

London & Southampton Scenarios – Someah & Sami

Web maps and Storyboards

Storyboard – Jokha

Storyboard 2 – Jokha

Storyboard 3 – Jokha‎

Tech demos and code snippets

SPARQL & Pseudo Code Example – Sami

UML diagrams

Business Use Case Scenarios & UML – Sami & Someah

Pleasure Use Case Scenarios & UML – Someah & Sami

Overview of standards and protocols

Standards & Protocols Overview – Jokha & Sami

Link to demo software

Mockups – Sami

Video of software in action

Advertising Video – Sami

Testing data

Open Data Within Our Application – Someah, Jokha & Sami

SPARQL & Pseudo Code Example – Sami

Outcomes of usability evaluation

N/A

Overview of pitch to dragons den panel

Overview of Dragons Den Pitch – Sami

 

, , , , , , , , , , , , , ,

No Comments

Application Refined Version 5.0 – Sami

This blog will make clear which elements of our application will be included from the outset, and which elements are future considerations:

Building on the previous post Application Refined Version 4.0 – Sami which focused on the features of our initial application, this post will look at how the initial application of Koh.Tu.Me will be used to make money.

Our initial application will make money in the following ways:

  • Free app with advertising revenue.
  • Booking referrals (from taxi companies).
  • Purchased app with no advertising.

Once our app gains popularity and users then we could progress to these methods:

  • Premium business service.
  • In app purchases.
  • Ticket purchases within the application, with booking referrals.

Therefore to summarise, our initial version of Koh.Tu.Me will be focused on the social, purely built on Open Data, with minimal setup costs and complexities. The main complexity will be associated with handling the different types of Open Data that need to be correlated for the travel organisational element.

 

, , , , , , , , , , , , , , , ,

No Comments

Data Legal Challenges – Someah, Jokha & Sami

Personal Data

Cookies
Cookies are used to store data for an application for re-use, such as login information so that the user doesn’t have to login every time they want to use the application. Initially in our application cookie use will be optional, as the user will be able to select if they want to be “remembered” for their login, and if so a cookie will be created to store their login details. Upon doing this the user will be informed that to use this option they must accept the use of a cookie to store this information. If our application progresses to using cookies in other places such as for advertising, or to remember event preferences then the standard cookie banner will be shown in the application, informing the user that our application uses cookies and that to keep using the site implies acceptance of this policy. The other way that cookies will be used in our application is to store events for users that don’t wish to create an account. Users who do not wish to create an account will have the option to “active events” that they are sent via a link. Upon activating the event the application will ask if the user wishes to store this event using cookies so that a record of their events can be stored on their computer and specific browser, ensuring continuity on using our application without needing to create an account.  The cookie message in all cases will link to our privacy policy, which will also detail the users in how to remove our cookies if they wish.

Privacy Policy
Our privacy policy will state what data we are storing about a user. Our application, unlike many other social networking application isn’t centered around collecting masses of user data. The main pieces of data our social networking application wants to look at is, name and friends list, and that is the only data that will get stored on our application about each individual. This will be stated in our privacy policy. Our application offers login via Facebook, Twitter and Google Plus, and again all it will request via those logins is name and friends list, and it will get the user to agree to those permissions [2].

Advertising & Data Privacy
Our social networking application will use advertising (unless you choose to purchase an advert free version). However, this advertising will NOT be based on stored user data, and data will NOT be passed along to any third parties. Advertising (as stated in our Business Model blog [3]) is not targeted towards the user, but is targeted towards the event, and will be shown to the attendees of certain events. E.g a restaurant based event might show adverts of offers for that restaurant, or similar restaurants near to that location. This is still targeted advertising towards the interest of the group, without targeting individuals, and this data will not be stored once the event has occurred.

Travel & Weather Data
Obtaining travel data could prove both challenging and expensive. If we locate some data that is flagged as “non commercial use” or “private use only” then clearly it cannot be used within our application and then distributed to the public. Additionally we may find that different data sets have different licenses, and then there rises the issue of how do these licenses combine? In order to combat this Koh.Tu.Me will be using entirely Open Data for it’s travel and weather data. Open data is licensed under the Open Government License [4] which means that it is free to use within our application, thus ensuring that not only would this save us money, but that we could use as much of the data as we wanted, in whatever way we need to.

References
[1] http://www.cookielaw.org/the-cookie-law/
[2] https://developers.facebook.com/docs/facebook-login/permissions
[3] https://blog.soton.ac.uk/criticalmass/2014/03/12/business-model-jokha-sami/
[4] http://data.gov.uk/blog/new-open-government-license

, , , , , , , , , ,

No Comments

Application Refined Version 4.0 – Sami

After analysing the results of the survey it became clear that the most popular aspect of Koh.Tu.Me was the more social aspects of the event. Whilst the questions asked about the appeal of the business features gave some promising results, the highest results were given to the elements of inviting friends who aren’t on social networking, and creating that inclusive travel feature. It is also important to point out that only half of our participants were actually working professionals in the first place.

Taking this into account, the first version of our application, whilst still offering a Business/Pleasure event classification, will include the five primary social features proposed for social events in our survey.

  • Being able to invite friends to events irrespective of whether they are on a social network or not.
  • Being able to sign in with Facebook/Twitter/Google+ Accounts.
  • Receiving travel planning advice about getting from A to B, and money saving advice.
  • Being able to travel in a group to the same place.
  • Receiving information about the best companies to use to organise travel.

Ideally if Koh.Tu.Me is successful and gains popularity, then we will add in the additional ‘professional’ services, which will also allow us to provide a free social service, and a premium business service.

 

, , , , , , , , , , ,

No Comments

Mockups – Sami

This post shows some mockups of what Koh.Tu.Me would look like on a smartphone.

1. This is the login screen of Koh.Tu.Me. This allows users to login if they have created an account, or to login with their Facebook, Twitter or Google+ account. Whilst people may receive event invitations without an account, it is necessary to have an account to create an event. Alternatively, if you do not wish to login to the application if you don’t have an account you can skip this stage.

Mockup1-Login

 

 

2. This is the create event page, it is pretty simple, and requires a name, details, type of event (business or pleasure), the date (including start and end time) and whether it is private or not.

Mockup2-CreateEvent

 

 

3. This is the first stage of the invite friends part of the event. This page allows users to invite friends from their different social networking accounts, their Koh.Tu.Me account, and additionally other friends who don’t have a social networking account.

Mockup3-InviteFriends

 

 

4. This is the invite friends stage for if a user has opted to invite friends who aren’t on a social network. This allows them to either list email addresses to send share links to the event to, or provides a share link directly to copy and paste to their friends however they see fit.

Mockup4-InviteFriends

 

5. This is the select travel page, it allows users to choose their primary method of travel to the event.

Mockup5-Travel

 

 

6. This is the activate event page. It is for people who are invited to an event but do not wish to create an account. They can use Koh.Tu.Me to ‘activate’ their events within the app, as an easy way to see that specific event information and interact with the other people who have been invited to this event.

Mockup6-Activate

Created by: https://www.fluidui.com/

, , , , , , , , , , , , ,

No Comments

Branding – Sami

This post will detail the name and branding for our application.

We wanted to go for a simple catchy name, that wasn’t too difficult to say and that ideally had a meaning behind it. Thus we decided that our social networking application would be called Kohtume, which is estonian for “meet me at the” [1]. It also sounds a bit like “go to me”.

The main logo will look like this:

Screenshot 2014-03-27 18.38.00

The logo icon will look like this:

logo2

These were chosen because we wanted the logo to be simple and illustrate our name, and based on Facebook and twitters branding, simple text based logos seem to be the fashion for social networks. We chose a bright purple to reflect “fun” [2] as that is a main purpose of our application.

This branding and colour scheme will be used in our mockups to illustrate how our application will look.

Additionally the domain kohtu.me is available [3], as we wanted to pick a name that had an available domain so our application would be easily searchable on the Web, and wouldn’t be confused with any other applications under the same name.

[1] http://mymemory.translated.net/t/Estonian/English/kohtume
[2] http://www.colorcombos.com/color-purple-article.html
[3] https://www.123-reg.co.uk/order/domain?X-CSRF-Token=a49f26b5c99f63ef2a1c9efca76486b2dd692f8e&domain=kohtu.me

, , , , , , , , , ,

No Comments

System Flow Diagram – Sami

This blog illustrates some basic flow diagrams of our system.

Main Flow Diagram
This diagram shows the main functions of the system. If you are a logged in user, then you can manage your friends and create events. If you choose not to login, then you can activate events that you have been invited to. All users can accept event invitations and thus organise their travel within the group.

Screenshot 2014-05-01 18.02.53

Travel Flow Diagram
This diagram shows a breakdown of what happens in the organise travel module of the system. The user is shown their different transport options and asked to pick their preferred method, and they can check to see if (depending on the method) it is weather appropriate. For example if they were considering walking, and the weather forecast showed rain, then they might wish to reconsider. Equally if they were considering taking a taxi and the weather forecast showed lovely sunny weather, they might consider walking instead. Once the user has selected their transport method of choice, they will be shown other users that are also taking that transport option.

TravelFlow

Event Flow Diagram
This diagram shows a breakdown of what happens inside the manage events module of the system. The users can view their accepted events on a calendar, and their event invitations that they have yet to respond to. They can change their invitation status (aka accept invitations that are outstanding, or change their attending status if their plans change regarding a specific event). Both users who have accounts, and don’t have accounts have the potential to do this. If a user does not wish to create an account they may still keep a record of their events in the following two ways: if they are using the mobile app version of Koh.Tu.Me then it is possible to activate your events within an app, and have those events tied to the app id as opposed to a specific user. That way a user could download the app, activate their events on it, keep that data stored, without ever having to create an account or share any personal information. Being able to achieve the same service using the website version of Koh.Tu.Me is slightly harder. The user can still activate events within a desktop version of the site and opt to have cookies store that event information. That way the cookie will still store the event information for that site for that browser on that specific computer. However, this is the less reliable way as if the browser history is cleared or the user uses a different computer, they will not have access to that information anymore.

EventFlow

No Comments

Business Model – Jokha & Sami

There are many ways that our social networking application could be used to generate revenue. Advertising is an obvious revenue stream, although it is important that whatever advertising is added to our application (even for the purposes of a ‘freemium’ esque model) is relevant to the app itself. Relevant advertising could include travel and accommodation, and information about local stores and points of interest in the area the event is taking place.

Guidance
Some people would be prepared to pay for better advice, particularly if they are attending an event abroad e.g Italy. Our app could provide our users with advice about Italian hotels, Guide offices, prices for visiting points of interest such as the Vatican and much much more [1]. Moreover, our app could also detail people with the weather forecast information for the event, in addition to useful transportation information and pricing.

Targeted Advertising
Advertising could also be targeted based on the type of event a user is going to. For example if they are going to a meal with friends, and they have set their start location as their home address, perhaps our application could provide offers on restaurants in their area [2]. The beauty of this type of targeted advertising is that it wouldn’t revolve around storing and repurposing the users information, it would purely be based on the current event that is being organised. This could work for all the varieties of events that our application offers (e.g business and pleasure).

Promotion Advertising
In addition to getting people to pay for general advertising on our application (which would be distributed to the relevant audiences) specific travel companies could also pay to be promoted within our application. For instance specific taxi companies could pay to have their taxi number promoted for all people in that area wanting to travel by taxi.

Booking Referrals/Extras
Companies might also pay for booking referrals, for instance if a taxi was booked through our app.
In the same vein as “in game purchases” our application could offer extras such as upgrades to first class travel where we would receive a certain payment for facilitating this purchase.

No Advertising App
There are some people who won’t want advertising in their app however relevant it might be. For those people we could offer a “pay for” app that doesn’t have advertising. That way we could collect purchase revenue for each person who wanted that kind of app.

Promotion
An essential step towards commercialising our application is to promote it. This could also be done via the use of social networks, for instance it could be advertised on Facebook or a blog could be produced illustrating how it works with a video [3]. In addition it is important to advertise this to people who don’t use social networks as well, so that they can understand how they may use the application without having to sign up for it. This could be done through TV or magazine advertising.

[1] http://www.forbes.com/sites/larryolmsted/2012/01/20/why-you-need-a-travel-agent-part-1/
[2] http://www.ican.org.uk/da/Support-us/Fundraising%20Events/Arrange%20your%20own%20event.aspx
[3] http://www.entrepreneur.com/article/229305

, , , , , , , , , ,

No Comments