Last April I built an app for a novel contest run by an online writers group. It was set up so users could sign up for the app, make an entry for their novel, and then use the app to track their writing progress, as well as see the writing progress of other users.
The concept was basically to make something similar to the Nanowrimo website (National Novel Writing Month for those of you who don’t hang out in writing spaces as often as I do!), but smaller and focused on the specific functionality the organizers of the contest wanted.
I launched it, the group used it, and it was great!
And then a few months later, I got a request for another version of the site for a different group to use. I spun up and hosted a new version—changing a few things like the yearly rollover of novel projects—but doing that got me thinking. Creating this site for another group required another whole instance of the site, and if I ever wanted to do this again for another group, this really wasn't efficient. If I took some time to rewrite the app's code, I could instead give users the ability to run and manage multiple contests within the same app.
With that in mind, I set out to make a version of the app that would support users creating and running their own contests, multiple if they wanted.
And that starts with project planning, which is what I’ve been doing this week!
The Notes
To start off with, I walked through some user stories—what I wanted users to be able to do with the app:
- One user story:
- A user signs up for the app
- They make their own contest
- As the contest admin, they can set a date for when the contest ends, if they want it to end
- They have/generate a link to let other people join the contest, and send that out
- They can make other users in their contest admins too, if they want
- They make a novel, associate it with their own contest
- They view their novel, and also edit it
- With the same account, they can create, view, and/or sign up for other contests if they like as well
- Another user story:
- A user receives a link for a friend to sign up for this app
- They sign up for the app first
- They enter the token to sign up for that specific contest
- This prompts them to create a novel, and they have the option to add the novel to that contest, since they have joined the contest
- The user creates another novel that they just want to have for themselves
- This novel is not associated with any contest and won't show up on any contest pages
The Models
From the user stories I had come up with, I knew that I needed some complex relationships with my database models here. Users needed to be able to have many contests, and contests should also have many users. I also wanted users to be able to have different relationships to their contests—one user may be an admin of two contests, but just a member of a third, for example.
At this point, this started to sound familiar, and I realized I had come up with some very similar models for a previous project of mine, a collaborative novel writing app built in Rails. In that app, meant for online collaboration on novel projects, users had many novels through memberships, which also included a role attribute that would designate the user an admin or a regular member of the novel project.
Adjusting this a little, from novels to contests, I was in business! I also decided to change “contests” to “challenges.” Despite the original use for it being to run a novel contest, “writing challenges” is a lot more generalizable and represents more use cases for the app, so it made sense to start from here on the model level. Contests became “challenges”, and novels became “projects.”
I also wanted projects to be able to be a part of multiple challenges, but that was a simpler join table.
I used drawSQL to diagram this because it was free, visually appealing and easy to use, allowing me to drag tables around to organize things in a way that made it easier to interpret visually.
The Sketches
I did these sketches at the same time as I was diagramming my models. The sketches helped me make sure I had everything I wanted in my models, and vice versa.
The main difference I knew that I wanted on the frontend from my original app was I wanted users to be able to easily view the splash pages for multiple challenges, and also create new challenges. In addition to that, I wanted them to be able to easily view all of their projects. The layout will probably change when I get to the React part of this project, but for now, dropdown menus made sense. The project cards are taken directly from how they’re laid out in my novel contest app.
With multiple challenges, it didn’t make sense to have the challenge guidelines in the main nav bar anymore, so here I have the projects and guidelines views as two tabs on the main challenge page.
Another thing I wanted to add to this app, now that I have figured out it’s possible to update a user model without having to update the password was user pages with a bio and the user’s projects. Ideally, the user should be able to set them to private vs public so all of a user’s projects would show up for them but only “public” projects would show up for other users.
Finally, a very draft-y admin panel for challenges. I wanted users to be able to change a variety of settings, such as being able to set challenges as open/closed, public/private, and also to determine if they should have set start and end dates. This is one of the sections that is likely to change as I go along, just because there's so much functionality I could add here. Keeping minimum viable product in mind though, this is what I'm going with for now.
What comes next?
Now, with a better idea of my user stories and my models planned out, I’m ready to start building the Rails API backend for this project! More on that soon.
This project is in progress, so if you have any questions, suggestions, or feedback you’d like to leave on the project, please feel free!
Top comments (0)