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
Page 67 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.
Page 68 of 86 Non-functional requirements
ID Requirement description Achieved?
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
ID Requirement description Achieved?
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
Non-functional requirements
ID Requirement description Achieved?
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].
Page 69 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: