Reading Length 2.0 - Developing project requirements

Reading Length 2.0 - Developing project requirements

I want the redesign of my website, Reading Length, to allow users to interact with it in the exact same way as before, while allowing me to develop further the features that I would like to see. Allowing users to interact with it in the same way as before is important for multiple reasons, but most importantly search engine optimization (SEO). Most of the traffic Reading Length receives is from organic traffic (search engines), so to protect my high rankings I need to make sure links still work and serve up the same information to start. The link /book/isbn-1234567890 still needs to display the same exact information when I go live with the first iteration of the new site.

Beyond preserving current features, I need to make sure the features I am planning add value greater than the cost it will take to build and maintain. The cost for me build is moot at this point, since I am undertaking this project to learn how to develop a website in a professional manner. However, the cost to maintain could be huge and last for years. For example, I don't want to build a forum that requires my daily attention in moderation. All of these features need to be automatic, or require minimal intervention. If they do require maintenance, they better be worth it monetarily.

Cost benefit analyses

For each feature, I will perform a cost benefit analysis in the form of:

  • Ideal value added

  • What could go wrong

    • Mitigation

The primary features that will be included in the first iteration do not need to be analyzed, since they are currently in production and I know the costs and benefits.


Primary (v1)

  • Book search
  • Word count generation
  • Reading time estimation
  • Reading speed calculators

Users (v2)

  • User log in

    • Ideal value added: Increased user retention, user experience, word-of-mouth marketing, visibility into loyal user demographics
    • What could go wrong: Security vulnerabilities, data leaks, maintenance, requires legal notices (privacy policy, terms of service, etc), spam accounts

      • Mitigation: Use a well-known auth library or auth pattern, keep things minimal, do not collect much user data, find good boilerplate terms of service, disallow common spam patterns in names or profiles, create an admin dashboard
  • Log in through OAuth

    • Ideal value added: Users may not feel comfortable registering, ease of registration, social sharing opportunities
    • What could go wrong: Duplicate accounts being created, upkeep for each API

      • Mitigation: Use a well-known OAuth solution like Passport.JS
  • Add books to lists

    • Ideal value added: Increased user retention, user experience, marketing opportunities
    • What could go wrong: Upkeep, showing book data may require too many API calls

      • Mitigation: Cache some book data, allow easy edits of lists
  • Update reading progress

    • Ideal value added: Increaseed user retention, user experience, data for word counts by asking how long it took them to read X number of pages
    • What could go wrong: Complicated data relationships, inaccurate information skewing derived data

      • Mitigation: Carefully design the data relationships, weight the input reading times against other 'known's such as audiobook length, page count
  • Submit quotes that stood out to them

    • Ideal value added: User experience, unique content on book pages and user profiles
    • What could go wrong: Copyright issues, spam

      • Mitigation: Make quotes editable by admin
  • Integration with Goodreads

    • Ideal value added: User experience, most users probably already have a Goodreads account, data could be synced

    • What could go wrong: Terms of use needs to be researched, lose users to Goodreads, number of API calls could go beyond the quota, out of sync lists

      • Mitigation: Bidirectional data transfer so people don't have to add a book to their list on both services, research terms of use, reach out about quota if that's an issue

Clubs (v3)

  • Users can create a club

    • Ideal value added: User experience, differentiation from competitors
    • What could go wrong: Could become something that needs to be maintained

      • Mitigation: Carefully design the system to be managed by usrs
  • Users become the admin and owner of clubs they start

    • Ideal value added: User management of their own clubs, sense of ownership
    • What could go wrong: Abuse of powers

      • Mitigation: Allow users to report groups or users, implement in admin dashboard
  • Users can add other admins and moderators
  • Admin can modify permissions and group information
  • Moderators can delete comments and change meeting information and approve user requests
  • Groups can be public or private
  • Groups can have meetings

    • Ideal value added: Users can organize their book club meetings through the website, user retention
  • Meetings can have a time, place, and description
  • Groups can have comments

    • Ideal value added: Bring the discussion to the website, allow for online book clubs
    • What could go wrong: Users spoiling books, maintenance

      • Mitigation: Create spoilers feature
  • Comments can be hidden behind spoilers
  • Spoiler visibility can be toggled by user's reading progress
  • Groups can set a currently reading book
  • Comments and spoilers can be tagged by book and/or meeting or general
  • Historical books of the month can be viewed along with relevant comments and meetings


  • Affiliate links to Amazon and Powells (v1)
  • Price data from Amazon (v1)
  • Price data from Powells (v1)
  • Price alerts on 'want to buy' user lists (v2)
  • Book of the month email to those who do not own the book (v3)

Photo by Joanna Kosinska on Unsplash

Bridger Putnam

Bridger Putnam

Full Stack Developer

January 5th, 2019