Options to reduce diagram clutter #478
Comments
keyserj
added
enhancement
|
I think this would be a really important thing to add. People won't join the site if it's this complex and bloated with so many different icons, buttons, and so on. It's not an issue that there are these different features but they should probably partly be changed a bit in the UI, be reduced (e.g. only show top 2 layers until clicking), and have a simplified view mode. |
|
@prototyperspective I made a separate ticket for ideas to improve the first-time-user view #539 and added the layers/simplified view ideas to it |
|
Most needed I think would be removing the edge nodes, so that by default
Don't know if that should go into a separate issue? I think the other things you put into red boxes are not as cluttering, one could live with it as is if just something is done about these edge nodes. Another really large problem with the edge nodes currently is that they can be underneath other nodes so this needs some changes anyway – one could move the labels so they're always above or nearby nodes and if needed increase the margins between nodes, here's what I mean: If the rating in the edge node is for rating the item when it comes to its parent node then this is redundant if the child node is only connected to one item. When it's connected to multiple items, I think the rating of the node should be changed somehow to show multiple ratings – I don't think it makes sense for nodes to have rating that are not connected to any parent. On Kialo, this is implemented by whenever you link a branch it becomes like a new branch that you can give a rating again. Here I think it could display up to 4 numbers if the node is connected to 4 items and colors if it's linked to even more. When hovering over the rating, this circle/square would be larger so you can more clearly see the ratings. When hovering over any of the ratings, the associated edge is highlighted so you can easily and quickly see which rating refers to which connection. Alternatively (or as an option in addition), one could show the rating at the place where the edge is connecting to the node. Currently, that's the black dot at always the same place but it could be changed to a rating. If multiple items are connected to a node each place of connection would be spaced out so you can see all the ratings. See below: From this: I would suggest that the items at the bottom right of nodes are by default only shown when hovering over a node. Same for the black dots at top and bottom of nodes. I think something should probably done about the "View criteria table" button, if a new user accidentally clicks it / clicks it before knowing much, the user will be lost, not knowing how to return and what this is that's currently viewed or why the website looks so strange...maybe only showing that button when the user is registered/signed in and has completed the tutorial about it would be best. The "View details" button is redundat because one can just click the node. |
I was considering not even showing the label by default, and requiring users to hover the edge dot to see that. But I suppose it might be best to have the default be something that doesn't require interaction in order to understand it. Another question here is whether or not to show a box around the label - I think I might just have to experiment to see if it stands out enough. Maybe no border but with a white background so the line behind it doesn't interfere with legibility.
I discuss this here #535 (comment): "A while ago I made the decision for the layout to ignore edge overlap. I think that, when a diagram gets bigger, trying to avoid the overlap results in the diagram being a lot more spread out. This is something that I'm open to reconsidering, but there's usually only one type of edge that could be between any two node types, so I don't think seeing the edge info is that big of a deal (you can also click on the edge to get it to come to the front, if you really need to see it)." Admittedly, the last time I investigated label placement via the layout library that Ameliorate uses, I think I had misunderstood a few of the library's options, and was creating more space than necessary. I had forgotten that right now the edge label is just dumbly placed based on a bezier curve between the two nodes it's connecting, without using the output of the layout algorithm which would account for other nodes/edges 😅. Created #559 to look into this.
Even for a node with only one parent, the intention behind scoring the child vs scoring the edge is different. In the cars-going-too-fast example, you might score the Detriment "pedestrians might get hit" a 9 to convey that it's a big concern, but the edge where it's "created by" Problem "cars going too fast in my neighborhood" could be scored a 3 to convey that, while the Detriment is a concern, you don't think it's actually created by the Problem. I think being able to make this distinction is important, because I feel that disagreements often miscommunicate such distinctions (e.g. imagine one party accusing another of not caring about people getting hit, when it's specifically that they don't think that cars actually cause the problem). Unfortunately, I also generally have been scoring nodes within the context of the Topic. So in the above case, since the Problem is the Topic, if I didn't think the Detriment was relevant to the Topic, I would score it low. I feel that this is also a useful thing to have, because otherwise people can always come up with some reason why the Detriment is important that's irrelevant to the Topic, which isn't useful for the discussion. But this conflicts with the above intention. I think this conflict creates ambiguity and is therefore pretty important to deal with. Created #560 to try and figure this out.
I'm having a hard time envisioning this. I'm also not sure if it's still relevant if node scores are intentionally distinct from edge scores as described above.
This is an interesting idea I hadn't thought of. But:
I was thinking of just hiding these by default but showing on hover could be good too.
Hmm maybe something like this could work. Separately though, maybe UX could be improved such that switching between table and diagram is more intuitive/less jarring.
This button actually has two purposes currently:
I'm not sure what's ideal to do about this. Potentially the indicator could conditionally show and be moved to the bottom right section of the node. But there should still be a way to select a node that's in the Details pane. Could make clicking on the node's text not select it, and clicking elsewhere on it would select it, but I don't think that would be intuitive. |
Could indeed be better. It could become an option disabled by default.
Right, the lines behind it could be a problem for readability.
I understood the problem trees very differently – I think it would be rated with a 9 because it's the subproblem (or detriment) why cars going too fast in my neighborhood is a problem at all so I think only a very high rating and the exact same rating for these two would make sense. I don't understand why it would be rated a 3 (or anything other than the rating of that edge) so I still think having two ratings there is redundant and problematic. If nodes are are impactful/important for some reason, they need to have some (possibly new) parent node and be connected to that with a high rating. Having a high rating without such a node it's connected to would make the rating misleading, unclear and miss data.
Thanks, this makes it clearer – in this case people would rate the one ranking lower and add a new node or critique (or rate it highly if it already exists) about cars going too fast not being a cause of pedestrians getting hit by cars. Ratings that are about things that the problem tree is not about, e.g. have no relation to it aren't useful and can't be understood + are probably misleading and used differently. I think the nodes are all only evaluated in the context of the current problem map. It just needs to be clear that the ratings are about the node in relation to the node it's connected to / the context of the particular problem map, not about overall societal importance or anything else. I think most users wouldn't assume that and use the ratings. People wouldn't interpret a node with a rating of 9 to be of possibly low importance to the particular node but high overall importance disconnected from the map at hand but think the node is considered highly impactful in relation to its parent node.
May be good to make it visible to see who rated a node so one could ask them about whether they're considering the relevance. If even you have rated nodes according to the problem map context, then clearly most people are going to do that too. Moreover, things like Detriments and societal importance of nodes is relevant to the problem map but it would not be captured in the map in the form of an additional ratings on the node but via child nodes like Detriment and so on. Maybe you have another example so I could better understand how it was meant to be used and give an example of how this could be better solved via new nodes each with ratings instead of having a general rating on the node assuming I didn't get things wrong.
Yes that was before I noticed that these are kind of redundant to the more specific edge ratings. I meant that the node's one number in its upper right is changed to an element containing 2,3or4 numbers (one for every rating) but as you said these are currently distinct ratings and I thought it was the rating of the edge(s) connected to it.
You mean labels like "created by"? Not sure if I understood you but why would these be needed for the ratings? For the ratings it's the text of the node connected to it that matters, not the edge label that just makes it easier for (especially new users) to quickly understand how the node relates to the node above it which otherwise can be inferred from the two node types. Why would the labels be right next to the node? If they are shown (e.g. when hovering over the connection line), then it could be shown somewhere around the middle of the line just like before.
Not sure about this and some examples may help but I think it could be best to show them always on the child nodes. This makes it simpler and more expectable (consistent place to look for the ratings). If one want to see a parent node's child nodes by rating one can click on the (parent) node and just spot all the child nodes each with the rating above them.
So the black dot turns blue if there is a hidden node above or below it? One could display the blue do next to those ratings.
I didn't understand that – isn't the details button showing all details not just Justifications and isn't the details just one pane with several sections (one for Justifications) so how would that button help vs just clicking the node? Also note that not every slight speed-up would outweigh negatives and even slowdown due to having lots of buttons and text crammed everywhere; it's often easier to just do an extra click or short scroll than to click some button for the niche activity; also I don't think people would edit Justifications of multiple nodes in a row instead of eg a Justification there then some Research item there then trying to add a Note to a third item and noticing a Critique somebody else set on it etc.
Isn't that already just clicking [anywhere] on the node? Also consider for popular large maps it would be more relevant which items do not have Research items/Justifications supporting them instead of showing which nodes have them set; this could also be a config so (not very new) people looking to add research/sources can toggle the option in the sidebar to be able easily see which items do/do not have such already set. |
If the child node is rated highly as a concern, but the edge is rated low to suggest the node isn't created by the parent, I think the implication of another missing parent is a totally reasonable use case for scoring this way. Perhaps there's intuition about the Detriment being important because it's caused by something else, but that something else is currently unknown/needs to be looked into. Maybe if you scored that way, it'd be best to add a comment or a question node to indicate the suspected unknown.
To clarify - if the edge were scored low, the edge could have a Critique to justify why someone thinks that the Detriment is not created by the Problem.
You're probably right. I think the problem that seems important to solve (#560) is that ratings could have different meaning if considered in relation to nodes it's connected to vs in relation to the context of the particular map. I suppose it also seems possible that the scores don't need to be unambiguous, that the score with ambiguity is sufficient enough to prompt discussion/addition of justification.
When you turn on score comparison, you can hover scores to see who scored them. See tutorial Viewers > 2. Navigating a topic > Perspectives (step 3).
Fair point
Eh I think you're right, it'd probably be hard to have something truly irrelevant. And if someone tries to add something irrelevant, it could be best for clarity (in case someone else thinks of it too) to add it anyway and just score it low, with justification to explain lack of relevance.
Gotcha, I see now
Yeah labels like "created by". I was thinking about this for new user clarity specifically.
Hmm yeah the label could still be shown in the middle of the edge. I suppose the benefit behind this UX is that putting the score closer to the node would make it easier to see which relations are important, whereas putting it in the middle of the edge is harder to see especially when there are many edges/nodes are far apart.
My concern is mainly that Problem and Solution nodes are both like core nodes, and Components/Causes/Effects/etc basically help explain these core nodes. So the relation from Problem to a Detriment is similar to the relation from Solution to a Benefit, but in the diagram, since problems are laid at the top and solutions at the bottom, Problem will be the "parent" (above) Detriment, and Solution will be the "child" (below) Benefit. So if all child nodes had the scores on them, sometimes (on the Problem/top half of the map) the scores would be on the nodes (Detriment) that help explain the core (Problem) nodes, but other times (on the Solution/bottom half) the scores would be on the core nodes (Solutions).
Probably could work
Yeah Justifications are just one example type of node shown in the Details pane that you might want to view its Details. Maybe this video will help to convey the issue. When you click between nodes in the Details pane (in the video I click on Support and Critique), you wouldn't necessarily want to go to that node's details - normally you'll just change that node's text, and going to its details on every click would be jarring. So you have to click on the indicator to be explicit about going to its details. chrome_2024-11-05_10-33-47.mp4
Yeah that's a good point. It does seem probably not worth to show the indicator on every node in the diagram, because it does add a lot more visual clutter.
Yeah that seems like a reasonable idea. |
I think people should just create that other missing parent. There's no use or need for an extra rating imo. It just makes things more ambiguous and confusing, e.g. people will use or understand it wrongly or when it comes to extra nodes think that rating nodes some way would suffice instead of going ahead and creating the missing node. Is the node rating referring to the edge the node was first connected to, or the overall problem context, or the set of nearby/connected nodes or something broader than the problem map context such as overall societal relevance...people would rate each on all of these different notions.
If it's unknown then the rating(-change) is probably not warranted. Otherwise, they can leave a comment. Adjust the rating if there is something concrete. Changing ratings because people's gut feeling tells that maybe something somehow relevant to this may or may not possibly exist is exactly the wrong thing to facilitate imo – it would skew things towards emotions and away from reasoning and map completion. However, there's a good point about uncertainty and I think it would be good to at some point add more features about uncertainties. That's basically what I had in mind some years ago: certain node types could challenge others – e.g. a Detriment could challenge a solution. If these are added people who rated the node could be prompted to reevaluate. This is roughly speaking and it's not well fleshed out anyway – I think something like this could be built in later on. I think adding uncertainty would be a very useful feature for nodes more broadly: those nodes with no or only low-quality supporting sources have low uncertainty; this would also help researchers research the things that urgently need at least some more research or even any research (there's lots of these). I think I also mentioned this here.
I think a key premise and usefulness is that the rating in relation to the context of the particular map is encoded in the ratings of the connections between it and the main node. That's how the top-level has the broadest things and where the ratings are most important. If people would rate the individual nodes differently, there's an issue with a rating somewhere in the chain of node/edge ratings. I guess the rating set on nodes would be related to the ratings of the nodes above it, e.g. how much of a problem it solves + how it effective it would be for that. Ratings when it comes to solution nodes would be another thing to think about at some point.
Great. Will do the tutorials at another point soon. Currently there doesn't seem to be a page where maps are indexed and can be found, at least none well visible on the website.
By the way and not sure if this is planned anyway or meant to be used that way but it would be nice if it was facilitated that users when rating nodes low, are prompted to either add Critiques to justify their rating or also rate (with a high rating) some node that challenges the node like some Detriment/Subproblem. In this case you outlined the user would put that justification not into the node itself but also via either or both of these.
Indeed. Haven't thought about that but actually that's also something that I find makes it difficult to make sense of (or 'read') the maps, so kind of part of what the 'clutter' problem is about. I think new users would look at edge labels only occasionally, e.g. when they want to make sense of why a node is underneath one but the ratings are always looked at and important for all, so having these in the middle is not so much an issue (plus it would have to be shown at both ends). One could show the label at hovering right next to the mouse so one can hover on the line right above the node and see the label there.
You mean the details of the Support and Critique nodes? You first switch between the Problem and Cause nodes and for each click the detail view is changed which is what I thought is good to consistently always have. I didn't know there is a details view for a node's details like its Support and Critique nodes if you meant that. Okay now I see how these detail-nodes are nested – this is not easy to see and use (e.g. I think if there's nodes beneath it would be good to show some sort of tree maybe or something like it that makes people see/understand this).
Well it seems redundant on the main nodes since wherever one clicks on these nodes that opens their details view. There could maybe be some sort of option to not open the details view when clicking on the text instead of elsewhere on the node and then show these buttons but actually I don't see what the use of such a setting would be at all.
One could also replace it with some color or some UI element that looks like 'how full is the glass' that's showing how well backup a node is with data/source (maybe also justifications and maybe also considering critiques) that simply shows the lowest 'measure is empty' for nodes without sources. |
I disagree. My suspicion for our difference of views is that Kialo's scoring seems like its main value (per its defaults) comes from bringing the most important arguments to the top, but the main intention of Ameliorate's scoring is to identify agreement and disagreement. It should also be able to help bring important nodes to the front, but this isn't the primary intention. I feel that a huge amount of time is lost in discussions where people misunderstand what is agreed/disagreed upon. People justify themselves when the people they're talking to already agree on that, when the disagreement is actually elsewhere. It takes an often exhausting effort to figure that out, assuming they have the patience/willpower to get through it and do end up figuring it out. Having an unscored diagram would help with this, but scoring should make it trivial and blatant. If everyone agrees that something is important, then there's no need to spend time justifying it. One can always ask "why?" more and more times, to get to deeper and deeper reasoning, but you have to stop somewhere. And it makes sense to stop where people are in agreement and have no reason to doubt. Note: if you think of justification that seems useful, you don't need to wait for disagreement to add it - I'm specifically referring to times where you'd have to stop and think further to come up with justification. I disagree that scoring emotionally would skew things away from reasoning, I actually think it does the opposite. It enables differences in emotion to be highlighted, making the question of "why?" blatant, and provoking reason to be considered and identified. If people (try to) exclude emotions from their scores, Ameliorate would fail to bring emotional disagreements to light, and fail to identify the reasoning behind those. As a further clarification: scores also help reveal inconsistencies in your own intuition. If you score that node a 9 but that "created by" edge a 3 - that's another "why?" question being provoked, that might have been left unidentified if you only scored the node. Concretely, scoring only the node or only the edge could mean that the other thing creating this Detriment is not identified, which may be relevant to the discussion.
Question nodes can help make uncertainty explicit. Not only do they clarify what the uncertainty is, but they can also be scored, so that the perceived importance of the uncertainty is clear too (and can be discussed). Potentially there could also be a separate score for uncertainty ("confidence"?), which might help when even the questions to ask are unknown. I suppose this might be similar to "veracity" in the Kialo discussion you mentioned (thanks for sharing).
I like this concept
It seems to me that Question nodes (and their scores) should help facilitate this.
I think this should be generally true, but again there's the specific situation where there's intuition about a node's importance that's not covered by existing parents. Allowing that node to be scored separately from the existing edges enables the question of "what's missing?" to be implicitly posed in the diagram without having to answer it yet, while retaining the ability to convey your intuition that said missing thing is important. I also think that this distinction would be rare enough that top-level ratings of importance wouldn't be significantly disrupted by something like this.
I think prompting users about something that seems needs justification (whether it's through Support/Critique vs Detriment/Subproblem etc.) is something that would be useful. I'm skeptical about triggering that for all high/low-scored things, as that seems like it would basically continue triggering indefinitely, until you decide not to score something? It's appealing to me (per my above explanation of score's main intent i.e. identifying agree/disagree) to prompt for justification based on scores that differ from other people's scores.
Yeah
Yeah, one thing that I suppose isn't highlighted very well is that all nodes, including justification & research nodes, can have their own nuance (i.e. notes, justification, research, and comments). I see this as an important aspect of the tool's precision capability. People can disagree on the importance of a Question, so that a conclusion can be reached about whether or not it's worth trying to answer the Question. People can disagree on the importance of a Source, so that it's clear if people are doubting something because of lack of a Source's credibility, and people can add justification to clearly convey reasoning about it.
There is a justification tree for each node/edge, though getting to it is maybe not intuitive (also "Root Claim"-type nodes I think are a tech debt that will likely be replaced by direct "[supports/critiques] importance of" edges #294 (comment)) : chrome_2024-11-21_12-40-49.mp4The tree helps see all the chained justifications, but justifications can have other details not in the tree too (like questions/facts/comments), so I think it's necessary to enable viewing the details for any of these justifications.
I think similar to my skepticism of prompting justification for any high/low-scored node, I hesitate to assume by default that all nodes need data/sources, as opposed to something like allowing any user to "request source" or score an existing source low. |
That's good but what you described is not fully what I mean: I meant that people should specify why they disagree instead of just rating things with gut-feelings or hivemind-voting. The why is missing when people rate the nodes. On Kialo, one can also identify agreement and disagreement by either the Perspectives feature or by clicking on the vote stats for a claim. It may be that you partly misunderstood what I mean. Also what you said can also be done if only voting on the edges is possible.
I don't see how also rating nodes instead of just nodes in relation to other nodes (edges) helps with that. Maybe an example would help. Or it's something that would be better to come back to later, maybe once it's clear contributors misunderstand and improperly use the node rating feature. Moreover, enabling rating nodes directly I think does the opposite of what you just described because it makes things more implicit when things should be on the map.
Ah ok that may be the first usefulness case of rating nodes directly that I can understand. However, that something is important is specified already on the edge like the "is solution to" so it's still redundant. Furthermore, you only consider the contributors to the map. I think of it more like this: even all contributors to a Wikipedia article already know of / agree about something that often should still be in the article since the article is intended for a general audience. For example, these maps could be used by policymakers.
It does the opposite of that because people may just rate a node instead of adding a critical node like a Detriment. Moreover, there may already be a critical node attached to it so people mistakenly think that's why the node is rated so low by some.
The whole point seems rational maps where people make nodes connected to other nodes. E.g. if people think allowing any abortions is bad thing they can still rate edges accordingly which are specific. Instead of just downvoting every relevant node without even specifying why. The point of this project seems to mindmap basically, not to just vote things without reason. Disagreements are brought to light via the edge ratings, just that they are made explicit and aren't ambiguous and rated in an understandable clear way. Also I don't see why you seem to say people should vote on their gut feelings instead of by thinking about things and carefully considering the attached nodes. It would result in superskewed ratings that are not useful to anybody if many people did so and also decrease the mindmap quality a lot by e.g. low rating important key nodes. Imagine a mindmap about climate change with caused by greenhouse gases rated very low and caused by Solar cycles rated very high. It would be distracting the activity to a quite irrelevant branch about Solar cycles instead of thinking about how to actually solve the problem. Also note that it's one rating per node and edge that gets displayed. By enabling rating nodes, it would rail to identify the reasoning behind them.
Do you think people will carefully check each and every contributor's ratings and then ask them why?
I consider this a reason for not enabling node ratings: I would add 'scoring the node and the edge means that the other thing creating this Detriment is not identified'. Again maybe it would be a good idea to just come back to this later. I think people should be facilitated to put the Detriment on the map. They are facilitated to not do so if they can just rate the node low or high. Moreover, I think they could already rate an edge to capture this like the is solution to edge because they think it's not a good solution.
Interesting, didn't know they can also be scored. There are more uncertainties than can be put into questions I think like uncertainty of having too little data for something. Maybe that could also be phrased in question format, like "Is there more data supporting this?". Mainly it's for some score/assessment that there's lots of data e.g. for greenhouse gases causing current climate change while there is are not so many for novel packaging materials being a viable solution for plastic pollution.
Yes those also. But often there is a problem of too little data supporting a node.
This can also be done via the comments / questions and via rating specific edges like the is solution to link. Moreover, it doesn't enable that as the rating could be consistent with the linked nodes (or people think that other users only rated the node itself but not the edges).
Not sure what you mean there – it would skew the map, e.g. distract users and readers (could be anyone like people interested in the subject, policymakers, researchers, etc) to get a flawed picture instead of streamlining things so things are mapped well.
No, e.g. just once; also often things are rated at some deep/low level where there's no nodes beneath; usually only one or so node explains a rating not a full chain of nodes but one could also facilitate rating multiple linked nodes, like highlighting the connected nodes whenever one has rated an edge.
Yes that may be better or good in addition.
But still I don't see the point of having the details view button – wouldn't it be best to always show the same details view when clicking on a node? So many different behaviors depending on many conditions, nobody can keep that in mind, it's probably best to always show the details from where people can go to the justification nodes or somewhere else. For people who use the tool daily and like some power functions one could have a setting to show this button and to keep the details subview the same when clicking on different nodes (if that's what it's for).
I think it's hard to find. Maybe it could be signified otherwise that there's linked claims beneath these nodes but maybe those icons in the bottom right makes people see/understand this. So I guess the tree can't be well integrated into the details panel directly and would need to be shown in the map. If there's only Pros and Cons I think it would be possible to have an integrated UI in the panel that shows the nodes directly beneath for further navigation like on Kialo but if anything that would be something for later. I just think that loading it into the main map UI element like that is confusing, it makes the main map disappear and replaces it with some submap. It would be better if some layer was put above it, maybe with the full map still visible in the background or partly, and with a large X to close this in the top right corner. That would make things far easier, people would be lost, like not knowing how to see the main map again and whether they just opened an entirely different problem map etc. Seems like these maps are kind of 3D where some nodes can grow into Z dimension, maybe at some point some 3D visualization/navigation will be possible many years from now.
Glad we share this view then. I don't think they need data/sources, only that ideally they have them and that enabling users to see which nodes are well-supported and which could still be aided by searching for / … sources/data is useful. |
|
I've noticed that there are a ton of points that we've made about the question of scoring nodes vs edges, and I think it's a perfect example that Ameliorate should be able to help us discuss more effectively. I converted the scoring issue into a discussion #590 and added a TODO at the top of that to create a Topic when I get the chance. I started replying to your scoring-related points, but I think it's probably better to continue the discussion separately and/or come back to this later, so I won't finish replying to the scoring points here. I've put the reply that I started making into the linked discussion so we can continue there when we want to #590 (comment). Side note: generally I think I haven't been on the lookout for extracting discussions that go beyond the desired scope of a ticket, but I'll try to catch these earlier going forward so that each discussion can be more focused and easier to follow. |
|
For the sake of this ticket, I think it's easiest for now to keep showing indicators by default - so users know the indicators & scores exist, since they're core pieces of the tool - but to make sure that the "hide indicators" button (I'm thinking of just calling it "Zen mode" since I've seen that terminology used in other tools) is at the forefront/easy to find and its function is clear. I also think it's easiest to just have one button for this, and not to include separate controls for show/hiding each kind of indicator. That's something that could be added in the future if it seems desirable.
I think that there's further consideration to be had for this details button but that it's not critical for this issue, so I've created a separate discussion for this #591.
Yeah this seems possible. Agree that could be done later. But I do have a design here #551 (comment) (see the pane design on the right side of the image) that seems like it'd make this more possible - the Details pane would have a lot more space for each section if tabs were used and only one section were shown at a time (the main motivation for tabs initially was that I feel the details pane is a bit cluttered/hard to know where to look).
Funnily enough, I previously had Research and Justification information put into their own separate diagrams, that were overlayed exactly how you're describing, with an X to close (you can actually still play with it at https://deploy-preview-391--velvety-vacherin-4193fb.netlify.app/playground - wow these free-tier deploy previews are epically long-lasting...). I refactored and scrapped this in #359 in order to allow Research and Justification to be displayed in the same diagram as Breakdown information, since that was sometimes desirable. I think adding the X back in could be good but might do with some design thought. Implementation I think should be easy though. Created #592. What it used to look like:
Oooh I've never thought of that, that could indeed be pretty cool, and useful (especially for larger maps). Yeah this wouldn't be done for a long while probably but still created #593 to track it/have more discussion about it. |
|
Ok after trying it out, it does seem maybe worth defaulting on. The diagram does look a lot cleaner, and as has been said, new users won't know what the extras mean anyway. If hovering/selecting will show the indicators, that should allow new users to discover the indicators if they haven't gone through the tutorial to figure out about Zen mode. Currently Zen mode is defaulted to off - will try getting hover/select to work, then see about changing the default. |
|
Ended up calling the button "show indicators" because I think that's more clear than "zen mode", and "zen mode" seems like something special that shouldn't be defaulted on. I have some issues with the naming as described in this commit message 26ff555 but ultimately I couldn't think of a better name that didn't have other issues. Here's what the solution looks like as merged - can always make changes as we think of improvements though. chrome_2024-12-06_17-11-34.mp4Something else I didn't do was hiding the node/edge types (e.g. "Problem"/"addresses"). I think we could also explore hiding those, but I think they're probably more important than the other things for new users, so it seems maybe better to have it as a separate config for advanced users. |
Describe your issue
There are a lot of UI pieces that aren't always necessary to show.
If I just want to see the diagram structure, I don't need to see:
If I'm not color-blind and am familiar with the tool, I don't need to see:
Solution you'd like
Clutter Config (or some wording like that?) section in the More Actions Drawer, with options:
Also:
Clutter config should be:
Questions:
Alternatives you've considered
No response
Additional context
Technical ideas and questions
The text was updated successfully, but these errors were encountered: