• Introduction
• UX
  • UX design work overview
  • Colour scheme
  • Typography
• Development cycle
• Features
  • Navbar
  • Town Modals
  • search bar
  • Pagination
  • Items details
  • Bag page
  • Spice index
  • Profile page
  • Store status feature
  • Store management page
  • Item availbility feature
  • Django messages
  • Checkout page
  • Delivery time
  • Footer
• Registration and login
• Technologies used
• Data schema
  • Forms used
  • Migrations
  • Foreign key
  • CRUD authorisation and security features
  • Checkout user restrictions
• Testing
  • UX testing
  • validators
  • Django unittest
  • Chrome DevTools
  • Site testing
  • Responsive design
  • Browser compatibility
  • Button and link testing
  • CRUD operation testing
  • Form validation
  • Stripe operation testing
  • Issues encountered during development
• Deployment
  • Run code locally
  • Setting up of S3 bucket
• Future improvements
• Credits

This project is an online food ordering and delivery service site. The site name 'MoLacuizine' is mauritian for 'My Kitchen'. The menu covers a wide range of popular mauritian cuisine whereby a customer can add food items to a basket and then make online payements using stripe service.

The site would also permit the user to add and modify profile information to be used at checkout and also to have a list order history for reference.

The site uses the Django framework.

The live site can be found here.

By visiting this site as a user I want to:

• have a user friendly registration/login process in order to use the site.
• be provided with details of each product.
• be able to narrow down items list so as to show items that meet my requirements.
• be able to add items to a basket so I can view all items I have selected together with the associated cost.
• be able to modify items added to my basket so as to make any required changes.
• be able to add and update my user profile so to make any changes if required.
• have a user friendly checkout process.
• be provided with estimated delivery time for ordered items to be able to know when I expect my food items to arrive.
• be provided with a list of previously ordered items for me to track my order history.
• be advised that checkout was successful to ensure order was processed.
• be informed of the online open/close status for ordering.

By using this site as the site owner:

• be able to add, update and delete items for store management purposes.
• be able to toggle the online status of the store for control purposes.
• be able to make an item become temporarily unavailable.
• be able control access to the store management page and features.

The following provides an overview of the site layout and logic behind design choices.

A wireframe was constructed using balsamique wireframes. It can be found here.

The site consisted of a main landing page which contained a fixed top navbar from which the user could access food items categories,accounts and basket. This was done so as to give a general overview to the user before showing any items. The main landing page would also show the main information about the site such open-status and delivery zones.

The site implemented several features to make registration, login, checkout, adding items and profiles as user friendly and intuitive as possible which are described below.

The django messages system was included so as to enable the user obtain feedback on whether actions had been completed and raise relevant errors.

A search bar was then provided in the top navbar for conveienience to provide an easy way for searching for items.

The items product page provided an overview of the item which could be purchased with the main information on the product. Each item could be clicked on to provide further detail on the product. This was done to make the product listing page less bulky and more user friendly.

From the product detail page items could be added to a basket to be viewed later.

The bag view consisted of a convenient place to view all items added to basket with their associated cost. Items could be modified if required in this view.

The profile page consisted of a form which the user could prefill to be subsequently used at checkout so as to enable a smoother checkout process.

The store management page allowed a convenient place to upload items and update shop online status.

All features are described in detail below.

Several colour schemes were tested and the following palette was finally adopted since it was thought to fit into the overall site theme.

All button were also designed to have an identical colour scheme for easy identification.

Font were obtained from google font and consisted of the following:

• 'Lato'

The main development cycle is listed below:

1. Site design work making use of sketch pad and balsamique.
2. Database design.
3. Alluath initial setup.
4. Home app creation and coding (main landing page).
5. Product app coding (item listing pages including item details, search bar).
6. Bag app creatoin and coding (bag page).
7. Coding add to bag view.
8. Coding of context.py (bag contents).
9. Coding of bag view.
10. Coding of edit and update bag features.
11. Pagination coding of item listing page.
12. Profile app creation and coding (profile page).
13. Checkout app reation and coding(checkout page without stripe).
14. Coding for updating of profile page details.
15. Coding for adding order history to profile page.
16. Coding for store management page (adding/updating/deleteing products).
17. Store status coding.
18. Deployment to heroku.
19. Coding for stripe checkout.
20. Coding for google distance matrix.
21. Project review.
22. Minor modifications addressed from step 19.
23. Addition of spice index to site with neccessary updating of installed apps.
24. Unit testing
25. Addition of item availability feature.
26. Final project review.
27. Final adjustments.

This section gives details of the features included and their function.

The navbar was contructed using bootsrap and and made to be collapsable on medium devices and smaller.

The navbar consisted of 3 levels. The top level contained a logo, search bar, Account login and bag link. Middle level contained category links and the bottom level the store status.

A modal to display the towns the delivery service catered for was provided for the user. It was located on the home page since the users would be able to know from the beginning if the delivery service catered for their location.

Search bar was included in the site since it would be a helpful tool in too narrow down user requirements with ease. The search criteria was based on:

1. item description
2. iten name

These criterion were suitable enough to narrow down the item list significantly.

From the project initiation it was decided to include pagination for the item listing pages to improve UX by preventing large amount of items being listed in one page.

The amount of items listed per page was defaulted to 8 since this was thought to provide a good balance between small and large devices.

The items details were displayed on two types of cards. One for the main item page and the other for the item detail page. This was done so as to not overload the user with details whilst browsing items.

The main difference between the 2 display cards was that the item detail card contained item description and the 'add to bag' link. Both cards contained price and category.

The 'add to bag' link would permit the user to add the item to the bag with the corresponding quantity and spice index.

Certain dishes which could be prepared to have different degrees of spiciness were given a spice index selector. This would permit the user to select a spice index according to their preference. This would then be taken into consideration when the menu was prepared. The levels were mild, medium and hot.

The spice index could be toggled on/off from the product form.

The bag page consisted of an order summary where all the items which were added to bag could be viewed in one convenient place together with their associated cost.

This page also permitted the user to update and delete items while also updating the total cost.

The bag page could be assesed via a link in the navbar which also showed the total cost (excluding transport). The bag icon would be black and disabled if the bag was empty and would change to blue and active otherwise.

A user profile page was included which permitted the user to upload/update information about themselves. This information would be used during the checkout process, thus providing a smoother checkout experience. The information required was phone number, street address, town and postcode.

The profile page consisted of a form which would allow users to create and edit records in the UserProfile database.

The profile page also provided a list of clickable ordered items for the user to review.

A store status banner was included in the navbar which would indicate whether ordering could be performed.

If the case where the store status was set to close, coding was added to prevent ordering or checkout being performed. This was done to allow the site admin control on when orders could be accepted. This feature would be used to change store online status for openning and closing purposes.

Such an option would also be useful in the case temporary closure was required for unforseen cicumstances.

A Store management page was designed to cater for two features:

1. Adding/updating of items.
2. Toggling of store open/close online status.

This page was solely for the store adminstrator and additional security coding was provided to achieve this requirement.

For adding items a form was provided allowing the uploading of category, item name, description, spice index present, item availability, price and image.

The same form would be used to update the item if modifications were required but with prefilled information which also included the original item image.

As for store status, a button was added which would toggle store status from online to offline. The offline status would disable the checkout process and the 'add to bag' operation only.

The item availablity feature was included in the add/modify product form. This feature was not originally planned and was introduced to permit the administrator to quickly remove items temporarily from the user view only without removing the item completely. Such an option was thought to be ideal in the instance if a specific dish was missing a prepartion ingredient and would not be able to be ordered at that specific time.

The item would then be tagged as available or unavailable for the admin only.

This feature could be toggled via the product form.

The django messages framework was used to provide temporary messages to indicate whether actions have been completed or not. This was done using django message levels info, success and error.

This was used specifically for:

1. Login and registration
2. Adding/Updating of products
3. Adding/updating of profiles information
4. Adding/updating/deleting products from bag
5. Store status update
6. Checkout process
7. Form validation errors

The checkout page consisted of a form which would be prefilled with user profile information and a seperate section for order summary. This page would permit the user to add credit card details and make payment online using the stripe payment sytem.

The town field consisted of a list of available delivery towns. A text request field was also added to permit the user to add any special request which they might have.

A delivery time featuture was also included making use of google distance matrix API.

Requests were made making use of the user's selected town coordinates referenced to the home base coordinates. An arbitary home base of Vacoas was chosen.

The calculation used was: 30 mins preparations time + google matrix delivery time rounded up to the nearest 5 mins.

A basic footer was provided with openning times and conatct info.

During project conception it was decided not to allow anonymous checkout and thus sign-up would be required. The reasoning behind this was to gather maximum information on user order preferences. This information could be used as a marketing tool to pick-up user trends which could then be used to send out customised promotional emails which in the long run could be more profitable than having anonymous checkout.

Also, anonymous users would still have to fill in the checkout form which contained most of the details for registration hence making registration process less of an issue.

The django allauth module was used for registration and login purposes.

• HTML5
• css
• javacript (ES6)
• python (v3.8.6)
• Django framework
• SQL database
• Amazon web servives for production storage of static and media files
• Jquery to simplify DOM manipulation
• pylint, flake8 PEP8 compliance
• official W3C validator to check HTML syntax
• css official validator(jigsaw) to check css syntax
• JSHint to check javacript syntax
• Chrome developers tools for analysing scripts and debugging
• Boostrap 4 for :
  1. page layout purposes and responsive design aspects
  2. Forms
  3. Modals
  4. Navbar
  5. Footer
• balsamiq wireframes application to create the site design
• Chrome extension 'responsive viewer' to aid in responsive design
• Google distance matrix to calculate delivery time

SQLite was used for storing data local storage and PostgreSQL for production.

Models were created in django by defining the fields and behaviour of the data. These models would then map to the above databases.

The following table gives the model used:

The User model made use Django-allauth package so as to reduce software development. Some customisation was provided so as allow users to add their first and last name during sign-up. Customisation was achived by literature obtained from here.

Signals were used to permit the creation of a Userprofile model once the user had registered and also for the updating of cost totals when items were deleted or added.

The store model permitted the saving of the store online status which would could be changed accordingly.

Once models were defined migrations were made to SQLite database using the commands:

1. python3 manage.py makemigrations
2. python3 manage.py migrate

This would ensure the database was set-up correctly and were aligned with the models.

Forms were available for the following models:

1. Order
2. UserProfile
3. Product

The forms provided a convenient means for the user to apply CRUD operations to the relevant database as described below. All forms required validation and were tested below.

Foreign keys were created for databases which relationships were required, thus permitting querying objects related to another model. Hence justifying the need for a relational database.

The foreign keys were set-up as follows:

An example of the use of foreign key was one could obtain all orders for a specific user profile through a query as such: orders = profile.orders.all().

CRUD operations from the site interface were provided as follows:

Full CRUD operations where provided for all models from the admin page interface.

A user would be able to have access to only their profile page and thus could only update their own profile. This was achieved using the django login decorator.

A user would be able to apply CRUD operations to items stored in their bag sessions only.

The store management page could only be accessed by the administrator by usng the django login decorator. A redirect was also included to prevent url manipulation by a user if the user was not an administator thus preventing illegal access to the store management page. This would prevent CRUD operations on products and changing of store status.

Redirects were also applied in the case site users tried to manipulate urls to delete or update products or if a user tried to manipulate url to access the checkout page if store status was closed.

As anonymous checkout was not allowed users would be required to sign-in for purchases. Therefore, if a user had not signed in and the checkout page was clicked on a redirect would trigger leading to the sign-up page. This redirect was for anonymous users only.

This section provides details of testing performed during development. The following table highlights the different stages when testing were carried out:

The goals set out in the UX section were accomplished as follows:

1. User goal: have a user friendly registration/login process in order to use the site
   This was achieved using the django allauth application which allowed a tried and tested login and registration process.

2. User goal: be provided with full details of each product.
   This was achieved using the product details card which provided all relevant details on the item for the user.

3. User goal: be able to narrow down items list so as to show items that meet my requirements.
   This was achieved by using both search bar and category search links.

4. User goal: be able to add items to a basket so I can view all items I have selected together with the associated cost.
   This was achieved with the bag view page described above.

5. User goal: be able to add and update my user profile so to make any changes if required.
   This was achieved with the profile user page.

6. User goal: have a user friendly checkout process.
   This was achieved by using the checkout page.

7. User goal: be provided with estimated delivery time for ordered items to be able to know when I expect my food items to arrive
   This was achieved by using the google distance matrix described above.

8. User goal: be provided with a list of previously ordered items for me to track my order history.
   This was achieved using order history page providing a list of all ordered items for that user.

9. User goal: be advised that checkout was successful to ensure order was processed
   This was achieved with the checkout success page.

10. User goal: be informed of the online open/close status for ordering
    This was achieved with the store status desribed above.

11. Site administrator goal: be able to add, update and delete items for store management purposes.
    This was achieved with the store management page.

12. Site administrator goal: be able to toggle the online status of the store for control purposes.
    This was achieved with store status feature.

13. Site administrator goal: be able to make an item become temporarily unavailable.
    This was achieved with item availability feature.

14. Site administrator goal: be able control access to the store management page and features.
    This was achieved with by providing coding to prevent illegal access as described here.

Code syntax were checked for errors with the following validators:

• official W3C validator located here
• css official validator(jigsaw) located here
• JSHint located here
• Pylint, flake8, PEP8 for python code validation

Errors were corrected and final test results are given below:

For the W3C HTML validator all errors were due to django template language which raised a bad value error. These errors were filtered out.

The error 'Doctype must be declared first' was also ignored and was due to the use of base.html template.

The Jshint test results had the warning " 'let' is available in ES6 (use 'esversion: 6') or Mozilla JS extensions (use moz)." was due to syntax used for defining variables.

The PEP8 'line too long' warning was left for the AUTH_PASSWORD_VALIDATORS in settings file since attempting to divide lines into segments gave rise to errors.

Django unittest was performed on all apps created by myself to check for bugs and inconsistencies in python code. The testing covered the views, models and forms for each app.

The coverage is summarised below:

Chrome DevTools were used extensively during development phase to assist in:

• page layout issues
• checking errors
• debugging
• verifying correct output using console

The site was tested by myself and once the main site was completed it was further tested by relatives. The feedback obtained was positive.

The site was viewed on different device sizes to check for correct responsive design. This was done using primarily Chrome DevTools with different emulated devices(moto G4, iphone 6/7/8, ipad, ipad pro). The responsive viewer chrome extension was also used. Resolutions covered are as follows:

The site was tested on Google Chrome, FireFox, Internet Explorer, Safari and Opera. Issues are discussed below

The following gives test results for button and link testing not related to CRUD operations and stripe checkout process.

The following summarises the CRUD operations from the site interface except for STRIPE checkout process:

Full CRUD operations were available from the admin interface.

The following summarises the CRUD operations from the admin inteface for categories and town:

Two types of form validation existed. One would pick up errors in the frontend such as missing required fields and the other backend. The backend validation would check if form was valid before applying CRUD operations to the database. If for any reason errors were detected this would raise an error with a message.

The add/update product form were tested as follows:

The above condition didnt not apply to the profile page since none of the fields were required. Testing was performed only on the incorrect number format as follows:

Hence, the above test was proof that the backend form validation was operational.

The stripe process was linked to the order model since orders would only be created if the stripe payement process was successful. Therefore testing was peformed also on the stripe process as detailed below.

Stripe webhook testing was performed by:

1. Creating test activity on account
2. Manually sending test events from dashboard

The above two testing methods were in-line with the stripe documentation

Results are given below:

After successful stripe operation, orders would be created in relevant database with a feedback success message and a redirect to the checkout success page. Results are given below:

Once the 'send to kitchen' button was pressed stripe would verify card details before processing order. During this process the submit button was disabled temporarily. After successful payment the submit button would be re-enabled and the order would be created in database as tested above via the checkout view. If the card checking process was successful but the submit button could not be re-enabled the order would then be created via the webhook handler view. This would cater for the event that a customer had made a successful payment and submit button was not enabled.

Below details tests performed to verify that this process was successful. To simulate the condition where the submit button was disabled the page was closed after pressing the send to kitchen button.

In both cases orders were verified to have been created in the Order and orderInLine database.

Form errors were also tested in the checkout process. Any errors would be highlighted to the user via a message which was part of the feedback system:

During testing phase the following issues were identified and corrected.

1. Pagination was included in the items listing page. This was initially planned to be coded in the all_products view. After completing this function the pagination would not work with the search bar or category search feature. The search criteria would be dropped when selecting another page. The solution adopted was to create seperate views for search bar and category search.

2. Whilst scrolling the items page the active pagination number link would hide the navbar. To prevent this issue the active z-index index was set to 0.

   

3. Initially at registration the user would only need to input email, password and username. After mid project review it was decided to include firstname and lastname in the sign-up process since anonymous ordering was not permitted and these inputs would be required. Attempts to modify the sign-up form were tried and unsuccessfully and research was performed. The solution was obtained from the this link.

4. When forms fields consisted of a dropdown field, such as category and towns, the placeholder would not reflect that field. It would be dashed lines.

   

   Inorder to resolve this issue javacript was used to make the first child equal to that field with the following coding:

   $('#id_category option:first-child').html('Category');

5. On the store management page the upload button was default button for uploading images. This was thought not to fit into the overall site deisgn. To overcome this issue the default button was set to hidden using javacript and another button was introduced which when clicked on would activate the hidden upload button.

   $('#id_image').hide()
$('#upload-button').click(function(){ $('#id_image').click() })

6. One of the features introduced was the store status which permitted opening and closing of the store online status. The toggling of store status was originally planned to be a form situated on the store management page. However after initial coding the form would not work since the store management page already had a form for adding and removing products thus not allowing a second form. To overcome this problem, and still have the store status feature on the store management page, javacript was used instead of a form. When the open/close button was pressed information was sent to the store status view using javacript which would subsequently update the store status model.

7. After initial deployment to heroku was performed the site would not run. After research one of the issues was thought to not having data in the category and product database. To fix this issue fixtures were created using the dumpdata command. These fixtures were then loaded into the PostgreSQL database. This corrected the issue.

8. Initially when unittest were performed a 404 error would occur for all tests eventhough the site worked normally. After several attempts to identify the problem the issue was found to be not having the store status defined. To resolve this issue the the store status was set to 'open' in the initial test class set-up.

   

9. When a item was set to unavailable it still could be added to bag by manipulating the url. To prevent this issue additonal coding was introduced which would trigger a redirect if an unavailable item was added to a bag followed by a relevant error message.

10. For browser compatibility, only Internet Explorer caused several issues. The issues were incorrect font colour, font sizes, missing backgrounds and quantity increment/decrement buttons not working.

    

The site still worked on Internet Explorer but the overall UX was less than that of other browsers. Due to Internet Explorer no longer being supported bugs were left as such.

11. During form testing it was noticed that incorrect phone format could be applied to the UserProfile phone number field without raising an error. Research was peformed and django RegexValidators were used. This permitted the use of regex for correct phone number formatting while raising an error which could be displayed to the user.

12. When the store status was changed the django message system would not always send a success message. This error was left as such since the store status banner would always update to the correct statement, hence providing sufficient evidence that the store status had effectively changed.

13. During testing it was noticed that toast success messages would always display the checkout button even when the store online status was closed. To resolve this issue template logic was incorporated to only allow the checkout button to be visible when store was open and bag contained an item.

Gitpod was used as an online IDE and then pushed to GITHUB. The Github account was then linked to heroku for hosting.

To deploy the project from Heroku the following steps were used:

1. Login to heroku and create the mo lacuizine repository by clicking on create new app.

   

2. Provision a PostgreSQL database for the new app from the resource page.

   

3. Install dj-database-url and psycopg2-binary

4. Freeze requirements: pip3 freeze --local > requiremenets.txt and ensure Procfile has been created.

5. Run migrations to the new PostgreSQL database from the gitpod CLI by adding the new database to django settings as such:

   DATABASES = {'default': dj_database_url.parse(os.environ.get('postgres://******************************'))}

6. Make fixtures for categories and products using the dumpdata command.

7. Load data into new database using the loaddata command.

8. Create a new Superuser using the command: python3 manage.py createsuperuser

9. Go to settings and set all config vars in Heroku including DISABLE_COLLECTSTATIC=1. Static files would be hosted by Amazon web service for the herokuapp.

   

10. Add host name of heroku site to allowed host in settings: ALLOWED_HOSTS = ['mo-lacuizine.herokuapp.com', 'localhost']

11. Go to Deploy section in Heroku from menu bar.

    

12. Scroll down to deployment method and select Github.

    

13. Scroll to connect to github and search and select the required repository.

    

14. Enable automatic deploy.

    

15. When the command git push is applied in gitpod this will automatically update heroku.

To run code locally the following steps should be performed:

1. On GitHub, navigate to the main page of the repository.

2. Above the list of files, click Code and copy URL.

   

3. Open Git Bash.

4. Change the current working directory to the location where you want the cloned directory.

5. Type git clone, and then paste the URL you copied earlier.
   $ git clone https://github.com/zahur76/molacuizine

6. Press Enter to create your local clone.

Information on setting up a AWS s3 bucket can be found here.

Once the s3 bucket was set-up the settings file was updated to allow the heroku app to link to the Amazon Web Service bucket for static and media files.

1. Pagination would need to be added to the order history on the profile page.
2. Add a feature which would add the orders to the kitchen once checkout was complete and list the ingredients required. Once the order had been prepared the order could be ticked off as being ready for delivery.
3. Include an app which would be used for the delivery service. The app would be able to show delivery status and update the order delivery status.
4. For delivery, instead of having a list of towns for the user to choose from, the user could select their location using google map. Their location could then be used by the delivery service for more accurate delivery time and location.
5. Provide a loyalty program for users which would offer discount to users and attract more customers.

• Geek for geeks for providing resource:
  • on how to hide input arrows.
• Stack Overflow for providing resource:
  • on how obtain selected value from dropdown menu.
  • making backgrpound image transparent.
  • on how to use RegexValidators in django.

• All Icons were obtained from font awesome.
• Background image was purchased from vecteezy.

• I would like to thank shabana, zara and sofia for testing the site and Allen Thomas Varghese for his input during the mentor sessions.