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.
When my client approached me, she was suggesting building a mobile application. She had a wish list of items that she wanted to accomplish:
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:
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.
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.
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 repository.
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.