My developer journal: Sprint IV— Final features, UX & UI
Building a web chat app
This is the fourth entry to my Developer Journal for Lambda Labs project, where we build a service chat app for hotels and its guests.
During our last demo, where we presented the project status, we’ve received a deadline for “feature freeze”. The deadline was this weeks Wednesday. Together with team we’ve decided to take advantage of this time to build out some of the features we did not intend for the MVP. I’ve worked on two additional features:
- Guests can scan a QR code that takes them to the chat application where they can talk with hotel staff.
- Admins/receptionists can talk to guests in English and messages will be received in the guests preferred language
QR code generation
We wanted to generate a QR code for the guest, when the Receptionists checks the guest in. Scanning this QR code would allow the guest to be redirected directly to the chat app, with his credentials already prepared for him. He would not need to type in any URL or passcode, which we generated for him.
On front end, I generated the QR code with a library I found online. The component that will generate QR code takes in string parameter, that would be displayed upon scanning the QR code. In our case, this would be the URL to the chat app together with secured user credentials. On back end, I have modified the way we generate JWT, so it includes guests passcode. And on guest chat app I created a function, that would check for fragment identifier in the URL and based on that decode user credentials and populate the login form for the user.
Translate the chat to/from English
This feature was a bit more complicated, as it required connection to Googles Cloud Translate API. As always, when I work with third party APIs, I had issues with authentication. After struggling to find answers online, I turned to StackOverflow, which was recommended by Googles Support. Fortunately, I received help quite soon and was able to get it working.
With the API connection working, I built out two functions. The first one would detect the language which the guest used to chat in the app and then translate that text to English. The other function would receive English text with target language and translate that text into targeted language.
Then I build an endpoint, which would take requests for translation. This endpoint would decide based on request body, which function to use and how to respond.
On front end I originally wanted for the hotel staff to select the language to which they want to translate, but I thought that would not be a great UX, so I’ve changed it to automagically detect the language and just added simple buttons to the chat screen, which would handle the requests for translations. One would translate guests message to English. The (Translate & Send) would translate the message from hotel staff to guests language.
After testing it locally and code reviews, we’ve pushed it into production. Only to find out the authentication was not working in production. So I went back to Google Documentation on this service and found out I could use different authentication method for a project like this. So I adjusted our back end and front end for it to work properly when deployed.
With both features deployed and feature freeze, I moved on to help my team mates with improving the UX and styling the UI.
Restricted alerts
First thing I worked on were alerts for restricted actions. We’ve decided to use modals instead of standard alerts, that browsers use.
First I’ve created a reusable component, which would take the text to render, state of the modal (open/close) and a function to close the modal. Then I’ve replaced all alert calls in the React app with this component and passed in proper properties. For them to work I added a state property to the parent component, which would handle whether the modal should be open or closed.
Fixing up a Pull Request
Next I pair programmed with a team mate to help him finish up a Pull Request he struggled with. As the PR grew in the last couple of days, we ended up spending couple of hours going over it and fixing and refactoring stuff.
Billing page styling and UX
I’ve worked on styling our billing page inside the Company Dashboard, so it would be aligned with styles on our landing page and the rest of the app. I’ve removed all the material-ui components we’ve used before to bootstrap the app and replaced them with proper components we’ve built out and styled. I also changed how the Stripe modal for the payment information looked like. Then I changed the UX for newly created users, who did not have a payment information yet, so they would be prompted to add them before being able to change their billing plan.
Netlify routing bug
One thing that was bugging me, when I was testing features on deployed app was a bug on Netlify where when I refreshed a page on some route, I would get a 404 Page Not Found error. So I’ve created a ticket for this bug and started to read up on this issue.
The fix was pretty easy and well documented in Netlify documentation and couple blog posts. I just had to create a _redirects file with a path to our root index.html file, which would redirect routes based on our routing.
We’re getting pretty close to finishing up the project. It’s quite amazing seeing it all come together. We have one last week ahead of us, where we’ll polish the UI and fix any remaining bugs. We’ll also have to prepare for the demo of our project, probably with a video featuring all of the apps functionalities.
