bizziquest / questlistsfb Goto Github PK
View Code? Open in Web Editor NEWQuestLists frontend with a Firebase Backend
Home Page: https://questlists.web.app
License: MIT License
QuestLists frontend with a Firebase Backend
Home Page: https://questlists.web.app
License: MIT License
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
Remove all the current icons in the sidebar. For each of the last 10 items, show the list names.
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
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
.
There are several methods for getting Questlists on the desktop. Here they are, in the order of easiest to hardest to implement.
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.
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.
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.
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).
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.
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]__________|
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.
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.
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
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:
Currently, there is no firebase reactivity for the List view. We should implement it.
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
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.
A user should be able to click on a list tile and be taken to a new page which shows all the list items.
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 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.
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.
We should add transition effects when thew UI changes:
Make sure we sync up with the team on testing procedures and how to write them.
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.
The organization is as follows:
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}
)/userListItemStates/{fbauth.currentUser.id}/{list.id}
)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
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.
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.
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.
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.
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
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
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.
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.
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 .
Import the README from https://github.com/skamansam/questlists/blob/develop/README.md.
Import the assets as well, such as the icon, etc.
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?
We should allow users to be able to use their Gravatar as their avatar. Add a checkbox to the user profile edit form.
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.
We need to add logging for the following user actions:
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
The profile edit page is not intuitive and contains developer output.
The following needs to be done:
Update
or Save
instead of Edit
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).
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.
Make sure PRs can't be merged until all tests pass. Tests need to include the Vue tests, as well as eslint validation.
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.
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
@KickButtowski80 would like to update the color scheme to something a little less depressing.
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.
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.)
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 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 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.
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.
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.
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.