Skip to content

First MVP

Jump to bottom
Tim Yao edited this page Sep 6, 2024 · 5 revisions

User Login use cases

  • A user creates a login
    • user specifies and verifies their email address for account recovery
  • User logs in with their password
    • in spite of passwords being inherently insecure (password strength requirements)
  • (stretch) User logs in with their Google/Facebook/discord account
  • User recovers their password (through their verified e-mail)
  • (stretch) User deletes their account
  • (later): MFA
    • passkey (account automation) to avoid using passwords (biometrics can act as a passkey; password managers);
    • in the future, have an option to remove the password entirely (so they don't have to have one)
    • have multiple ways to login into the system

User profile

  • User can populate their description field
  • linktr.ee field
  • User can opt-in into making their profile publicly viewable
  • (later) social media entries, writing-related fields (e.g., favorite books, authors, own books, other links)

Projects

  • User can create a project (writing, editing, writing & editing)
  • Start date = date of creation or whatever the user specifies
  • User can set the target end date
  • User can set optional separate writing and editing goals
  • Writing measured in # words
  • Editing measured in one of: hours, days, pages, chapters
  • Project title (optional)
  • Project description (optional)
  • Project genre(s) (optional)
  • (stretch) cover image

Progress

  • User can enter their progress (# words written, # hours spent, # days spent, # pages edited, # chapters edited) for today or a specified date for an existing project. This isn't the cumulative progress, just what they've accomplished for the date specified.
    • decimals, not integers
  • Behind the scenes, we will calculate their cumulative progress (combining like units) and also will combine entries for a common day/unit.
  • For comparison: % completion
  • There will be a simple table presented to the user on the web interface showing their progress (day/date, # words, # hours|days|pages|chapters)
    • could do unit descriptions (writing and editing) and let them track it however they want
    • in the future, there may be people to track things like # queries sent (or other custom units: ideas, recipes, poems, drawings, monsters)
  • (stretch) they can edit/delete any progress entries
  • (stretch) there may be an individual graph
  • word count (integer) --> fixed precision (2 digit precision decimal)

APIs

  • User can opt-into enabling world visibility of their project via APIs
  • users can opt-into enabling world visibility of their profile via APIs
  • world visibility = publicly visible
  • Levels of privacy: public | buddies | private
  • use case: discord bot fetching data from APIs
  • for a specified userid, API can retrieve
    • username, user profile description, linktr.ee, list of visible projects (project key and project title, genre(s), project start date, project end date, goals)
  • for a specified userid and project key, API can retrieve
    • all the progress data: date vs #words, # hours, # days spent, # pages edited, # chapters edited, % complete vs. goals
    • (stretch) provide this with smoothed data up until the latest day

Front end web app

  • will consume the APIs

Community graphs

  • These will be implemented via cron jobs and gnuplot in the MVP; later, we can build this onto the solution, along with Quests and Communities, buddies, etc.

Support system

  • tell users how to use it
  • knowledge-based documentation
  • github issues for system issues
  • google form for human issues (good to have people to help)
  • we can point people to a public discord (but who can join it, community manage it)
  • we can point people to the /r/writingquests reddit (with moderators)

Reporting

  • MVP: people should be able to report inappropriate text; moderators can then set the profile private until it can be investigated
  • Some users should have moderator powers to do this privacy setting and check things out.
  • Consequences --> warning, banning, banning of e-mail, banning by IP
  • (later) Code of Conduct - Moderator's choice
  • Keep it PG-13 (visible note to users)

Tech stack

  • php framework: Laravel (a bit big), Symphony (huge but modular, DB-abstraction layer), Slim (an Express clone)
  • front-end: react (well-documented, really small; huge community), VUE (also small)

Questions

  • What type of auth do we want? Some options are username/password, email/password (with a separate display name), or some sort of magic login button (basically single-use passwords sent over email). I normally like the last one since it means we don't have to store passwords, but idk if Dreamhost has reliable email-sending capability.

    • Suggested requirements: give some freedom to user on their displayed username; one username per email; unique userid that can be used in API queries; MVP should minimize the development cost. Username should be case-insensitive
    • Dreamhost is roughly reliable (sometimes there have been outages, but while running, it should be okay)
    • I like the magic login button and OAuth with google or Facebook accounts if we can easily do these
    • if someone is intercepting the user e-mails, then they have other problems (not a system problem)
    • username/password is faster to implement (a big plus); with email for password recovery (username is immutable; can't change it once selected)
    • userid = lowercase, alphanumeric + - + _ + .
    • username = userid? postgres has a column type that is case-insensitive, but case is preserved. Then username could have some caps but equivalent to lowercase. Okay to preserve case but do comparisons in lowercase.

  • How will this integrate with Quests in the future? I wonder if a Quest object should be part of the MVP with only one configured manually (Novel Quest: 50k words in November) while allowing people to overwrite their own goals

    • I wanted to keep the MVP small; and if we have APIs with the data, we can provide graphs and such outside of the MVP without expanding it.
    • no Quests on the front end but enough of the DB to support the future growth. E.g., projects would have start/end date and goals. per-project goals
    • Quest is something that participants are attaching their projects to (multiple Quests per project are possible).

  • Quests == Buddies? (buddies in the future, not as part of the MVP)

    • people have different groupings of buddies (Quest might be a user-defined group that potential buddies could join)
    • one buddy universe with a profile wall
    • or instagram-style? dashboard you login and see cards at what your buddies are doing
    • or instagram: you can follow each other but not have to mutually follow each other (people can follow each other but not necessarily follow back)
    • so a follow system
    • buddies are people who follow each other (maybe with special permissions)
    • direct messaging (1:1 buddy)
    • to comment on something, you have to be their friend

  • How can we send transactional emails (I think Dreamhost might offer an SMTP server?). The only ones in the MVP are password reset and email address verification emails

    • Dreamhost does offer SMTP for sending mails

  • Does Dreamhost allow cron jobs?

    • Yes

  • Is oauth an option to consider for user login as well? It also offloads password management and I know as a user, I'm more likely to hit an oauth button if I see one.

    • Supporting OAuth (google, facebook, discord) --> can still store information for their account (just a way to avoid dealing with passwords)
    • an option in addition to username/password
    • can leave this for later (stretch goal for MVP)

  • IDEA: Discord bot to post images of graphs to writing communities

    • top ten lists
    • winners list
    • list of top ten daily gains
    • there are many regions that use discord
    • authorize it to a guild
    • to foster competition between teams (update word count through the bot)

  • The only other thing that jumps out to me in the MVP is having the start date of a project be the creation date. I know a lot of planners who would want to put a project in in advance of the challenge, and having a project graph/stat section show a start date as creation rather than when they intend to start probably wouldn't land.

    • ok: allow a special start date

Next

  • Get the basic tooling and framework up and running
  • Database schema (graphql would be similar)
  • Next Friday, 5 PM CDT

Clone this wiki locally