CS2001 Group project report

Hugh Matthews, Group 11

Introduction:
My groups idea was a location based app we called FadedLondon, where you would find various
locations in London based on a blurred image. With this idea my group members and I worked on
our own interpretations of that idea, focusing on different types of location as well as their target
user type. The purpose of this report is to critically reflect on the development process of the group
project that my group and I made through four aspects, technology, design, teamwork and the
research topic. I cover what happened, what worked, what did not work, and what could be
improved on if a similar project were to arise.
Section 1: Technology
The rest of the group and I used the same programs to develop each of our versions.
Initially I tried to make a prototype using a software program called DroidDraw, but found it is easier
to make initial prototypes by drawing on paper (see Figure 4), and then transferring and refining the
design on Android studio, the main software used in this project (see Figure 1). Android Studio
utilises two main languages; the scripting language XML for designing the interface, and Java for
making code to switch between screens using buttons as well as detect where the user using GPS. I
also used a free software program I found online called Fotor which allows graphical effects to be
applied to pictures. This how I created the blurred images I used for this app, and it was very easy to
use and understand.
Although I was familiar with Java before using Android studio, I still did not find it intuitive to use.
While I still had to learn some new functions to create the code which I did eventually understand,
there was always a feeling that an error would pop up at random or that the app would crash
without me doing anything. Even when I was with a group member looking through my code, we
were finding and fixing errors and problems that either android studio could not find or could not
describe adequately enough to be helpful, which to me stressed the importance of asking for help
from people who are experienced in the subject. I found XML easier to use than Java in Android
Studio, especially since you can add elements such as textboxes and buttons by just dragging them
on to the phone template as well as alter properties without having to look at or change the actual
xml code that much.

Figure 1: Android Studio prototype

I realised when implementing new features to the app that the best method was to create new
projects solely for testing and improving those features. This allowed me to keep the main code
intact while being able to test new features such as gps tracking, the directional arrow, and receiving
data from a database and eventually add them into the main project, keeping it more organised.
To create the database and servlet, I used a program called Putty (see Figure 2), which allows the
creation of databases or programs and stores them on a server. Putty uses a Linux environment and
this was my first time navigating Linux. This meant having to learn various commands in order to
navigate through and find the files I was looking for. However I have used the windows command
prompt in the past, meaning that a lot of the commands such as cd were very familiar to me.
However, there were some commands such as vi and nano, that took me a while to get the hang of.
The main problem that I had with Putty was how to use it to connect to the server off campus, as it
took me a very long time to realise that I had to connect to the Brunel AnyConnect vpn in order to
access the server. This is also the reason why I think I struggled with this software the most and had
to rely on the other group members, because I could not use and experiment with Putty outside of
the labs.

Figure 2: Putty servlet code

The only data that is generated and used by the app is the gathering of the users coordinates via
GPS, to determine how far away they are from the location and what direction they need to go in to
reach it.
MySql which was used to create the database is a language that I learnt in the previous year to
navigate through and create databases. I had to learn to not only create a database but also how to
create primary and foreign keys, as well adding, deleting and altering data. This was not too hard, as
I was already familiar with most of the content being taught, with the only exception of learning how
to alter existing data. Java was also used to create the servlet that accesses the database and
presents its data on a webpage.

From a technical perspective, I would develop the project in the same way if I were to attempt it
again. The one thing I would change is to better plan out my time in order to flesh out the intended
features, as the final product did not turn out as polished or complete as I would have liked it to be.
I do not have any particular usability concerns for the target user type, mainly because with families
the app will be handled by an adult parent, so if a child has trouble with using or understanding the
app, the parent will be there to help them or use the app in their place. Considering the app also
does not have much complexity to navigating its contents and is mainly about observing visualised
information, the only true usability concern comes in making sure that the information being
visualised is clear and non-vague.
Section 2: Design
Using Visio, I created a UML class diagram (see Figure 2) with entity relationships to show the
relationships between the different data entities in the database, as well as a use case to show how
my app would work when in the hands of a user. The other members of the group also used Visio to
create a number of different diagrams, including object, sequence, state machine and deployment
diagrams. I chose to do a class diagram because I could place entity relationships on the diagram in
order to more easily demonstrate how the classes interact with each other.

Figure 3: Class Diagram

When designing the screens I tried to take the concept of flow into account to achieve one
particular goal which was to get the user to a destination without them relying on a map or specific,
detailed instructions to get there (Csikzentmihalyi,M., 1992). To achieve a balance between the user
knowing exactly how to get to a destination and getting completely lost, I decided to include an
arrow into the app that points them in the basic direction of the destination, meaning that they will
not get lost but they will still have to navigate the streets of London in order to get there.

Figure 4: Sketch prototypes for the app

While I was looking into how to engage my demographic, I looked into tourist motivation and how
older tourists are motivated by a desire to learn more about the culture and heritage of the location
they are visiting (Correia, A, Kozak, M. & Ferraderia, J, 2013) . In order to appeal to this, I decided to
incorporate a system where as the user gets closer, facts about the location will appear, keeping the
user engaged in finding the location. I also researched a psychological concept called epistemic
curiosity, looking into e-type curiosity and how children are motivated more by novelty rather than a
desire to learn (Valkenburg, P, Litman, J, Pitrowski TJ, 2014). Unfortunately I was not able to connect
the app to the database the group created in order to access these facts, meaning that I had to cut
out this feature of facts appearing from the final app.

Figure 5: Code connecting the app to the data servlet

Figure 6: The results from the servlet accessing code

I did not use the design diagrams that were produced with the group for designing the visual and
technical aspects of the app. They were produced mainly for the database that we created in task 2.
A design pattern that I did use was to constantly create new projects to experiment with new
features and then discussing how to improve the app with the other group members, later adding
them to the main project. This is similar to the rapid prototyping methodology that is popular with
many software developers.
If I was to design a similar app again I would still use a design pattern that includes some sort of
constant iteration. I found that this was a more efficient approach of not only developing the project
but also of furthering my programming knowledge.
Section 3: Teamwork
I feel that the idea that the project group chose worked very well for the group. It allowed us to not
only target a wide variety of demographics but also allowed us to have our own iterations on the
basic idea of finding a location based on a blurred image.
Before the end of the first term, we did have occasional meetings, but the weekly meeting with the
tutor was when the most progress was made; clarifying any doubts we had about task briefs, as well
as helping us develop the concept of the app. During later tasks the number of meetings increased
to make up for time spent on other modules and work. Despite this, organising meetings was rather
difficult since we had to plan around our own schedules as well as taking travel times for members
living outside the university into account, making it difficult to be efficient. However, we still
managed to have effective meetings that made progress.
Our main communication mechanism was a WhatsApp group were we would ask questions about
parts of a task we were struggling with, organise meetings and socialise. One main benefit of this is
that, since all of the group could see our messages it made us more open to asking for help. For

example, if one group member asked for help with a problem, another person who also has the
same problem but does not want to ask for help could see the discussion in the group and get help
indirectly from that. This means that in the future, that person would be more willing to ask for help.
We mainly used our WhatsApp group rather than the tools on Blackboard. However, we did use the
file exchange tool, which was useful for posting files of diagrams and code that the whole group
could look at and take inspiration from.
Despite this, one thing that I would have done differently is to try and do more work and research
independently of the group. This is because more often than not, I felt like I was just waiting for a
person to help me solve a problem that I had instead of me trying to work on the problem while
waiting for someone in the group to be available to help. I think that this led to a situation in task 2
where one or two people would be in charge of creating diagrams and tables, while the rest of us
would then learn from those members. Although we did eventually learn what the tables and
diagrams meant and represented, I feel that this placed a bigger burden on the members who had to
help us with understanding the content, especially when it wasnt exactly clear to anyone how to
approach it, leading to us seeking clarification from the lecturer. The next time a situation like this
occurs, I would try to learn more independently while also not being against asking for help when I
feel like I need it.
As I have explained above, our scheduling could have been more efficient but overall I do think that
we were effective.
For task 1 we discussed what user types are app could be directed towards and which user types we
would choose to work on. Task 2 was different as the work we would eventually submit individually
was mainly worked on as a group, unlike task 1 were we had to develop the app based on our
individual ideas. Therefore, the group was split up into different tasks, half worked on developing
the servlet code, half worked on creating the database structure where we would individually add
our own unique data tables. I helped with creating the database structure, suggesting what types of
table were needed and how the data would be presented in those tables.
Section 4: Research Topic
The research topic that I have decided to look at and experiment is Visualising mobile devices and
the internet of things for the L2 project. This is because to an extent I am already trying to visualise
directional information in the form of an arrow that points the user to a location. Another reason is
that the users mobile phone has to interact with other objects in order get the coordinates of the
users location and calculate what direction the user needs to go in, as well as register the QR codes
that the user will receive when they reach the location. With this system you can effectively connect
users to businesses using the internet/GPS.
As I struggled to find a way to implement an arrow that would rotate and point to the location, I
thought that an alternative solution could be to implement a graph instead using the open-source
library called graphview, showing a line connecting the users location and the destined location.
One interesting opportunity that arose was that the line would get shorter as the user got closer,
giving the user another source of useful visual feedback.

Figure 7: Graphview implementation

Figure 8: Graphview navscreen code

Another prospect I have to consider when trying to visualise information is the limitations of the
mobile platform, the screen size, the limited hardware as well as the variabilities in form factor. To
address potential issues with performance, the arrow will not be constantly updated in real time,
instead the user will have to press a button labelled check direction in order to update the arrow

and orientate themselves towards the location. This has the benefit of allowing the user to focus on
the environment around them, making them able to navigate their way safely as they will not be too
distracted looking at their phone. It becomes more significant when you take the typical mobile
context into account. Unlike office environments, mobile contexts are full of distractions or other
activities which are being carried on in parallel (i.e. walking), meaning that cognitive resources are
not being fully committed to the device. To be able to present the same information while using less
cognitive resources is a big benefit, especially since the app is targeted towards families with small
children.
I would recommend trying to further implement this type of visualisation to other areas of the app,
even if they dont seem like they could be visualised easily. The less cognitive resources the user has
to employ to understand the app, the better, especially when the user is multitasking.
Conclusion:
In conclusion, I think that the group and I as a whole managed to come up with a novel
implementation of the treasure hunt concept through FadedLondon. Through several meetings
and constantly iterating on the concept while getting feedback from other group members, the
group and I were able to expand the idea and successfully apply it into many different areas. The
main issue that I faced with this project is that my main idea of implementing a directional arrow
was too ambitious, meaning that the solution that I came up with did not work as smoothly as I
would have liked.
I think a key improvement would be to plan out meetings better in order to get more done, as well
as make more efficient use of time to make sure that the work is done not near to a deadline, but
more evenly throughout the period of time available.
References:
Csikzentmihalyi,M. (1992) Flow: the psychology of happiness USA: Harper & Row
Chittaro, L. (2006) Visualising Information On Mobile Devices , Computer, Vol 39, no.3, pp 40-45
Valkenburg, P., Litman, J., Pitrowski Taylor J. (2014), Measuring Epistemic Curiosity in Young Children,
Infant and Child Development, Volume 23, no.5, pp 542-553
Correia, A, Kozak, M. & Ferraderia, J., (2013) From tourist motivations to tourist satisfaction.
International Journal of Culture, Tourism and Hospitality Research. 7 (4) . p. 411 - 424.