f4if / ctree-demo Goto Github PK

• show history for user for specific description config or element
• filters at top-left
  • toggle at most 1 filter on (none by default)
  • shows only history of type toggled on
• sort using controls at top-right
  • order by options on left
  • ascending/decending on right
• share common implementation with user's history screen

• show stats diagram (ex. stat wheel)
  • element (when designer)
  • description segments
  • feedback (includng responses)
  • relations (when suggested elemnt relation)
  • others?
• metrics selection to control what's shown in stats diagram
  • contribution volume - how much created of each contribution type
  • contribution ratings - average rating for each type created by user
  • rated - average rating given by user for each type
• time range
  • quick range (ending with current date)
    • day
    • week
    • month
    • year
    • all
  • manual range
    • date only, not time
    • drop down date selection

• add new description config when add/remove segments
  • add: plus buttons at start/end and between segments
  • remove: trash button on left side of feedback bar when editing segment
• only push change once close dialog, change page, or switch config
  • prompt if want to save changes

When a description segment has multiple variations, if you update the variation currently visible then move it the segment up/down, or move an adjacent segment which causes that segment to move, it will reset the segment variation back to the original variation. When the segment variation is changed it should remain until the element dialog is closed and reopened.

Note: this may be easier to implement after #41 is done

• avatar
• name
• if favorited

• add test users as add test elements (randomly reuse existing user or introduce new test user)
• populate with random name, thumbnail, & other appropriate values from Lorem.html
• users should be per cTree (we'll add a concept of global users linked to cTree users later)
• keep track of what's assigned to user for user history

• try to get iPad/iPhone to display site in Chrome
• Polymer appears to work because polymer-project.org and component demos display correctly

• in page on element dialog for item with relation
• page showing all parent/child related elements
  • possibly separate rows or tabbed pages for each
• elements shown as preview items
• show unlinked relations
  • at end of each list
  • elements which have been suggested to be removed
  • elements which have been suggested to be added by a limited number of people
• include options over preview items
  • suggest removal
  • agree with relation
  • feedback for relation
• button to suggest new relation

When press + buttons, while editing the element description in the element dialog, show a prompt to select the type for the new segment to add. This prompt should probably be inlined, maybe a horizontal list of icons above the + button. The icons/images representing each type should probably come from the segment type element definition, along with a human readable type name, used as a tooltip. This should also include actually creating the new segment and adding it to the description config (cancelling while editing would remove the segment). The same rules about saving the description config from #39 should apply to this.

Icons for each element type, in style of site icon:

• Seed
• Root
• Xylem
• Node
• Bud
• Vein

• when list of content type icons doesn't fit, add an overflow (vertical ellipses) icon button
• additional buttons would be accessible in a dialog attached to overflow button (probably vertical list)
• anchored dialog should be below overflow button if there's room, otherwise it should be above it

Currently description configs (lists of description segments) are altered in place with changes to element descriptions (moving segments up/down and deleting segments). Instead, description config changes should be stored locally until something triggers a save event:

• manually saving via save icon
• prompt to save after trying to change description config
• prompt to save after trying to close element dialog
• prompt to save after trying to change element dialog screen

When edit description config show save and cancel icons in footer. If description config is restored back to how it was originally (ex. moving a segment up then back down again) the save/cancel icons should be removed again.

• bundling only appears to remove pages listed as fragments
• should combine pages for fewer imports?
• ignore if fixed by updating to Polymer 2.0 (build system updated)

• design comps for improving the site's polish
• general flow and layout should be mostly the same, or trivial to implement/change using existing components
• new icons should be vector graphics

Add storage of bookmarks and history into Firebase so we can get the appropriate list data.

• when scrolling, even when the items have been loaded, the refresh stutters (probably starting load image animation)

To go along with the new Firebase support added in #48 and #49 we should support loading cTrees from Firebase instead of hard coding them. We should continue to support the hard coded cTrees for test configurations, but when using Firebase we should only see Firebase backed cTrees.

As part of this, we'll need the ability to create new cTrees. Probably the easiest way to do this is to leverage the search box, and when someone types a search term there should be a button at the end of the list results for creating a new cTree, named with by the search query. This would NOT be visible if an exact match was found (cTree with the same name).

New cTrees would have the element types and any other required cTree data pushed into Firebase with default values for now.

Currently edited segments can only be saved manually, but there should be prompts to save if changes could be lost. These events include:

• changing segment variation
• switching current segment being edited
• any other situations listed in #39

It should be noted that when moving segments which have been edited should either keep the edited value or prompt to save.

• use data from description config to get contributors
• data summary comes from description config and element
• use real user avatar and name

• element loaders should be able to register to get updates based on filters
  • specific elements
  • specific lists
  • specific properties
• test by adding support for toggling bookmarked in element dialog and verifying updated on element preview item in list

• globally configurable text for promoting project
• target top social networks (share plugin?)
• (preferred) dialog anchored to button clicked

• history of all contributions made by user
• use sorting component
• when click open element to appropriate context (based on contribution made)

When adding a new description segment variation, add a prompt asking why the segment variation was created. There should be a shared list of reasons from the segment behavior, and reasons from each type. Reasons should each have a unique ID, which is how they would be saved in data, and the string would be looked up using the ID when needed. The IDs for shared reasons should have enough room to grow (probably no less than 99 or 0xFF IDs), and IDs can be reused between different segment types, as long as the value doesn't overlap with the shared behavior reason IDs. A reason must be included to be a valid segment, and we may want to also include the ID of the variation being changed so it can be compared.

Unique icons for each cTree type, probably not specific to cTree name/theme, probably variations on site icon.

• different pot (base) colors
• some foliage color variation
• foliage overlays
  • flowers
  • berries

• update cTree list as typing (compare what's typed to cTree names)
• show icon for each cTree indicating if it's saved once search starts
• can toggle saved icon to toggle if it's saved or not
• "x" to clear search text
• when search text is empty show all saved cTrees and hide "saved" icons

• open user dialog to any page other than details (ex. stats)
• click element preview to open any element
• observe empty dialog and errors reporting unable to load page for element dialog
• need to ensure don't bleed page changes from one dialog type to other (always default to details)

• get users (designer & top contributors) from element (& description config)
• replace random icon and type text in element header with real user icon and name
• top contributors list could also include designer, but filter out since they're already listed as designer

Element descriptions can have segments added or removed, changing the description config, or have new segment variations added. These changes need to be pushed to Firebase whenever the element updates are saved. If confirming changes hasn't been implemented yet (i.e. #40), go ahead and push changes to Firebase whenever the element is updated.

It's important to note that we should NEVER update a description or segment, just add new variations.

• should hide address bar when scrolling down

• random elements with reason suggested
• surveys to improve suggestions
  • appearance is TBD, can use placeholder
• should badge to show new notifications

Users may want to save their changes for later, or if their session ends unexpectedly they may want to resume editing where they left off. We should persist editing changes in a user's local history so they can resume them (from the notification bar on the right). This can include segment variations, description config changes, and new elements without a required parent. There should also be an option to save changes for later manually, which would behave like cancel except cancel should remove the changes from the user's local history (i.e. users can't resume canceled changes).

• open root site (subpage of wordpress site)
• click any link to update address
• refresh for updated address
• observe wordpress served 404 page
• should open site to same state as before refresh

Capture feedback in Firebase, including up/down votes, comments, and additional data attached to comments. If feedback isn't fully supported by the UI yet, implement sufficient endpoints such that the feedback UI can be easily tied to Firebase via loader components.

• support text entry
• support adding other content types above comment as part of feedback (1 or 0)
• support optionally adding sentiment (thumbs up/down) as part of comment
• sentiment of comment goes toward thumbs up/down rating for what feedback applies to (description config, segment, or other feedback)

• for selecting or creating parent
• in element dialog
  • keep type and title in top bar
• show tabs at top
  • matching list types on home screen
  • only show icons for each type, with tooltip
  • search tab
    • show search bar when selected
• show element preview items based on tab selected (or search)
  • filter based on allowed parent types
• suggested tab shows suggestions based on content of element
• if parent isn't required show option to have no parent
• show fab over dialog for adding new parent
  • take user to new element screen if clicked

• expand input in toolbar
• random search results
• replace list contents when press enter or click search icon again
• put search results as query parameter (page is search)

If #55 isn't implemented, element search can be added to the list loader returning newly generated list in the same way suggested results are generated.

• list feedback entries for element
• collapse responses to show top 3, with more accessible via expand button
• support thumbs up/down response
• as current code shows, indent responses up to limit based on screen width

Add an implementation of ctree-element-loader which uses Firebase as a backend. This should maintain the same interface as the test loader. Logic which may be shared between other Firebase backed loaders should be put in a separate behavior component, like how test loaders are implemented.

The loader should be set up to use Firebase, but default to the test loader if no Firebase is configured. Code committed to the project should NOT point to a specific Firebase, as it will need to be configured by each user of the project.

The proposed Firebase structure can be found on the Wiki at https://github.com/F4IF/ctree-demo/wiki/Firebase-Structure

• bar at bottom of element dialog
• not visible until go to feedback page (stays visible when back out)

Add user tracking to Firebase data, so additions/changes/feedback is tied to a specific user. Users should be able to register a new user (username, password, & avatar), login, logout, and update avatar (manually entering a url or selecting one of ours from a list is fine). This may be made simpler by using FirebaseUI Auth. We don't need to implement this functionality for when Firebase is disabled, although we should have a reasonable fallback (ex. hide anything related to login).

When editing image URL, clear image to black as soon as start loading new URL. This should make it more clear that a new image is being loaded, especially if loading takes a long time (ex. a poor connection).

To accompany the Firebase backed elements loaded from #48 we need to be able to generate lists of the Firebase elements. This should be done similar to the test loader, with random elements selected for the Suggested List and, for now, empty lists for bookmarked and history.

• on details page of element dialog
• replace placeholder items with item for each description segment
• hide feedback bar until user clicks on item
• scroll through varations using left/right buttons (sorted, no wrap around)
• show + button between each segment (maybe just when editing a segment) - no logic yet
• view and edit content for each segment type controlled by type specific component (like element preview)
• editing a segment adds a new segment variation (to end) when done

• aggregate results for each list from all saved cTrees (mix together seamlessly)
• ensure correct cTree is passed when opening elements/users (owner cTree, not "all")

• all public user data
  • large user avatar
  • name
  • country
  • languages
  • education
  • specializations
  • groups affiliated with (logo & link)
• private data if for current user (generated randomly in the beginning)
  • email
  • phone
  • age
  • gender
• if current user enable editing of values and field visibility (except name and avatar)

• update so entire screen contents scroll, so top feedback entry can be scrolled away
• sort component should anchor to top of screen (just under top bar for element dialog) if would be scrolled off top
• try to still use iron list for feedback items, since we may have a lot of items

• Upgrade all Polymer elements
• Follow upgrade steps
• Resolve any issues found (if many found, break out into separate Fix issues)
• Only merge once all issues fixed

• in element dialog
• hide fab
• enter title in top bar
• select element type in top bar
  • validates user has permission to create type
  • if permissions not added yet, add placeholder and restrict seed from being created
  • if creating parent of a new element, only show options for allowed parent types
• description entry
  • initially show empty textbox
  • add segment buttons above and below textbox
• suggest possible duplicates in element dialog body
  • element preview items (possibly smaller than list)
  • divider above separation from description section
  • scrolls with description (i.e. don't scroll each separately)
  • can select element preview
    • stop new item creation
    • open in view mode
    • supports going back
      • re-enter edit mode
      • preserve previously entered description
• save progress to user data
  • if user closes dialog it should be possible to restore (not part of this issue)
• add item button
  • shouldn't look like fab
  • validates fields
    • has valid title
      • not empty
      • minimum words specified by tree
    • has type
    • has valid description segment
      • validation responsibility of segment types
      • at least 1 description segment
  • if can have parent
    • opens element linking page
    • keep progress in user data
  • if can't have parent
    • save to cTree
    • remove data (after added to cTree)

The ctree-description class makes heavy usage of procedural element creation, including setting values and adding listeners. By using templantes to stamp out elements data binding can be used instead. It should also be assumed that even if the + buttons are still only using paper-icon-button they will eventually also need a template and stamp, which means alternating between different templates will be needed. Using a template and stamp may also be better than the current code to procedurally create and manage listeners for segment containers.

• some of randomly generated history should have no reason (indicating viewed is the reason)
• add elements to top of history as view them