Reflection and Evaluation

Overall this has been a successful project. We have all worked well as a group and have shared out our tasks equally and fairly to ensure that we produced the application and background documentation to the best of our abilities. The application we have produced works well and does what we set out to do. This task has provided more experience in documentation of a project and given us some extra experience in actually making the product, this gave us a better feel for what it would be like to actually produce something once we had planned and designed it and this gave us more motivation as we could see and use the final product ourselves. All of the members of our group were able to expand our skills in the different areas we worked on and gained some more valuable experience in planning and creating a project.

Our application works well and completes the criteria that we were asked to carry out. Creating an application challenged us in both development and documentation as it was different to the project we did last term. We had to think of and research new technologies and this helped us to learn more about web application design.

Success Criteria


We can see how successful our application was when we compare it to our requirements that we wrote at the beginning of the project;

• Must be inspired by a board game, or some form of children's game, and this inspiration must be obvious in the final product- Our application was inspired by the game hide and seek and this is obvious in the final game play, the app has two different forms of game play, one where you can simply just message your friends to see where they are, or one where u can play the game as a hider or seeker.  

• The application needs to be easy to use. People of all ages including 40+ will be using our application as it is designed for families so the interface should be simple and similar to other iPhone application platforms and therefore recognisable to the user to make it easier to use- The application has a simple user interface and looks similar to other iPhone interfaces therefore has continuity in terms of general iPhone applications. This will make it easier to use especially for older iPhone users as hopefully they will find our application has a familiar interface. 

• Must provide an enjoyable experience for the user. The application should create a fun experience and keep the user engaged for a prolonged amount of time- Our application is multifunctional and one of these functions is as a hider and seeker game, having played the app ourselves we had a pretty good time walking around Drake Circus sending photos and trying to find people and we are sure that any user would find the same. 

• The final idea must be unique and take our ideas to the 'next level' to make sure we have developed something fun and engaging that uses the best of our skills- Through our development process we have be able to develop our original ideas in a successful web application and something, we feel, has not be created before. 

• The final application must use iPhone or web app development software- Our final application uses iWebKit which is web app development software. 

• The application must work on the iPhone 4- We have tested the application on our iPhones and found that it works pretty well. 

• The application must have the potential to be developed to other mobile platforms like Android and other smart phones, even if we do not have time to develop it to this level- iWebKit can only develop iPhone web applications but if we wanted to we could develop the same app for other mobile phone applications. 

• The application must provide a fun and exciting game experience and a functional experience for the user so they can choose which they want to use- Our application is multifunctional so the user can choose the way they want to use the application depending on the amount of time they have and the number of people they want to play with. 

As you can see we completed all of our requirements which shows that we sticked to them and kept them in mind throughout the development and creation of the application.

Improvements 

The app could be a lot more efficient for the iPhone if developed natively in a iOS format however this would not allow cross platform adaptability. Though our project is based on iPhone, it could be adapted with more time to work on other smart phones, however to develop it natively for each device would be the best option, though not applicable with our time and resources. This would also improve many of the features within the app, for example native development for iOS would make the basic ‘send Blip’ feature of sending a sound to another persons phone, as the iPhone does not allow basic javascript manipulation of inline audio, creating a big problem for the web app, which would be a simple solution creating it manually.

Due to restrictions in time, resources and people power, this app has been restricted, and is just a prototype of what it could be in the future; an effective and powerful ‘Hello World’ for what it could become with further development and attention. As stated before, it could be further developed natively for more platforms, however features such as the ability to take and send photos as clues could be developed further and more effectively.       

Group Dynamics

We aimed to act like the specialization model. This allowed us to focus on our skill set while focusing on a main aim. At the start of the project this however was not the case. Intentional we aimed to work like the peer model. This allowed us all to be involved with the initial stages then as the work load got more specialized we split into groups, mainly the first and second years. This was a shame as it would have been nice to be aware of both sides. However i think that we learnt a great deal of information and working skills that will be useful for next year.

Deployment

Walkthrough of Beacon in-development prototype.

Plan for Deployment

• First of all we need to make our application. We are using iWebKit so the application can be coded on our computers as a webpage and uploaded to the internet. 

• Once we have the application working we need to test it. The best way to test it would be going out into Drake Circus and playing the game using all the different options and see what worked and what didn't. This would give us a clear view of what worked well and what needed to be improved.

• Once the application is done and is working we need to get it onto the market. There are several ways of doing this; we are making a web application so users of smart phones like the iPhone can go onto the internet to our webpage and save the page to their background like a bookmark. It would then appear as an application that they can access straight from their phone.

• Another option for deployment is becoming an Apple developer. We can pay £100 to register as a developer and with this we can upload our application to the app store, this may be more beneficial than the other option as the app store gets a lot of hits everyday, this way we can make sure that lots of people see our application, and if the application is free it may be more encouraging to people to download it. 

Timetable: 

For this project we do not have such a strict timetable centred around one day as we are not making an installation. We want to get our app up and running as soon as possible though so we have a rough timescale in which to make the project, mainly planned out week by week. Rather than a timetable, we have a list of things that need to be done in a certain order before we can deploy our application. 

14/01/11: Given the brief; between now and the end of January we have the opportunity to do the planning part of the process. This involves thinking of new ideas and developing our final idea so we have a clear scope of what our project is going to be about and what we are making. 

21/01/11: Research; after our first group discussion research should be done into what programs we could use to make our application. Ideas should be developed and our final idea should be taking form. The research can help us plan out what our application will look like and how it will function. 

28/01/11: Final idea; our final idea should be finished with justification of which board game(s) we are taking inspiration from and how we have incorporated this into our ideas. With our final idea sorted we should we able to move on to development of the visualisation and some mockups of what the application will look like on the iPhone. 

04/02/11: Begin coding; after 2/3 weeks of group discussion we now need to begin to start coding our application. We have settled on the final idea for the game, Beacon, and now need to move on to doing some documentation as well as making the app.  

04/03/11: Testing; after a month of coding our application should be finished, so we can now move onto testing. The best way to test it would be taking our phones to Drake Circus and playing the game ourselves to get a feel of what the game is like and what areas could be improved or changed if any need to be. Those who were not involved with the coding part of the project should be working on the documentation, doing more research, and feeding their results back to the coders who could incorporate them into the application. 

18/03/11: Documentation completed; documentation needs to be completed by this date and the application should be ready to be released. Any final alterations should be made to the application in the next week. 

25/03/11: Application completed; the application should be completed by now, with all the final adjustments made and completed. The website should be up and running ready for people to download it to their phones. If we decide to upload it to the app store then we need to apply for a developers licence. 

Possible Problems: 

There are only a couple of problems we could face when it comes to deploying our application:

• Application does not work; in order to stop this happening we need to make sure we thoroughly test our application before we release it to the public. We need to go out into Drake Circus and make sure we use every aspect of the app to make sure each one works and eliminate any bugs or problems that we find.

Creation and Realisation - iPhone Web App Interface Mock Ups

These are a series of screenshots of the Apps interface: (Click to enlarge any image)

Loading/Title Screen shown while app loads.

Home screen shown when app is loaded, providing user with information about How To Play, an about page at the top, and the ability to log in with Twitter.

The page shown when 'About' is pressed, with the ability to return to the previous page.

The page taken to outside the app when  'Log In With Twitter' is pressed, the page on Twitter, allows the ability to log in, and link the account with the app.

Screen shot showing the addition of account details with the iPhones integrated keyboard automatically appearing.

Page telling user connection of Twitter was successful and a link to get back to the Beacon app. 

Game Lobby page showing Twitter account names of hosts that are available and the choice to select a a host, or to host your own game.

Same as above, however the host available has been selected. 

Next when selected, or making a new game, is the ability to invite friends to the game, and then a button to start the game.

Same as above but with other Twitter names added, no '@' symbol is required, it is added automatically.

Same as above however with invites sent to people. 

Screen showing seekers perspective, with abilities to send Blip, request location or a clue about location. Selecting a person by pushing slider to on for person to send to.

(All images are preliminary and not an exact representation of final product.)

Creation and Realisation

For our application we need to make a visualisation of the map of the shopping centre so that people can select where they are on the map and can see where their friends and family are. The map is shown on the main screen and the user can plot where their friends are.

In order to make this I took a screen shot of an overview of Drake Circus for Google Maps and uploaded it into photoshop. This helped me get the general outline of the shopping centre and helped me plot out where I needed to put all the shops.

Once I had the photo in photoshop i drew the outline of the centre over the picture so I could get it accurate. After this I plotted out the shops and drew in where they all go. 

Below is a mock up of a possible screen capture from the iPhone and an example of how the game works. The hider can click on the shop that they are in and receive a collection of photos from a cache of images of the area they are in. The players can flick between the levels of the shopping centre and select the different shops. The screen won't look exactly like this but this shows how the concept will work: 

Inspiration:

From the screen shots in the post above you can see how hide and seek has influenced the way we have designed our game and they way you play it. The original concept of hide and seek, one person finds all the people hiding, has been incorporated in the way that the first user selects themselves as the finder and the rest of the people linked into the game become the hiders. From here the group can split into separate locations across the map and its the seekers job to find them all.

However we have tried not to be too literal with the game of hide and seek. Although our application can be played like this we wanted to make it a bit different to try and develop the game more and bring it into modern day using the features on the iPhone. Players can send photos of the location they are in to get the seeker to guess where abouts they are on the map. This adds a bit of fun to the game as the seeker has to guess where they are rather than simply finding the hider. The seeker can also send 'blips' to the hiders phone when they get close to their location to make the hiders phone make a noise so it is easier to determine where they are. Again we have tried to develop on the original game to make it more technological, and more fun for the players.

As well as the game function the application has a more practical aspect. If you and your friends are lost in the area and can't find each other the application acts as communication between you so you can send an instant message telling your friends where you are. We wanted to include this more practical feature to make our application more than just a game. Hopefully this will make it appeal to a wider range of people and make the application more helpful.

Meeting the Requirements:

• The application is clearly linked to the game we chosen, hide and seek, and uses this concept effectively. It is obvious how we have incorporated the game into our ideas and final designs and we have expanded on the original concept to take the application to the next level. 

• The application is easy to use. The interface is really simple so could be used by anyone of any age and uses the same layout and styling as other iPhone applications which would help a new user as they would already be familiar with the layout. 

• We will be able to get a better idea whether the application is enjoyable to use when we test it but so far we have made an effective application that does what we want it to and has a game function and a practical function so should be enjoyable for the user. We aim to make an enjoyable application so hopefully our final product will be. 

• We have taken our ideas to the next level and developed them as a group. We have always liked the idea that our application goes back to the basics of what a game is supposed to do, bring a family together, and we have made something that practically does this. We put all our skills together to complete this project and we have collectively created something that has expanded our ideas and led us to be more creative. 

• Our final application was made using iWebKit as a web application. 

• The website for beacon can be accessed on the iPhone 4 and downloaded to the desktop to be played directly from there where the user wants to.

• We hope to develop our application onto other smart phone platforms. Currently the app can only be accessed from the iPhone but in the future we want to develop it further and make it a multi-platform application. 

• Our game is practical and fun to use and the user can choose which function they want from their application. 

iWebKit Help

We found a couple of helpful videos on YouTube that could help us to use iWebKit, some of the other tutorials are quite long and are not tailored for the kind of thing we want to make so most of the application development on iWebKit will come from past experience with the program or trail and error:

Requirements and Specification

Requirements for our application:

• Must be inspired by a board game, or some form of children's game, and this inspiration must be obvious in the final product. 

• The application needs to be easy to use. People of all ages including 40+ will be using our application as it is designed for families so the interface should be simple and similar to other iPhone application platforms and therefore recognisable to the user to make it easier to use. 

• Must provide an enjoyable experience for the user. The application should create a fun experience and keep the user engaged for a prolonged amount of time. 

• The final idea must be unique and take our ideas to the 'next level' to make sure we have developed something fun and engaging that uses the best of our skills. 

• The final application must use iPhone or web app development software. 

• The application must work on the iPhone 4. 

• The application must have the potential to be developed to other mobile platforms like Android and other smart phones, even if we do not have time to develop it to this level. 

• The application must provide a fun and exciting game experience and a functional experience for the user so they can choose which they want to use.

Environmental and Contextual Observations

Observations around finding our target audience and demographic.

We chose to study the entrance and exits of drake circus initially to allow us to find how the space worked and how people interacted with the space. we chose to study between the hours of 11 and 1 pm on a tuesday. We belived that this would give us a very quiet period and thus allow us to understand the worse case scenario for lack of users. Additionally we could also use this time slot to allow us to prototype and test before deployment at a busy time. We found out the following ..

The Raw data shows us that during the hour 159 people entered the complex. However around 20 percent of these visitors were walking straight though the center. This left us with around 100 potential customers. Our idea is based around group interaction, there were 14 groups entering the complex. ( a group classed as 2 and above people) single's are still important to us as they maybe hiding or seeking others. However our app is mobile web based so we wanted a rough idea on the smart phone users. We found this out by seeing visual clues, for example it being on show or headphones etc. Therefore approximately 60 people an hour could be users of our app.


Additionally The center is very dynamic. due to its central location people tend to "float" inside and out. Therefore we also studied the exit flow of people in the second hour.

The numbers were slightly less across the board. This indicates the lack of predictability. this could be an issue when we have to work out server workloads on the application. However the same correlations between groups, smart phone users and people walking through are evident. Although it seems less groups leave the center, this could be due to the fact people spilt up after meeting at drakes to complete there own tasks and then meeting somewhere else. If this is the case then our app would be beneficial to these users.


We as a group have been informally quizzing and asking a cross section of our potential demographic about our ideas. We have found that a pleasing majority like the idea of the app however some are concerned at its implications. Successful applications integrate into daily life rather than controll/replace it. Our app they said would have to seamlessly integrate into the experience of finding others and be the first port of call over texting. They say texting is problematic and calling is un-natural. This does give us a space to fill in terms of integration.

Studying the space in drakes circus i noticed that lost people and or people using phones congregated on the balcony's and entrance foyer. This offers two useful insights, one is that there is a large amount of visual space offered, Suggesting the possibility for augmented reality. Also visual clues would be easier to spot. ie if you can actually see the logo for topshop you may just be able to reconise the small section sent to you etc. The other insight is that these areas could have a fixed beacon devise. This would allow for non smart phone users as well as advertising.

There is no obvious lost and found point for children or other users. This is, I thought, unusual because most modern shopping complex's have dedicated areas, for example westfeild in London.


Studying the journey of one user ( our social group, they were unaware of my study and i made efforts not to control or influence the events other than our normal actions)

Walking into drakes with assumed friends.

Stand next to entrance when additional friend from other entrance joins.

3 girls 2 boys.

They walk into H & M

Boys walk out and go to apple store

Girls walk into zara

Boys walk back to H & M foyer

One uses phone then goes to zara.

All five walk to topman/shop

All five walk out together and go to primark

Leave primark and center...

Studying the movements of a few individuals will help us to plan out the general area travelled by the majority of people. As you can see from this one example, there was a time when the group split and lost each other and had to retrace their steps to look for their friends, from this we can see how our beacon application would be integrated into this situation and how it would be beneficial to this group. This reinforces our decisions behind making the application as we can see how it would be helpful to this group.


Photographic background research,
We were refused permission to take imagery in the center so here are a selection of images from google.

The photos that we took of Google can help us to instantly see how busy the shopping centre can become, again giving us a view of the potential users of our beacon application. As you can see at the time the photos were taken the shopping centre was very busy, we roughly estimate the photos were taken on a Saturday due to the number of people in the shopping centre, so this gives us an idea of when our application would be used the most. We hope, due to the large numbers of people, that our application will be quite successful and in the future we want to expand it to the shops in the wider area outside Drake Circus.


Demographic of users.

we aim to obviously attract a wide audience of users however we must be realistic. Its impossible to honestly attract everyone. Our break down for our initial uptake is as follows;

Smart phone users - groups of more than 3 people - groups that spilt up - digital natives our groups with majority natives. They will be likely to be young professionals and/or students additionally we will inspire families with teenagers and digitally aware parents. 

Problems with the space,

Due to the inside aspects of our chosen space we have taken tests of mobile phone reception. In various locations.We found out that in communal area's that reception across the board was fine, retail units near phone shops was very good. However some retail units had struggling reception near the back of the store.

Therefore we are deciding to allow the app to also work on wi-fi as a back up. In future versions of the project we could argue a case for signal boosters in the store to increase use and therefore advertisement potential.

Research

iPhone and Web Applications

The iPhone has over 350,000 different 'apps' available for users to download straight onto their phones, this is a huge market, open to hundreds of developers with the opportunity to create anything and everything. There is a variety of popular application genres, the most popular being social networking and gaming, everyone with an iPhone seems to have the 'Facebook' application and 'Angry Birds' and these two genres offer a great opportunity for expansion and collaboration.




If a developer is lucky enough to design an application that becomes very popular they can be looking at making over $1,000,000 within the first year of the applications launch. The application market is a huge one and competition is fierce, but those who strike it lucky can make a lot of money.

http://www.wired.com/gadgetlab/2008/09/indie-developer/

There are loads of different websites and pieces of software available for users to make their own iPhone applications:


iWebKit 


iWebKit is an iPhone web application and website creator. iWebKit was specially designed so that anyone can use it, it caters to people with any level of programming skill, even those with only a little knowledge of HTML. iWebKet is specially designed to make web applications only for the iPhone or iPad so the technology can not be expanded to other mobile platforms like Android or Nokia. iWebKit has a very small javascript file making the application run quicker than other mobile development software. 

http://snippetspace.com/projects/iwebkit/

jQTouch 


jQuery touch is a plug-in for mobile web development that allows the development of web applications for the iPhone and iPod touch. The advantages of this technology over any other is that its layout makes it really easy to use. It provides a basic set of widgets and animations to allow you to create a dynamic iPhone application. However when running the application there can be some performance issues that can make the screens jumpy and delayed. 

http://jqtouch.com/
http://interfacethis.com/2011/adventures-in-html5-part-one/

Create With Context

We found some research by a company called 'create with context' who are a firm which focus on web, mobile, desktop and consumer electronics applications. They did some background research into the way  people use their iPhones mainly focusing on the 30+ age range which they distinguished as the older, 'non-trendy' demographic. This type of research would be very beneficial to our project as our main target audience would be a family of which half could be made up of 30+ adults, we need to know how people of that age range use their iPhones to help us produce a more user friendly application.

• Most of the navigation of the iPhone was done through trial and error, many users, especially novices, had a hard time distinguishing what some of the symbolic buttons meant. Buttons which had their use written on them, such as the alarm button in the 'clock' application enabled users to quickly find what they were looking for rather than having to press multiple buttons to get to their desired choice. 
• The easiest applications to use were those that had real world similarities so needed no instructions to explain how to use them, for example the air hockey game, it is so similar to how someone would play the game in real life that users instantly worked out how to use it on the iPhone. 
• The research showed that many expected the iPhone applications to have a layout similar to the same applications on the computer, such as the address bar in safari being at the top of the page like it is on a generic internet browser. This made the application easier to use because the layout was familiar and limited the amount of time it took to learn how to use the application.

They concluded the research with 'Eight rules of thumb' that give advice on how to design a good application. We should definitely take these into account when designing our application to make it as user friendly as possible. 

1. Take advantage of learned behaviours. Users tend to be more successful in using an application when they had previous experience of how a similar program worked. They could transfer the skills already gained from the pervious experience to help them use the application, and familiarity with the program meant they felt more comfortable using it. 
2. Avoid interaction inconsistencies. Icons that look different but do the same thing leads to confusion with the user as they think that because it is a different icon it does something different. Keeping the user interface the same as previous iPhone applications helps to eliminate this problem. 
3. Provide clear conceptual links across widgets. If there is a group of icons that do similar things to the page then group them together, this way the users gets a quick idea to what a group of buttons do and it takes them less time to work out what to press to get the page to do what they want it to. 
4. Put space between action widgets. Make sure there is enough space between the buttons so that the user does not press one by accident. 
5. Plan for accidental over-swiping. 
6. Don't rely extensively on multi-touch. Some users may not like the multi-touch function on the iPhones so making the entire application use multi-touch would put the user off. Try and have multiple methods to achieve the same action. 
7. Provide visual feedback for taps. This helps the user see what they have pressed and ensures that the phone has responded to their touch. 
8. Provide interaction affordances. 

http://createwithcontext.com/media/cwc-how-people-use-iphone.pdf

GreyStripe

Greystripe are one of the leading mobile advertising networks. Alongside the work they do they also do research into mobile phone technologies into the way people use their phones. In their 2009 Q1 research paper they looked at iPhone engagement metrics, how long people used applications for, whether the price or advertisement affected usage etc.

Greystripe found that the average time spent on an iPhone application was 9.6 minutes, with only 19.9 uses per download of the application meaning that the average user uses their application only 20 times regardless of whether they pay for it or download it for free. 58% of application downloads are on iPhones, showing that this is the more popular product compared to the iPod Touch.

This information can help us to ensure that we create an iPhone application that is engaging to our audience. We want our application to be one that users keep coming back to and use on a frequent basis, so qualities like functionality and appearance are important.

http://www.greystripe.com/wp-content/uploads/2009/11/GreystripeConsumerInsightsApril2009.pdf

Massachusetts Institute of Technology

I found a paper written by some students at the Massachusetts institute of technology which detailed some research they had done into the educational benefits of playing technological games. The entire paper does not directly link to our research but one section talks in detail about the success of gaming on mobile devices. The research documents the success of games like the Tamagotchi, popular because of its ability to be played for only minutes and seconds at a time. It is shown that a game that does not need to be played for a long duration is more popular because people can play it where ever they feel like it, when they're shopping, on the bus, waiting in a queue etc. They do not have to commit themselves to a game that lasts for a long time, they can simply pick up the game from where they left off at any time they wish. The game becomes popular because of its freedom of play.

"People can play these games for minutes at a time in the interstitial spaces of life – on the bus, waiting in line, and even while on the go."

From this research we can pull out the data about the length of the game play and apply it to our own application. We want to create a successful application therefore our application will have to be one that can be used where ever and whenever the user feels like it. Our concept embodies this in the way that the user can choose how they want to use the application, as a game or as the more functional use. 

http://education.mit.edu/papers/MovingLearningGamesForward_EdArcade.pdf

Ten points to consider to make a successful app

1. Clear information.

 Too many apps overload the screen with clutter. Most app users don't have a high commitment level due to the spontaneity of there download. If we overload the user they will feel like its a task rather than an experience and log off. 

We will have to consider and remember the constraints of the small screen. one or two tasks per page maximum to allow for focused tasks and achievements. 

feature aware, If we add surplus to requirement features that confuse or change the experiance then these "features" will deter the user. 

sometimes more is less. If a complicated task is done with one click then the user can feel disjointed from the experance. sometimes actions and tasks need to be explained to the user. especially when dealing with user data they need to feel incontroll.  Our service handles sensitive data about the user so we need to make sure they are involved.

Use white space effectively.

2. Keep it simple.

Our first experiences of software utilized complicated manuals and readme's to explain the software. We, as digital natives, pride ourselves on being able to pick up software and use it. However this ability is down to the user experience being natural and self explanatory. If our experience is over complicate or un-natural we will loose users. However if complicated sections would benefit from explaining then walkthoughs or pop out explaining bubbles can be used effectively. 

 

3. Don't interrogate the user 

having initial registration screens will scare and annoy the users. Therefore we have decided to utilize a well known database, twitter, therefore people will feel less disengaged or interrogated. for our ap p to work effectively we need login sections however using twitter will lessen the detrimental effect.  

4. Use Mental Modes

Users relate to an experience with realistic, world based scenarios. If our app works against this then people will feel confused and disjointed. this isn't a major concern for us as we don't provide a function its more of an experience however the way data is passed backwards and forwards have to remain conversational. 

 

5. Understand Conventions

We all aim to re-invent the wheel when it comes to design. However apple provide HIG's and there are other graphical design resources to check were not being stupid with our interface. 

 

6. Less is More

Making a GUI is extremely difficult. Especially if we wanted to create a custom interface. Therefore we will have to keep it simple, too many apps out there, break conventions badly by trying to be too unique. Apple design there apps to have similar methods to complete tasks so the user feels at home when using a new application. we will have to strike a balance between following conventions and making it unique.

7. Professional

To make our app proffesional we will have to consider; contrast, repetition, alignment and proximity.

Being aware of these principles will allow a professionally aware app and therefore show the user that we safe with there data aswell as providing the correct service. 

8. Mobile Context

Sounds obvious however we must remember our user will be utilizing the app in a mobile context while completing other tasks and moving though the space.

 

9. Don't Rush

It will be obvious if we add features last minuet because they will look rushed and misconceived. We'll have to make sure each element is thought though properly. if needed we could add extra features at a later date.

 

10. Test, Test, Test !