-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Collapsible nodes #22
Comments
I was thinking double clicking. Basically double clicking expands a node (same thing as in the disambiguation page, where you double click in the word you are interested in and you get the plot of the tree) |
There is a problem with double clicking on a phone: it is interpreted as zooming. For this reason I am thinking of replacing double clicking (both on the disambiguation page and on the main page) with taphold. |
I think we have two different issues here. The first is how to get the collapse/expand feature running (it makes sense to start off with the double click for now as it is the simplest). The second is a question of changing the UI/UX. This is pretty important, but maybe we come back to that after this feature works? What are your thoughts? |
The idea is that any time a node is colored in orange you can double click on it (or taphold?). For example, in the disambiguation page all nodes are orange. You know you can click on them. In the tree, if a node is orange you can double click on it to expand it or to jump to a different etymology tree. If a node is yellow (kaki :)) you cannot double click on it. The demo here shows this in action with the appropriate substitutions: |
collapsing works in the demo as I'm using d3 dendrograms but this mechanism might be introduced in dagre too. |
I was working on this, and it seemed to be going well, but I realized there is no way set up to retain old data if you remove it from the graph. Since d3/dagre run on a set of data, we need to be able to store the data as an accessible/readable variable, and only update it when a new search is performed. Right now, the process of drawing out a graph is one long chain of events. Everything will get easier if we have each function alter the graph and update the state of the graph so the next function can read the state. This is similar to what you were talking about with width/height and how you needed to make them global. The approach I am suggesting is Object Oriented Programming, like they do in this d3 snippet. This will make it easier to check and assign values. Not only am I not sure there is a good way to handle this collapsibility issue without switching to an OOP model, but I think this will speed up everything else we need to do. I will make another issue for OOP. |
I am going to show below a table where I classify different methods based on the functionalities they provide/do not provide. There are four main alternatives. The first is "d3 collapsible dendrogram", basically the one I used in the demo, then the "d3 collapsible force layout" that I was using ~ 2 month ago for etytree, the "d3 dagre layout" (current) and the "vis.js" framework. The latter has all the functionalities we need for etytree i.e.: we can build oriented graphs (where arrows all go from left to right for example), collapsible graphs (as we can dynamically add nodes), and we can build a graph structure and not only a tree structure as in the dendrogram. |
That all makes sense. I see how this will be a simpler issue after switching to visjs. switching to visjs is all the more reason to complete issue #24 so that it's just simple branching and "plug-and-play" like programming. All the other functionalities (such as data retrieval and management) would remain separate from which framework we use. So I will prioritize the OOP issue for the moment. |
With the OOP reorganization done, I think we should discuss if we want to switch to visjs, and how we want to go about that. That issue is holding up moving forward with collapsible nodes. Switching to visjs makes sense to me. |
some potentially useful links: |
You had mentioned wanting collapsible nodes so as to make the whole tree navigation smoother and less cluttered.
I guess we have to figure out which functionalities we really want or don't want and the right UX approach to them.
Right now, if you click on a node the tooltip shows up.
If you click on the language code below the node, a tooltip stating the language shows up.
How would you want to handle collapsing or opening nodes? We could add clickable + and - signs
What were your thoughts here?
The text was updated successfully, but these errors were encountered: