An online shop and lesson hub for guitarists.

Source code can be found here

The live project can be viewed here

The aim of the project is to help users on their journey to musical proficency. The website consists of a shop where instruments and accessories can be purchased, and subscriptions to music lesson videos can be signed up to.

Purpose of Project

ECommerce Business Model

Web Marketing

Features

User Experience

• Design
  • Fonts
  • Colour
  • Wireframes

Development Process

• Project Planning
• Search Engine Optimization
• Data Model

Testing

• Manual Testing
  • Feature Testing
  • Responsiveness
  • Lighthouse
  • Code Validation
    • Python
    • JavaScript
    • HTML
    • CSS
  • User Stories
• Automated Testing
  • Django testing

Bugs

Libraries and Programs Used

Deployment

• Deploying the app on Heroku
• Making a local clone
• Running the app in your local environment

Credits

Acknowledgements

This project is a B2C, where the aim is to sell directly to consumers, rather than to businesses. As the customers are free to browse online stores and buy impulsively, it is a central design principle that the customer should be able to proceed through the selection and purchase process with an absolute minimum of friction. Thus, the site contains minimal extraneous information that would distract from this process.

The site offers both products and a service. The products are guitars and their associated accessories; strings, cases and cables. These are displayed in a grid layout, with the product image prominent. Selecting a card from the grid opens a full page product detail view, which is the only page that contains a significant amount of text, detailing the specific qualities of that product. A quantity of one can be added to the basket with only one button click, and the user can proceed to the checkout page with one more subsequent click, having checked that their basket contents are correct. On the checkout page, there is a form, with a checkbox enabling the user to save their information, so that subsequent purchases will only involve entering their card payment details.

The digital service offered is a subscription to a selection of video lessons teaching the student the basics of how to play acoustic and electric guitar. The user can browse the courses on offer, and watch two videos from each course for free. A large clickable panel allow them to proceed to a page where they can pick the duration of their subscription, and clicking a duration card takes them straight to the Stripe payment page. Users are required to set up an account in order to subscribe, but this is the only occasion on which they need to enter PII before gaining instant access to their subscription. Payments are then taken automatically from their card at the end of each period.

Both single payment and subscription payments are handled by Stripe, and no card or payment information is held on the site.

A facebook page was set up as the initial stage of a social media marketing strategy. The page mimics the styling of the site, and a Shop Now is prominent in the page description. An introductory first post was made to the page, containing another link to the site and inviting visitors to view the products and services on offer. In case the page is taken down, screenshots are included below.

The following pages are visible to all users, logged in or not.

The following pages are only available to logged in users.

The remaining pages are only accessible to staff

• It would be useful for staff to be able to track volume of sales of different product across different timeframes. A good feature here would be a dashboard, maybe using Plotly to display sales by product and time period.
• A feature with added benefit for subscribers would be the ability to share videos of their progress with each other, and like and comment on the videos. This would need to be moderated to ensure subscribers did not become discouraged by harsh/unfair criticism and leave the site.
• Another future feature, which I considered implementing here, is an embedded video-calling functionality, which would enable subscribers to jam with each other, or connect with real teachers for lessons and tips to help them improve their playing. Unfortunately, there wasn't enough time available to try to implement this in this version of the project.

Return to top

The Nunito font is used throughout the project. It's a simple, very legible sans-serif font, with a rounded appearance, particularly on headings and larger font sizes.

The following colour palette was used in the project

The primary colours used are derived from the project's hero image, a cherry coloured electric guitar shown on the landing page. The orange is used wherever reference is made to a special offer, and the blue is used sparingly, only on large buttons which link to pages that are part of the payment process, i.e. the Checkout and PayNow buttons.

Return to top

GitHub Issues were used to document the development steps undertaken in the project. Two issue templates, for User Epics and User Stories were used. Various labels were employed to enable quick identification of issue type including Bugs, User Epics, User Stories and Style. MoSCoW prioritisation was employed using the labels must-have, should-have and could-have.

To break the project into manageable sprints, GitHub Projects was used to provide a Kanban board onto which the issues were posted, moving them from 'Todo' to 'In Progress' to 'Done' as they were completed in turn. The iterations are documented here - [Iteration 1]

The User Epics and their related User Stories are as follows:

• Epic : Product Browsing.
  • Story : View all products
  • Story : Search products by category
  • Story : Search products by keyword
  • Story : Listen to sound of instrument
  • Story : Watch video of instrument being played
  • Story : See any special offers currently available
  • Story : View associated products
• Epic : User Interaction with Basket.
  • Story : Basket summary
  • Story : Alter quantity of item
  • Story : Remove item from basket
• Epic : Checkout.
  • Story : See a summary of my basket
  • Story : User can enter payment details securely
  • Story : User can save their delivery information for future purchases
  • Story : User should receive on-screen confirmation of their successful order
  • Story : User should receive email confimation of successful order
  • Story : Staff can see list of confirmed orders
  • Story : User can view and edit their UserOrderProfile
• Epic : Stock Management.
  • Story : Staff can add and edit products
  • Story : Staff should receive email notification when stock levels are low
  • Story : User can see when product is out of stock
  • Story : Staff can view summary table of all products
• Epic : Video Lesson Subscription.
  • Story : View all lessons
  • Story : Watch video lessons
  • Story : Subscribe to unlock all videos
  • Story : Add new video courses

A set of long and short tail keywords was developed. The initial set was generated from a combination of brainstorming and examining the related searches returned by Google for these terms. This was then culled back to a smaller set of more targeted short- and long-tail keywords, which were each trialled on wordtracker.com. This resulted in the following list of terms, ordered by volume:

After completing this research, I returned to the project's templates, and made the following changes:

• <title> tag in base.html:
  • Set to 'Everything a guitarist needs - Strings Attached'. This gets a high volume short-tail keyword in one of the most important SEO locations, as well as mentioning the site name.
• <meta> description tag in base.html:
  • 'The guitar is the most beautiful musical instrument. Join us here at Strings Attached, where you can learn guitar with our online guitar lessons. Of all the musical instruments, our passion is the Six String, and you can find a wide selection of gorgeous instruments in our online Guitar Shop.' While keeping the description reasonably short, I managed to squeeze in 7 of the chosen keywords.
• <meta> keywords in base.html:
  • The following terms were added to the keywords meta tag: guitar, guitarist, guitar shop, six string, online guitar lessons.
• Heading elements:
  • On the landing page, welcome.html, the <h1> element text was changed to 'For Guitarists, by Guitarists (shortened to 'For Guitarists' on smaller screens).
  • On the product detail page, the product name appears as the content of the <h2> tag.
• <img> tag alt attributes:
  • On the product display page, I decided to leave the alt tags for each product image as 'Image of {{ product.name }} to ensure that the product names would be indexed if a shopper happened to do a Google search using the specific name of a product.
• Image filenames:
  • The product image filenames were already changed from the source filenames to describe the product contained within them. The lesson images are all titled according to the type of guitar taught in the lesson.
• Emphasized text:
  • On the CheckoutSuccess page, the words 'video lessons' were placed within <strong> tags.

The entity-relationship diagrams above were created using the django-extensions graph_models command. For this command to execute correctly, the GraphViz package must be on the system path. For my Ubuntu machine, this is done as follows :

sudo apt install graphviz

The following python dependencies must be installed in the project environment :

pip3 install pyparsing pydot

The diagrams were created by specifying the models required for each .png file e.g.:

python3 manage.py graph_models -a -I LessonSeries,VideoLesson,UserLearningProfile,Subscription,User -o docs/video_lessons_app_db_schema.png

The following decimal fields, representing currency amounts, are protected by Django's MinValueValidator, with the minimum value being set at 0.

video_lessons.models.Subscription.price

products.models.Product.price

products.models.SpecialOffer.reduced_price

As such, if a staff member attempts to add a product with a negative price field, the product_add form will be returned to them with the error highlighted. Similarly, the model fields representing product quantities have also been protected with a MinValueValidator.

products.models.Product.stock_level

products.models.Product.reorder_threshold

Also, the javascript running in basket/static/js/quantity_buttons.js checks the value of the quantity input on the page each time it changes, and disables the decrement button if the quantity <= 1, or the increment button if the quantity >= 10. It also prevents the user from typing an out-of-range value directly into the input. This code was copied from the Boutique Ado project.

• Manual testing
• Validator testing
• User story testing
• Automated testing

The manual testing of features is organised by app below. Testing was carried out on a 1920 x 1080 desktop screen, a Samsung tablet and an iPhone 12 Pro.

All pages on the live site were tested with the default list of devices in Chrome Devtools. It should be noted that the three pages only accessible to staff (Product List, Order List and Order Detail) contain large amounts of data in tabular form, and are more usefully viewed on small devices in landscape mode. A note to that effect appears at the top of each of these three pages, on small screens only. Various non-essential columns are hidden on medium screens, but a minimum number of columns is necessary to make the pages useful, and these would not fit on a small screen in portrait mode. As these pages are not consumer-facing, I judge that this is an acceptable compromise.

The lighthouse best practices tab returned a lower than ideal value due to the presence of 3 vulnerabilities in JQuery 3.3.1. I checked the actual vulnerabilities themselves on www.cve.org:

• CVE-2020-11022 : jQuery >= 1.2, <3.5.0
  • Passing HTML from untrusted sources in DOM manipulation methods may execute untrusted code.
• CVE-2020-11023 : jQuery >= 1.2, <3.5.0
  • Passing HTML containing <option> elements from untrusted sources - even after sanitizing it - to one of jQuery's DOM manipulation methods (i.e. .html(), .append(), and others) may execute untrusted code.
• CVE-2019-11358 : jQuery < 3.4.0
  • jQuery before 3.4.0, as used in Drupal, Backdrop CMS, and other products, mishandles jQuery.extend(true, {}, ...) because of Object.prototype pollution. If an unsanitized source object contained an enumerable proto property, it could extend the native Object.prototype.

jQuery is used in this project only as a dependency of Bootstrap 4.3.1, and without going through the Bootstrap source code, I can't be confident that these functions are not used by the Bootstrap JavaScript-based components. Unfortunately, I only discovered these vulnerabilities late in the project, and would prefer not to run the risk of using a more recent version of Bootstrap at this late stage, which might break various elements in the project. In any future projects, I'll be using Bootstrap 5, which has the added benefit of no longer depending on jQuery at all.

Accordingly, while I have included the Best Practices result on the Welcome Page, I have left it off the rest of the pages, as there is no great need to repeat bad news a dozen times!

• All python code is validated by the Flake8 linter (installed in VSCode). The sole exceptions are the test classes, whose function names and implementation can be very verbose.

• All JavaScript code in the project was validated during development with the ESLint plugin for VSCode.

• All HTML files in the project were validated using the W3C Narkup Validation Service. https://validator.w3.org/

• No errors were found when the single CSS file style.css was passed through the W3C Validation Service. https://jigsaw.w3.org/css-validator/

The User Epics and Stories in this project are documented in three GitHub Projects, corresponding to the iterations that comprised the development work of the project. These can be found here :

• Iteration 1
• Iteration 2
• Iteration 3

Alternitively, the Epics and Stories are individually linked here :

• Epics and Stories

The payment flow handling differs from the Boutique Ado project. I decided that the application would be more robust if orders were saved to the database before the Stripe payment process was initiated, with a flag, payment_confirmed set to false. This ensures that any order made is recorded before the network back and forth begins. It also allows the application to send the order_number field from the order instance to Stripe as metadata for later retrieval, so that the order does not need to be built from the basket contents. When the Stripe confirmPayment method (called from stripe_payments.js) promise is fulfilled, the front-end then sends a POST request back to the endpoint, which sets the payment_confirmed flag to True.

In the event that the promise is rejected, or the POST request fails, the Stripe webhook event (stripe.payment_intent.succeeded) will pass the metadata back to the webhook handler. If the order is present in the database, the handler ensures that the payment_confirmed flag is set to True. If it is not present, the handler will construct a new order from the basket information encoded in the metadata as an insurance policy.

Another advantage of this approach is that orders whose payments are not processed remain on the system, and can be retrieved by staff and users if necessary at a later point (although this is not implemented in the project).

The application listens for 5 Stripe webhook events, and takes appropriate action based on each. The events were tested by adding a local listener on the dashboard webhook page, which forwards the webhook events to the development server on localhost:8000. The webhook for the deployed project on Heroku was disabled for these tests, as the deployed and development versions of the project both use the production database. Tests for each webhook are manual rather than automated.

• stripe.payment_intent.succeeded:

  • The handler retrieves the order_number from the event metadata and checks that the order exists. If so, it ensures that the payment confirmed flag is set to True. This was tested by commenting out the code in checkout.views.PaymentConfirmedView that sets the flag to True and then, after the payment has been processed and the webhook event received, checking the flag in the admin panel. Results as follows :
    • With webhook forwarding disabled : payment_confirmed flag is False
    • With webhook forwarding enabled : payment_confirmed flag is True. So, the handler is working correctly when an order is already on the system. Next the code in the handler is altered by setting the value of the result_set returned by the search to None, creating an order on the site and then initiating a payment. This should result in a duplicate order being created, the same in all respects as the original except for its order_number. The results were as follows :
    • With webhook forwarding disabled : Only one order exists in the database.
    • With webhook forwarding enabled : A duplicate order also exists in the database. So, we can conclude that this webhook handler is working as intended.

• stripe.payment_intent.payment_failed

  • This handler just returns a HTTP 200 response code to Stripe. The stripe webhook dashboard confirmed that the event had been fired and that the 200 response had been received.

• stripe.checkout.session.completed

  • Unlike the payment_intent.succeeded webhook, this hook plays a crucial role in confirming a subscription payment has been processed by Stripe, as it is the only means by which notice of a successful payment will be sent. We need to confirm that subscriber flag is set to True, and that the stripe_customer_id and stripe_subscription_id fields are set correctly on the UserOrderProfile record. The test consists of examining the UserOrderProfile record created when the user chooses a subscription plan, and comparing it with the same record after the payment has been processed. Results as follows (with invoice_paid webhook disabled in order to isolate this webhook) :
    • With webhook forwarding disabled : subscriber flag set to False, stripe_subscription_id and stripe_customer_id fields unfilled.
    • With webhook forwarding enabled : subscriber flag set to True, stripe_subscription_id and stripe_customer_id filled correctly (compared to stripe webhook event detailed on dashboard). So, we can conclude that this handler is working correctly.

• stripe.invoice_paid

  • This handlers task is simply to set the UserOrderProfile's subscription_paid flag to True, so that the subscription is live and all video content is available to the user. The test consists of checking the UserOrderProfile record before proceeding to process payment for a subscription, and confirming that the flag is set afterwards. Results as follows :
    • With webhook forwarding disabled : subscription_paid flag set to False following payment.
    • With webhook forwarding enabled : subscription_paid flag set to True following payment.

• stripe.invoice.payment_failed

  • This handler sets the subscription_paid flag to false when it is received. Unfortunatly it is not possible to trigger this webhook either from the Stripe dashboard or from the CLI, so the only way to test it is to supply stripe with a test card with a short expiration date, and wait for the subscription period to end and the test to fail! A bit of research uncovered this project, released by Stripe, but the time required to get the mock HTTP server up and running and the fact that it is stateless anyway(the responses to mock API calls are hardcoded) means that I'll reluctantly have to leave this handler untested. With a fully-fledged e-commerce application, before switching to live mode on Stripe, I would set up a fake product on the backend and a corresponding product on the Stripe dashboard with a subscription period of 1 day (the shortest option Stripe currently offers) and show up punctually to observe the handler fire 24 hours later.

A full suite of automated tests is included in the project. The tests for each app can be found in each apps test/ folder, and can be run with the following command :

python3 manage.py test

The most recent coverage report can be found in the htmlcov/ folder in the project's root folder, and can be accessed by running python's built in http.server from that root folder as follows :

python3 -m http.server

The coverage html report can be generated using the following commands :

coverage run manage.py test

coverage html

Return to top

• A number of other bugs and their solution are documented in the issues tracker on GitHub, such as :
  • Special offer not flagged on products page
  • Special offer still displayed after expiry date
  • Application relies on order in which webhooks are received
  • Stripe subscription flow calls payment_intent.succeeded webhook
  • uri_mismatch error for Google social sign-in on Heroku
  • Payment submits with card errors
  • Repeating quick pressing of increment and decrement buttons loses click info

There are (hopefully) no remaining bugs in the project.

Return to top

1. Pencil
   • Pencil was used for wireframing some of the pages in the project.
2. Balsamiq
   • Balsamiq was used for wireframing the initial pages in the project.
3. Heroku
   • Heroku was used to deploy the project
4. Git
   • Version control was implemented using Git through the Github terminal.
5. Github
   • Github was used to store the projects after being pushed from Git and its cloud service Github Pages was used to serve the project on the web. GitHub Projects was used to track the User Stories, User Epics, bugs and other issues during the project.
6. Visual Studio Code
   • VS Code was used locally as the main IDE environment, with the ESLint and Flake8 linters installed for JavaScript and Python code validation respectively.
7. pytest
   • Pytest was used for automated testing.
8. GIMP
   • The GIMP graphic editing package was used to manipulate and export all images used in the project.
9. GraphViz
   • This open-source graph visualization package was used along with the pydot package to generate ER diagrams from the models in the project.

The project stores all of its static and media files (including images and audio clips uploaded when adding products by staff) in an S3 bucket, which is publicly accessible for downloading files to facilitate this use. Detailed instructions are available here on how to set up and configure the S3 bucket on the AWS side.

On the Django side, the following lines in the project's settings.py file are necessary :

AWS_STORAGE_BUCKET_NAME = '{PROJECT NAME}'
AWS_S3_REGION_NAME = '{REGION}'
AWS_ACCESS_KEY_ID = os.environ.get('AWS_ACCESS_KEY_ID')
AWS_SECRET_ACCESS_KEY = os.environ.get('AWS_SECRET_ACCESS_KEY')
AWS_S3_CUSTOM_DOMAIN = f'{AWS_STORAGE_BUCKET_NAME}.s3.amazonaws.com'

# Static and Media files
STATICFILES_STORAGE = 'custom_storages.StaticStorage'
STATICFILES_LOCATION = 'static'
DEFAULT_FILE_STORAGE = 'custom_storages.MediaStorage'
MEDIAFILES_LOCATION = 'media'

# Override static and media URLs in production
STATIC_URL = f'https://{AWS_S3_CUSTOM_DOMAIN}/{STATICFILES_LOCATION}/'
MEDIA_URL = f'https://{AWS_S3_CUSTOM_DOMAIN}/{MEDIAFILES_LOCATION}/'

Replace the PROJECT_NAME and REGION placeholders with the appropriate values for your project.

1. Log into Heroku and navigate to the Dashboard.
2. Click on the 'New' button.
3. Choose a unique app name, and select the region closest to you.
4. Create a database on Heroku (I elected to stay on Heroku and pay the monthly fee)
   • Click on the Resources tab.
   • Click the Find more add-ons button.
   • Select Heroku Postgres, and click on Install Heroku Postgres.
   • Select a plan (default = Mini @ $5.00 a month, which I'm using), and select your app.
   • Return to Resources tab and click on the Heroku Postgres icon, then select the settings tab and click on Database Credentials. Copy the URI to your clipboard. Paste it to your env.py file using the key "DATABASE_URL". This will allow you to use the same database for development and production.
5. Click the settings tab on the Dashboard, and click the button to Reveal Config Vars. Your database url should be populated here already. Add your Django secret key to the config variables, and set the PORT to 8000.
6. In your local repository, add a Procfile to the root directory of the project, containing the following line :
   web: gunicorn strings-attached.wsgi.
7. Add the url of your Heroku project to the ALLOWED_HOSTS list in settings.py.
8. Create 2 social apps, for Facebook and Google social signin, and add their respective API-keys and SECRETS to the database. Add your application details and callback urls to the respective Google and Facebook OAuth dashboards.
9. Open a Stripe account, and add your STRIPE_PRIVATE_KEY and STRIPE_SECRET to the config vars. Set up a webhook to hit your webhook endpoint, and copy the STRIPE_WEBHOOK_SECRET to config vars as well.
10. Create 3 products in the Products tab of the Stripe Developer console, to match the 3 subscription durations in the project, and add their respective API-keys to their corresponding Subscription instances in the database.
11. Set DEBUG to False, and commit your changes and push to GitHub.
12. In Heroku, navigate to the Settings Tab, and within this the Buildpacks section, and click on Add Buildpack. Select the python buildpack, and save changes.
13. On the Dashboard, select the Deploy tab, and under the Deployment Method heading, select the GitHub icon to connect your Heroku project to your GitHub repo. Enter your repository name in the text input, and click Search, and then when your repo appears, click Connect.
14. Under the Manual deploy section, click Deploy Branch. You should receive this message - 'Your app was successfully deployed". Click view to see the app running in the browser.

1. Open a terminal/command prompt on your local machine.
2. Navigate to the folder on your local machine where you would like to clone the project.
3. Enter the command : git clone 'https://github.com/johnrearden/strings-attached.git'

1. Create a virtual enviroment in the new project folder using the command python3 -m venv venv
2. Activate the virtual environment : source venv/bin/activate
3. Install the project requirements : pip3 install -r requirements.txt
4. Create an env.py file containing the following variables (see env.example.py in the root directory of the project for a complete list of variables necessary to run the app) :
   • AWS_ACCESS_KEY_ID : Used to access S3 bucket for static and media files
   • AWS_SECRET_ACCESS_KEY : As above
   • BASE_URL : The root URL for the dev project, usually http://localhost:8000/
   • DATBASE_URL : This is the url generated by Heroku - see Deploying the app
   • DEBUG : Set to True for development work locally
   • EMAIL_APP_PASSWORD : The email password for your email account
   • EMAIL_APP_USER : A personal or ephemeral email account you can use to test your email functionality.
   • PORT : Default Django port is 8000.
   • SECRET_KEY : This is the Django secret key.
   • STRIPE_PRIVATE_KEY : Stripe private key credential
   • STRIPE_PUBLIC_KEY : Stripe public key credential
   • STRIPE_WEBHOOK_SECRET : Stripe webhook signing secret

Return to top

Structure of extensible base.html page largely copied from Boutique Ado Walkthrough https://github.com/Code-Institute-Solutions/boutique_ado_v1/blob/250e2c2b8e43cccb56b4721cd8a8bd4de6686546/templates/base.html

Hero image of guitar on guitar stand - Kelvin Franca on Pexels https://www.pexels.com/@kelvinernandi/

Truncate text in a paragraph tag in html https://stackoverflow.com/questions/47761085/how-can-i-set-a-character-limit-for-paragraph

Remove up and down arrows from number input https://www.geeksforgeeks.org/how-to-disable-arrows-from-number-input/

Combining querysets in Django https://stackoverflow.com/questions/431628/how-to-combine-multiple-querysets-in-django

Testing in Django https://realpython.com/testing-in-django-part-1-best-practices-and-examples/

Email send test not working because of missing User email field https://stackoverflow.com/questions/39493749/django-tests-for-sending-email

Generate database schema diagram from project models https://django-extensions.readthedocs.io/en/latest/graph_models.html

Make a Django class based view CSRF exempt https://www.programmersought.com/article/2914850608/

Testing a DoesNotExist exception on a query https://stackoverflow.com/questions/11109468/how-do-i-import-the-django-doesnotexist-exception

Mocking stripe methods in a view to enable testing https://stackoverflow.com/questions/31284622/mock-stripe-methods-in-python-for-testing

Prevent a table cell event listener from also firing its table row event listener https://developer.mozilla.org/en-US/docs/Web/API/Event/stopPropagation

Creating an xml sitemap https://www.xml-sitemaps.com/

I'd like to acknowledge the invaluable assistance I received from my tutor, Celestine Okoro, and the advice and encouragement I received from my cohort facilitators Kenan Wright, Kasia Bogucka, and Paul O'Donnell. Thanks also to my fellow students whose help in our weekly stand-ups made a big difference.

Return to top