bizziquest / questlistsfb

QuestLists frontend with a Firebase Backend

QuestLists

QuestLists is a crowd-sourcing application that organizes lists of any sort. The crowd builds the lists, you say what you want to use from that list, and then use it as a normal checklist. At its heart, this is an n-state checklist application.

The intention is to use the crowd to build lists for games, inventories, shopping, music, videos, and more! Once the lists are built and created, you can add/remove your items from them. It uses the browser's caching for data, so you don't even have to login to use it (only for the same devise)!

NOTE: This is the frontend for QuestLists, with a firebase backend, by default. More backends will be developed separately.

Demo

This is the public code for http://skamansam.github.io/questlists. The code is redeployed when I finish any feature or want to test something, so it may change a lot and may break down often. I will do my best not to disturb any data that is already there, but be warned, your data may be a casualty of development!

Once everything is stable, it will become a REAL application, and all the notices about the demo will be removed.

Roadmap

Questlists is originally intended for game quests, so will have the following ideas implemented first:

1. Your progress in quests.
2. Items collected
3. Overall progress in the game
4. Locations reached
5. Information about any other object in the game

I am sure you can generalize these ideas to fit any circumstance, so i will eventually create a few demos of lists for everyday use, such as a shopping list and various TODO lists.

Contributing

To keep things simple, I am only using GitHub and associated tools that anyone can use. I am even deploying this app to GitHub pages. For ticket management, I am using ZenHub, so you can use it too, if you want. All tickets will be managed through ZenHub, but you can create Issues in GitHub if you want, as well.

GitHub

If you would like to help with the development of this project, follow these instructions:

TL;DR - Fork repo and create a new branch for each issue, then create a new pull request. I won't be too 
harsh on the rest.

1. fork this repo (or ask to join the BizziQuest team!)
2. See if there is an issue currently in GitHub that addresses your feature, bugfix, etc. If not, create one!
3. create a new branch in your forked repo, including the ticket number in the branch name, like 4-my-new-feature or my-new-feature_issue-4 or my_new_feature-issue_4. You get the idea.
4. hack away!
5. When committing your changes, please make sure you include the ticket number in the description, surrounded b y brackets. Something like make sure we use the correct ES2016 syntax for foo-bar elements. [46]. The commit message should read like a command, not a summary of what you did. (This is a hard one to follow, as you can tell from my commit messages, but it really does help new-comers get an understanding of what's going on.)
6. Make sure ALL tests run successfully by running yarn check. This is to ensure you do not bug the application. Automated tests run for every PR and merge, and any code will not be merged without passing tests and linter checks.
7. Create a new pull request against the develop branch once you are happy with your code
8. Wait for the team to review and merge the changes. Merges cannot happen without review.

App Setup

We are using node version 10.x, due to compatibility with the firebase libraries. You should be using it as well. You can install nvm to manage local versions of node.

nvm use
npm install -g yarn
yarn
yarn serve

Running Questlists for Development

Just run yarn dev or yarn serve from the repo's directory. Running the dev command will start a local firebase emulator for you to connect for testing and local development.

Deploying Questlists

You can set up your own firebase instance at https://firebase.google.com. From there, you can configure firebaseConfig in main.js with your project's name. You need to have the following environment variables for deploying to your firebase instance. You can put these in a .env file, or copy the .env.example file.

VITE_APP_FIREBASE_API_KEY
VITE_APP_FIREBASE_AUTH_DOMAIN
VITE_APP_FIREBASE_DATABASE_URL
VITE_APP_FIREBASE_STORAGE_BUCKET
VITE_APP_FIREBASE_MESSAGING_SENDER_ID
VITE_APP_FIREBASE_APP_ID

Code Style Guide

Having a style guide really helps code readability and lessens cognitive overhead when developing software. I am using the Airbnb rules for eslint, with a few differences:

1. line length is 120 characters. the 80 char limit has not been applicable for more than 20 years.
2. You ARE allowed to use console.[error, info, warn] in production code. The team will be looking at these to determine whether they are used correctly and are necessary. You are not allowed to just console.log, as that usually means you are not thinking about why you need to print to the browser console.

NOTE: eslint is run as part of the testing for each PR so PRs will not be merged that don't pass the tests and linter. If you want to run the linter yourself, you can run yarn check.

Special Thanks

I want to convey a special thanks to Pimp Trizkit, for the use of his Pimped Javascript, which is covered under the GPL.

questlistsfb's Issues

Add day / night switcher for theme

There should be an easy way for users to switch day and night themes, i.e. light colored themes to dark ones, and vice versa. This should be a simple switch, with a sun icon on one side and a moon icon on the other. It should be out of the way, but visible on all pages. You can put it in the side bar or top bar, or in the main content area top right or bottom right.

interesting/challenging bits:

Having two themes with styles for both. Placing a switch for usability.

In the future, we are going to extend this to have more themes. Note: vuetify may already support light and dark theming.

light theme: https://material.io/resources/color/#!/?view.left=0&view.right=0&primary.color=FFF176&secondary.color=AB47BC

dark theme: [see original theme. maybe update fo the purple.]

(Editor's Note: Personally, I prefer the top right, in the main content area, no larger than 30px.)

The color of a list item background should reflect the state color

If a user has a color for a state, use that color as the background of the list item row.
This ticket is blocked by #35 .

This would probably need a color picker to be added to the states editor.

TRY THIS:
If the background looks too busy or intense, experiment with changeing the color of the underline, text, or checkbox.

Users should be able to edit their profile

As a logged in user,
When I click on my avatar in the top right,
I should be able to click on a menu item which
should allow me to edit information about myself

Also, as part of this ticket, the log out button should be moved to a log out entry in the user menu.
Basically, when the user is logged in, they should see their avatar in the top right of the top bar, replacing the log in / sign up button. The avatar should open a menu which will give them options to update their profile or log out.

For now, a user's profile should contain an avatar upload/change and full name fields (first and last). Make sure you display their email, but ensure it cannot be changed. The gist of the avatar is that if a user gets a random avatar they don't agree with, they should be able to change it. If you want to use a random avatar generator, make sure it can be randomized further or customized in some way.

Add firebase backend

We need to start using the firebase store. From now on, we will have to think about how to store the data constructs used. We should be using the realtime database. We will need to implement our own offline solution.

We need to organize data for queries, not for storage. As with any NoSQL database, denormalization is key. Please read completely through the firebase documentation before continuing.

Here is the scheme I have in mind:

NOTE: The top-level items are Collections. The *ref* items are the document references.

{
  states: {
    stateRef1: {
      name: 'CheckBoxes with an Intermediate State',
      description: 'Standard checkboxes with an intermediate state.',
      stateOrder: ['notDone', 'inProgress', 'done'],
      states: {
        notDone: {
          text: 'Not Done',
          value: 0,
          icon: 'mdi-checkbox-blank-outline',
          color: '#ff0000',
        },
        done: {
          text: 'Done',
          value: 1,
          icon: 'mdi-checkbox-marked-outline',
          color: '#00ff00',
        },
        inProgress: {
          text: 'In Progress',
          value: 0.5,
          icon: 'mdi-checkbox-intermediate',
          color: '#00ffff',
        },
      },
    },
  },
  userStatuses: {
    user1Ref: {
      listRef: {
        _status: 'inProgress', // cached status so we don't have to actually get the list items to calculate its status. useful for sublists
        listItemRef: 'done',
        listItem2Ref: 'inProgress',
      },
    },
  },
  lists: { // we want to store the list options here, so we don't have to retrieve the entire list with items when we just want a sublist
    list1Ref: { // firebase assigns new docs these IDs, when using push() we should take full advantage of this.
      title: 'Test One',
      color: '#ff00ff', // the color of the tile and background color of the page view
      states: 'stateref1', // we are deduplicating states by
      prerequisite: 'list3Ref.complete && list5Ref.listItem1Ref1 >= 5', // prerequisites for enabling this list. NO EVAL()!
    },
    list2Ref: {
      title: 'Test Two',
      color: '#ff0000',
    },
    list3Ref: {
      title: 'Test Three',
      color: '#ffff00',
    },
    list4Ref: {
      title: 'Test Four',
      color: '#465362',
    },
  },
  listItems: {
    list1Ref: {
      list1Item1Ref: {
        text: 'Item 1', // the  dispalyed text of the list item
        state: 'done', // state can be any arbitrary value, i.e. "5", "ten",
        prerequisite: '(list item 2 title).done', // one of several ways to specify objects in our
        order: 0,
      },
      list1Item2Ref: {
        text: 'Item 2',
        state: 'inProgress',
        order: 1,
      },
      list1Item3Ref: {
        ref: 'someOtherListID',
        order: 2,
      },
    },
    list2ref: {
      list2Item1Ref: {
        text: 'Item 2',
        state: 'inProgress',
        order: 0,
      },
      list2Item2Ref: {
        text: 'Item 2',
        state: 'inProgress',
        order: 1,
      },
    },
  },
}

NOTE: list.bgColor is now just color.
You should use the firebase emulator for testing this feature. https://firebase.google.com/docs/emulator-suite

The list view does not automatically refersh when new lists are added

Currently, there is no firebase reactivity for the List view. We should implement it.

There should be a few examples of kinds of lists that can be made with QuestLists. (SRS/Scenarios)

We need to have a few different lists to showcase what can be done with QuestLists. The following use cases are the inspiration for this application:

A Shopping List

A simple shopping list with items that can be hidden, marked as done, or marked as not done. Each item should be categorized into sections in the store (i.e. dairy, vegetables, cereal, etc.). A user can show the list alphabetically, in order of completion, or by section in the store. When the shopping trip is over, the user should be able to hide all the checked items, then show a list of hidden items so they can be moved back to unchecked state. This is to prevent users from having to enter in each item everytime they want to go shopping.

A List of Quests for a Game

A user should be able to create a wiki-like list of lists, in order to help them complete games. A user should be able to keep the following lists: Characters (people met), Quests, Items, Armor, Weapons, and Laurels (PS4 Trophies, Xbox Achievements, etc). We should use the Skyrim wiki to get the data for this. Each sublist should have different states and default to the states of its parent. For instance, a weapon can be undiscovered, discovered, in inventory, or in storage. When creating these lists, a user should be able to add more attributes about the items, such as damage and durability.
There should be a dynamic list that covers what the user has and what their attributes are for a specific character. The user should be able to maintain different characters, and different list states. This feature needs the ability to add named state sets.

An Agile Management Platform

A user wishes to create a list of items that have or have not been completed, in order to facilitate an agile development workflow. The user should be able to see swim lanes and be able to sort priority in each lane. This should be a typical agile bord view, with sorting based on at least two configurable attributes.

New Lists from Third Party Sources

A user has created a list of items in Google Keep and wishes to transfer them to QuestLists. They may also have errata in a Google Spreadsheet, so wish to import that as well. We should support multiple third-party task management applications and APIS. We should also support different file formats for import and export.

Deliverables

The deliverables for this ticket are Software Requirement Specifications for each of these scenarios, created on the GitHub wiki for this project. See https://www.geeksforgeeks.org/how-to-write-a-good-srs-for-your-project/ for an example.

some of the files changes belong to another branch

hope all is well with you

Unmerged paths:
  (use "git reset HEAD <file>..." to unstage)
  (use "git add <file>..." to mark resolution)

        both modified:   src/App.vue
        both modified:   src/components/LogInorSignUp.vue

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        modified:   src/components/DrawerMenu.vue
        modified:   src/components/TopMenuBar.vue

no changes added to commit (use "git add" and/or "git commit -a")

this is the output I get after git status and I feel all these changes must be added and committed into making-user-authentication-buttons
I tried to stash in create-list-for-authroized-users and stash pop them in making-user-authentication-buttons there and git commit and git add it, but create-list-for-authroized-users branch is more updated than the other one.

First, I lost the code, but after a few seconds of remembering, it works now, I feel?

I am confused about what to do?

should I commit and add all changes inside create-list-for-authroized-users branch or
you want it to be committed inside making-user-authentication-buttons because it is more appropriate to that branch?

Users should be presented with preset values for the colors of lists.

When a user clicks on the color chooser in the list preferences, they should be presented with a list of 10 colors that compliment our chosen theme colors, both light and dark. There's no reason to have a different palette for light and dark; it should be the same palette that compliments both. You can use a material palette website to find the colors. There should be an option to bring up the full color selector as well. The theme switcher should be implemented first.
NOTE: we can and should use vuetify's color picker swatches for this. You can use this site to generate a palette - http://colormind.io/bootstrap/. The base color is #363636 and the secondary color is #F9AA33

Colors are too depressing

@KickButtowski80 would like to update the color scheme to something a little less depressing.

URIs should use slugs instead of firebase IDs

Currently, we use firebase IDs in the URL to locate the correct list. We should use title slugs instead.

NOTE: One potential problem is how to handle duplicate list names.

Users should be able to set more preferences for ListItem states.

Note: this is a redesign of the states UX in the list preferences dialog.

The new UX should have only a list of items in it and should be in the same preferences dialog. The existing add button and the entry field should be removed and only a list should be there. It should function the same as the List page, where there will always be an empty item at the bottom of the list where users can create new items.

This is what the UX should look like:

Here is a gif of, roughly, what the dialogs should look like:

Sorting:
The list of states should be an ordered, sortable list of items which defaults to the Done/Not Done options. There should be handles on the left of each item which can be used to drag the items so they can be sorted.

The next item in the row should be the icon for the state. When clicked, a simple, compact dialog should be displayed, with links for how to find the icon string. There should be a row where the icon is displayed on the left, with the rest of the row filled with a text entry. When the dialog is opened, the text field should have focus. When a user types in the text field, the icon should be automatically updated. When the user presses enter, the dialog should close and the text should be used as the icon string for that state. There should be no close button or any other way to close the dialog, except clicking outside the dialog.

The next item in the row should be the color of this state. It should be the same palette chooser as the other color selector. (It should use the same component.) This should default to nothing. It will be used to change the color of the rows when the item is in that state. (In another ticket.)
The next item in the row should be the text. This is a user-friendly version that will be used where the icon can't be shown, and as alt text. The key in the states object in datastore should be this string, for easy lookups. Using the same string should not be allowed.

The final item in the row should be the value of that option, and can be anything, but the index number should be the default.
At the end, there should be a blank entry that should be auto-filled when one of the items is changed. Basically, this should reflect the UX of the list view.

We should plan on using the data structure as outlined in #33

Users should be able to see a privacy policy

Users need to be able to view a privacy policy. opensource.com has a really simple one, so we should probably do something along those lines. see https://opensource.com/privacy-policy

NOTE: we need one of these before the initial release, for Facebook OAuth use.

Users should be able to login via OAuth

There are already a few OAuth providers set up in Firebase for this app. We need to add buttons on the login form so users can login via these OAuth providers.

Users should be able to pick out icons from a list, instead of searching for them on other sites

On the state selection screen, where you can choose an icon, there is currently a text entry box. This needs to be replaced with a searchable list of icons. We can keep the same look, but the links should toggle the library, and the text entry should show a dropdown, like auto-complete for the icons. The Vuetify docs already has a component that does this, at https://github.com/vuetifyjs/vuetify/blob/master/packages/docs/src/components/doc/IconList.vue. We can probably steal that and customize it for use with multiple libraries.

All items should have timestamps

Lists, StateGroups, and ListItems need to have timestamps. They should have created, updated, createdBy, and updatedBy fields so we can keep track of who and when something was changed.

Users should be able to upload their own avatar

I know there may be firebase charges for this feature. 5Gb should be enough for quite a long time. We can create a vue component for resizing images, using the script here: https://gist.github.com/dcollien/312bce1270a5f511bf4a#file-imagetools-es6 . Also see https://stackoverflow.com/questions/2434458/image-resizing-client-side-with-javascript-before-upload-to-the-server for usage.

Create a test validation pipeline in Github

Make sure PRs can't be merged until all tests pass. Tests need to include the Vue tests, as well as eslint validation.

Add notes to listitems

My wife said she would like the ability to add notes to list items. There should be an option to clear these notes when the list is reset. The notes should be marked as cleared, not actually removed, unless the attached list item is removed.

The drawer items should reflect the most recent 10 lists which a user has used

Remove all the current icons in the sidebar. For each of the last 10 items, show the list names.

Logged in users must be able to create a list

As a logged in user,
I must be able to create a list,
In order to store lists. 

As an anonymous user,
I cannot create a list.

As a logged in user,
When I create a list,
I must be able to specify a title for that list.

As a logged in user,
When I create a list,
I must be able to specify a color for that list.

As a logged in user,
When I create a list,
I must be able to create a list of states for that list,
Where the default states are ['not done', 'done'],
so that I can set those states on individual items. 

As a logged in user,
When I create a list,
I must be able to specify a cover image for that list,
which I can upload,
in order to set the cover image for the collapsed tile.

Dashboard layout

Users should see tiles of their lists which they have created or have used. The tiles should be sized according to frequency of use and list size. See https://v15.vuetifyjs.com/en/components/cards#grids for an example of a tiled view. They are called grid views in some circles, but tiles makes more sense, as some may be larger than others. Think of how the MS start bar used to be. A good example can be found here - https://s3.envato.com/files/66223283/preview/08_Tile.png

Users should be able to specify dependencies for lists

User should be able to specify dependencies for lists. If a dependency has not been met, the list cannot be used, only viewed. Here are a few examples of dependencies:

"Cake Grocery List"._completed = true

"Weekly Grocery List".eggs > 6 && "Weekly Grocery List".milk = true && "Weekly Grocery List".flour > 2

Users must be able to log in

Most data will be publicly accessible in Questlists, and state will be stored on the client. However, if we want users to be able to create lists, we need to hold them accountable, so we need to be able to create lists and assign them a creator. In order to do this, we need to allow users to sign up. We should probably allow all OAuth methods, as well as simple username/password login. We need to have a login modal or popup as well as a global method for setting long-term user data.

Deliverables:

• Login window or popup. Must not ne a new page.
• Sign in, sign up, and logout methods in the Flux store
• Global sign in and sign out links which show the login window/popup. Must not redirect on signin.

Users should be able to view a full page version of a list

A user should be able to click on a list tile and be taken to a new page which shows all the list items.

Add Site Search

Since we can't do full text search in firebase, an easy solution to start with is the google programmable search. Here is a URL explaining how to implement it:
https://support.google.com/programmable-search/answer/4513751?hl=en&ref_topic=4513742&visit_id=637312500270360151-3890492741&rd=1

Since google forces ads for site search, we are going to go with the recommended site search: Algolia.

User is not reloaded after verification

The user is not reloaded after email verification. We should notify users in the create list window that creating a list will fail if they are not verified or signed in.

List item statuses should be icons instead of check boxes

Each status in the list item should be associated with an user-defined icon. For now, use the md and mdi icon set strings, which means render those strings as icons. We are not worried about validation of these strings, as a list creator will notice.
When a user clicks on a status icon, it will cycle through the states. Don't worry about Ordering the states.
Issue #35 has the method for specifying the strings. It also contains more information on how to create list item states.

We should plan on using the data structure as outlined in #33 .

BUG: Inital Loading should have a loader instead of text.

The initial page loading should show a v-skeleton-loader, then either the info box or lists after loading, if no lists exist. Currently, the info box is displayed before the lists.

Add slight effects to make the UX a little more smooth.

We should add transition effects when thew UI changes:

• When transitioning between pages (should be less than 0.3 seconds)
• when adding rows in any list
• when removing rows from any list
• when clicking on a list tile to go to the list page

Create a deploy pipeline in Github

THe main issue with this is the firebase secrets. Fortunately, we can store secrets in Github now, just fo this purpose. See https://help.github.com/en/actions/configuring-and-managing-workflows/creating-and-storing-encrypted-secrets

We can deploy to github pages with https://github.com/marketplace/actions/github-pages

We can deploy to Firebase with https://github.com/marketplace/actions/deploy-to-firebase

Init with Firebase and Flux store

This project needs a firebase backend, to begin with, but must support other backends as well. We need to create a Flux model with support for Firebase, to support long-term storage. There should be node tasks to handle common maintenance and development tasks, such as firebase:deploy or firebase:serve. The tasks must be prefixed with firebase.

Import content from old Questlists repo

Import the README from https://github.com/skamansam/questlists/blob/develop/README.md.
Import the assets as well, such as the icon, etc.

Lists should be able to contain other lists

A list should be able to contain other lists. A user should be able to add a list as a list item. When Sublists are displayed as a sublist, it should behave as if they were a list item with child items. A user should be able to add as many sublists as they like. When a cycle is detected, the first sublist is shown, with the subsequent lists shown only as a listitem which links back to the first one.

Users should be able to specify a URL for their avatar

A user should be able to specify a URL for an image to use as their avatar.

We should default to a custom, local generic user image if it doesn't exist. We should offload this to the browser as much as possible by using HTML instead of javascript.

Users should not have to logout to begin using verified-only actions

Currently, the user needs to logout and log back in before performing actions like create, which require a verified user. We need to make sure the user can just continue to use the app, uninterrupted. We have a start on this ticket, but the backend doesn't allow us to perform these actions.

We need a code of conduct for our project

The TOS should cover soem legal codes of conduct, but we should also have another one, for code contributions. You can automatically generate one. See https://www.contributor-covenant.org

Dashboard Tile(s)

The dashboard Tiles should be cards which contain an image, a title, a bar of action icons, and a few list items. For larger sizes, the image is on top, like a banner, with outlined title (text-shadow) on top of the image. (The reason for the outline is that outlined text is readable on any background color.)

Some cards will be larger than others, so there are two styles that are needed. These styles should be responsive.

Here is a rough layout for the smaller size.

_____________________________________________
|                |          [ Title ]       |
|                |        [description]     |
|                |  [description, cont'd]   |
| [ Image]       |  [ ] List Item 1         |
|                |  [ ] List Item 2         | 
|                |  [ ] List Item 3         |
|                |  [ ] List Item 4         |
|________________|__[edit icon]_[view icon]_|

Wider tile. For now, we aren't going to worry about the larger/wider sizes. We can get to that when we have more information on how to determine the larger sizes.

______________________________________________
|          [ Title with image background ]         |
|________ ____________________________________|
| [description ]                              |
|  [ ] List Item 1        |  [ ] List Item 3  |
|  [ ] List Item 2        |  [ ] List Item 4  |
|__________[edit icon]___[view icon]__________|

Users should be able to view a Terms of Service document

We need a TOS document before initial launch. It should be a popup from the sign up window, as well as on the profile / settings page.

There is a good one here - https://opensource.org/ToS

The New Quest List dialog Should be a page instead

The current dialog has a few issues, including difficult to use UI states when creating a lot of state items. This should really be moved to a new page. We should use a router guard when navigating to this page that opens a login/signup window. The current url for the dialog should go to the new page, and the old code removed. There should be router tests for this and the tests should be updated.

Create some basic tests for existing features

Make sure we sync up with the team on testing procedures and how to write them.

Users should be able to install the app on their computers

There are several methods for getting Questlists on the desktop. Here they are, in the order of easiest to hardest to implement.

1. Web SPA - we already have this, but we need to make sure the app can be installed by every browser. We should make sure the prerequisites are met, and let the browser automatically ask the user to install. See https://web.dev/customize-install/ on how to let it happen or how to do it ourselves.
2. Use electron. This is really really easy to do, however, electron is really heavyweight and is an extra browser instance, so I'm not certain we want a desktop app that's so heavy. If we do this, we need to make sure our signup process works and we can connect properly to firebase. We also need to decide if we want a local database only for desktop apps.
3. Use Tauri (https://tauri.studio/en/) for a lighter-weight desktop app. (is there another alternative?) We can use the firebase emulator as a local database, as we can package extra binaries. I tried a simple run with Tauri, and it worked well, but the icons didn't show up, so we need to address that issue.

Error Messaging User on Login/Logout Processes

We need to add logging for the following user actions:

1. login
2. logout
3. signup

Users should be able to specify whether to use their Gravatar

We should allow users to be able to use their Gravatar as their avatar. Add a checkbox to the user profile edit form.

Users should be able to change the state of multiple items at once

There should be a menu toggle button at the top of the list page that allows a user to select multiple items in the list and update their states.
When a user clicks the button it should show the text, "click on the items you wish to change." below the button. There can be many ways to do this, just ensure the user is notified well they are in multiselect mode and can update multiple items. When each row is clicked, it should be highlighted in some manner, such as background color change or border color change, that it is going to be updated. When the user clicks the dropdown and selects an item, all the selected rows should update so they are at that state. This should be disabled or not shown when there are only two states (this method is actually more steps to update with only two states). The user should be able to shift-click a range of rows (click on one item, and hold shift while clicking a second item should select all the items in between, endpoints inclusive).

Enable realtime updates for list editing

The firebase realtime updates don't matter so much in other components, but when editing a list, there could be serious data clobbering going on. In order to mitigate this, the UI should be updated in real time as new items are added and updated.

When an item changes, it should have a badge added to it with the user who made that change.

If an item is currently being edited, and another user updates it, there should be a notification that another user has updated the item, with a way for the user to reload the item with the new changes.

When an item is updated, it should be highlighted in some way to show what type of edit has happened. For example, if an item has been deleted, it may be highlighted in red, with a bright red frame, and a big strike-through over it (this is just an example, use your imagination to make something wonderful!). There should be visual feedback for updates, deletes, and creations.

Use a stepper to add wizard interface for list creation

The list creation process needs a little help, so we should add a wizard interface, using a v-stepper. We should include information about each step and the context/reasons for having the settings.

Step 1: a little information on what a list is, and choosing a name. Should have two fields: name and description.
Step 2: Should have a scrolling view of choosable cards that represent and describe different types of lists. These will create template lists, and should contain a single item for now: Questlist. When a user hovers over the card, a description should pop-up saying this is a basic list. There should be text in this step that says the basic type can be changed later and no lists limit options.
Step 3: The state editor goes here, with a description of how it works.

I mocked up a quick demo here: https://codepen.io/skamansam/pen/LYWyoZR?editors=1010

Users can create list items

Reference: Dashbord Tile, #22
One of the actions on the List tile should be to add a list item. It should be one click to add, then the user should be able to start typing. Basically, there should be an empty item at the end of the list item preview which a user can just click on and start typing. In much the same way Google Keep works in its expanded view.

EDIT: The feel for this is to have each item in the list be editable. When you click on an item, it allows you to edit the text inline, instead of via a popup or other mechanism. At the end of the list, there will be an extra blank item that will allow you to add another item. As soon as a user begins typing in the blank item, a new blank item will appear below it. This should apply to the tile view and the full page view.

Upgrade to yarn v2

Yarn 2 is out now and should add a lot of speed to our development and deploy processes. Since it is quite different from yard 1, we should really analyze the difference with our code and see if it will be worth it now.

See https://next.yarnpkg.com/advanced/migration for a migration guide

Cleanup Profile Edit Panel

The profile edit page is not intuitive and contains developer output.

The following needs to be done:

• Update the pane so it doesn't look like a popup window. It should look like a page.
  • Make the user editing pane top-left aligned, instead of centered
  • Add a preview widget that allows you to see what your user card will look like to others. This should update in realtime.
• Change the text of the button to be Update or Save instead of Edit
• Move the EditProfile component to the views folder, because it is a view.
• Remove the developer garbage from the bottom of the window
• Remove the checkboxes for editing name and avatar. The fields should always be editable.
• Reduce the roundness of the button. It should be slightly rounded, not oval. All input elements should have a border radius of about 0.4em, except fab buttons. We should test this out with a bunch of inputs of different sizes.

Here is a reference page: https://demos.creative-tim.com/black-dashboard/examples/user.html. Notice that it looks like a page instead of a modal dialog.

Deliverables: When finished, there should be a view for the user info. This view should contain 2 widgets, one for editing and one for preview. The preview widget will be used in other places, when a user card is needed (so "preview" should not be in the name).

Users should be able to save their item states in their user collection

Currently, users can't save their state data, so we need a way to do that. There is already state data in the firebase emulator data, so that should be a starting point for this implementation.

• When a user changes an item's state, it should be saved in their collection
• When a list is loaded, it should load the user states and display those

The organization is as follows:

• the userListItemStates collection should have a document for each user, where the document name is the same as the firebase user ID (so the path should be /userListItemStates/{fbauth.currentUser.id})
• the user document should have a subcollection where each subcollection represents a list and has the same ID as the list. (the path should be /userListItemStates/{fbauth.currentUser.id}/{list.id})