Post your notes in the form of a nested flowchart.
(a nested flowchart) is a 4-tuple (P, p_0, F, N). P is a finite set of posts. p_0 is the start post, a member of P. F is a finite set of flows, a subset of P x P, where (P, F) is a connected directed graph rooted at p_0. N is a finite set of nests, a subset of P x P, where (P, N) is a connectd directed tree rooted at p_0.
A post is a unit of user generated content, e.g. text, picture, audio, video, or hyperlink.
A flow is an directed relationship between two posts; it is rendered as an arrow. Flows should be used to form a search hierarchy rooted at p_0 (like a search tree, except a post can have multiple incoming flows). A flow stores indices giving its ordering relative to the other flows (out from the source) and (in to the target).
A nest is an directed relationship between two posts; it is rendered as the nesting of its target in its source. Nests should be used to form a search tree rooted at p_0. A nest stores indices giving its ordering relative to the other flows (out from the source) and (in to the target). A nest stores a vector describing the position of the target relative to the source. A nest stores flags indicating whether the nested posts should be displayed as a list, or as a scatterplot. Nested lists form the standard hierarchical outline format. Nested scatterplots form nested flowcharts (like nested desktops). You can think of the nest tree as a tree highlighted from the flow graph. The nest tree can be redrawn from a post onwards based on the outgoing flows.
I want to put a file in more than one folder; the best way to visualize this is a directed graph with nesting.
soon, also at http://dish.catering
Build a hierarchy of notes in the shape of a satellite dish to represent yourself and catch signals! Render it as a web of nodes and arrows where you can collapse a sections of the web into individual nodes. Overlay hiearchies and link similar and opposing notes across individual hierarchies!
(mindscape.io ((nodejs neo4j) (reactjs redux))
(Node ( coordinator_node_id init_vector hide_vector commit_vector edit_vector node_id user_node_id value))
(A user posts by creating a Node) (The coordinator_node indicates the reference frame) (a flag (e.g. init_vector) is unset to () or set to a vector (e.g. (t x y z), e.g. (timestamp, longitude, latitude, altitude)) consistent with the coordinator_node) (post stores nodes and relationships to the neo4j database)
(Present ( coordinator_node_id init_vector hide_vector select_vector edit_vector present_id user_node_id start_node_id start_out_index listed vector end_node_id end_in_index end_as_leaf end_as_list source_present_id))
(model (each user_node is the source (root) of a directed tree (Nodes, Presents) that connects all nodes in the user's view; this tree is the user's presentation tree; it is essentially a search/recognition tree, render/enumeration tree)) (view (each Present is visualized as the nesting of its end-Node in its start-Node)) (start_out_index indicates the index of this Present relative to the other Presents starting from start-Node) (listed is unset to () or set to t when the end-Node should be presented in the list of the start-Node) (vector the position (e.g. (t x y z)) of the end-Node relative to the-start Node, given that the end-Node is not listed) (end_as_leaf is set to t when the end-Node should not present any of its Present-children) (end_as_list is set to t when the end-Node should force all its children to be listed this overrides the 'listed' property on those Presents) (source_present_id is unset to () or set to the id of the Present that this Present copies, to animate movements of a Node made by another user)
(Define ( coordinator_node_id init_vector hide_vector select_vector edit_vector define_id user_node_id start_node_id start_out_index end_node_id end_in_index))
(model (each user_node is the sink of a directed graph (Nodes, Defines) that connects all the Nodes acknowledged by the user (this includes all Nodes and Defines created by the user; the user can Define between Nodes he did not create)) (view (each Define is visualized as an arrow from its start-Node to its end-Node) (if a Node is leafed, the arrows to/from its children go to it instead)
(register ( coordinator_id user_vector user_id present_id define_id root_id) (Node ( coordinator_id user_vector () () () user_id user_id ())) (Node ( coordinator_id user_vector () () () root_id user_id ())) (Present ( coordinator_id user_vector () () () present_id user_id user_id 0 t (0 0 0 0) root_id 0 () () ())) (Define ( coordinator_id user_vector () () () define_id user_id root_id 0 user_id 0)))
(expand ( coordinator_id user_vector parent_id present_id present_out_index define_id define_in_index child_id user_id) (Node ( coordinator_id user_vector () () () child_id user_id ())) (Present ( coordinator_id user_vector () () () present_id user_id parent_id present_out_index t (0 0 0 0) child_id 0 () () ())) (Define ( coordinator_id user_vector () () () define_id user_id parent_id define_in_index child_id 0)))
... )
define and present are a little abstract, meant to describe processes of consciousness. to make it more concrete, we can imagine: wire <-- define nest <-- present
Visualization (A <-- B) is similar to (A (B)) (having an index on a list is similar to having an arrow, reference to that item/ having its address) (A1 <-- B --> A2) is similar to (A1 (B) A2) but if you pull A1 away, does B move with A1 or A2? in the graph, B gets its own position/identity also, (A1 (B) A2) is ambiguous with (A1 (B (A2)) of standard list/function composition syntax thus, if A1 and A2 are both displayed (with no overlap), then B appears in two parent Nodes, i.e. ((A1 (B)) (A2 (B))) having the same object in two containers (i.e. in 2 places at one time) violates classical object mechanics, but I think this kinda pattern comes up in quantum entanglement? Nesting nodes is helpful, bc we can move groups of objects together. Maybe an object can be in two places at once in the view, but then they must be linked by a line? I dislike this because classical objects seem intuitive-- nested folders metaphor So a node can only be inside one of its Parent nodes
trees single relationship in one direction multiple relationshisp in other direction graphs are better because each node can have multiple parents/containers/tags multiple relationshisp in both directions
trees are nice highlight trees in the graph
display a tree of nodes via nesting (can only have one nesting tree going on)
have a graph in the background to store structure that can be used to redraw trees
A user opens http://mindscape.io He/she sees a logo, navbar/title dashboard, info Ol' Billy Ham Cham registers via the dashboard, automatically creating (author <-- (mandala)) i.e. he/she creates (author:Node)<-[read:DEFINE]-(mandala:Node), (author)-[write:PRESENT]->(mandala) in neo4j. Then, he sees logo, navbar/title dashboard, mandala
(Universe (user (thought (Internet (mindscape.io (author (mandala (node))))))) (Internet (mindscape (author (mandala (node))))) in general.
generally,
(author) <-- the user's identity, (mandala) <-- everything in his/her experiencing. (mandala) contains all (Node) in the webportal e.g. (mandala (node1) (node2) (node3 (node3.1) (node.3.2))) (author) isn't in rendered in the webportal (author) can be attached via OAuth to other authenticators/services.
allowing (a)<--(b) or (a<--(b)) or ((a)<--b)
**Nested lists are ordered trees!
He links related Nodes with arrows, i.e. he creates -Define-> relationships, taking some (specific/concrete Node)-to Define->(a abstract/general Node). The directed graph (Nodes_defined, Defines_created) must be connected, with the author Node as its only sink. {Nodes_created} by the user must be a subset of {Nodes_defined} by the user. The user nests Nodes within other Nodes to group them, i.e. he creates -Present-> relationships, which are directed from container to component. A Node can be nested within a container only if there is a Define path between them, and all the intermediate Nodes in this path are already nested within that container. The directed graph (Nodes_presented, Presents_created) must be a connected tree, with the author Node as its only source. The intersection of Nodes_presented and Nodes_created by the user need only contain his author and world Nodes. This Presentation tree is the secondary structure of the model and the primary structure of the view. Creating a Node automatically creates a Define to and a Present from its container. Committing a Node makes its content immutable. The user dismisses a Node from view by selecting it and deleting the Present_in relationship between it and its container Node. Each Node (e.g. the user's world Node) can switch between displaying its component Nodes in either a list (that can be sorted along a selected property) or in a resizable space (that supports arbitrary positioning, plotting according to selected properties, and automatic repositioning via force simulations). Nested list formats yield the standard hierarchical outline format. A Node can be minimized to hide its components, or maximized to fill its container.
The user can position a Node (along with its components) in a space manually via either drag and drop or selection and click command. The position of a component relative to its container is stored in the Present relationship between them. When a Node is moved to a new container, the corresponding Present relationships are automatically deleted and created. Define relationships are created via selection and click command. When the user selects a Node, its details are displayed in the dashboard that accompanies his world Node in the view. These include information and controls on the adjacent Nodes and the relationships connecting them. Adjacent relationships/Nodes can be grouped into sets, either by relationship type and direction or by manual selection, so that the user can operate on them simultaneously. Dashboard controls enable the user to create and delete relationships. They also let him move adjacent Nodes (into the selected Node's parent container, into the selected Node itself, or out of the selected Node). Some operations may be applied recursively (with support for depth limits). For instance, the user can select a Node and recursively apply the [make specifics (neighbors via Define_in) into components (neighbors via Present_out)] operation, followed by the [display components in a list] operation. This would re-outline the related content according to the selected abstraction! When a Node is committed, the service automatically creates Defines from it to the 4 coordinate Nodes that correspond with the user's position in space-time. These coordinating Nodes are what initially connect the user's structure to that of other users, allowing him to create further connections with their structures, and they with his. The user can Define abstractions on these coordinates, like cities and seasons. The user can make a Node private, obscuring its contents to everyone but the user. If the user creates a relationship between his private Node and another user's Node, the content of this Node becomes visible to her. When the user brings another user's Node into his view, he can set his Present to synchronize itself with her Present, so that any repositioning she does is duplicated in his view. He may want to Define one of his abstractions with this Node, to maintain a consistent handle on it, in case she breaks the synchronization by Presenting the Node from another container not in his view. Or, a stronger synchronization setting can automatically bring these extra containers into view. When the user modifies his Nodes, Defines, or Presents, the changes are streamed live to everyone with those objects in view. Uncommitted Nodes can be used for live, ephemeral chat. The user can move a Node around (in and out of) a container as an avatar or a prop. He can form a party with his friends, roaming from container to container, play a card game, present a set of slides, etc. The user can follow the paths laid out by righteous users, and duplicate those paths with his own. Aggregating the relationships between Nodes yields a gradient of the community's preference. The user can mark a pair of Nodes as equivalent by creating two Defines that link the pair in each direction. When he and another user each create such a Define cycle between one of his Nodes and one of hers, they have declared an isomorphism between their structures. The user can tip (i.e. pay) and/or subscribe to another user at one of her Nodes using an internal currency called Joles. Joles are earned from the system by performing services for the community, such as paying the developers money. Joles can be used to purchase various doodads and knickknacks from the store, such as fonts, animations, advertising bandwidth, weapons (e.g. an ability that minimizes the targeted Node after 10 seconds), shields (e.g. so the attackers need 100 times the attacker*seconds to minimize your Node), better weapons..., hats, etc. The store and its products will be modeled in the graph, using the components described. Machine learning will be applied to create agents that play the role of teacher/enzyme, linking together related (e.g. anti-related) Nodes, to promote interaction between users based on the content they publish. An API will allow researchers and developers to query the graph directly and perform their own studies and provide their own services/agents. Keyword search will be implemented in this enzymatic model, where the user creates a Node with a query in it, perhaps addressing the enzyme by name in the query or Defining the enzyme with it, and the enzyme would link that Node with some response. The user can select a section of the graph and scroll backwards and forwards over time to animate its transformation. Integration with git, syntax highlighting, a javascript engine, and other development tools that make the app a good software development environment. The app will be designed to facilitate extension with tools and features. Integration with web browsers will allow users to interact with external web pages and manage their bookmarks. Native apps for computer and mobile will be added to the web app, which might be called Graph Outliner. Maybe the mobile app will be called Pocket Book, because you write in it on the go. I'd like to brand a user's structure as a Mandala or a Notation or a personal symbol in a human alphabet that might be mostly symmetrical with other symbols and form nice little groups in a taxonomic tree. VR integration will allow for 3D visualizations of the Internet. I think the VR app will be called Matrix. The code and models will be made as freely available as possible. They will be engineered to emphasize readability and elegance.