Recreating WUPHF: App Data Structure (part 2)

At the end of my last post, I had just finished shipping my MWP (Minimum Wuphfable Product). A user is able to visit wuphf.io and send a Wuphf to their friends without having to register.

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.

Data Structure

I need three models to achieve desired functionality.

  1. User — A registered user
  2. Recipient — A contact created by the user
  3. Message — The “Wuphf” being sent from user to recipient

At a glance, the models look something like this:

Users
has_many recipients
has_many messages
email: string
password: hashed string
Recipients
belongs_to user
name: string
email: string
phone: string
twitter_handle: string
Messages
belongs_to user
belongs_to recipient
content: string

Connecting Twitter

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 and 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 access_token and access_token_secret.

In order to allow users to pass their own tokens so that they can tweet on their own behalf, I pass parameters when calling boot_twitter:

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:

Home page
A user’s dashboard after logging in or registering

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:

Newly designed home page
Newly designed dashboard

Check out Wuphf live here and the Github repo here.

Up next: Creating the API and consuming it with a React-Native application

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.