This may take some refactoring so that notes index just expects any object with notes

Campaigns seems vague and could potentially confuser users in the future.

"Campaign" is a term used in RPGs for referring to a story-line that players play through. Players can have multiple characters through the same campaign. Players may also have multiple campaigns with the same character. If groups of notes are referred to as campaigns, this could be confusing to players.

There are already words for "groups of notes". "Notepad", "notebook", and "journal" immediately come to mind.

We could also just refer to groups of notes as "notes". Do we need a grouping system for notes as a default, or is it enough for users to group notes based on ownership by the user? This question seems to infer two paths we could take:

1. Players have notes through some other object such as Journal or Notepad.
2. Players have notes directly, and these notes are grouped through filtering.

The upside to option 1 is that notes are grouped in large batches by default. This would make it easier for users to have individual journals for each character they have. They could group these batches however they wanted, so they could even have notes grouped by campaign instead (if they had multiple characters in the same campaign and wanted to keep the notes together).

The downside to option 1 is that if a user wanted to group notes from multiple journals, that would need to be implemented somehow, as they would be separate by default.

The plus and minuses for option 2 are basically the inverses.

To do:
What is the main goal of the dashboard? It should give user's a quick look at what has changed since they last used, including notifications raised and potentially changes that have happened to shared journals.

• Show user's journals (potentially with a list of changes)
• Show user's notifications

Extra (original issue text):

Originally, I had the idea of when the user is signed in, they would view different things at the root address based on conditionals. These were:

• If user had no journals, redirect to new journal page
• If user had one journal, open the journal's notes index
• If user had multiple journals, open the journal index

However, upon exploring implementation of this, I decided this may be a poor idea. The idea was designed to make navigation simple for the user, but it may be confusing that the user uses the same address for multiple different pages.

Instead, I think it would be better simply for the user to see a dashboard if they are logged in, and ignore all these other conditions. The dashboard should give easy access to all of these previous ideas.

Users should be able to view notes right after creating them.

The view should display notes in order of recently created.

• User should be able to only have one membership per collection.

• Users should not be able to send invitations to users that already have membership to the collection.

• #51

https://github.com/test-prof/test-prof

Symbols meaning images!

The hamburger button saving some navbar space is only necessary for mobile. These links can be constantly visible on desktop.

Navbar should always be accessible via hamburger button.

Links on navbar should include:

• Home
• About
  If signed out:
• Sign in
• Sign up
  If signed in:
• Journals
• Friends
• Notifications

This path assumes:

• User is signed in
• User has no campaigns (so they must be able to create first campaign)
• User has no notes

Currently, membership is recorded in a group through the accepted_at column in collection_invitations.

However, it feels now that we need a Membership model and table as well. These are separate things. While tracking accepted_at in invitations does not feel completely wrong, I want to now add a role for controlling user permissions in joined collections. This role does not belong on the invitations.

collection_memberships

• user_id: references (users)
• collection_id: references (collections)
• role: integer

Since we are going with memberships and invitations as separate entities, this has exposed a problem with invitations as they currently exist.

Currently, invitations invite Journals. This infers that Journals are inviteable, but it is the user that should be inviteable. Users should personally choose which of their journals join a collection, not the person that is inviting the user.

Invitations should invite users.
Memberships should track which journals are in the collection.

Users should be able to leave a collection they are a part of.

This is pending the implementation of friends to the app.

This should easily be implementable per https://github.com/heartcombo/devise/wiki/How-To:-Allow-users-to-sign-in-using-their-username-or-email-address.

Navbar visibility should be toggle-able with a hamburger button.

Party is a group of users that want to share their notes.

When a campaign is attached to a party, they should be able to view all public notes for other campaigns attached to the party.

All new notes created after joining the party (that are also public) should be viewable to the user and other party members.

There is currently a link in the navbar for "About" which is intended to explain the app. This static page needs to be setup as currently only the route exists for it.

Pages that lack styling:

• Journals#index

When creating a note on the journal notes index page, content is lost (notes shown and journal title). The page should simply show the flash and allow the user to continue as they were.

This is pending the implementation of notifications to the app.

Currently, there is no styling applied to the entire project. It is very bare bones. It's time to change this!

• The position of all current elements on existing pages should be approximately correct
• Colors should be applied
• Font size and height should be applied

Users should be able to invite and/or request permission to view or edit their friends notes.

User's should not have notes named the same thing. However, the note name's should not be globally unique.

Note names being unique for the user should assist with linking to other notes using their names.

Allow users to message other users. We can call it a "whisper" system. This could be another way for players to share notes or even possibly chat while playing the game.

The goal of this system is not for complete communication in a game. However, it should help users share notes easily without distracting from game play.

Should be more friction for a user trying to delete a journal, more than just an alert. Because they will lose all associated notes when doing so. Perhaps typing the journal name.

We want the navbar to cover the current page content (slightly) or in other words "popover".

The user should be able to tap outside the popover menu to exit the menu. There should also be a close button for the popover as well.

Think of how links are made in Obsidian with the [[link]] syntax. If something like this was available, users could easily add links in their notes without having to move away from their keyboard, which will help the user focus on the game in front of them as they add notes.

View transition resources:
https://developer.mozilla.org/en-US/docs/Web/API/View_Transitions_API
https://seattlejs-view-transitions.netlify.app/

Evil Martians article exactly on addIng view transitions to an app using Turbo:
https://evilmartians.com/chronicles/the-future-of-full-stack-rails-turbo-view-transitions
https://github.com/palkan/turbo-view-transitions

Other stuff I looked into:
This may be a useful plugin:
https://github.com/domchristie/turn

Bridgetown implementation:
https://github.com/bridgetownrb/bridgetown/blob/main/bridgetown-core/lib/bridgetown-core/configurations/turbo/turbo_transitions.js

Some discussion on view transitions with Turbo:
https://dev.to/nejremeslnici/how-to-use-view-transitions-in-hotwire-turbo-1kdi

The core skeleton of the app is CRUD with notes. Users should easily be able to create, read, update, and destroy their notes.

The app encourages users to only use one of two modes:

• Adventure mode
• Library mode

Adventure mode is the mode where users input (create) new notes. They should be able to see their recent notes too, but not too many of them. This mode is not meant for users to view their notes in organized ways. One way is to think of this as the short-term memory of their character.

Library mode is for navigating (reading and searching) existing notes. They should be able to sort notes in various configurations and find notes using keywords.

We created a Users namespace for Invitations to separate it from the Collections namespace. However, since this is a user focused app, it seems like the Users namespace is redundant.

Instead of going to "users/invitations" it should just be "invitations".

If for some reason this namespace is deemed desirable, it may be worth it to then consider making it the User namespace instead, singular. The plural only sounds correct because of the possessive "user's".

Some research from years ago suggests that having a bottom navigation bar instead of hamburger menus increases user engagement.

Refer to these resources:
https://ux.stackexchange.com/questions/101595/mobile-website-menu-should-hamburger-menu-be-on-left-or-the-right
https://www.youtube.com/watch?v=OkeJg92PA4E&t=3248s

Notes should be taggable to help with navigation.

Some example default tags:

• character
• location
• item
• secret
• event
• lore

Notes should be easily filtered in ways that users will want. Some ways that a user may want to filter notes are:

• Their played character
• Campaign
• Who they are playing with
• Date of note
• Keyword in the note title or body
• Location of character
• Tags
• Pinned

It feels like these can mostly be achieved with just two of the above:

• Keyword in the note title or body
• Tags

It could potentially be achieved with just keywords in the note, if the tags existed in the notes themselves, but I can see cases where users would want ways to achieve filtering without clogging up their actual note. All of the other options could easily be achieved implemented in the ideas of note content and hidden tags. Some tags could have smart defaults so users could filter notes with less work

Notes can currently be created in the Notes#index page. This may be the ideal location, as Notes index route is nested in journals, and an associated journal is required for a new note.

The new note section on the index page can expand to allow the user to take advantage of the whole screen without changing pages.

If any benefits of having a new note page separately are discovered, please comment on them here.

When users delete journals, all notes attached to the journal should also be deleted.

Users must accept friend request to complete the friendship relationship.

User should only be able to view notes if:

• User is the owner of the note
• User was given authorization access by the owner (This would need to be implemented!)
• User is viewing the note through a Collection that the owner has joined with that note's journal

This article seems interesting:
https://thoughtbot.com/blog/testing-your-factories-first

Users should be able to add other users who they play with and easily share notes with them. They should also be able to hide notes from all other users as well.

If the user could see a preview of their styling, it would help them get their desired layout. This would be especially useful to users not familiar with markdown.

Symbols meaning images!

I created CollectionInvitations thinking that there may be other types of invitations in the future such as friendship "invitations". However, in this case, I think we should just have Invitations and polymorphic relationships of "inviteable" things and/or "attendable" things.