Affirmations Application | Kalib Watson's Portfolio

Affirmations Application

Situation

I was approached by a client who currently runs a daily affirmation program. Each day she emails hundreds of people an affirmation at 7am EST. However, having an automated mail system send out hundreds of emails every day gets quite expensive, and this process is not very efficient. The client had been asked by recipients whether she would consider creating an application instead of sending emails, this way clients could come to the app at any time during the day to view their affirmation. This would also allow my client to load multiple affirmations into the database ahead of time, instead of having to send an email every morning.

Process

When my client approached me, she was suggesting building a mobile application. She had a wish list of items that she wanted to accomplish:

  • Users would receive a notification in the morning
  • Users would be able to view their affirmation at any time during the day
  • Including music and an image with each affirmation so users could meditate
  • To be able to add affirmations to the database, preferably from the application
  • Monetize the application; users would pay $0.99 for the app on the app store
  • To follow along in development, knowing how the application worked in case she needed to troubleshoot a problem

I held several meetings with the client to sketch out ideas, talk about expectations, and develop survey questions for her users which guided our choices.

Our survey showed that most users were fine with going online to view their affirmations, they didn’t mind not being able to set when their affirmation appeared or when they got notifications, and they didn’t want to have to log in to an affirmations app because they felt having a password would be more trouble than the app was worth. They wanted simplicity more than anything, and so did my client.

This steered us away from creating a mobile application for a few reasons:

  • Developing a mobile app would likely require us to build two versions of the application for different devices, and the client wanted to launch the product all at once.
  • Users did not want to have accounts on the application, which makes using a web app more feasible because we don’t need to authenticate users as we would on a phone.
  • There are more options for monetizing a web app. Even without user log ins, the client can use advertising or online donation services to generate continuous revenue, instead of receiving one-time payments.
  • Web apps can send notifications to users through email or through the browser using the new web notification API.
  • The client is already familiar with web technologies, and this allows them to better understand the codebase if errors occur.

After determining that we were creating a web application, my client provided me with some fonts that she liked and I created a mockup of the application using the Marvel app.

View the project mockups.Opens link in new tab

The project is currently in the process of being translated from designs into code, and will be built on React and (most likely) a Python microframework. The application is scheduled to be completed near the end of May, 2018.

Currently I am working to translate the designs of this application into a React app. This began with understanding which parts of the application should be components, and which parts of the app will gather and store information as the state.

A diagram that I drew on a whiteboard showing the application components and the methods that they will need to call.

This has gone quite smoothly so far, but because different individuals use different semantics to write their React apps, I’ve run into a couple of instances of not being able to understand why a component is written a certain way. This makes it harder to translate this directly to my application functionality, but it’s also a good learning exercise to understand why other developers might choose to structure their code differently.

If you’d like to see exactly where this application is right now, you can view the codebase from the GitHub repositoryOpens link in new tab.

Takeaways

Although this project isn’t complete yet, so far I’ve gained a great understanding of how to better communicate with clients, what questions are important to ask when conducting user research and planning an application, how to negotiate project goals, and how to create and interact with back-end APIs. I’ve also learned a lot about React and how its file structure, render methods, and component lifecycles function.

Throughout the rest of the project, I hope to learn more about client-coordinator relations, React, application security, and Python microframeworks.