Welcome to the third part of the eight-part series documented on the web app project I undertook – OSAAT. In the previous posts, we looked into the communication and research aspect of the project where I went through all the site’s major features without going too deep into the details. I gave a thorough walkthrough on how the site was deployed, along with the development of the Login page and its authentication.
In this part, we will look briefly into the development of all the customer pages. I will explain the design given to me, and go through all the different features expected to be built – the front end and the back end side of things. Along with the customer pages, we will also take a look at the development of the “Add Customer” Page, which doesn’t really come under the Customer Pages, but I think it would be very relevant to cover that in this post.
UI DESIGN MOCKUPS
I’ve attached a few of the customer page UI mockups to give an overall idea about these pages and how they work. As you can see the sidebar that we built in the previous post always appears on all these pages, displaying the user’s name. We have 4 main tabs on this page that create the foundation for the customer page.
Keep in mind that the customer pages can only be accessed by an admin, and this would start to make more sense once you see a lot of editable fields and posting features that live inside this page. All this is being built to make it easier for the internal staff users to work on anything that involves a certain customer just within the customer page.
FEATURES
| Feature | Description |
|---|---|
| Info Page | Contains all the information about the customer. Mostly includes fetched from the Customer model from the database. Provides an option for the user to schedule a visit. Along with the option to edit a certain customer info fields that live in the info tab |
| Gallery | Displays all the images that were uploaded in the timeline based on the date it was posted, newest on top. All these images are fetched from Wasabi S3 storage after the timeline creation function uploads these images into the Wasabi bucket. |
| Timeline | All the timeline posts that were created for a customer will be displayed here. |
| Orders | Displays all Wasabi folders and their files for every order in an embedded file viewer. This tab also has a button that allows the internal staff to go to the order wizard page. (THIS FEATURE WILL NOT BE COVERED IN THIS POST, PLEASE CHECK THE FOURTH PART OF THIS PROJECT DOCUMENTATION SERIES) |
BACKEND
Along with the customer model, there are a few other models that were created to add to the customer pages. In the table below, I will go through all of them and the fields they contain.
| Model name | Fields |
|---|---|
| Customer | The customer table stores all the details of each customer that is being created. We uniquely identify the customers using the autogenerated unique_code field. first_name last_name company discount_1 – either 0% or 40% discount_2 – 0% or 5% or 10% or 15% or 20% zip_code primary_contact address main – unique mandatory field storing the main mobile number of the customer mobile work_phone cc_email website account_notes default_order_notes unique_code – Unique code generated with first three letters of last_name + main customer_type source – 16 different choices to pick from sales_rep – Names of 5 sales reps as choices payment_terms |
| Profile | Sometimes, a Customer object will be linked to a User, in this case, we refer to these users as Dealer Users. Dealer users have the group “dealer” in their group list and their customer objects are always associated one-to-one with their User objects. We do this by creating a Profile object that links the user to the customer user – One-to-one field to the User model customer – One-to-one field to the Customer model |
| Timeline | As we saw before in the Timeline tab, each timeline post that is being posted for a customer by an internal staff user is stored as a Timeline object linked to a customer and a user with the comment as the post content. customer – Foreign key field to the Customer model user – Foreign key field to the User model type – Technical Issues or Order Finalized or RMA or other comment timestamp |
| CustomerGalleryImage | In the gallery tab, we would need some way to associate an image to the customer, which is why once we upload the image to wasabi, we create a CustomerGalleryImage object that links the image to a customer, so that it would be available to be viewed on the gallery tab inside the customer’s Customer Page customer – Foreign key field to the Customer model image – Image field that stores the image directly into the Wasabi Bucket uploaded_at |
TimelineImage | When a timeline post is created with an image attached to it, we need to be able to link this image (which is a CustomerGalleryImage object now) to that particular timeline. This enables us to not only display these images along with the posts we show in the timeline ta but also link the images in the gallery tab (which are, more often than not, linked to some timeline post) to the appropriate post content. timeline – Foreign key field to the Timeline model gallery_image – Foreign key field to the CustomerGalleryImage model |
All these Django models are created inside main/models.py along with being added to the Django admin interface so that rows can be managed easily without getting into the manage.py shell or any external backend management tools. There are many more models that were added to the main app’s models.py, the ones I have mentioned above are the only models that we will make use of on the Customer page.
Now, one at a time, I will go through each of the four tabs on the page and explain how each of the features comes together to provide a robust way for the internal staff to view and work with their customers.
INFO TAB
The first tab on the customer page contains all the information about the customer. It is a pretty straightforward design, and we use the data from the customer model to display it on the page. There are a few extra additions to this that were not added in the design, so I had to improvise on those aspects.
| Feature | Description |
|---|---|
| Customer Information | All the customer’s information on the text is the way it’s shown on the design mockup above. |
| Editable Dropdown fields | Three fields displayed as editable dropdowns |
| Schedule button | A button that opens up a popup that contains a form that allows the user to create a calendar event (for now it is going to be an empty popup, but once the calendar pages are created, we will work on this popup) |
Firstly, an html page was created extending main/layouts.html. The frames were built according to the design. I used some javascript so the tabs were dynamically made to switch based on the tab that was clicked and made active.
Customer Information
The Customer model was imported in views.py, and inside the customer view which was linked to the url /customer/<str:unique_code>. Here we will use the unique code of the customer to identify them. The unique code passed down through the URL would be used in the view to fetch the customer object of the customer we want to work with. Once we pass it down to the templates, it’s just a matter of plugging in the customer object’s items into the view.
Editable Dropdown fields
Next, I added 3 more fields from the Customer model to the page – discount_1, discount_2, sales_rep. But they were put into a form where the initial value of the field would be the value from the customer object. By adding an update button at the end, we are now done with the editable dropdown fields.
Schedule button
On the same page, I added the schedule button and used simple JavaScript to create a popup window that opens on clicking the button. Inside I added the close icon which can be used to close the popup.
In the end, we ended up with a dynamically rendered page that looks like that, showing all the information about the customer based on the URL you get into. The rest of the tabs will be based on this same foundation, although the upcoming ones are going to hold features that are going to be way more crucial than the ones we just tackled.
GALLERY
The only purpose of this tab would be to display all the images that are linked to the customer order and labelled by the date they were added. Within the same customer view that we worked on before, I imported all the models that I created for the customer page.
By using the code customer.wasabi_gallery.all().order_by('uploaded_at'), I stored all the gallery image objects inside a variable and grouped them into a dictionary using the upload_at date as the key. This dictionary was then passed into the customer.html page and inside that, I used the for loop to loop through the dictionary and display the images according to their upload date.
This was the end result, and it was exactly as expected. Every time a wasabi_gallery object was created for a customer, it was stored inside the /gallery folder for the customer, and the image would show up on the gallery tab within the customer page.
TIMELINE
Timelines are posts created by the internal staff inside the customer page to keep track of all the activities for any order related to the customer. The page must allow the user to add a timeline post through a popup where the user can enter a comment and select a “Post Type” for the post.
Post types always belong to one of the below types:
- Technical Issues
- Order Finalized
- RMA
- Other
The form must allow the user to attach multiple images to the post if necessary, through the popup. The username of the user who creates the post must appear on the bottom left end of the post frame. There is also an option to delete a timeline post by clicking the button.
Interface connected to the Timeline Model
Firstly, like always, I built all the frames necessary inside the timeline tab using HTML and Tailwind CSS within main/customer.html. This included the “Add Post” button along with an example post frame. In main/views.py I created a variable named timelines that stores customer.timeline.all(). Within the HTML page, I used a for loop to iterate over all the objects within the timeline and display them as timeline frames as per the design.
Add Post Popup
I created a hidden div inside the main/customer.html file, filling the popup with all the necessary fields. The pop-up contains the dropdown, comment as well as the image input field. All the input fields were put inside a form that was linked to the URL /customer/<str:unique_code>/timeline/create/, and this URL was linked to a view I created named timeline_create. The timeline_create view created a new Timeline object and linked it to the customer which was linked to the unique_code in the URL.
By using request.FILES.getlist(‘images’) we fetch all the image files that were uploaded. For each of these images, a CustomerGalleryImage object was created and linked to the customer. Then a TimelineImage object was created linking the CustomerGalleryImage object to the Timeline object that we just created. With this, the Timeline page was ready to allow the user to create posts and display the same.
Delete Timeline Post
A delete button was added to the timeline post div inside the for loop, and this button was linked to a URL /delete_post/<int:post_id>, which was linked to the view delete_post. This view would fetch the Timeline object based on its ID and delete it.
With that, we ended up with the page above containing all the necessary tools for the internal staff to create and manage timeline posts for their customers.
ADD CUSTOMER PAGE
The “Add Customer” Page is very straightforward, where it’s just a matter of plugging in a form that contains all the fields to create a Customer. This page is intended to be used by a few internal staff users who would create a customer through the website. Linking the customer to a user account would be done by a staff who works with the admin interface.
First, we create a form inside main/forms.py, including all the fields from the customer object. Back in main/view.py a view is created and linked to the URL add/customer/. This view displays the main/add_customer.html page while also creating a new customer object based on values in the customer form when it’s a POST request.
Once the customer is created, the page will be redirected to the customer page of the customer we just created.
With this we are done with the customer page as well as the add customer page. We are however yet to build the Orders tab inside the customer page, but I have saved that for the next post since it has alot to do with the Order model as well as the Order Wizard page, like the name suggests.
NEXT STEPS
This post is the third part of the whole project documentation series. In the next article, I will go through all the Order Wizard pages, how the order placement process works, and the way all the pages come together involving multiple users to provide a robust medium for the customers to place custom sunshade orders within the site. Feel free to use the links down below to read about any part of the project you are interested in. I’ll see you on the next post!
- Meetings and Project Kickoff – https://stagmoney.com/meetings-and-project-kickoff-osaat-part-1/
- Deployment, Authentication and Dashboard – https://stagmoney.com/deployment-authentication-and-dashboard/
- Customer Page – Current Post
- Order Wizard – Upcoming
- Calendar – Upcoming
- Workstation – Upcoming
- Map Navigation – Upcoming
- Minor Features – Upcoming
