Project title: Easy Donation
About: The project is about designing an on-line donation management system to enable every person/household to donate anything easily. As many charity organisations are making a big effort to collect donations. It is quite costly and inefficient for charity organisations to do on-door envelope distribution and collection. While many people have unwanted things at their homes, they couldn’t donate due to time limitations. The basic idea is to help people to select preferred charity organisations and send the donation information on line to inform charity organisations. Also to help charity organisations to provide better management of their resources and only make necessary door to door collections.
Project deliverable: The project deliverables for this project is a web application showing the donation management system, and a report to describe the stages and process of this project.
Originality: This project will enable me to design a site where people can choose their preferred organisations and send donations to them; similar to a “compare the market” website. This will not only help the people who use the site but also the charity organisations as it will cut down on door to door collections and make smaller organisations more noticeable.
Timetable:
Research (29/09/16 – 20/10/16) – This will involve researching similar donation/charitable sites, making note of the similarities and differences in the design and navigation. This will help me structure my own web application and improve on the flaws and also incorporate design ideas from other sites. This is one of the most important stages of the project as it will help spark ideas and create an initial proposal.
Wireframes / Initial Design (20/10/16 – 10/11/16) – I will be designing low fidelity wireframes (paper based or some online tool) for the initial design of the web application. I will also be brainstorming ideas on how the structure should be laid out through the research I have done. This will help me design a suitable prototype after getting feedback.
Prototyping (10/11/16 – 08/12/16) – When I finish these I can then design some high fidelity wireframes in Photoshop or some similar program. This will lead to the design of the final layout which I can implement into the web application, however this may change due to resources or testing. Prototyping is important as designs are going to change over time and new ideas will arise so it’s best not to jump straight into development.
Development (15/12/16 – ) – The development is the largest and longest stage, as this is the implementation of the design which can change due to resources and/or response from the testing of the initial design. The development stage may start earlier or later depending on how the project evolves, within this, I will be using a Laravel framework to help build my web application in PHP – therefore I will need some time to learn and practice using this framework.
Testing (After development) – Testing is the last stage and will be done once the implementation has finished, this is perhaps the most important stage as this will ensure that the site meets the needs of the parties using it. I will be performing some; functionality testing to verify the flow of the system and there are no dead pages. Some usability testing to test the navigation, interface and compatibility testing, and finally performance testing. I may do some security testing also as there may be payment transactions through this application however this will be through a secure channel such as PayPal.
Contents
Database Design (Class Diagram)
Interface and Compatibility Testing
Introduction
This report will justify the ideas behind this project and the need for such a web application; furthermore it will explain the aims and objectives how this project was constructed as a whole.
Problem
Many people donate to charity, and many of them make regular donations whether its money, clothes or other items. Also, many charity organisations provide a door to door collection service for donations however this is something businesses are trying to reduce as it is not environmentally friendly. Charities issue bags to houses in certain areas near to them, then they have to make door to door collections in that area and sometimes there is nothing to collect; therefore a website that tells charities where there are available pickups is ideal.
Relevance
This project has an interdisciplinary approach, exploring areas in human computer interaction and web development, and therefore relevant to a number of areas within computer science and multimedia.
Structure
The main areas in this report are;
Design & Human Computer Interaction – In order to develop an intuitive GUI, I will need to establish the requirements of the target audience and create an interface that is effective and simple.
Programming and Software Architecture – A number of programming concepts will be required in order for the application to work efficiently. Furthermore, software architecture, such as, the model view controller will be needed for the structure of the application.
Database – This project will require a carefully designed database, allowing data to be stored safely.
Web Development – Basic front end and back end web technologies will be used, such as, HTML/CSS, JavaScript, PHP and MYSQL. PHP Framework ‘Laravel’ will also be used.
Testing – A very important stage in this project and in any software development project. This will be done to ensure the application is working and find any issues that need to be fixed.
Project Aim & Objective
The overall aim of this project is to build an application that helps charities (large or small) to gain more donations, and to reduce door to door collections.
To achieve this aim it will involve completing the objective of designing and developing a web application.
Requirements Analysis
Target Users
Before any design ideas can be created, it is important to understand the type of user that will be using the application, and what the application has to do in order to satisfy their needs.
In this type of development, the purpose of the application or features designed will completely change in this project. This is especially true while taking an evolutionary acquisition approach, in using the iterative model; this will hopefully result in a much better design.
The intended users of this application will be charities and people who want to donate. Charities will want to manage/accept donations, while users will just want to be able to donate and keep a track of their donations. This website will also be useful for smaller charitable organisations that want to make a name for themselves.
Primary Research
Questionnaires
A questionnaire was conducted in order to get a better understanding of the target users. This was sent out to the general public (via: Reddit) and got many responses. Furthermore, I went around with a questionnaire aiming it at charity shops to see how there door to door collections work and if this process is suitable, the results were collected and shown in the pie charts below.
Figure 1: Do you donate to charity?
Figure 2: Would you be interested in a web app that allows you to choose a charity to donate to?
Figure 3: If smaller charities are made available on the web app, would you be more inclined to donate to them?
These are the three main questions that will provide a general idea of how easy it is for people who donate, and also whether a web application is suitable.
The first question asked if people donate to charities, as times and trends change this result can differ. As shown by the results still 75% of people who took this questionnaire said that they still donate to charities so a web application can still be useful. The second question asked if a web application is needed to choose a charity from and nearly 90% said that an application such would be a very useful tool, this shows that a web app is needed so people can easily find the charities they want to donate to. The third question asked was to see if a web application would benefit smaller charities against the more popular ones when it comes to donating, and over 90% of people said they would be more inclined to donate to smaller charities if they were available on a web application.
Secondary Research
Secondary research involved, looking at similar web applications that are already on the internet. For this project, this would involve, charity sites and any kind of application where the user is able to donate.
Figure 4: Home page of British Heart Foundation.
This website has a consistent red colour scheme, a maximum of around three colours is used to draw the user’s attention; too many colours can do the opposite effect. When booking a free collection, it is a very simple process of filling in your personal details and then collection dates and times, the user also does not have to be a member in order to donate – this is a good idea because many users don’t want to make an account for just a one-time donation.
Figure 5: Donation page of British Heart Foundation
The donation process is easy, and the website provides you with easy visual links to how much the user wants to donate.
Figure 6 & 7: American Heart Foundation – Home & Donation process.
The American Heart Foundation only allows the user to donate money, from the homepage it does not look spectacular, but when the user goes through the donation process, it is designed intelligently with buttons and minimal text. As shown from figure 4, the items the user has to select are chosen from an icon instead of standard text button.
Figure 8: Next Gen Climate homepage.
This websites design is very elegant, as it stripped all the information (text) and populated the site with images that link to different parts of the site; the only text used is on the navigation bar for quick access. It can be quite tedious for new users to navigate on the website as it is ‘in-your-face’. The downsides to this website is that you have to be a member before accessing most features, this will not be implemented into the web application however some of the design features will be taken into account.
Figure 9: JustGiving homepage.
The JustGiving website is a very similar application to the one that is to be built, as it has a search base for all charities to donate to.
The donation process is very simple and the type of style that I will be implementing into my web application.
Once on the chosen charity, there is a link to their social platform and an option to make a fundraise also. This project should have a donation process similar to this and may implement a place to leave a message.
Figure 10: Just Giving search page.
Figure 11: Just Giving search page – charity page.
Figure 12: Just Giving donation page.
Figure 11 and 12 show how to donate to a charity on the website, it is a very simple process with a clean interface, which is something that should be taken into account when building the application.
Persona
Personas are a good way to be able to design to the type of user and to understand/communicate with how my application will be useful to these types of users. Below is an example of a persona.
| Name | Kevin Jericho |
| Age | 32 |
| Description | Kevin has recently moved out of his parents’ house in Leicester after finding a well-paid job in Birmingham City Centre. Kevin is now living in an apartment alone.
Kevin is settling in nicely in his new apartment however he has a lot of old clothes and other items that Kevin wants to dispose of, however it is too much effort to have them collected by the council. Also, there are not many charity shops near him that are trustworthy. Kevin would like an application where he can choose the charity he wants to donate to and then have them collect the items at a time that best suits him. Kevin is not ‘Tech-savvy’ and owns 1 laptop and 1 phone, and sometimes gets confused with new technology and some applications. |
| Needs | Kevin’s needs are as follows:
|
Overview
Primary and secondary research will help understand the type of application that will be built in more detail by looking at existing solutions and using similar design techniques.
A number of different models will be followed in order for this project to be successful, including; agile, iterative and v model, these will be discussed further on in the report.
Use Case Diagrams
These are some use case diagrams, designed to show what the main functions of the application will be.
Figure 13: Use Case diagram to show functions of a user searching for a charity.
This use case diagram shows the main functions of a user that searches for their chosen charity in the search bar. The user will search for the charity and then have a choice to add the charity to their favourites, or make a payment donation or other donation to the charity. The web application “actor” will update the donation, show the user a PayPal system, and update the user’s favourite list if they added the charity to their favourites.
Figure 14: Use Case diagram to show a new user making an account and logging in.
This use case diagram shows the options that a new user has when presented with this system, they have a number of options, such as; log in with an existing account, register for a new account or forgot password. The web application will present the user with an email confirmation if they decide to register or click forgot password, or update the account information if the user decides to edit their account after they have logged in.
User Requirements
The user requirements help when building this application, to make sure the design is suitable to the user and this app will be beneficial. These have been split up into functional and non-functional requirements.
Functional
Functional requirements describe what my system should do, and what the user expects from it. These have been divided into; general web application requirements which discuss the general functionality that the app should deliver to the user. The user actions define the general things that the user can do on the application. Finally, the donation requirements is what the application should offer when the user is going through the donation process.
General Web Application Requirements
- The application should allow users to sign up/ create account.
- The application should allow users to delete their account.
- The application should allow users to modify their account/data.
- The application should present the user with a forget password option.
- The application should allow the user to see their donation history.
- The application should allow the user to see their favourites list.
User Actions
- The user should be able to search for available charities.
- The user should be presented with information about the selected charity.
- The user should be able to see comments made by other people.
- The user should be able to favourite chosen charities.
- The user should be able to delete charities from their favourites list.
- The user should be able to make a comment when they make a donation.
Donation Requirements
- The application should present the user with a donate money option.
- The application should present the user with a donate items option if the charity accepts items.
- The application should ask the user how much they want to donate.
- The application should have a comment section for the user.
- The application should have an option to publicize a comment.
- The application should allow the user to make a secure payment via PayPal.
Non-Functional
The non-functional requirements describe how the system works, and how the system should behave.
- The application should run smoothly across all platforms (Internet Explorer, Chrome, Safari, Firefox, Opera etc.)
- The page load time should be kept to a minimum.
- The GUI should be easy to use, with a well-designed clean interface.
- The application could be functional on a mobile device.
Schedule
This project will be completed in logical steps, throughout the project the dates in the Gantt chart are considered as deadlines and work should be completed before these deadlines so it can be checked over.
The Gantt chart will be updated if the project falls behind, or some parts are moved forward.
Figure 15: A Gantt chart showing the main stages of the project and the time periods they should be completed in. The main headings are at the top in red, and the green stages are subheadings accordingly.
Web Technologies
The development of this web application will rely on web technologies – both front end and back end frameworks – working cohesively in order for the application to run smoothly.
Front End
The majority of the front end of the web application will be coded using HTML 5 and CSS 3 – CSS will be used for all the styling and positioning. However, for added functionality, animations and interaction JavaScript will be used, in particular the framework JQuery (version: 3.1.1).
Back End
The back end of the web application will be coded in PHP framework Laravel. The current version is 5.3 (5.4 releases in January which will be too late to start development). Laravel’s key features include: restful routing, composer (tool that manages third-party packages easily), built in unit testing and an ORM (called Laravel) which means working between database objects and relationships is a lot more eloquent with easy syntax.
I have chosen to use a framework because as well as making development a faster process, it makes the code well organised and clean, which makes it more reusable. Most frameworks, including Laravel use a MVC architecture which ensures separation of presentation and logic. Also, learning Laravel will be a challenge as I have not used it before, therefore the end application will be more satisfying.
I chose to use Laravel because it has sufficient documentation which makes the learning process easier, also makes managing databases simpler. Furthermore it has a templating engine called ‘Blade’ which allows me to write plain PHP in the templates.
Finally, Laravel has a very unique architecture, making it easier for developers to create their own infrastructure specifically designed for their application; and therefore Laravel can be used for big or small projects.
Design
Before any development can begin, design must be completed in order to set the overall tone of the project and I am able to follow some structure when developing.
The first thing to do when designing is to brand the application, which can be the most difficult part because a lot of people judge the application solely on the branding (this includes; the name and logo). Therefore choosing a name that is boring or hard to pronounce is really bad for the project before it has even begun.
Names that were brainstormed were: AceDonate, LoveCharity, EasyCharity, and EasyDonation.
Eventually the name ‘EasyDonation’ was chosen because it’s easy to remember and it is also the whole point of the application – to make donations simpler. Having also shown the names to other people, the majority thought ‘EasyDonation’ sounded better.
Once the name was chosen, the logo could be designed. Initial designs were designed on paper and taken further in Photoshop.
<< Show paper images >>
<< Show picture of logo >>
This logo was picked because…
This logo works well with the website because…
I chose these colours because…
Wire-framing
When first starting to design a web application or any kind of interface, it is important to produce wireframes, as doing so can generate new ideas. Wireframes block out the main functionality of the application and allowed me to concentrate on what the design should look like to benefit user experience. The wireframes that I developed can be see below:
<< figures of wireframes >>
After designing these wireframes, I wanted to see what the interface would look like on the web, therefore I mocked up designs in a program called Axure that allowed me to see what the interface would look like on the web.
<< show picture of design on Axure >>
After experimenting in Axure, the design was best as simple and minimal, there is no need for an overload of information on each page. Furthermore, the design consistent throughout the whole application. It is interesting to see the changes the design has taken and progressed from the initial wireframes to the mock ups; however, this may also change when development is in progress.
Responsive Design
The application will have various pieces of information on each page, however there are not many pages to navigate to, therefore a simple navigation bar located at the top of the screen will be most useful. When initially designing this at the beginning of the project, a side navigation bar was going to be added.
Interface & HCI
Features
Database Design (Class Diagram)
As I am following an agile development style, the UML diagram does not represent the final state of the application, the following diagram is a starting point from which it can be built upon.
<< UML diagram >>
Development Method
The overall aim of this project is to create a web application that works effectively and beneficial to the end users. Initially the project would be of a relatively small scale however the application needs to allow for scalability and enable to work as a large scale application. Therefore, I will be implementing a few development methods; agile, iterative and v model.
Agile Model
Agile was the main development strategy that will be followed. The agile model is a type of incremental model and areas of the site will be developed in rapid cycles. It is useful for a long project like this to ensure the application will be useful to the end users. This model has many benefits to my type of project.
Working software (parts of the application) are delivered on a frequent basis, so the application is being design and developed correctly. It is very easy to adapt part of the application when there is a change in circumstances, even if there are late changes – these can be implemented. It is both suitable to fixed or changing requirements. Finally, not much planning is required making the whole project easy to manage.
Iterative Model
An iterative process model will also be followed. This model does not attempt to start with a full specification requirements, development begins by specifying and implementing just part of the application, which can then be reviewed in order to identify further requirements.
This model can be used in cases where a small part of the application is developed which can then be tested. This process would be repeated (develop – test), to ensure every part of the application is working as intended to.
The iterative model has many benefits including; detecting flaws in the project early to avoid a bigger problem later on in the building. The model also supports changing requirements, also testing and debugging is made simpler during small iterations.
V Model
The V model is essentially very similar to the waterfall model – more specifically the V model is an extension of the waterfall model. Phases only start when the previous phase is completed, this is used when in design to development phases, i.e. every phase in the design has to be done sequentially (wireframe – mock ups – interface implementation) before a start can be made on the actual development of the application.
There are some benefits to using this model in my project, including; phases are completed one a time – such as research, design, development and testing, this is useful because my requirements were shown to me at the beginning of the project and I was able to follow them one by one using the V model.
Application Architecture
Application architecture is very important in web development and it varies depending on the type of application. It is fundamental in keeping a neat coding style so it is clear to understand and easy to maintain. As said above the Laravel framework will be used for backend development which encourages the use of a MVC architecture, however it does not force you into this scheme as the application will still work if, for example, code that should be placed in the model is placed into the controller instead.
Code Styling
Using a consistent coding style is essential in large applications especially when it comes to testing or modifying certain areas. It improves the overall readability of the code therefore if another developer came in part way to inspect, it would be easy to understand what is happening. For these reason, certain PHP coding standards will be used – ‘PSR-1’ and ‘PSR-2’. PSR-2 is essentially an extension of PSR-1, the guide includes:
[5] PSR-2 Coding Style overview
I have followed this style of coding throughout my application, as shown below;
Figure []: Example block of code following PSR-2.
Version Control
Version control is a type of a system that records changes to some files so the programmer is able to recall specific versions later. This is important in this project as the application is quite large, therefore a mistake can be costly to other parts of the application, and version control will allow files to be reverted back to their original state. For this reason, Git version control was used throughout in order to track changes in the project.
S.O.L.I.D Design Principles
S.O.L.I.D stands for five principles – Single responsibility, open closed, Liskov substitution, interface segregation and dependency inversion – respectively. These five principles relate to the design of the finished application, design is important due to quality and it is the only way to effectively and accurately translate requirements into a finished software product. These principles combined together should encourage the development of a maintainable and understandable application.
Single Responsibility
“A class should have one and only one reason to change.”[7]
In the single responsibility principle, each responsibility should be in a separate class because each responsibility is an axis of change. Following this technique in the development of this application will make maintaining and debugging it much easier.
Within my project, a practical example would be that within the User model, there should only be functions related to the user. This responsibility can also be applied to functions, such as, a function that stores the charity as a favourite for the user should only do that. The output of their favourites would be done in another function.
<< Example of function that stores user’s favourites >>
In figure [], shows the single responsibility principle in action. This function strictly only stores the charities information into the corresponding table in the database when the user clicks on ‘Favourite’.
Open Closed
“Software entities (classes, modules, functions) should be open for extension, but closed for modification.” [8]
Essentially this means that a class should be easily extendable without modifying the class itself. Therefore it prevents breakages and code rot caused by modifying existing code which forces planning ahead for extension.
In simple terms an example would be having a method that sums up the areas of more than one shape, therefore an if statement would be implemented in order to check what shape it is. This can be resolved by attaching the logic to calculate the area of the shape’s, and then create an interface in order to check whether the object passed is actually a shape.
<< Interface example? >>
Liskov
“Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.”[9]
This principle can be thought of as an extension of the open closed principle and therefore means that any new derived classes are extending the base classes without any change in behaviour.
“Subtypes must be substitutable for their base types.”[10]
Interface Segregation
This means that a client should never be forced to implement an interface that it doesn’t use or clients should not be forced to depend on methods they don’t use. This essentially means that if you are implementing interfaces and the implementation does not implement all methods of that interface, this could mean that the interface is bloated and may need redesigning.
An example may be, if in a workplace there is a manager that sets work to the workers. There is a standard worker that works and takes a lunch break, and then there is a robot that works but does not need to take a lunch break. Originally there would be one interface that the worker implements that contains a work and eat method, if the robot implements this then there would be an unused method (eat), which violates this principle. Therefore, the robot class should implement its own work interface that does not contain an eat method.
It is better to use an interface containing only one method rather than writing useless code in order to satisfy the implementation.
Dependency Inversion
“Depend upon abstractions. Do not depend upon concrete classes.”
Basically this means that high level modules should not depend upon low-level modules, both should depend on abstractions. Abstractions should never depend upon details, details should depend upon abstractions.
This is important because changes are very risky, therefore depending on a concept instead of an implementation, it reduces the need for change at call sites.
An example in this project is how every model extends the ‘Eloquent’ class, which essentially allows the models to have no knowledge of how they actually interact with the database – this can allow swapping of the database without any changes to the actual models.
Namespacing
Namespacing is a relatively new feature in Laravel, it allows classes to be of the same name. This is important because we may use third party libraries that contain, for example, a ‘User’ class. By using a namespace at the top of a class, it means that everything that is happening in that class is relative to that namespace, also, any classes created within this file will live inside that namespace. Then in order to instantiate a class within a namespace, you can prefix it with the name of the namespace.
External Libraries
This application makes use of some external services and libraries, such as; MailTrap and PayPal (STRIPE?).
MailTrap
MailTrap was chosen as the email service instead of a traditional email service provider because, even though it being fake SMTP server which is used when testing applications; it also allows all emails to be viewed and then forward them to a real email address if necessary.
I used this mail service because it is easy to setup as there is no need to tune my mail server, no need to clean up my database from the users’ email addresses. Also the fact that it is platform independent so it can be integrated into any programming language and framework.
<< Show a screen shot of mailtrap in application >>
PayPal/Stripe?
Evaluation
Testing
Testing is a very big and important part of this project, which is why it is allocated over a few weeks (as shown from the Gantt chart).
In order to develop an effective test; the system must be understood in detail (having implemented it, I do), application and solution domain knowledge, know what testing techniques to integrate and the skills to apply these techniques. From the project definition form, a number of different tests will be implemented; usability tests, functionality tests, performance, interface/compatibility, and security tests.
The system will be tested first, in order to test the complex functionality. However there will be independent testers as well. It would be bad unsatisfactory if I, as the developer to test it because; of mental attitude that the program will behave in a certain way even though it may not, sticking to data set that makes the programs work, for example, only performing the main tasks when in fact naturally users may make mistakes therefore the application needs to react accordingly, as a program may often not work when tried by somebody else.
When testing, a number of black box and white box testing methods were implemented. Black box testing is a method where the internal structure/design/implementation of the item being tested is not known. White box testing is essentially where the items internal structure is known. Some black box testing methods are; acceptance and system testing. A white box testing that I will be implementing is unit testing.
Unit Testing
Unit testing is a testing technique where individual modules are tested in order to determine if there are any issues, this is performed by me – as the developer. The main aim is to isolate each unit of the application in order to identify, analyse and fix the defects.
Below shows the traditional cycle I will be taking.
[11] Unit test life cycle.
In my application…
User Testing
Usability Tests
Usability testing is a non-functional testing technique that measures how easily a user can essentially use the system, it can be measured using the following: the level of skill of the user, it should maintain the balance for both novice and expert, and the overall assessment of users’ attitude towards using the application.
This test will be performed before implementation, after the initial designs are drawn up, they will also be done after implementation when the final designs are complete. This is an effective test because if the application is not easy to use, then it doesn’t matter how complex the functionality is, the application will be useless.
Summary of Findings
System/Functionality Testing
Interface and Compatibility Testing
Performance Testing
Security Testing
Acceptance Testing
Conclusion
References
[1] British Heart Foundation, (ONLINE). Available at: https://www.bhf.org.uk/?gclid=CLOi8LaA-88CFfYV0wodu-kG2w Accessed on: 10/16.
[2] American Heart Association, (ONLINE). Available at: http://www.heart.org/HEARTORG/ Accessed on: 08/10/16.
[3] Next Gen Climate, (ONLINE). Available at: https://nextgenclimate.org/ Accessed on: 09/10/16.
[4] Just Giving, (ONLINE). Available at: https://www.justgiving.com/ Accessed on: 09/10/16.
[5] PHP-FIG, (ONLINE). Available at: http://www.php-fig.org/psr/psr-1/ Accessed on: 14/01/17.
[6] PHP-FIG, (ONLINE). Available at: http://www.php-fig.org/psr/psr-2/ Accessed on: 14/01/17.
[7] (BOOK) Robert C. Martin. (2002) Agile Software Development, Principles, Patterns, and Practices.
[8] (BOOK) Bertrand Meyer, Prentice Hall. (1988) Object Orientated Software Construction. Page 23.
[9] (BOOK) Kelt Dockins. (2016) Design Patterns in PHP and Laravel. Page 12.
[10] (BOOK) Robert C. Martin. (2002) Agile Software Development, Principles, Patterns, and Practices.
[11] TutorialsPoint, (2017), (ONLINE). Available at: https://www.tutorialspoint.com/software_testing_dictionary/unit_testing.htm Accessed on: 08/03/17.
Bibliography
1. https://laravel.com/docs/5.4 Laravel Documentation, 2016/17.
2. Acorns Shop. Great Barr. Questionnaire response. 2016.
3. http://api.jquery.com/ JQuery API Documentation, 2017.
