Lyndon J Fawcett Mini Architect Virtual reality furniture ... J Fawcett Mini Architect Virtual...

Lyndon J Fawcett

Mini Architect

Virtual reality furniture arrangement application

B.Sc (Hons) Computer Science

March 20, 2015

of 86

“I certify that the material contained in this dissertation is my own work and does not

contain unreferenced or unacknowledged material. I also warrant that the above statement

applies to the implementation of the project and all associated documentation. Regarding

the electronically submitted version of this submitted work, I consent to this being stored

electronically and copied for assessment purposes, including the Department’s use of

plagiarism detection systems in order to check the integrity of assessed work.

I agree to my dissertation being placed in the public domain, with my name explicitly

included as the author of the work.”

Date:

Signed:

of 86

Abstract

Online retailers have been continually finding new ways to visualise their products. This has

been done using various mechanisms, primarily through web applications. However, for

home goods and appliances no such innovation exists, or has been deployed. Recent

popularity and advancements in mobile devices have opened up new commerce channels

for online retailers. Letting us put more information into the consumer’s hands. This project

addresses this problem of visualising home goods. This is done by creating a cross platform

mobile application that displays user generated content. The application provides an

interface for furniture arrangement and an ability to share creation. Moreover it explores

user interface potential for complex applications on mobile devices.

of 86

Table of Contents

Working Documents .................................................................................................................. 6

1 Introduction ........................................................................................................................ 7

1.1 Aims of Project ............................................................................................................ 8

1.2 Overview of Document ............................................................................................... 8

1.2.1 Background Research .......................................................................................... 8

1.2.2 Design ................................................................................................................... 8

1.2.3 Implementation ................................................................................................... 8

1.2.4 Testing and Evaluation ......................................................................................... 8

1.2.5 Conclusion ............................................................................................................ 8

2 Background ......................................................................................................................... 9

2.1 Visualisation problems with online shopping ............................................................. 9

2.2 Mobile and cross platform development ................................................................... 9

2.2.1 Mobile UI guidelines .......................................................................................... 10

2.3 Related work ............................................................................................................. 10

2.3.1 Academic papers ................................................................................................ 10

2.4 Existing applications .................................................................................................. 12

2.4.1 IKEA virtual reality .............................................................................................. 12

2.4.2 BuildApp ............................................................................................................. 15

2.5 Summary ................................................................................................................... 18

3 Design ............................................................................................................................... 19

3.1 Introduction............................................................................................................... 19

3.2 Design Process ........................................................................................................... 19

3.3 Design Considerations ............................................................................................... 19

3.3.1 3D Viewer ........................................................................................................... 19

3.3.2 Assisted Room Creator ...................................................................................... 20

3.3.3 Multiplatform ..................................................................................................... 20

3.3.4 Content Sharing ................................................................................................. 20

3.3.5 Sketching based control ..................................................................................... 20

3.3.6 Menu driven control .......................................................................................... 21

3.3.7 Grid based wall placement ................................................................................ 21

3.4 Design choice............................................................................................................. 21

3.5 Requirements ............................................................................................................ 22

of 86

3.5.1 Front-End (Application) Requirements .............................................................. 22

3.5.2 Back-End (Server) Requirements ....................................................................... 24

3.6 Back-End (Server) Design .......................................................................................... 25

3.7 Front-End (Design Sketches) ..................................................................................... 26

3.7.1 Home screen designs ......................................................................................... 26

3.7.2 View rooms ........................................................................................................ 29

3.7.3 Arena .................................................................................................................. 31

3.7.4 Screens navigation overview ............................................................................. 33

3.8 Use cases ................................................................................................................... 33

3.9 System architecture .................................................................................................. 38

3.9.1 Architecture rationale ........................................................................................ 38

3.9.2 Module breakdown ............................................................................................ 38

3.10 Application Prototype ............................................................................................... 40

3.10.1 Home screen ...................................................................................................... 40

3.10.2 View rooms ........................................................................................................ 40

3.10.3 Arena screen ...................................................................................................... 41

3.11 Iterative design .......................................................................................................... 41

3.11.1 Observation and Interview ................................................................................ 41

3.11.2 Summary ............................................................................................................ 43

3.11.3 Analysis .............................................................................................................. 43

3.11.4 Iteration of design .............................................................................................. 43

4 Implementation ................................................................................................................ 45

4.1 Class diagram overview ............................................................................................. 45

4.2 Tools used.................................................................................................................. 46

4.3 Observer architectural pattern ................................................................................. 46

4.4 Paint application ........................................................................................................ 46

4.5 The scene and arena items ....................................................................................... 47

4.6 Node detection algorithm ......................................................................................... 48

4.7 Wall creation algorithm ............................................................................................ 49

4.8 Uploading room......................................................................................................... 50

4.9 Downloading and file storage ................................................................................... 51

4.9.1 Models ............................................................................................................... 51

4.9.2 News................................................................................................................... 52

of 86

4.9.3 User generated rooms ....................................................................................... 52

4.10 Rotation ..................................................................................................................... 52

4.11 Scene photo ............................................................................................................... 53

4.12 Technical challenges .................................................................................................. 54

4.13 Server implementation ............................................................................................. 54

4.14 Findings from prototype ........................................................................................... 55

4.15 Summary ................................................................................................................... 55

5 The system in operation ................................................................................................... 56

5.1 Menu ......................................................................................................................... 56

5.2 Login .......................................................................................................................... 57

5.3 Browsing rooms ......................................................................................................... 57

5.4 Arena ......................................................................................................................... 57

5.5 Arena Help ................................................................................................................. 58

5.6 Publish ....................................................................................................................... 59

6 Testing and evaluation ..................................................................................................... 59

6.1 Testing ....................................................................................................................... 59

6.1.1 Client side testing ............................................................................................... 59

6.1.2 Server Side Testing ............................................................................................. 62

6.1.3 Testing Summary ............................................................................................... 63

6.2 Usability feedback ..................................................................................................... 63

6.2.1 Results analysis .................................................................................................. 63

6.2.2 Discussion of usability feedback evaluation ...................................................... 66

7 Conclusion ........................................................................................................................ 67

7.1 Review of aims .......................................................................................................... 67

7.2 Front-end requirements ............................................................................................ 67

7.3 Back-end requirements ............................................................................................. 68

7.4 Lessons Learned ........................................................................................................ 68

7.5 Future work ............................................................................................................... 69

7.5.1 Wall creation and placement ............................................................................. 69

7.5.2 Furniture selection ............................................................................................. 69

7.5.3 Website implementation ................................................................................... 70

7.5.4 Social networking integration ............................................................................ 70

7.5.5 Partnership with retailer .................................................................................... 70

of 86

7.5.6 Auto adding furniture ........................................................................................ 70

7.6 Summary ................................................................................................................... 70

References ............................................................................................................................... 71

8 Appendix ........................................................................................................................... 73

8.1 Usability feedback form ............................................................................................ 73

8.2 Sketching interface .................................................................................................... 74

8.3 Tree List User Interface ............................................................................................. 75

8.4 Class diagram............................................................................................................. 75

8.5 Project Proposal ........................................................................................................ 78

Working Documents

All source code and models used in this project is available at:

http://www.lancaster.ac.uk/ug/fawcetlj/

http://www.lancaster.ac.uk/ug/fawcetlj/

of 86

1 Introduction

Online shopping has presented challenges to retailers and their developers ever since e-

commerce emerged. One of the main challenges with designing an e-commerce application

or website, is giving the customers a similar level of interaction with the product as they would

have in store. Online retailers’ solutions to this problem include, videos, 3D views, and

animations all to provide the customer with a better view and interaction of the product

before purchase [1].

Without these innovative designs to aid in better product viewing before purchase, a

customer may decide against online shopping, and therefore might end up not purchasing

from your store whether it be virtual or not, especially if the retailer does not have a local

convenient physical presence. On the other hand, the customer could purchase a product

that was not as they expected, and end up returning the item. These two points negatively

affect profit and waste time.

So there is a gap to be filled in the furniture and home accessories department. The

innovations in these departments related to online shopping are scarce, and lack the

advancements made to advertise other products.

Mobile devices have rapidly improved. Reasonably priced data, and more powerful SoCs have

increased mobile interaction and has made them a viable platform for m-commerce. It also

allows for relatively computationally intensive 3D programs to run on mobile devices, this is

important to the success of this project. Studies show that m-commerce is becoming

increasingly popular and customers are likely to install a mobile commerce application rather

than a desktop program [3].

With the factors above in mind, this research aims to explore the methods in which laptops,

smart phones, and tablets, with their user interface restrictions and advantages can be used

to provide a solution to the challenge of helping a customer visualise home products.

Furthermore, it presses to overcome the challenge of designing an easy to use and intuitive

user interface for a relatively complex mobile application.

Existing research shows that to be successful at selling online, web designers and developers

are tasked with generating innovative methods of visualising and adverting products [1].

This project researches the challenges with multiplatform development and finding the best

way to handle complex user interfaces with touch screen devices. It Provides retailers with

another commerce channel. Potentially providing an upper hand to whomever uses it to sell

their products.

Furthermore it demonstrates reusability of code. It has the capability to be coded into a client

program and also adapted to a web application, covering two entry points for e-commerce.

It boasts an alternative solution to providing well designed rooms than some related papers

(though they may be used for a different purpose). Retailers could sell a mass of popular

layouts to be used for game development [17].

of 86

This project is feasible to do now because the barriers to m-commerce have been alleviated.

These barriers were pulled down by affordable 3G, and capable mobile devices.

1.1 Aims of Project This project, Mini Architect is a cross platform application that aims provide a medium in

which retailers can advertise their products in a meaningful way. This is done though virtual

reality, empowering the customers the ability to design their own 3D virtual rooms with real

products and share these rooms with other users.

The main aims of this project are:

To develop a furniture arrangement application on mobile devices that allows users

to create and share rooms with ease.

To make use of the touch user interface on mobile devices to assist in arranging

furniture models.

To develop a back end that provides centralised data for all users of the Mini Architect

application.

1.2 Overview of Document

1.2.1 Background Research The background research chapter examines the advantages of m-commerce and why it should

be applied to furniture products. It further explores projects and technologies that are similar

and relevant to this project to give an insight to how this project could tackle the same

problem.

1.2.2 Design This chapter provides a high level view of the design solutions and sketches along with

justifications for design choices made. As part of the iterative development it analyses

observations and interviews conducted to further improve the system.

1.2.3 Implementation This section covers the specifics of how the system was setup and how the design choices

were carried out. It highlights important algorithms in pseudo code and diagrams showing

structure of code.

1.2.4 Testing and Evaluation This chapter tests the system through a set of acceptance tests, identifying whether the

systems are capable of what was initially planned for them. In the evaluation section, a user

feedback study was taken place to verify whether different sections of the application are

easy to use.

1.2.5 Conclusion The conclusion checks the whole project and questions if the requirements and project goals

were reached. It further goes into future development and lessons learned from the project.

of 86

2 Background

This section analyses related academic papers, projects and applications. It covers the

technical problems they encounter when dealing with visualising furniture, and describes

what implications those issues might have on my project. Additionally it justifies choice of

platform and software solutions for this project based on secondary research, through

surveys and device usage statistics as wells as guidelines from accredited design books.

2.1 Visualisation problems with online shopping As mentioned in the introduction section, the problem of online shopping is that customers

are not getting the same experience that they would in store.

This is compliant with various studies, one that claims stores offer a sensory experience and

immersion into the product that online retailers cannot offer, 75% of consumers agreed with

this survey [5]. Thus stores are considered better because than online alternatives because

the customer gets to experience the product using all of their senses. Whilst it’s not possible

to bring every aspect to the user’s home, we can give them better than a 2D image of the

product which currently is the only deployed online visualisation form available for furniture.

The current solution to this issue is alleviated by web applications, zoom tools, 360 viewers

and product videos [13]. Currently IKEA relies on zoom tools to give better detail of their

products. Unfortunately these don’t give a sense of size and colour relative to other products,

this is something that is considered when purchasing furniture but not as important for other

products. These tools are generally used for expensive products like bikes, laptops, and

monitors.

From this 360 viewers may be helpful to the problem, with a 3D viewer the customer would

be able to zoom into the product as well as get a view of the product from all angles. Although

it is important to consider that this would change the web shopping experience as they would

be required to download a heavy web application on arrival of the web page, along with the

models for each product, currently the 360 views are made of a compilation of low resolution

pictures rather than a full product model.

2.2 Mobile and cross platform development A mobile app survey show that users are more likely to download and use a mobile application

rather than install something on their laptop or desktop computers. Furthermore, if only using

a mobile device a user would rather an app over a website due to it being more convenient

and easier to browse providing an overall better user experience [9]. With this in mind the

project will develop for mobile devices first, specifically application based.

Aiming for the market share which is in IOS and Android covering over 79% of mobile devices

[6] it is important that the application works for both of these platforms. There are multiple

options, I could either develop a native application for each. This would require writing the UI

code twice but would blend well with the OS’s user interface guidelines and would provide

the best performance. Create a hybrid app in HTML5 and make wrappers for each platform.

of 86

It would make development time shorter but the performance hit might make the app not

feasible; performance is important as to implement the project concept is going to be

computationally intensive. And finally a cross platform framework could be used, these allow

for the performance of a native application with the development portability of hybrid apps

where only a wrapper is required for each platform [9].

From this it is clear that the cross platform framework is the best solution for an independent

project.

The cross platform framework LibGDX [7, 22]. It is free, open source, and well documented.

It also provides direct access to OpenGLES which will be useful when developing the 3D side

of the project; it is primarily used for developing 2D and 3D games. Mini Architect has similar

technical requirements to a game. The commonality is through the need for a 3D virtual

scene.

2.2.1 Mobile UI guidelines These guidelines are helpful for reducing the complexity of the user interface later on in the

design section.

Both android and IOS have a method for returning through either a hardware button or

software button implemented on the OS.

Figure 2.1 Android navigation bar

The left of figure 2.1 shows a software back button on an android device.

Android design guidelines exclaim “Your app should not add a Back button to the UI” [10].

Removing the back button from the application user interface saves screen real estate and

prevents confusion of having two buttons that have the exact same function. Furthermore,

mobile users’ are already familiar with this design of using their hardware buttons to control

any app.

2.3 Related work

2.3.1 Academic papers This section covers academic papers that are significant to my project. Existing research is

important as it shows the ways the technical challenges that are common with my project can

be solved. These potential solutions are then followed by and reasoning and evidence, this

provides a legitimate basis when justifying my own choices.

of 86

2.3.1.1 Interactive furniture layout using interior design guidelines

This paper has different motives for creating….

Figure 2.2 Screen shot from video of furniture arrangement

Figure 2.2 shows a screen shot from the video demonstration [17]. It shows the user made

room in the main screen towards the left and 3 suggestions made on the right.

Interactive furniture layout using interior design guideline paper presents an application that

allows a users’ to place furniture into rooms and then automatically arrange them [8].

The paper talks about using interior design guideline to do common sense furniture

arrangement such as, not blocking doorways, and paring different pieces of furniture

together.

Furthermore the paper refers to tests they conducted on a relatively powerful quad core

desktop PC which produced suggestions in under just one second. This would likely not

perform anywhere near the same speed on a mobile device. Therefore if implemented for a

mobile device the arrangement function would have to be a lot less intensive than the one

they produced.

This differs from Mini Architect as its aim is to use interior design guidelines and a density

function. This is to provide the user with a number of suggestions to assist the user in creating

a room. Whereas Mini Architect uses user generated content to provide the user with a list

of rated pre-created rooms. Also this is developed for mouse input and was running on a PC,

of 86

a mobile would not provide suggestions in a responsive time. However the methods they use

to let the user define their room could be helpful to this project. Especially the snapping

furniture to walls and creating walls by click and dragging features.

2.4 Existing applications The purpose of this section is to see similar applications to the one that I am trying to create

to find shortcomings as well as what their system offers to help with the design of my

application. I go over the design choices these applications use to solve the problem of

creating a too complex user interface.

2.4.1 IKEA virtual reality IKEA’s home planner web application allows the customer to design their own house. It also

allows them to order all products in that house to the closest IKEA store. From my own

observation it appears that this application has similar aims to my project. [4]

Figure 2.3 Room selection screenshot

The image above shows a screenshot taken the home planner application. We can see its

solution to placing walls consists of giving a few options for the user to pick from a top down

layout. This provides a clean experience when creating a room but does not provide flexibly.

On the other hand, with enough room designs the majority of common room layouts could

be covered. With an added scaling feature for each layout, this could suit my application.

Additionally this simplifies the technical challenges of dynamically create a room along with

their floors.

of 86

Figure 2.4 2D editor screenshot

The 2D view above allows for easy manipulation of furniture but does not offer a detailed

visualisation of the objects that are being placed. The measurements shown in the figure

above would be useful when trying to get an exact fit for a piece of furniture or trying to

emulate your own room as much as possible.

At any time the user can press the cube at the bottom to swap from 2D to 3D view. This is

relatively responsive only taking a couple of seconds.

of 86

Figure 2.5 3D editor and viewer screenshot

The above image is a screen shot of the 3D view whilst moving an appliance towards a wall.

This application is controlled via the bar containing buttons at the bottom. This works fairly

well for a laptop or desktop screen as it saves a lot of screen space for the main part of the

app. This said, for a mobile device with touch input the small buttons would be difficult to

press. Making the UI bigger would consume too much screen space on smaller screens.

The manipulation of appliances through the 3D view has been simplified by removing rotation

gestures/ controls with the mouse. Instead to navigate the arrow buttons are used.

As shown in the image above, moving appliances to walls or other appliances provides a

snapping feature that moves an object to the intended destination. This helps when trying to

get something in place and looking neat. It also makes it quicker to move an item to a

predictable destination (an appliance usually rests against a wall).

Despite the application being complete and functional it is not advertised on IKEA’s front page

as it is not in use. The few products that are available are outdated and not for sale anymore.

This said, for a mobile application this design maybe more appropriate. It is not integrated

with their main website, on product details page it would be expected that a link or widget to

this would automatically add the viewed piece of furniture. The main barriers that would stop

this from working, (assuming that it was deployed) would be that the start-up time is over 15

seconds. This is probably due to having to download the models and application every time

because it is a web app. This time is not acceptable for a mobile application and would cause

frustration which may lead to the user not using it [11]. However with caching of models and

of 86

data should decrease the load time significantly. This will be important part of my project as

users maybe on a data tariff so unnecessary downloading should be cut to preserve data.

Mini Architect aims to give a similar application, with a method of arranging furniture to give

the user a better view of product. IKEA’s home planner differs from the goals of this project

in various ways. Mini Architect aims to provide an application of this style across many devices

and its main aim is to do this with touch gestures as well as some kind of sketching interface.

It also has a focus on sharing create rooms which IKEA’s app does not.

2.4.2 BuildApp This is the most similar application that fits some of the aims of my project and is currently

available on the android market. It overcomes the task of offering complex control to the user

through two planes. One planning plane and a viewing plane.

2D layout tool:

Here we can see the complex UI issue has been overcome by using a 2D room plan view that

allows editing of objects in a room. Thus 3D camera control is not a concern for this part of

the application so no extra buttons are required. Thus resulting in a screen where the main

content is not obstructed or shrunk by the UI. This view worked well for moving walls around.

Also the walls did not get in the way when arranging other furniture and were created by

selecting the pen and drawing on to the grid; the intersect points on the grid make for easy

placement of walls although with less precision it is a good compromise.

Figure 2.6 Build App 2D view screenshot

of 86

Furniture selection dialogue window:

This menu driven solution to furniture selection works well for the small range of furniture

available however if an entire retailers stock of home furniture was present 4 categories may

not be enough to split the furniture in to small enough groups to be searched by the user

effectively.

Although in the images of furniture on the right is very small (because of small screen) it is

still better than not having an image at all. It gives you a lot more informaiton about what

each piece of furniture than just the name on its own. This could be important to use in my

application to help the customer quickly view what products are available, this will help them

select what they want to put in their virutal room.

Figure 2.7 Sub category selection Figure 2.8 Furniture selection

of 86

Outer view screen shot showing virtual house:

Figure 2.9 shows the 3D viewer of BuildApp. This screen allows the user to rotate and zoom

on the scene. Other than the share buttons, these are the only mechanisms possible on this

screen. Interestingly the textures seen in this app are created within the app. An impressive

feature but not helpful to my project. A store often doesn’t have the exact same furniture

with different or customisable materials/textures.

The share features available consist of taking a picture of your creation (without the GUI

overlay) and post to Facebook and google plus.

Although this app has overcome the complex UI issue for the limited screen real estate of

mobile devices, the lack of intractability and placement assistance made it tedious to manage

the room. By far the biggest issue is that placing something on the 2D view may not be exactly

as you expect it to be in virtual reality. The swap between these two views was around 3-5

seconds and more depending on the size of the room, thus making little changes gets

frustrating quickly.

During use on an OnePlus (Modern mobile phone) the application did not perform well.

Dragging walls on the 2D viewer was too demanding, often I found that I would end up

attaching them to things I did not want to. This could be due to the fact it is running two main

functions at once, the 2D viewer which provides the ability to adapt the rooms. It contains

various images all of which you can interact with. It also has a 3D viewer, non-intractable but

shows the floor plan rendered.

Other people through google play store reviews share my issues with performance and delay

switching between views.

Figure 2.9 Build App 3D view screenshot

of 86

BuildApp differs from Mini Architect in that its aim on sharing is through a picture on

Facebook (to provide the app with publicity rather than share content). Additionally

BuildApp’s main focus is to simulate your own house as true as possible with taking photos

and using them as textures for walls; Mini Architect aims to show new products as opposed

to redesigning ones that you already have. This said the method of furniture arrangement and

camera control are still useful to this project.

2.5 Summary Background research has given the project a direction on how to design the system and what

tools should be used. It has suggested that a cross platform framework would be better than

manually coding each platform, considering this is an independent project and there are time

constraints.

Existing web application solutions to arranging furniture are difficult to use and don’t have

any option to display pre-created room. This means that the user has to create their own

room from scratch with their “Home planner”.

IKEA has been experimenting with similar apps to try and find an innovation that solves online

shopping for furniture. From this can deduce that this research and development into this

area will be valued. The applications IKEA have produced have not been updated with new

items and is now not useful as the few items it was originally populated with are not sold

anymore; the current solutions to this problem have not taken off.

The original idea for this project, as mentioned in the proposal at appendix 11.5, was to

separate the control plane from the viewing plane by using a 2D layout screen and 3D viewing

screen. However this project will not use a separate 2D view because it’s made the “BuildApp”

android application slow and frustrating to move from one view to another. This is a problem

with the power of the hardware and would be difficult to solve.

Related academic papers described in this background section focus on auto arrangement of

furniture. This said, for placement of furniture they use pair wise matching and define

constraints to help match different pieces of furniture together. Grouping and snapping on

constraints is a feature that could help for manually arranging furniture.

of 86

3 Design

3.1 Introduction This section describes how the final design came around. The designs include reason and

thought behind the user interface, general architecture, choice of tools, and platform choice.

Design planning is important to ensure that incorrect and unnecessary features are not

implemented. Doing so is time consuming and thus is why this stage is important in the

project.

3.2 Design Process

Figure 3.1 Design process diagram

Figure 3.1 shows the design process of this project. The main part of it is the iterative

development with user centred design. The aim of this to develop a prototype, get user

feedback and then improve on the prototype.

3.3 Design Considerations This stage ensures that ideas for the project gathered from background research and problem

analysis are feasible in 20 weeks. This will help direct the project to provide potential ideas

for the problems listed earlier.

The following sub chapters listed here represent a single feature or idea and are an aim to

solve part of the problem. Thus the final project will need a combination of these together.

These ideas have been influenced by existing applications and papers mentioned in section 2.

This is one to see what is possible (from the background research).

3.3.1 3D Viewer Basic 3D viewer for products that would allow the user to interact with the object and see all

sides of the product. This is similar to existing web applications for displaying expensive

products like laptops and monitors.

This would be relatively easy to implement and could be an effective addition to a program.

But not the main feature. It would require any relatively new smartphone to run the program

at a smooth frame rate. This is because only one object would be on the screen at once

of 86

3D viewer is part of the overall solution, it could be used to show one model at a time in high

detail. If mobile devices struggle too much with multiple models loaded at once this showing

one high detail and multiple low detail models will give the best of both scenarios.

3.3.2 Assisted Room Creator Assisted room creator would be the main part of the application that will provide the user

with tools to create a virtual room but also guide their creation. This could be either through:

Auto placing sets of furniture for the user, snapping furniture into place

Grouping furniture and making them act as one.

Making placement of furniture as painless as possible with natural gestures or

something better.

Providing half done or a library of pre-created rooms.

3.3.3 Multiplatform Create the program on more than one platform to expand the market audience for the

application.

Being platform exclusive has the advantage that you only need to develop one application

which makes maintaining and support easier as well as the initial development cost and time.

This could be difficult to implement. The options are to either use a framework which won’t

be able to take advantage of the platforms user interface guidelines and adaptors or native

development for each application will be required which would mean interface code would

have to be recreated for each platform.

3.3.4 Content Sharing This will allow the users to view rooms that have been created by other users. This is a solution

to having the retailer create rooms for every new set of furniture they sell.

Depending on the complexity of the rooms this could be difficult to implement. Uploading the

whole room including details about textures, nodes, materials, transform would not be

feasible. A reduced version of the room would have to be shared.

3.3.5 Sketching based control With touch devices gesture based control is one of the more natural ways to interact with an

app. This could involve placement of furniture and or something to interface with the

furniture.

It is important to mention that an alternative might be required for a desktop application.

Although gestures can be done with the mouse, a menu could be easier and would definitely

be more familiar.

By default the android only has basic gestures. Custom gestures would require another library

or an implementation. Providing a library was used this should not be too difficult to

implement but could be difficult to get working with a large amount of different gestures.

Additionally a method to let the user know what gestures are possible would be required.

of 86

3.3.6 Menu driven control This is going to be required somewhere in the application to let the user navigate into

different functions. But it could also be used for the main function. As well as this it could be

used as an alternative for the gesture control.

This should be relatively easy to implement. That said consideration on how it would be laid

out for mobile devices with small displays would be required. Too small buttons and text and

the navigation is fiddly and frustrating, too large and it quickly eats up screen real estate which

might be needed for the main function of the application.

3.3.7 Grid based wall placement Grid placement, as mentioned in the background section for the “BuildApp” android

application this worked well for the 2D view. As I have decided against using a 2D view this

would have to work in 3D. This in combination with the sketching based control could create

walls based on drawing lines across the screen.

Grid based placement for all furniture is also an option but it may limit the user creating too

much and make the application similar to a game rather than a furniture arrangement

application.

3.4 Design choice This section describes my justification for design solutions selected from above.

My initial design choice includes mixing 3.3.6, 3.3.5, 3.3.4, 3.3.3 listed above. This is subject

to change based on user evaluation and whether or not it is practical to implement.

I have chosen to create and assisted room creator application instead of a room generator.

This is because the idea for generating rooms has already been created and applies less to the

selling online problem; allowing the user to create their own rooms allows them to match

their current setup in their house and replace their existing furniture with what they want to

buy.

Furthermore allowing users to share and vote on creations they have made will populate the

app with a diverse range of rooms. If these rooms are voted on the top rooms show be

relatively high quality, and debatably more idea to the customers than an automatically

generated room that was made following design guidelines.

For the main form of input for the application sketching based control will be used. This is

because the primary use of the application will be on mobile devices to support m-commerce.

As mentioned above gesture based control is favourable over menu driven control for mobile

devices. How far this extends will be limited to the amount of unique gestures can be created.

It would not be possible to create a gesture for every piece of furniture.

Developing over cross platform will give a greater range of users’ access to the application.

This will be done via a framework which will allow for the code to be created once and used

on various platforms.

of 86

Although an option to auto generate and assist room creation could be combined together

that would take too long to implement during the 20 weeks for this project.

3.5 Requirements Now the preliminary design choices have been made, requirements gathering for the server

and application are required to ensure that the system being developed meets expectation.

The stakeholders in this system include:

The customer. This is person using the application.

The admin. Manages the server.

The retailer. Updates the system with new products

The following requirements explain how the server side and client side parts of Mini

Architect’s system should function (functional requirements) and information about

resources, efficiency, and performance (non-function requirements).

3.5.1 Front-End (Application) Requirements Functional requirements

Requirement #1 The app shall allow users to share generated content

Reason As previously mentioned in the background, user generated content is a solution when there is a need to produce a lot of content that is targeted and applicable to the customers. This app would potentially host a lot of different products, manually creating high quality rooms to show would be time consuming.

Priority HIGH

Requirement #2 The app shall work in and be native for browser as well as IOS, android, and desktop

Reason Opens the market audience up to all platforms. Native applications are important, as mentioned previously, this 3D heavy application would not run well on mobile devices if served through html5.

Priority MEDIUM

Requirement #3 The app shall enable the user to create rooms.

Reason Most parts of the app depend on this. Without room creation no rooms would be shared so only pre-created content would be viewable on the app.

Priority HIGH

Requirement #4 The app shall provide a list of rooms categorised

of 86

Reason Giving the users the ability to search for top rated rooms first will help them see the rooms that are popular and more likely to be designed well.

Priority LOW

Requirement #5 The app shall provide an accounting system

Reason The accounting system will allow users to track their own rooms.

Priority LOW

Requirement #6 The app shall show prices of rooms and models

Reason Knowing the price of rooms and models will affect the customers actions, maybe even negatively, but without it customers may be reluctant to use the app if they only know the price upon checkout

Priority HIGH

Requirement #7 The app shall let the user get to main part of app swiftly (jump into functional part of app)

Reason As mentioned before entering an app and getting the apps main purpose is shown to be important. If it takes a time and is frustrating to get to the main function then the user is less likely to come back to the app after their first try.

Priority MEDUIM

Requirement #8 The website shall provide similar functions to the app

Reason For users with only desktop computers the website will be there only point of online contact. The website can be used to host the app along with a store.

Priority LOW – but if implemented on a real retailer’s website then this would be more important. Users go to the website before downloading the app if ordering online so it would be an entry point for the application.

Requirement #9 The app shall provide a method of using app without account creation. Similarly remember if a user has already logged in/.

Reason This helps to get the user into. Again mentioned in the background section.

Priority MEDUIM-HIGH

Non-functional requirements

Requirement #10 Scales for new devices

of 86

Reason Old applications that haven’t been updated recently for devices on all platforms suffer from not scaling properly on new high density displays.

Priority LOW

Requirement #11 Varying internet connection – environmental

Reason The app will require internet connection at some point for new content updates and users sharing rooms. It is important the app either watches the state of the connection or handles when a request fails due to no internet connection.

Priority LOW

Requirement #12 Provide user friendly interface, on all devices. Specifically room creation should be intuitive and easy to use.

Reason The main part of the app where all content is generated. It is important that this works well as it is needed to let the users create content that they will share. Thus to view good rooms, a good interface on creating them will be needed.

Priority HIGH

3.5.2 Back-End (Server) Requirements Functional requirements

Requirement #13 The server shall provide a means for adding rooms

Reason Rooms have to be added to server to allow users to share and download rooms

Priority HIGH

Requirement #14 The server shall provide a list of rooms in selected orders

Reason Giving the users the ability to search for top rated rooms first will help them see the rooms that are popular and more likely to be designed well.

Priority LOW

Requirement #15 The server shall allow adding of accounts

Reason The accounting system will allow users to track their own rooms.

Priority LOW

Requirement #16 The website shall allow a means to add news

Reason The news aspect gives a way the user can see new furniture.

Priority HIGH

of 86

Requirement #17 The website shall allow a means to add new models

Reason The retailer stakeholder will want to be able to easily add new products to the application.

Priority HIGH


Requirement #18 Performs under heavy load – user capacity

Reason Sudden popularity in an application can lead it to a quick death. If a low capacity server has been used for feeding the app content and a sudden increase in users occurs the servers performance will be impacted which will adversely affect the experience for all users.

Priority LOW

Requirement #19 The website should be secure

Reason There is no user information to be stolen so this is just for maintaining services for the app. The website and app server are both running on the same server.

Priority LOW

Requirement #20 The website should not allow downloads directly (limit bandwidth)

Reason Stops unnecessary traffic from to the server which should be used for the application. Additionally the server is rented and charged by bandwidth usage.

Priority LOW

Now requirements have been identified, design of the back end and front ends of the project

are next. The following sections go into details about how the server with interact with the

application, along with how the application will look and function

3.6 Back-End (Server) Design This project requires a backend to handle data that will be shared between multiple users.

Additionally it is required to hold furniture models and their prices. If used in production, the

models, news, app data, would be updated frequently to keep up with the retailer’s new

products and developments. A server is required to provide a centralised database for the

application to update itself and share data. It will act as a model and control whilst the client

views the information.

The database shall hold information about publish rooms and registered users. The rooms

table will contain a description, owner, and price of the room along with a list of model

of 86

identifiers with their respective rotation and location. Register users will hold a password and

username for login purposes.

The server will have to host other information which is not advantageous to hold in a

database. The application has to update with new stock and news. This will be done by file

hosting the models and a news and data file. These objects can be downloaded and

deserialized by the application at start up.

MySQL will be the database used for this project. Using MySQL through android directly is not

secure and susceptible to hacking. Android applications can be decompiled back into human

readable code. Any account used to access MySQL would be easy to obtain.

Using multiple PHP scripts as an interface to MySQL solves this problem. All account

information to access MySQL is stored in the PHP file which cannot be seen by anyone other

than the server administrator.

The application will require PHP scripts with these functions:

Uploading rooms

Rating a room

Requesting rooms by top, random, or username.

3.7 Front-End (Design Sketches) This section entails the design of the front end of the system (the client application).The

design sketches are mock drawings of how the user interface might look, a brainstorm of ideas

before the first prototype. The following shows some of the mock designs I created and the

reason behind the design that I chose.

The user interfaces created here have been done so with the knowledge that it is going to

work within the Libgdx framework. UI design in Libgdx is covered by, windows, dialogs, tables,

labels, and buttons. Thus these restrictions have been taken into consideration to make sure

designs are possible to implement.

3.7.1 Home screen designs This screen is where the user lands when first launching the app. Two designs have been

considered, both are similar but make use of screen real estate and application activities

differently.

3.7.1.1 Design 1

of 86

Sketch 1 Home screen 1

Sketch 1 shows the home screen, this screen is where the application starts. Two clickable

options are given to either login with your account or go through as a guest. The login button

will provide a dialog to with user name and password section, as well as a method to sign up.

When either of these are clicked, both will be replaced with a fragment, this will give options

like room shape and other uploaded rooms to load and modify.

3.7.1.2 Design 2

Sketch 2 home screen design 2

Design 2 differs from 1 with the login and guest buttons replaced with a settings cog. On first

login the user is logged in as anonymous. This removes the extra navigation step in order to

get to the main function which is less frustating. (Explained in the background)

of 86

The room design and view rooms buttons will launch a new screen instead of merging into

one window. This will separate selecting uploaded rooms from predefined walls, this will be

easier fit all list items in one screen.

The news window shows were update information will be displayed, more informaiton

bellow.

3.7.1.3 News window design

Sketch 3 news window design

Sketch 3 shows the news window in detail, it shall consist of a scrollable list of cards, each

with a picture, information, and price, or just text. Designed to advertise new products along

with textual update information.

3.7.1.4 Home room design choice

From these two sketches home screen #2 is better suited because it lets the user jump straight

into the app. The settings button is commonly used on apps so the user should be familiar

with its function.

of 86

3.7.2 View rooms

3.7.2.1 Design 1

Sketch 4 View rooms design 1

View rooms screen is shown after the view/browse button is pressed on the home screen.

Sketch 4 shows the first design for the view rooms’ screen. This screen allows the user to look

at rooms created by other users.

The buttons at the top filter the scrollable list view into date, top rated, and logged user’s

rooms.

Each list item contains a name/description, total price of all product with in it, and an up and

down vote buttons. These buttons push items up and down the list, this will push the better

rooms to the top of the list.

of 86

3.7.2.2 Design 2

Sketch 5 View rooms design 2

Sketch 5 is the second design for view rooms’ screen. It’s slightly different but still keeps the

scrollable list view, it needs to be able to show an infinite amount of items so it stays in the

design.

The up vote button has now changed to just a thumb up. The down vote button is unnecessary

so has been removed for a cleaner UI.

The filter buttons have been moved to the left because the room name, username, and price

do not take up much room horizontally, therefore moving it provides more space for viewing

rooms on one screen.

3.7.2.3 View rooms screen choice

Out of the two designs the second design will be used for the prototype. Picked because of

the better use of screen real estate.

of 86

3.7.3 Arena

3.7.3.1 Design 1

Sketch 6 Arena design 1

Sketch 6 shows the overview for the arena screen, the main part of the application. The UI

has various buttons and point of interaction.

The camera button at the left bottom hand corner are used for navigating around the virtual

3D room. As with other solutions mentioned in the background, there is always a separation

between moving and rotating furniture, and moving the camera. As there is no 2D view in this

app for arranging, a toggle camera button will disable the interaction with objects and

dragging on screen will move the camera.

The “DELETE” zone at the top is where arena items will be deleted. This is opposed to adding

a delete button or gesture delete. Instead swiping the object up will delete it.

The list on the right shows categories that furniture will be stored in. Once clicked they will

then expand into another list with furniture. Possibly after the first prototype pictures will be

added, similar to the “BuildApp” analysed in the background section.

of 86

3.7.3.2 Category window design 2

Sketch 7 Arena window design 2

Sketch 7 shows a tree style list, still similar to design 1. Each category will be expandable,

revealing the furniture items within that category. The indentation may take too much room.

3.7.3.3 Category window design 3

Sketch 8 Arena window design 3

Sketch 8 shows a development of the last two. A swiping interface allows the user to change

category. The arrow buttons are an alternative to change category.

of 86

3.7.4 Screens navigation overview

Figure 3.2 Screen navigation

Figure 3.2 shows the navigation of the chosen designs above. There are three main screens,

the main menu screen is where the application starts on launch. The other two screens revert

back to the main menu via the hardware back button.

3.8 Use cases

Figure 3.3 Use case diagram

This use case diagram provides a high level graphical overview of the functions capable

through the application and website.

Use case name: Create room

Scope: Application

of 86

Primary actor: Application user

Secondary actor: None

Summary: Provide the user with the means to create their own room from

selected furniture.

Preconditions: User has downloaded models (requires internet connection)

Main success scenario: 1. User places walls

2. User places and arranges furniture

Alternatives: None

Exceptions: None

Post conditions: A room has been created. The user can decide if they want to

upload it.

Use case name: Publish room

Scope: Application and server



Summary: User is satisfied with their room and wants to share it. Publishing

lets others see and rate their creation

Preconditions: A room has been created and device has an internet connection

Main success scenario: 1. Up arrow button is clicked

2. User fills in description

3. Publish button is clicked

Alternatives: 2.1 Cancel button is pressed

Exceptions: 2.1 No room description was entered and notification pops up

2.2 User fills description

3. Publish button clicked

Post conditions: Window closed, contents of room and user details are uploaded to

MySQL table rooms

of 86

Use case name: Browse rooms

Scope: Application



Summary: Displays a list of rooms which the user can order, vote on, and

edit.

Preconditions: Models have been downloaded (Internet connection required)

Main success scenario: 1. User searches for desired room

2. User selects room

3. Room is launched into editor

Alternatives: 1.1 user selects top rooms

1.2 user selects my rooms

1.3 user selects new rooms

Exceptions: 1.e User does not have internet connection and no rooms are

downloaded

Post conditions: Arena screen is launched and populated with furniture and walls

Use case name: Add content

Scope: Server and application

Primary actor: Retailer

Secondary actor: Admin

Summary: Retailer adds new product to database and server file store

Preconditions: Retailer has registered admin account

Main success scenario: 1. Enter username and password

2. Login

3. Select file to upload

4. Upload file

Alternatives: None

of 86

Exceptions:

2.1 login failed

2.2 redirected and login again

4.1 file is too large over 50mb

4.2 upload again with smaller file

Post conditions: Model uploaded to server

Use case name: Authenticate

Scope: Application



Summary: User logs in to edit rooms under his name

Preconditions: User has an account and internet connection

Main success scenario: 1. Enter login details

2. Click login button

3. user logged in

Alternatives: 1.1 Shared preferences loads login details automatically

Exceptions: 1.2 Password incorrect

1.2 no internet connection exception

Post conditions: User logged in and preferences are saved

Use case name: Create account

Scope: Application



Summary: User creates an account and it logs in

Preconditions: User has internet connection

of 86

Main success scenario: 1. enter account details

2. create account

Alternatives: None

Exceptions: 2.1 No internet connection

2.2 Account already exists

Post conditions: New account create and auto logged in. Account saved to shared

preferences

Use case name: Vote on room

Scope: Application



Summary: User clicks up vote on an existing room

Preconditions: Internet conneciton

Main success scenario: 1. user clicks thumb up

2. room moves up the rankings

Alternatives: 1.1 user has already voted so nothing happens

Exceptions: 1.1 user has no internet connection, nothing happens

Post conditions: Room has moved up the rankings

of 86

3.9 System architecture

Figure 3.4 System architecture diagram

Figure 3.4 shows a client server model architecture overall with a layered system for the

clients.

3.9.1 Architecture rationale I decided to use client server architecture for the design because the application will be

updated continually with new models, news, and rooms; the application will download new

content on initialisation.

Furthermore, there will be many instances of this app across different phones (clients), so it

should be able to access this data from a range of locations. It also makes sense as it allows

for centralised control for adding new products to the market.

For the smart phone app I decided that a layered architecture would be good because when

using the app you need to go through different parts of the application to access and update

certain pieces of information. So in my design the user has to interact with the application’s

interface and authenticate before they can access any of the functions in the application.

As well as this a layered approach should provide with easy and clean extensibility and

swapping of modules of the app because of the modularity of the style.

3.9.2 Module breakdown

of 86

3.9.2.1 Client Interface

The interaction between the client and the application. This could be different depending on

what peripherals are connected to the device. For example the touch features will work both

with a mouse and touch display on a PC in the same way that they work on android.

3.9.2.2 Authentication

This module is optional as creating an account is not required. That said it is a valid layer

because if the user has not created an account then they are authorised as “anonymous”.

This will connect to the accounts database.

Authentication is also included for the admin panel on Mini Architects webpage. For this

authentication is required as it allows the admin to change products and news

3.9.2.3 View room

Viewing rooms’ lets the user look at rooms others have already created. This page will include

the uploaders user account, the price of the room, and a description of the room.

It has these features:

Vote on rooms

Filter rooms

Load into other room

3.9.2.4 Load room

User can load one of their own previously created rooms or load a new empty room. The data

from load room comes from the rooms’ database located on the server.

3.9.2.5 Room editor

The room editor is the main part of the application which is accessed after going through the

other modules. It is used by load room to load a user generated rooms and uses publish a

room to the server.

3.9.2.6 Publish

The publish module is accessed after the user has finished using the room editor and is

satisfied with their result.

It carries information about the contents of the rooms and the user that created it.

3.9.2.7 Server

The server module is where the data for the application will be stored. This data is stored in

a MySQL database that is accessed through a PHP interface. It will be hosted on a virtual

machine to allow for expandability.

of 86

3.10 Application Prototype The first prototype was created to get user feedback to improve the UI and usability of the

application.

Below are the screenshots from the prototype application running on Windows 8.

3.10.1 Home screen

Figure 3.5 Prototype home screen

3.10.2 View rooms

Figure 3.6 Prototype view rooms screen

of 86

3.10.3 Arena screen

Figure 3.7 Prototype arena screen

Although the above screens are captioned prototype, all the features are there and are

functional. The next section evolves the UI and improves it based on a user centred design

done through observations and interviews.

3.11 Iterative design

3.11.1 Observation and Interview As part of the iterative design applied to this project a guided observation was undertaken

after the initial prototype of the application was created. The purpose of the observation was

to judge how the application would function whilst being used by a user and not a developer.

For this I talked before to the participant explaining the purpose of the application and the

reasons for which I was observing.

The observation consists of a asking the user at various points to do different tasks to cover

all the main mechanisms in the application. Then afterward a few questions are asked about

their opinions of the application.

The first observation is as follows:

Brief: “Mini Architect is a free furniture arrangement application that lets you plan your own

rooms in a 3D virtual environment. Its purpose is to help you visualise the furniture and place

it in a virtual room that is a model of your own home.

Task 1: “Click on the Mini Architect application and create a room of your own choosing”

P1 starts by clicking the application, waiting a second for it to launch. Next they select the

“CREATE NEW ROOM” button and the app launches into its main function.

of 86

P1 spends a few minutes creating a room, successfully rotating and deleting objects without

any intervention. Object snapping occurred and p1 instantly realised its purpose. P1 quickly

understood the menu system and has manage to orient the camera.

After a while the user had nearly completed the room. I then asked “Can you now add some

walls to your room”

The user looks around for a bit, scrolls on the list and notices the foundation category. Then

they click on it and click on wall. Nothing happens. They then move their finger on the screen

and notices that it places the wall. They then drag and delete the wall and start again drawing

a line around their furniture. Walls have now been created.

The user clicked the pen and drew a line but struggled to figure out how to use it. They

progress with a half-finished gesture.

Next I ask “Now publish and share the room that you have created”.

P1 finds the publish button but clicks publish with no title added to the room.

After room creation and submission p1 is asked “Now find your room within the application”

User then looks around, presses the back button on the categories window. Nothing happens.

They then find the button on my phone to which they return to the main menu. Then they

select the view rooms’ button.

Next p1 tries to find their room but cannot see it (They did not tag it with any other title and

there are a lot of rooms currently uploaded). After scrolling they clicked the “my rooms”

button and find the single result.

Post-observation questions:

Do you own or actively use and android device?

P1: “No”

What problems did you encounter when doing the tasks?

“The window on the right on the main page, er, the buttons were kind of too small and a bit

fiddly when pressing.”

“Whilst placing the walls with all the other pieces of furniture in the room, it was difficult to

select the piece of furniture that I wanted.”

“I selected the pen and dragged along the screen and it drew a line. I was not sure what it was

for.”

What parts of the application did you like?

“The magnet feature when pushing pieces of furniture together. It came useful when a lot of

appliances were added.”

of 86

3.11.2 Summary This observation has highlighted some optimizations that need to be made to the user

interface.

The main issues that I observed were:

User did not realise what gestures were available.

List items were fiddly

Walls took a try before getting right. Also walls got in the way a bit.

No context when picking a room from room finder.

3.11.3 Analysis The problems emphasised above can be resolved by creating a help screen that contains the

available gestures. Also increasing the size of buttons in the category viewer window should

make it easier to select a list item.

The issue with walls did not ruin the experience but maybe able to be done better. A block

wall placement (as discussed in the background) could be a better solution.

3.11.4 Iteration of design Arena screen with a question mark button for help dialog.

Figure 3.8 Arena with help

of 86

After help button is pressed, a dialog opens and show a scrollable help screen

Figure 3.9 Arena help dialog

View rooms, now with pictures so you can see the room before entering.

Figure 3.10 View rooms screen with images of rooms

of 86

4 Implementation

This chapter describes the systems in Mini Architect, explaining how they were built

throughout the project. It goes into detail about the primary algorithms used in the

application. The role of the frameworks, libraries, and tools are clarified along with how they

assisted implementation of the project.

4.1 Class diagram overview This initial class diagram is to show how each class relates to each other, methods and

attributes of classes have been remove from this diagram for simplicity to help get an

overview of the system.

Figure 4.1 class diagram overview generated with eclipse plugin UML object aid

of 86

This shows the overview of classes in this project. Looking at the top of figure 4.1 there are

two classes, Android launcher and Desktop launcher, these two different wrappers for

launching on a different platform. Note that the full class diagram is available in the appendix

4.2 Tools used Various tools including libraries, frameworks, services, and editing software was used during

the creation of Mini Architect. Next describes each tool along with its purpose.

The most important tools used in this project were:

Github

Gradle

Libgdx

Amazon ec2

$n gesture library

Jsoup web request library

Languages

JavaScript

PHP

Java

4.3 Observer architectural pattern Model instances (and anything else touchable) implement a touch listener which allows them

to be iterated over upon a touch event. Touch listener provides events for touches, panning,

dragging, and zooming.

This creates clean division between classes, this way the logic is not split across multiple

classes. Each object deals with itself, if it gets rotated, moved, selected, or deleted.

As many models instances are going to be added and removed, a modular solution was

required, which is why I choose the observer pattern.

The observer pattern is used throughout the project, buttons, arena items, scrollable lists; all

use the observer pattern to gather and process user input.

4.4 Paint application This basic program was the starting point for the implementation of the project. Its purpose

is to show the user progression whilst they perform a gesture.

of 86

Figure 4.2 Paint example, shows how paint texture is made

First it starts of by checking if user is drawing, this is done through the pen button on the

Arena screen.

Mobile devices have around a 100-200ms latency for touch input. When creating a paint

application this causes gaps in drawing. Easy solution is to draw lots of separate 2D textures

between current touch point and last touch point. But after several seconds of drawing on

mobile effect performance drastically.

To combat this I take touch points every 100ms and create one longer texture that’s size

depends on the gap between two touch points. Then it is rotated and translated to the lerp

of the two touch points.

After a 3 finger press, the drawing is cleared, drawing is deselected, and the gesture is parsed

to the gesture recogniser ($n) [21].

4.5 The scene and arena items The scene is the Arena/3D virtual space. It manages the models and user interaction between

them.

Observer pattern mentioned above helps managing when using a large amount of model

instances. It fits nicely with the heterogeneity of different products, allowing for each instance

to implement a listener so that it can handle its own touch input.

The Arena class contains the scene which includes all Arena items (model instances) stored in

an array list. This is important to many aspects of the program; each of these models needs

to inherit the same methods and include the same variables to allow interaction between

them (node snapping and grouping) and to make uploading and downloading rooms work for

any amount of new products.

This extensibility means that extra coding is not required when adding new products to the

store. Assuming they implement the same interface, they can be added at run time with no

extra intervention.

One sprite,

extended and

rotated

of 86

4.6 Node detection algorithm Node detection is required for snapping objects together. Object snapping, as mentioned in

design, should only work between select objects. Node snapping was an idea produced the

academic paper review in the background section 2.3.1.1.

Rather than hard coding every single product a product can snap with, types have been used

to simplify the process. For example, any type of chair should be able to be snapped to with

a specific table.

As new products can be added, this node data is stored on the server and is downloaded on

application start up. This allows the retailer to add new node points for new products.

JSON was used to allow for easy loading in once downloaded. The structure is the following:

{ "items":[ {"item": "diningroom_table_wood table QQQ100.g3db", "nodes":[ {"x":0.85217816,"z":-0.2564806, "roty":0.7069864,"rotw":0.7072265}, {"x":0.8604511,"z":0.6867062, "roty":0.7069864,"rotw":0.7072265}, {"x":-0.86872506,"z":-0.51296127, "roty":-0.70717543,"rotw":0.7072265}, {"x":-0.8273571,"z":0.40540493, "roty":-0.70717543,"rotw":0.7072265} ], "connector":"chair" } ] }

Figure 4.3 “Node.json” file extract

Above shows that the nodes.json file includes a list of products, each product includes a list

of nodes. Each node has the orientation and location that it wants another product to snap

to. Finally it has a connector, this defines what types of furniture can attach to this product.

Below shows the graphical representation of nodes at application runtime.

of 86

Figure 4.4 Node proximity explanation aid

Figure 4.4 show that when a chair (or specified object) comes in contact with the nodes

parameter, it snaps into place.

As each model in a scene may have these nodes, lots of checks will have to be performed on

item movement.

Pseudo code for node detections (located in ArenaItem class):

For all nodes in this scene If this object within this node perimeter then Set rotation (nodes rotation + my rotation). Set translation (nodes translation + my translation).

Figure 4.5 Pseudo code for node detection and object snapping

I decided against automatically grouping the item upon attachment; if accidently attached,

the user would have to ungroup the model. Unnecessary ungrouping gestures could become

frustrating, more so than the convenience of auto grouping would provide.

4.7 Wall creation algorithm The application allows users to create custom sized walls through a gesture. They draw a line

between two points and it creates a wall to that length, rotation, and translation. The

algorithm used for this is similar to the solution used for the paint application.

After wall has been selected in the category window under foundation, a wall listener is

started. This records the first touch-down and touch-up after wall list item has been selected.

Then the distance between two points is calculated, then a 3D cuboid is created with the

distance as length. It is then placed to the linear interoperation of the two points and is

rotated to fit the line.

The following screen shot shows how the wall creation works.

Node proximity

of 86

Figure 4.6 wall creation demonstration

This code is situated in the wall listener and Arena item classes. It is activated by a listener.

Pseudo code:

On touch down and touch up then Get Intersection of both touch rays with z plane. Calculate Euclidean distance between points. Calculate x and z length of touch rays. Rotation = Atan2(xLength, zLength). Position = linear interoperation of both touch rays. New ArenaItem() rotate, position. Dispose of drawing.

Figure 4.7 Pseudo code for wall creation

After a wall is created, the wall listener and drawn line are both deleted to preserve resources.

4.8 Uploading room Uploading rooms is an essential requirement of Mini Architect. They need to be uploaded in

a format that means that it can be shared and downloaded by other users, and be used to

create new objects on the fly, so that they can be viewed at runtime.

For this, JSON to Java conversion is used. Initially, on the first attempt the entire 3D scene was

saved and loaded, this was far too large at about 80mb per filled room. This is because it was

including information about models, textures, and materials that were not necessary and

already stored on the device thus didn’t need to be duplicated. Uploading to the MYSQL sever

via HTML and POST would not work as is too big, so is not an option.

Drawn line where wall is to be placed Previous drawing result

Create wall list item

of 86

The solution to this was the creation of the MinimalItem class, as a scene consists of various

ArenaItem objects, that was the bulk of what was being uploaded were these models. The

MinimalItem class is used to convert an ArenaItem into a simpler form that only contains:

Model name

Rotation

Translation

After conversion, rooms where a much more reasonable size for uploading at about 6KB for

a room filled with objects.

4.9 Downloading and file storage Mini Architect has to download various files on application run time to function. This is

required to get new content to the application without performing a full store update for all

platforms as management over these would be difficult (further described in the background).

Saving of files is handed differently on different platforms, on pc its stores downloaded data

in the root of the application folder (where it is installed). Android and IOS have specific local

storage for applications that is hidden from the user, this is where files and local preferences

have been saved.

The application has a potential to download a lot of information, therefore the

implementation of this needs to done conservatively to save mobile data and reduce loading

times.

These parts of the application are updated:

News card updates

User generated rooms (potentially massive)

Models

Product information

4.9.1 Models Upon application start, before loading anything it points to the server located at this site,

https://lyndonfawcett.me/models/ (contains products). Firstly it downloads the directory

listing of the website, then starts striping the page for all links containing “.g3db” (model

extension).

It then cross matches these models with already downloaded models, then continues to

download only the models not in the original set. This stops unnecessary downloading of all

models every application start, thus saving bandwidth and improving loading time.

These models are loaded into memory and are saved to local stored storage to be reloaded

later.

https://lyndonfawcett.me/models/

of 86

4.9.2 News The news is downloaded from http://lyndonfawcett.me/miniarchitect/news.json and is used

to fill the cards within the news window on the home screen.

{ "textcards":[ { text:"Welcome to Mini Architect!" }, { text:"New bedroom furniture just in!" } ], "imagecards":[ { text:"Modern wood", price:"Â£150", image:"bedroom.png" } }

The news.json file consists of both image cards and text cards. These are used to present

information about application updates and new products through the news window.

4.9.3 User generated rooms In Mini Architect, rooms generated by users are uploaded to the server. There is a potential

for the server to host a lot of rooms at one time depend on the size of the user base. This

means that downloading all of them at once every time on start-up could be time consuming.

Instead, the application only downloads room data on the view rooms’ screen, when a filter

button is pressed. The query sent returns the first 100 JSON files that include data about the

rooms. Only 100 requests are handled at once as to not make downloading take a long time.

4.10 Rotation Rotation is not supported by android or Libgdx but is needed for layout of furniture in this

application. This meant that it had to be implemented for this task. Looking at papers on multi

touch gestures aided an idea of how it can be implement. [14, 20]

Simple rotation algorithm of model:

1. After a model in the scene has been selected rotation can occur.

2. Each instance waits for touch inputs, if two are made rotation is initiated.

3. It detects if the touch points are being dragged

4. Then runs through a series of checks between the point to get direction of rotation

5. Rotate object by latency between each frame (frame rate).

http://lyndonfawcett.me/miniarchitect/news.json

of 86

Rotation starts getting complicated when objects are grouped together and want them to

rotate as one unit. This is where the middle object rotates with the axis in the middle of it and

other group objects orbit around it

Figure 4.8 Sketch explaining rotation problem

Figure 4.8 shows a table and chairs around it. These items are grouped and the table is the

parent. On rotation the table should spin on itself whilst the chairs should rotate around

whilst rotating on themselves.

Orbit algorithm (applies to both models instances and nodes)

For groupMember in group Z=thisDistZ-groupMemberZ X=thisDistX-groupMemberX Angle = atan2(z,x) + RotationAngle; //Project rotation on vector X= cos(angle) Z= sin(angle) groupMember.translateTo(x+thisX,z+thisZ) groupMember.rotate(angle+groupMemberAngle) groupMember.updateNodes(angle)

This algorithm rotates models around other models whilst handling their children through

update nodes.

4.11 Scene photo Adding pictures to the view rooms’ page was an idea generated from the user centred design

to help them pick the room they want to see.

of 86

Scene photo works by hiding the entire UI in the arena class and dumping the OpenGLES

buffer into a pixel map and then uploads that to the server to be saved. This is then ready to

be downloaded by a user browsing.

At the moment it takes a full screenshot. It could be further improved by taking a defined size

image or compressing the image to save time and data on uploading the image.

4.12 Technical challenges The main technical challenge was working with multiple resolutions and pixel densities.

Resolution independence was created by making multi sized fonts and taking pixel density

into account when scaling user interface.

Another challenge was the performance. When working with the old Nexus 7 tablet, using

over 20 items in a room adversely effected the performance of the application. This has been

reduced as much as possible by reducing the models vertices count.

When uploading and downloading rooms, the client has to handle it if a connection has failed.

Currently the problem is handled and nothing happens, the user can then repeat the

operation.

4.13 Server implementation The server part of the project provides a centralised point of data for the application. It allows

for updating new products, managing of accounts, and hosting user generated content. It also

runs the website which is an entry point to download the app and get to the admin panel.

Amazon ec2 service is used to host the server. It runs a minimalist version of Ubuntu with

Apache, PHP, and MySQL services. Further it provides elasticity as mentioned in the design, if

an increase of demand occurs, the server can be scaled (at a reasonable cost) accordingly. As

currently only I and a few testers are using it, a tiny VM is used with 1GB of ram, 1 GHz CPU

and 10 GBs data a month.

The MySQL database hosts two tables:

User generated content and their rating

Accounts

News, images, and models take up a lot of space so are just hosted on a file server and

referenced in the application.

Data is accessed of the server from the application through a PHP interface. This is an

alternative to directly communicating through remote MySQL. Doing so is not a good idea

because, it requires login information to be in the code (android apps can be decompiled) and

the parameters can be changed which is a security weakness. Thus using PHP and following

the “Don’t trust the client” policy, all login information is server side and input from client can

be stripped of injection attempts.

of 86

4.14 Findings from prototype Initially a sketching interface was considered instead of a menu driven interface (as

mentioned earlier in this section). The idea was that you could draw the item you wanted and

then it would generate a 2D representation of that item which you could then change into a

specific 3D model. However the limited number of gestures and need for the user to learn the

gestures made this not a viable solution to the problem. The time to create the right gesture

was much longer than selecting a model form a menu. The results are shown in appendix

10.7.

On my old nexus 7 (2012 edition) lighting performed terribly. Creating more than 5 lights in a

scene made the app became unusable. An initial idea was to have an option for the user to

add their own light sources. However due to the device limitation this was not continued.

There is now just one light source placed above the scene. As mentioned in the background,

this is worked around by prebaking textures with light sources then adding them to the scene.

As objects can be moved around the scene, baking textures was not useful to this project.

4.15 Summary The implementation section starts with core functionality of the application, this compasses

the basic concepts of moving and placing furniture, and sharing content to heterogeneous

devices, these are the first requirements gathered during the design phase.

It then progresses to implement other features to fill the requirements that improve the user

experience when interacting with the application, this included grouping, snapping, and

rotating.

The result of this process is a multiplatform application that allows users to share and make

their own rooms through a mix of different interface and application aids. Thus satisfying the

core requirements set out in section 3.

of 86

5 The system in operation

This section is a walkthrough of the final, complete system. Its purpose is to demonstrate the

applications functionality, by leading through tasks a user may take during application usage.

The process includes:

UI navigation

Creating a room

Uploading a room

5.1 Menu

Figure 5.1 Main menu screen

Entry point to the application, no operation processed yet.

of 86

5.2 Login

Figure 5.2 Login on home screen

User has pressed the cog and is now entering their credentials to login to the system.

5.3 Browsing rooms

Figure 5.3 View rooms screen

The view rooms screen where the user can pick from different filters (my rooms, top rooms

and discover).

5.4 Arena

of 86

Figure 5.4 arena screen with some models in room

Figure 5.4 shows after some furniture and walls have been placed into the scene.

5.5 Arena Help

Figure 5.5 Help screen

Figure 5.5 shows the help screen on the application. A user would click on this to find out

what gestures are possible.

of 86

5.6 Publish

Figure 5.6 Publish window

After user has created a room and they are happy with it, they would click publish and the

room would upload.

6 Testing and evaluation

The purpose of the testing and evaluation section is to verify that the requirements gathered

in section 3 have been met by this project. The following in this section includes a table of

tests, a usability study, and a heuristic evaluation. All of these were taken shortly after

finishing implementation are towards an effort to evaluate and inspect the usability of the

system as well as its robustness. After the testing evaluation methods, a summary of the

general points will be made, extracting the important information from the results.

6.1 Testing This section covers testing. It is used to confirm that functions within the application work to

provide all round robustness.

6.1.1 Client side testing Test #1 Objective : Navigation, ensure buttons work on all screens

Method Acceptance Criteria Outcome (Y/N)

of 86

Navigate through home, view rooms’, and arena screens. Press back button on all screens

A. The back button works on every screen B. On button click, screen changes

Navigation through home, view rooms’ and arena screens worked. The back button worked on every screen. It returns to the home screen.

Y

Test #2 Objective : Make sure application runs offline


Turn off data and wifi and launch the app.

A. App does not crash when attempting to download/upload data

The app launches as usual but news window is not updated and browsing rooms does not update

Y

Test #3 Objective : Adding item to arena


Launch app, navigate to Arena. Then select an item from the list (checking every item).

A. When any list item is clicked, that item is added to the scene

Clicking a list item puts that object into the middle of the scene

Y

Test #4 Objective : Group items with gesture


Navigate to arena. Place multiple items into scene. Select pen button. Draw circle around items. Tipple tap

Items are grouped and act as one object.

Gesturing items in circle groups them. They move and rotate as if they were one object

Y

Test #5 Objective : Rotate Item and group


of 86

Navigate to arena. Add item. Select item and touch with two fingers and twist.

A. Item rotates when gesture happens. B. Rotation works for a group.

Performing gesture rotates item. Rotating group rotates all items around center item.

Y

Test #6 Objective : Delete Item and group


Navigate to arena. Add items, group them. Drag group to delete zone.

A. Single item gets deleted after drag over box. B. Group of items gets deleted when member over box.

Items dragged onto box gets deleted and also so does its group.

Y

Test #7 Objective : Publish room


Create room in arena. Click upload button. Click publish

A. Room is uploaded B. Input is handled

With or without input in description field, rooms is uploaded and view able in view rooms’ screen

Y

Test #8 Objective : Browse and Load room


Navigate to view rooms’ screen. Select a room and tap its.

A. Rooms are listed in view rooms’. B. The same room selected is loaded.

Click on view rooms show a list of rooms with pictures. Clicking a picture launches arena and displays the room.

Y

Test #9 Objective : Check for SQL injection


of 86

Use “;drop table tmptable;” in text fields through the program. Test if table has been dropped

A. Nothing should happen server side

In all input fields the input on the server is an empty string whenever SQL was used.

Y

Test #10 Objective : Create account


Click on settings. Enter fields. Click login. Check if new rooms are made with that user.

A. Account was created. B. User was logged in. C. No duplicate accounts

Creating account logs user in and displays their name. Creating a second account fails if it is not using the same password.

Y

Test #11 Objective : Filter rooms


Navigate to view rooms’. Click filter buttons. Check output.

A. Filter results by top rated B. Filter by my rooms C. Filter by new rooms

On filtering top rooms everything works. When clicking any other filter first the application crashes.

N

6.1.2 Server Side Testing Test #12 Objective : Add new models to server


Navigate to website. Login. Select file to upload.

A. Have to login to access admin panel. B. File uploads and is saved on server.

After logging in with admin account I then uploaded a model and it appeared in app

Y

Test #13 Objective : Admin SQL injection


of 86

Try SQL commands in the username and password boxes on website.

A. Nothing should happen. User should not be able to access database through injection.

Trying “;drop table tmpTable;” does nothing. That table was not dropped.

Y

6.1.3 Testing Summary The acceptance testing of the features in the application has shown good results. All of the

tests returned positive results except for one. Test 11 failed, this was when testing the browse

room filters. The problem was not picked up before because it depends on what order you

press the buttons (One of them loads something the other two do not). Other than this, the

application is functional and robust enough for deployment.

6.2 Usability feedback A user study was taken to gather user opinion about the ease of use of the application, the

studies goal is to show how well this application has met requirements. It is important to get

a view of the application other than the developers, users may pick up on usability issues that

a developer wouldn’t notice. This feedback was done through participants testing the

application and answering a simple questionnaire about the usability of the system.

This feedback is different to the observation done in design as that was aim to improve the

system whereas this is evaluating it.

The tests consists of the participant creating a room, publishing it, and finding their room.

This will test the usability of both the navigation and user interface and assisted creation

sections. This was followed by the user using the application on different devices, the aim of

this is to see how the usability fits across different applications. After testing, the participants

were asked to complete a short questionnaire to provide feedback. This questionnaire asks

how they rate parts of the application on a 1 – 10 scale, when 10 is good and 1 is poor. The

questionnaire is attached to the appendix in subsection 2. Feedback results can be found in

the working documents.

The participants had a short debriefing of the application and it purpose. They were then

handed a sheet with a few tasks on: create a room, publish your room, and find your room.

The users were handed a nexus 7 tablet with the application already open. After the tests

they had some time to play with the app on an OnePlus android smartphone and desktop PC

controlled with mouse and keyboard.

6.2.1 Results analysis This covers the result from the usability questionnaires. The results are an average of the 10

participants that took part.

of 86

Figure 6.1 Average of system usability feedback

6.2.1.1 Navigation

The question asked was “How did you find navigation within the application? Especially when

trying to find your room after creation”. The purpose of this was to get an understanding of

how easy it was to get between different screens on the application, and whether it was clear

how to get back and return to a previous screen.

This scored 7.8 average between participants. This suggests that it has worked to a good

extent, this said it is marginally lower than some of the other feedback. After further

inspection of the results from the “do you use a modern smartphone frequently” question

showed a correlation between people that didn’t use/own a smartphone had a worse

experience with navigation, their average (4 participant that don’t use smartphones) was

4.75. This is probably because they hardware buttons on the device are used for navigation,

this is foreign to people whose integration with a program is through a keyboard and mouse.

As mentioned in the background Google suggests that the hardware buttons are used as to

not use many ways of getting the same operation (returning from screen) as to create a less

confusing UI.

6.2.1.2 Finding Furniture

This question is “How easy was finding the furniture that you wanted to place?” It aims to

find out how easy it was for the participant to find the furniture they wanted within the

category window.

At a score of 6.5, this was the lowest result from the feedback. This score is not drastically low

but definitely shows that there is room for improvement in this section. The difficulty with

this feature was mostly likely due to their not being an image to complement the text of the

furniture. The user found it difficult to pick what they wanted as text did not give enough

detail, this meant that there was a bit of trail an error until finding the right furniture.

0

1

2

3

4

5

6

7

8

9

10

Navigation Finding furniture Arrangingfurniture

Publishing room Browsing rooms Performance

Ease

of

use

Tested Feature

System Useability Feedback

of 86

6.2.1.3 Arranging furniture

The question “During room creation, how easy was it to arrange the furniture?” was asked. The purpose of this was to find out if moving furniture around could be done easily by the participant. Thus evaluating the snapping, rotating, and grouping tools. This scored over 8 so there is confidence that the tools created to help the user arrange furniture worked to a good extent. This could be further evaluated by doing some final observations and seeing which of the tools they use and any problems they have related to them.

6.2.1.4 Publishing room

The question “After creating a room you were asked to publish it. How easy was it to publish the room?” This question was asked to ensure that it was easy for the user to share the room after they had finished creating it, this is an important part to the user generated aspect of the project. Publishing the room scored over 8 again suggesting there is no problem with how it is done. This wasn’t too much of a surprise as the process consists of an up arrow button and a dialogue with a clear publish button. Rather than finding it my concern was that users would leave the application without uploading, this did not happen in any of the 10 participants but is something that should be handled.

6.2.1.5 Browsing rooms

The question “Next you were asked to find the room that you had just made. How easy was it find your room?” This was asked to evaluate the view rooms’ screen and see if users found it easy to use, after making changes from the first prototype to address this, it should be work fine. The feedback shows got a score of 7.5 suggesting that is better than satisfactory but may still have room for improvement. Part of the result could have been affected by navigating from the main screen to the view rooms’ screen.

6.2.1.6 General performance

The question “During your use of the application, how did the app run performance wise? I.e. did it lag or stutter during your use?” This was asked to see what the users felt about the performance of the application to evaluate if it had met the performance non-functional requirement. Although it maintains a 30fps throughout animations between transitions can stutter between screens depending on the platform.

This gave an average of just over 9. This suggests that the performance was acceptable but

some stuttering must have been noticed at some point but did not affect the experience.

of 86

Figure 6.2 Pie chart of participants' preferred device for Mini Architect

Figure 6.2 shows the results of question 8 from the feedback form. The purpose of this was

to see what platform the participants preferred. Tablet is the clear favourite here with 50%,

this makes sense as the application was designed first for touch devices and a tablet has both

a touch interface and a larger screen than a phone. This is not to say that it wouldn’t be used

on phones or PCs; it would be down to the users requirements at the time e.g. if mobility is

important then they would use a phone. The PC margin was only selected by the participants

that did not own/use a smartphone, the keyboard and mouse interface is familiar and they

already know how standard operations like dragging and rotating works. This fits one aim of

this project (developing for cross platform) as the participants have picked the platform that

they are most familiar with.

6.2.2 Discussion of usability feedback evaluation Feedback overall was positive and suggested that the application is better than satisfactory.

This said, this is the first exposure of the application to multiple people other than the

developer; sections can still be improved, as mentioned in the questions above. The user

feedback can help with the next release of the application, preferably before public release.

The lowest average feedback was 6.5 on category selection, this was in the finding furniture

section. This is a feature that could be improved upon with more research in future work.

50%

30%

20%

Prefered Device

Tablet Phone PC

of 86

7 Conclusion

The conclusion covers the details from the above to give feedback on how well this project

has achieved the aims and objectives set in section 3.

7.1 Review of aims To recap, here are the aims:

To develop a furniture arrangement application on mobile devices that allows users

to create and share rooms with ease.

To make use of the touch user interface on mobile devices to assist in arranging

furniture models.

To develop a back end that provides centralised data for all users of the Mini Architect

application.

These aims are broken down into more specific areas in the functional and non-functional

requirements of the system.

Next shows the whether the requirements defined in section 3 have been met, where not

met it describes why and the effect it has on the project.

7.2 Front-end requirements The following lists the requirements of the application set during the design phase.

Functional requirements

ID Requirement description Achieved?

1 The app shall allow users to share generated content Yes

2 The app shall work in and be native for browser, iOS, android, and desktop Yes*

3 The app shall enable the user to create rooms. Yes

4 The app shall provide a list of rooms categorised Yes

5 The app shall provide an accounting system Yes

6 The app shall show prices of rooms and models Yes

7 The app shall let the user get to main part of app swiftly Yes

8 The website shall provide similar functions to the app No

9 The app shall provide a method of using app without account creation. Yes

Requirement 2 was met and android, desktop and browser applications worked but the iOS

project was never compiled. This was due to requiring xCode which only runs on Mac PCs

which were not available.

Requirement 8 was not met although ability to browse rooms and a web application was

made it was never put together. Instead focus was on other requirements as this requirement

was set as a low priority in section 3.5.1.

of 86



10 Scales for new devices Yes*

11 Works with varying internet connection Yes

12 Provide user friendly interface, on all devices. Specifically room creation should be intuitive and easy to use.

Yes*

Requirements 10 and 11 have been achieved but it is difficult to say if they are future proof.

This because the screens have not been tested with screens with higher pixel densities than

are currently available.

7.3 Back-end requirements Functional requirements


13 The server shall provide a means for adding rooms Yes

14 The server shall provide a list of rooms in selected orders Yes

15 The server shall allow adding of accounts Yes

16 The website shall allow a means to add news Yes

17 The website shall allow a means to add new models Yes



18 Performs under heavy load – user capacity Yes*

19 The website should be secure Yes

20 The website should not allow downloads directly (limit bandwidth) Yes

Requirement 18 was not tested. This said, as it is running on an expandable virtual machine

more resources can be added if capacity has been reached.

7.4 Lessons Learned Multiplatform development proved to be a difficult challenge. Learning each platform and

how they handle system preferences, stored data, and managed application permissions

among other issues made the learning curve time consuming to overcome. Developing for

multiple platforms made debugging and tests a lot longer, the program had to be tested on

different devices to ensure it would perform the same.

Furthermore, learning about 3D development from scratch proved not to be easy, foreign

concepts had to be learned which again took time.

As mentioned throughout, the project uses the Libgdx framework. This required a steep

learning curve and most of the implementation time was spend learning that framework.

Fortunately books had been made on the framework which made learning it quicker [22].

of 86

Using open source frameworks and libraries are not guaranteed to function exactly as

expected. During use of Libgdx a couple of minor bugs were found, as a result this halted

progress for a long period of time. These problems were fixed as later versions of the

framework were released.

Developing for the majority of devices scales down app functionality greatly. Ensuring that

the application worked on older devices limited the resources there were available. This

meant that when creating models to showcase care was taken to ensure they were not overly

complex.

When creating a user interface for cross platform, unless creating completely separate

programs for each platform a unique UI has to be implemented. This means that the

advantages of the already implemented UI provided by the platform are not used.

If this project was going to be done again, then focusing on just one platform would help

reduce problem scope. Developing completely separate native UI code for each platform and

only porting over the logic code would be simpler, more aesthetically pleasing and familiar to

users on that platform.

7.5 Future work This section covers further work that would provide a useful addition to this project. The

observation and interview taken when the application was at first prototype showed useful

feedback of UI and methods of furniture arrangement.

With this feedback, and findings in the evaluation here are some directions of where

advancements can be made to the application:

7.5.1 Wall creation and placement One finding in the observation feedback detailed in section 3 said that the walls got in the

way and were “fiddly” after a full room had been made. Other existing applications get around

this by separating wall creation in a control plane where the room is designed in a top down

2D view. Ideally the walls should be set initially and then locked into place or made

transparent so they don’t get in the way when viewing and creating a room. So implementing

a wall locking feature or something to make them more subtle would be a part of future work.

7.5.2 Furniture selection User feedback suggests that furniture selection could be improved. It scored the lowest rating

of all the features evaluated. It is an important feature to the application, improvements to it

would decrease the time the user spent picking furniture when creating a room. A visual aid

is key to this, all of the existing applications review in section 2 had a picture of the furniture

to select, however their division of UI and more screen space on their platform made this

feasible. For this to work the category window would have to be redesigned to be larger to

accommodate for pictures big enough to show viewable pictures.

of 86

7.5.3 Website implementation This was the unmet requirement, the web application has been compiled but not tested. The

website offers an entry point for the application. A user may be tempted to try it first before

downloading it to their phone/tablet. Additionally it fits in more with the current e-commerce

solution to product visualisation, if used on a retailer’s website it could be combined to show

the items in a customer’s shopping basket. It also provides a completely cross platform

method of accessing the application, any system with a modern browser can use it.

7.5.4 Social networking integration The existing app BuildApp analysed in section 2 uses social networking as a method of sharing

content. As Mini Architect shares rooms through the app, sharing outside of the app would

advertisement of a user’s room to a wider range of people.

7.5.5 Partnership with retailer The next main step for this application would be reaching out to retailers for a partnership. If

partnered, the application would be used to visualise real furniture products. The extra user

feedback from a deployment would highlight more features within the application that could

be improved.

7.5.6 Auto adding furniture Auto adding feature could be used to speed up the process of creating a room. For example

when a table is placed, the matching chairs could be placed and grouped at the same time.

This also reliefs the furniture selection issue mentioned above.

7.6 Summary This project targeted the lack of a method to effectively advertise home furniture online and

through an application. To address this, a cross platform, furniture arrangement application

has been made, Mini Architect. It was the product of an iterative user influenced design that

has evolved as the project progressed. The evaluation of this project shows that a usable

system has been created that has provided users with a new way of visualising and

arranging furniture. Finally, from the evaluation and testing, this project has met its aims

and can be considered a success with prospects of further research.

of 86

References

[1] Limayem, M., Khalifa, M., & Frini, A. (2000). What makes consumers buy from Internet?

A longitudinal study of online shopping. Systems, Man and Cybernetics, Part A: Systems and

Humans, IEEE Transactions on, 30(4), 421-432.

[2] Einav, Liran, et al. Growth, Adoption, and Use of Mobile E-Commerce. The American

economic review 104.5 (2014): 489-494.

[3] Ikea home planner application – 2013 [ONLINE] Available at:

http://www.ikea.com/ca/en/about_ikea/newsitem/2014catalogue [Accessed 17 January

2015].

[4] Ikea Home planner application – 2015 [ONLINE] Available at:

http://www.ikea.com/ms/en_JP/rooms_ideas/splashplanners.html [Accessed 05 January

2015].

[5] Study Looks at Why Consumers Still Want an In-Store Shopping Experience This... --

COLUMBUS, Ohio, Nov. 21, 2013 /PRNewswire-iReach/ --. [ONLINE] Available

at: http://www.prnewswire.com/news-releases/study-looks-at-why-consumers-still-want-

an-in-store-shopping-experience-this-holiday-season-232913021.html. [Accessed 17 May

2014].

[6] Brenda Menard. (2013). Mobile Apps: What Consumers Really Need and Want.

[ONLINE] Available: http://investor.compuware.com/releasedetail.cfm?releaseid=747433

Last accessed [19/12/14].

[7] libgdx. 2014. Open source cross platform framework [ONLINE] Available at:

http://libgdx.badlogicgames.com/features.html. [Accessed 25 October 2014].

[8] Merrell, Paul, et al. "Interactive furniture layout using interior design guidelines."ACM

Transactions on Graphics (TOG) 30.4 (2011): 87.

[9] Palmieri, Manuel, Inderjeet Singh, and Antonio Cicchetti. "Comparison of cross-platform

mobile development tools." Intelligence in Next Generation Networks (ICIN), 2012 16th

International Conference on. IEEE, 2012.

[10] Google android design guidelines 2014 [ONLINE] Available at:

http://developer.android.com/training/implementing-navigation/temporal.html [Accessed

13 December 2014].

[11] Compuware mobile app survey 2014 [ONLINE] Available at:

https://info.dynatrace.com/rs/compuware/images/Mobile_App_Survey_Report.pdf

[Accessed 20 January 2015].

http://www.ikea.com/ca/en/about_ikea/newsitem/2014catalogue

http://www.ikea.com/ms/en_JP/rooms_ideas/splashplanners.html

http://www.prnewswire.com/news-releases/study-looks-at-why-consumers-still-want-an-in-store-shopping-experience-this-holiday-season-232913021.html

http://www.prnewswire.com/news-releases/study-looks-at-why-consumers-still-want-an-in-store-shopping-experience-this-holiday-season-232913021.html

http://investor.compuware.com/releasedetail.cfm?releaseid=747433

http://libgdx.badlogicgames.com/features.html

http://developer.android.com/training/implementing-navigation/temporal.html

https://info.dynatrace.com/rs/compuware/images/Mobile_App_Survey_Report.pdf

of 86

[12] Amazon elastic cloud services - http://aws.amazon.com/ec2/ [Accessed 12 December

2014].

[13]360 spinning view of bike 2014

http://www.halfords.com/webapp/wcs/stores/servlet/product_storeId_10001_catalogId_1

0151_productId_991978_langId_-1_categoryId_165534 [Accessed 24 July 2014].

[14] Hoggan, Eve, et al. "Multi-touch rotation gestures: Performance and ergonomics."

Proceedings of the SIGCHI Conference on Human Factors in Computing Systems. ACM, 2013.

[15] JSON to java library 2014 https://github.com/EsotericSoftware/jsonbeans/ [Accessed 9

Feburary 2014].

[16] Bootstrap. JavaScript, HTML, CSS framework 2014 http://getbootstrap.com/ [Accessed

13 January 2014].

[17] Furniture layout video 2011 [ONLINE] Available at:

http://graphics.stanford.edu/~pmerrell/furnitureLayout.htm [Accessed 3 December 2014].

[18] Oviatt, Sharon, et al. "Designing the user interface for multimodal speech and pen-

based gesture applications: state-of-the-art systems and future research

directions." Human-computer interaction 15.4 (2000): 263-322.

[19] Wobbrock, Jacob O., Andrew D. Wilson, and Yang Li. "Gestures without libraries,

toolkits or training: a $1 recognizer for user interface prototypes."Proceedings of the 20th

annual ACM symposium on User interface software and technology. ACM, 2007.

[20] Hoggan, Eve, et al. "Multi-touch rotation gestures: Performance and

ergonomics." Proceedings of the SIGCHI Conference on Human Factors in Computing

Systems. ACM, 2013.

[21] Lisa Anthony, Jacob O. Wobbrock (2010) $N Multistroke Recognizer, University of

Maryland: ACM.

[22] Marquez, David Saltares, and Alberto Cejas Sanchez. Libgdx Cross-Platform Game

Development Cookbook. Birmingham: Packt Publishing, 2014. Print.

http://aws.amazon.com/ec2/

https://github.com/EsotericSoftware/jsonbeans/

http://getbootstrap.com/

http://graphics.stanford.edu/~pmerrell/furnitureLayout.htm

of 86

8 Appendix

8.1 Usability feedback form

of 86

8.2 Sketching interface

Figure 8.1 Drawing table

Figure 8.2 Table recognised

Figure 8.3 Drawing chair

of 86

Figure 8.4 Chair recognised

8.3 Tree List User Interface

Figure 8.5 Tree list category selector

8.4 Class diagram

of 86

Figure 8.6 Full class diagram part 1

of 86

Figure 8.7 Full class diagram part 2

of 86

8.5 Project Proposal

Lyndon J Fawcett Mini Architect Virtual reality furniture ... J Fawcett Mini Architect Virtual...

Documents

Transcript of Lyndon J Fawcett Mini Architect Virtual reality furniture ... J Fawcett Mini Architect Virtual...