Recreating WUPHF: App Data Structure (part 2)
To flesh out my app’s functionality, I want to give users the ability to register and log in. A logged in user should be able to create, manage, and save contacts to whom they can send Wuphfs to. It also makes sense that a registered user should be able to Tweet their Wuphfs from their own Twitter accounts instead of from @wuphfwuphf.
I need three models to achieve desired functionality.
- User — A registered user
- Recipient — A contact created by the
- Message — The “Wuphf” being sent from
At a glance, the models look something like this:
password: hashed string
One of the bigger challenges I faced was giving users the ability to send tweets on their own behalf. Let’s take a look at some code from my previous post.
Notice that when
boot_twitter initializes, the
access_token_secret are being called from my environment variables. Currently, these variables store the tokens that allow an unregistered user to tweet from @wuphfwuphf’s twitter. I need a way to let registered users pass in their own acquired
In order to allow users to pass their own tokens so that they can tweet on their own behalf, I pass parameters when calling
Default arguments use the environment variables but also allow me to pass in different tokens for users. I am able to use the same
TwitterWrapper for unregistered users who tweet their Wuphf from @wuphfwuphf and registered users who tweet their Wuphf from their personal Twitter account.
Shifting Focus to UI and Usability
I finished adding the ability for users to register and create their own contacts and showed a couple of friends my web app. It looked something like this:
I noticed that people didn’t know that they could send a Wuphf without signing up for an account. They thought that the form on the landing page was a registration form! No one wants to register just to try a product.
In an effort to make it more clear that the form on the home page is for sending a Wuphf and not a registration form, I decided to restructure the order of input boxes. A user now types their name and message before typing in their recipient’s details. This experience is much closer to composing an email and less like filling out a registration form.
The newly designed home screen and dashboard look like this:
Up next: Creating the API and consuming it with a React-Native application