f4if / ctree-demo Goto Github PK
View Code? Open in Web Editor NEWCollaboration Tree - A community discussion platform built for maximum insight with minimum oversight.
Home Page: http://demo.ctree.org
License: Other
Collaboration Tree - A community discussion platform built for maximum insight with minimum oversight.
Home Page: http://demo.ctree.org
License: Other
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
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:
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:
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.
Add storage of bookmarks and history into Firebase so we can get the appropriate list data.
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:
It should be noted that when moving segments which have been edited should either keep the edited value or prompt to save.
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.
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.
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).
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.
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.
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
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.
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.
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.