Replies: 6 comments 12 replies
-
|
Idea: limit shown diagram to X layers from the selected node (solution/problem/etc) Good:
Bad:
|
Beta Was this translation helpful? Give feedback.
-
|
I think this is good idea and needed in any case because on mobile one can't show many layers (probably only one at a time i.e. one card with the items directly beneath it).
|
Beta Was this translation helpful? Give feedback.
-
|
Woops I overlooked this so I'm not sure how much of this is out-of-date, but:
This is a good point that Quick Views don't help with right now. Quick Views are completely custom, so authors might decide to make them in different ways, whereas a standard view (e.g. always start from problem) would be more consistent. As I said, I don't think it's always best to start from a problem, but potentially there could be multiple standard views e.g. one for starting from a problem, from a solution, and from the tradeoffs. That would still have some consistency at least, even though there would be multiple (though I'm not certain that there wouldn't be other good starting points than these three).
Yeah this could be good
For example, mta-congestion-pricing is a proposal and so the Solution is more of the focus than the Problems, which aren't very detailed. It's also just proposing one Solution, so there aren't even criteria for comparing to other Solutions. More detail could be added to the Problems, and maybe alternatives w/Criteria too, but I wouldn't expect those to need to be fleshed out at the start of a proposal. open-source-vs-closed is an example (arguably) where I thought it'd be best to start from the table, because it gives a high-level overview of the different aspects being compared. |
Beta Was this translation helpful? Give feedback.
-
Interesting. Could be very useful to use this for proposals – one could then also link to the map about the specific proposal on any map that includes that proposed solution. Maybe even a way to keep it in sync with the map that includes it depending on the level of detail there or making it so that only the solution and maybe some things close to it are shown by default but the entire other map can be shown as embedded in this map. One could see a large but still navigable map about climate change and then click on any solutions one is interested in to fetch the full/more nodes from the map it links to (here congestion pricing). For the example map I'm not sure if it wouldn't be better if the solution was always shown at the top, if not the node then the title and/or if the focal node (here that solution node) was highlighted and larger.
Disagree on that, I was very confused when I saw the table, didn't know how where to change what (plus didn't know this was just another view mode) and find the other view more useful but think both are not necessarily best suited for a default view (that also people fairly new to site or unregistered & entirely new use) as I think a simplified view looking roughly like in the image below but with e.g. more columns on desktop and a minimap in a corner to easily switch to the map view would be much better. Secondly, sooner or later there would need to be a way to find the maps – e.g. via tags and categories and a panel of recently active maps – and there one could have several buttons for each item where if one clicks any of these it loads the map in a given view (e.g. default, admins' recommended view, full map, table view). |
Beta Was this translation helpful? Give feedback.
-
I think that referencing from one to another Topic is a good idea, but I'm not sure exactly how embedding would work. Showing specific nodes from the other Topic would probably lead to wanting to connect nodes across Topics, which would be great, but if the embedded Topic has different permissions than the referring Topic, that UX seems like it might become pretty complex. Decentralized Topics wouldn't have this problem though.
The layout should be able to put Solutions at the top, then maybe Obstacles would be on the left and mitigations to those could grow below that, similar to where Causes currently are for Problems. Would have to see how it looks with a couple of examples. In general, highlighting the core nodes does seem like a good idea. Hiding other nodes at the start, or something like #552, would be easier implementation-wise. Topic title should be more highlighted/easier to see in the current view regardless.
My impression is that this is a UX problem. Conceptually, it seems reasonable to me that if the purpose of a Topic is to clearly compare 2+ things, that these things must be compared across a common set of criteria, and if that's true, that those would be a good place for new viewers to start in their effort to understand the tradeoffs at play. Then if they disagree about some criteria, the criteria would be a good way to categorize all the components/effects/etc into a narrower subset of concepts, so it's easier to identify & discuss specifically what is disagreed about. On the other hand, if a viewer cares more about understanding the two things independently than specifically comparing them, then criteria don't seem like a good place to start. I could also see an argument that understanding independently is a better goal to start with before comparing the things. I guess my intuition is that when a thing is complex enough, it's easier to consider one aspect/criterion at a time than to go through all the pieces of the thing.
I think right now that the UX for Quick Views and changing view Formats is not intuitive, but that this can improve and would help.
I hadn't thought of this, something like that could work too. I don't think each kind of view would always be applicable (e.g. table view when there are no criteria), but only relevant buttons could show, or instead of buttons per map, users could have a preference setting and that would determine how Topics open initially. |
Beta Was this translation helpful? Give feedback.
-
|
Kialo has some great UX that's intuitive for new users, maybe inspiration can be taken from that. Guided voting: shows one claim at a time, and another is shown after that one is scored |
Beta Was this translation helpful? Give feedback.
-
|
Kialo's sunburst navigation is a nice visual to convey depth of layers from one root node
|
Beta Was this translation helpful? Give feedback.
-
|
FYI the sunburst navigation is kind of neat but most likely barely used. I think most users there don't use it at all and instead just close the popup and look at the Pros and Cons at the top-level to navigate to those they find interesting or would like to add to. I think a sunburst diagram would be possible for the map you shown in the diagram: condense everything so e.g. the two green tiles are directly next to each other; only at the bottom in the middle right above the pink tile would there need to be an empty tile. Would probably be best to worry about that at a later point since it's not a simplified view but a way to navigate and get an overview like the map view so just as complex if not more so...think of the information overload people would get if they had such a view and then actually hovered over one item after another and try to make sense out of all of this linked condensed info – doing so can make sense once you spent a lot of time in a map and are familiar with most of items already but not for people new to a map or even the site. |
Beta Was this translation helpful? Give feedback.
-
|
Kialo's tree navigation is also nice way of contextualizing where you are in the diagram
|
Beta Was this translation helpful? Give feedback.
-
|
Kialo's simple 2-column view is easy for new users to navigate:
|
Beta Was this translation helpful? Give feedback.
-
|
Note: on mobile, two Ameliorate nodes just fit within the width of a 360px phone, and three nodes fit if using the criteria table mobile view, which sets zoom to 60%. So the image wouldn't necessarily work well on mobile (would have to use horizontal scrolling for 3+ nodes). |
Beta Was this translation helpful? Give feedback.
-
|
Another note: the image doesn't have edge data. Potentially the edge label & score/indicators could be placed below the detriment and above the solution. Though it's also possible that edge data is something worth forgoing for the sake of simplicity? Hard to say. |
Beta Was this translation helpful? Give feedback.
-
|
A simplified view as well as reducing the amount of things shown when opening a map and both could also be used for the mobile view. The Kialo view (in your screenshot above) also works really well on mobile, not just desktop. One could for example show a panel of tiles one can swipe through one at a time or display them vertically and when dragging them to a side show the tiles beneath or above it. Full desc. here; illustration below. (Also I would do away with the criterion as elements as these just blocks valid claims that can have subproblems like high cost. The problem of not all solutions being shown or on the right in the image may be due to this element, without it the solutions would be linked to a cause so when the cause is viewed all solutions to it can be seen.) Swiping main cards at the top has different actions than swiping nodes below these. When swiping the main card (at the top) downward it would show the item above it – here screen 1 is turned to screen 3 when doing so. One can tab on a node to make it the main/top tile – here screen 1 is turned to screen 2 when doing so. Parallel nodes linked to the same e.g. cause/subproblem can be seen when swiping leftward when something is in the corner. One can also swipe main tiles to leftward to see its parallel nodes (however maybe only when directly linked to the same node and not when there is some node like Detriment "temporarily requires detouring" in this case between one of them albeit one could specify which types of nodes can be ignored if in between...in this case I think the detriment should maybe be moved to beneath not above the component – however I think the design is problematic and it would be better if instead one simply added the subproblem of "temporarily requires detouring" beneath "stop light at intersection", often solutions are not implemented because of a lack of solutions or ratings of the subproblems of solutions and a main use of these maps would be to have these specified in the map and get addressed with nodes.) This is what I mean with simplicity and the desktop view I think most people would like to use could be similar to it or a variant of this view. Info on node type and connection type could eg be shown on hover (/one tab instead of doubletab/long press). In the unseen changes feed there are links to individual nodes that have been added or changed. For new users, complexity can be reduced (and quality of the site's maps be increased) by only allowing them to make connections or new nodes without being able to specify which kind of node (like problem) or relation these are. |
Beta Was this translation helpful? Give feedback.
-
I'm an advocate for considering simpler alternatives to the map view, but I'm not 100% convinced that the map itself can't be improved to a point where it's simple enough for mobile/new viewers. Miro at least is an example of a diagram app that people can use on mobile. As someone experienced with the tool already, I think the mobile view being a diagram is not thaaaat bad to use. I think a simplified view might help navigation for new users, but I feel that that's basically regardless of mobile vs desktop.
Wow thanks for the detailed design! I've got a few other tickets I'll be working on before considering this more thoroughly for possible further design & implementation, but this is a really awesome start. Nice:
Notes:
Concerns:
Some design questions I've thought of that we'll need to figure out:
I'm having a hard time envisioning what happens if there's multiple. My guess would've been that you'd have to swipe further, like this would be kind of like a carousel component.
I think, at least for users who will be building the diagrams, I would compare this to a diagramming app like Miro or Lucidchart. I would guess those are largely used on desktop because of the added UX powers that would outweigh phone convenience, especially when used for more than a few minutes at a time.
My current intention is that builders create Quick Views so that the default view for the topic is a smaller subset/high-level.
While the solution is being implemented - i.e. installing a stop light might take several days, during which traffic has to be interrupted.
I was thinking of it as "criterion for solving the problem". Maybe the edge could be "criterion for solving"? Hmm...
The intention of criteria are specifically to have a common set of things across which all solutions are evaluated, so that decisions can be made clearly via the criteria table. Usually I add criteria last when building a map, and so I might add a "expensive" Detriment to a solution (or maybe e.g. a component "$100k cost"), which could later be replaced by the criteria or tied to the criterion to explicitly convey why the solution doesn't fulfill that criterion.
This would be a reason to keep a Detriment/Obstacle node separate from the Criterion, so that it could be mitigated. If the creator didn't make one of these separately, a contributor could create one and then a mitigation for that. Or potentially even cleaner would be to include the suggested mitigation directly in the solution, via a new solution component or editing an existing solution detail.
See above, let me know if you're still opposed to them. I'm confident that criteria are valuable in a tool where decisions will be involved, but their purpose could be better explained, or maybe UX around them could be modified.
I think this is a good point. This might be a good argument for just removing criteria from the diagram view. Especially since they're always supposed to be evaluated for each solution (showing them in the view implies you can just delete edges between solutions and the criteria, which you never should). Created #548.
Hmm in your older post I had thought you meant that this would only apply to the selected node - children nodes would already all be showing, so I'm not sure that there would be any more parallel nodes for them.
Yeah "parallel" I think makes more sense if the sibling node is tied to the same parent (or child).
I'm not sure I follow the concern here. Are you suggesting that negative aspects of a solution should be placed below it, so that it's clear that these things would be good to be mitigated? In which case mitigations could go below those, and those mitigations could have problems below those to be mitigated, etc. As opposed to detriments above the solution, which would need to be mitigated by mitigations below those, which would then have to fan out to the side instead of downwards. |
Beta Was this translation helpful? Give feedback.
-
Yes, I'd propose a separate UI mode parallel to the map view. I think most people and especially newcomers would use that view mode the most. More experienced powerusers may use the map view even as the main view because they can see lots of things they're familiar with at once. It could be different but I think it needs this one/two pane view mode in any case. Maybe more people look for and like to use a map view on mobile but I can't imagine how zooming and dragging around the map while keeping many node locations and relations in mind could be preferable to a sleek simple one-pane organized view on smartphones (different for tablets etc).
Please also keep in mind that you're already very experienced with the tool. One forgets how it's like to use a totally different UI and concept website for the first time and since you never had that here but developed it over time you also can't know. Apps and websites are mostly drawing people in via first impression-like simplicity and interesting content readily engageable with. Successful apps all have relatively simple easy to understand UIs and reddit is even an exception where people sometimes wonder how it reached its success with such a filled UI. It's not fun, dopaminereleasing, or inviting for many to try to grok some complex site with small numbers and icons signifying all sorts of things to keep in mind and consider. It's not bad to use (at least once those overlapping connections are fixed and text not cut off anymore) but not the kind of UI one enjoys and easily can add lots of content during which one becomes familiar with the website and UI enabling one to make use of the map view.
You mean because those are usually at the bottom of a map and things are only above it? That wouldn't be a problem. I think below it, it could show the other things about the solution like Justification, Critiques, and Research items. Maybe this would be done for all nodes of type solution or all nodes at the bottom of map that don't have children below them. There could also be some indicator(s) above a top card like there are on the side of it in the 2nd image. I think it's also important to keep the UI consistent (expectable and the same).
Okay, so many would want to jump to solution after reading the problem instead of navigating to them. But then which solutions...this may work for small narrow problems but if you consider climate change, solutions could be building flooding protections but also mitigating climate change by reducing co2 by burning less fossil fuels and the solutions for how to do that. Which would one jump to? Maybe the most impactful solutions or only solutions to the root problem etc. I think this is a good point but it could be worked out later, e.g. via adding some kind of jump to solutions option (may in some sidebar or the context menu on the main problem card's three dots). I think it would be important to put as much things as possible into hidden context menus available when eg pressing the three dots but not visible by default, the less buttons the better and extra panels and buttons could be enabled via a setting (by users who have become familiar with the functions). For jumping to other solutions I think one would swipe the solution card (then loaded into the main card) to the left or right; one would need to determine which solutions are parallel somehow and maybe one could also make it possible to see solutions not parallel this way...e.g. if you swiped the card to the left so often that you saw all parallel solutions to its right then one could swipe to eg differently colored solutions that aren't parallel (the user may need to pull down the cards above it to see what the solution is about; there could also be a press-long view to see an excerpt of the map that shows its location similar to this but with text visible in the nodes and only the ancestry chain of nodes being visible).
You mean like a map showing the nearby region like often in some corner in video games? Could be useful and could be added later. But I don't know what you mean with high-level view there, what would it show in a large map of 1000 nodes?
The colors would be associated with the node type and one could show the node type when one is hovering or shortly tapping the node. I guess something would need to be thought in regards to the connections/edges, like "is a subproblem of" but it can also be inferred from this info about the node type if I'm not mistaken. Yes in the app there could be a brief tutorial, maybe people would actually usually share (or vice versa view) problem maps with unregistered external people in the full map view but contribute to (incl navigating it) using the simple view. An option to share a map with a specified area in focus and the rest kind of dimmed would be great too, so you could e.g. highlight opportunities and bottlenecks for people (like researchers) to work on. Also when it comes to the tutorial(s), I think it may be best to just show the utmost basics and then enable further functions like adding research items or justifications later on as kind of gamification achievements privileges which means people don't learn too many things at once and also new users don't enter problematic content into all sorts of fields but usually only the few the newest users can create suggestions for.
I have yet to become more familiar with the site to be able to answer this well (which I find difficult with the current view + low permissions in the few public example debates). One could also have more options when long press-holding the + button (if only pressing it shortly it would create a new node where one can specify type). Most things would be accessible via the three-dots-menu or things like press-hold. To create a node above, one would navigate to above and then add the node at whatever is the right place with the + button. Or do you mean creating a new node without any connection? (An example would probably help.) Edges could be created by pressing the three dots, selecting connect to another node which then opens maybe a map view so one can select the node to connect it to (there could also be a button to navigate the normal way so one navigates to the intended node via the swipings and then eg select the three dots on the node or tap on the dot below the node that is visible whenever one has selected connect to node on some other node). On desktop it would look similar but e.g. with an extra panel that contains Justifications, Critiques, Research items for every node and larger nodes with more nodes to their sides (also maybe this map in some corner with a button to easily switch to the map view and back). I have to become more familiar with the view pane if you mean the sidebar on "More actions"; maybe simply a sidebar on the left: one can still swipe from left outside to inside. Yes, the details of a node could be shown when pressing on the card that is the top card...or when swiping from the left outside to the inside. This could replace the nodes below the top card with the comments, justifications, etc as well as a button to show the nodes again. I think the quick views can cause problems for users and make things confusing with it being difficult to set it back, I haven't yet learned how to create a new quick view (that doesn't look like All Breakdown) and why one would use anything other than All Breakdown + Diagram format. In any case I think this should be difficult to find and change, maybe even only possible after getting unlocked after some contributions. It could eg be in the sidebar on the left (when swiping from outside the device to inner).
I meant there are multiple smaller cards on the side of the child node and one has to swipe precisely where the other card is at on the side. That could be bottom left of card, middle left or upper left. I guess it could be more difficult if there's 8 or more nodes also above that node but I think that's exceptional even for large maps. Maybe just showing one card on their left if they also have a node above them would be as good or better, one could swipe through the other nodes above it and either tap on the node to load it into the main card at top or do nothing and let it snap back to the child node that was original shown after one second of not holding the finger on it.
Seems likely at least at first albeit mobile gets ever more important. However, there I meant the webapp in general, not specific to the mobile app. I think the simple UI mode is for like the hard working content contributor in the mines while the map is for sharing the final result or for looking at to see the entire thing after lots of contributions and much experience. Like the map of mining tunnels to look at every once in a while. Not just when used for long but also especially when maps are larger, it may still be somewhat manageable and not cause headaches if it's a small narrow-problem map but I think the most popular maps are going to be quite large (it's also like that on Kialo where the most popular maps are some of the largest and most popular trees are quite large).
I think new nodes are by default not connected to nodes so then it's unclear whether the criteria is fulfilled or just the connection missing. For cases where it doesn't fulfill the criteria it's unclear which and why. Moreover, from the other map it seems like only nodes that fulfill the criteria can be added in the first place. In the cars going to fast map there's only solutions connected to criterions. I still think it would be best to not display them by default but I have to learn more by using the app more; however that more learning is required seems problematic to me already and these criterion nodes would be better captured with subproblems about costs because for one it matches the problem-solving structure where these would be problems not immune from getting collective intelligence thinking about how they can be solved and because it's kind of inherently subjective where I think these would only be good as things to add in or in the collab namespace / the more opinionated maps.
Yes, children nodes are all showing there. I hope I'm not confusing things: when swiping the child node leftward it would show its parallel nodes like "speed bump between intersection and hill" if that is linked to the same problem/subproblem/cause (here complicated by the criterion in between). In the map view one can see the parallel solutions right next to each other and with the same color, the same would through this way also be possible in the simple UI. The important thing is that it should remain possible to see alternatives and complementary things etc, and whether things are linked directly to this or that node isn't necessarily important in regards to that, semantically in terms of the idea it's parallel and maybe identifying these would be simply checking the Problem&Detriment nodes. Basically this is about seeing the relevant alternatives.
I think this was also about the problems to identifying 'parallel' solutions on the semantic level when nodes like that are placed in between which results in two nodes being linked directly to the same node. But I also think it would be better if it was placed beneath it because for complex difficult problems the real magic and need for solving would happen there. The problems are in how known solutions can be implemented. They may have certain subproblems / open questions as well as Detriments; the difficulty is implementing things in the real world and all the problems tied to that so I think these should branch downward where details as well as actual solutions are further down. |
Beta Was this translation helpful? Give feedback.
-
My thought is that a diagram is inherently better at conveying relations (so that you shouldn't have to keep them in your mind as much), but that Ameliorate's diagram UX is currently too cluttered/unintuitive to do this as well as it should. I think that after trying to improve this a bit, we'll have a better understanding of whether improvements will be sufficient for making the app accessible to new users.
Yeah I get that, and this is one reason why I appreciate your feedback so much. I definitely plan to keep feedback in high regard particularly for trying to achieve new-user-friendliness.
These are good points
Yeah
Hmm this would be a different way of being inconsistent though, if it's just for some node types. Potentially these auxiliary details could always be in a section below the child details, and so if there aren't child details, the auxiliary details are shifted up and into view.
Yeah this seems good
These might work. It's possible that large maps like these could use additional features to help navigate, or maybe this particular map could be better organized. One might want to consider all possible solutions to improve the climate change issue, or consider ones that specifically address one of the causes/detriments. I suppose the latter probably doesn't need "jumping" - you'd probably be looking at a cause/detriment, and that could have relevant solutions already showing as children in its view.
Agreed, it's more of an auxiliary consideration
Agreed
Hmm it's possible that this could work. Probably would want to be careful to ensure that parallel vs not-parallel are intuitive, and I'm not sure color would be enough.
Seems useful
Something small that can give you a sense of how your selected node relates to the Topic as a whole. Like Kialo's sunburst/tree views. Likely an optional thing. I think being able to get a sense of the whole map is valuable even if you don't know what the individual nodes are. Going through the map one node at a time is a nice easy/understandable way to navigate, but without a minimap of some kind, I feel that it would still be easy to get lost after moving through a couple nodes.
Maybe it would be good enough to just show the chain from the selected node to the root problem and/or root solution, similar to how Kialo's tree view shows from the selected claim to the root claim.
Typically there's one main edge type between any two node types, but this isn't 100% the case. There are two situations I can think of that don't follow this:
You're also able to have any edge between any two nodes, in case there's some situation I haven't thought of.
I hadn't considered something like this. I think Quick Views almost address this use case, by filtering down to the specified area you want, but there may be some advantage to dimming over hiding.
This was one intention behind splitting the tutorial into parts that you can complete separately. But the current setup could probably do a better job of having utmost basics separated from other good-to-know things.
Right now there's just a checkmark if you completed the tutorial. Tying this to privileges like being able to make some suggestions could be good.
I'm not sure the best way to become familiar with the app at this time. You could browse random maps under my user https://ameliorate.app/keyserj but many are older (so I have better ideas for organizing them nowadays) and haven't been groomed for viewing e.g. by creating Quick Views. Attending a discourse session would likely help. I guess long-term that ideally improved UX and the ability to contribute to a variety of maps would be enough. Probably just having more well-polished maps would help a lot. Potentially I could also convert more Kialo maps - converting existing information to an Ameliorate Topic is currently my preferred way of showing off the app to people, because I think it's easier to see the value if it's placed within the context of their own problems. I guess though this doesn't really help with the editing aspects of the app, which is maybe the main concern - you'd have to try converting them yourself for that.
Seems reasonable
Hmm well the + button, being located below the Selected node, seems like it would create a node as a child of the Selected node. In the diagram right now, Solution has components/effects as "parents" above it, whereas Problem has cause/effects as "children" below it.
Oh yeah these could work.
This seems reasonable
This is the view pane
This might work, maybe with a button to open it as well (if there's space I suppose?) so that it's clearer that swiping is an option. Its importance really depends on if Quick Views are use for this simplified view.
This seems good
The intent is that Quick Views contain all of the expected-to-be-useful views for a Topic. The first Quick View in the list is always the default one you view when you open a Topic without specifying a
Check out the tutorial "Builders > 5. Building Views" if you haven't yet
When a diagram gets big, oftentimes looking at a subset of nodes is much easier to consume, and there are specific sets of nodes that have some commonality that are useful to view together, separate from the others. E.g. each of the context views in the https://ameliorate.app/keyserj/open-source-vs-closed Topic focus on a different aspect of the map.
At least for the map view, the intent is that the Quick Views are the main way for viewers to navigate a Topic, so that a Topic (especially a large one) is easier to consume. This is because they're curated views by the people who've made the map, so they understand what should be useful ways to look at the map.
Ohhh I see. I had been envisioning that the cards to swipe to would be the same size as the node you're swiping from. Yeah multiple smaller cards vs one same-size card seem maybe like something that would have to be used to get a feel for which is better.
I see. I like the analogy, but I think it's important to reiterate that my intent for Quick Views is to help look at smaller aspects at a time, not just the whole map.
Solutions currently are tied to all criteria by default, so that decisions between Solutions can compare all of the possible good/bad things about each Solution (and e.g. if a Solution doesn't fulfill a criterion at all, the edge could be scored a 1 to explicitly convey that for the decision). Then Solution components/effects aren't tied to criteria by default, but they can be tied manually in order to convey that the piece is relevant for that criteria. In this way, the criteria table view can be used to get high-level understanding of the different ways that Solutions can be good/bad, then a specific criterion can be drilled into in order to see specifically the pieces of each Solution that are relevant for it.
The intention is that criteria are just ways to evaluate a solution - I don't think the criteria itself are much subjective. E.g. in the open source map "easy to get funding", "minimizes impact of security vulnerablities", these are ways in which Open/Closed source can be good/bad. Criteria are really intended to encompass all the ways that the solutions can be good/bad. The subjective aspect is where you score these e.g. I scored Open Source "fulfills" "Easy to get funding" a 4 vs Closed Source "fulfills" "Easy to get funding" a 7, so I convey that I think Closed Source is easier to get funding than Open Source. And I scored the criterion itself "Easy to get funding" a 7 to convey that I think funding is somewhat important for deciding between the solutions, though I scored "Higher quality software" a 9, so I convey that I think quality is more important than funding. I do realize that this is another complexity of the app that may not be intuitive. If you haven't gone through the tutorial "Viewers > 1b. Evaluating Tradeoffs" that might help.
I see now - "speed bump" is parallel to "stop light" because they share a parent e.g. "cars going too fast". I was confused because I was thinking that the shared parent would be the "30 day implementation" (in screen 2). I also see where this could be problematic with criteria because e.g. if "temporarily requires detouring" has a criterion as a parent (via "fulfills"), then that Detriment would be siblings with all the other Solutions, which doesn't seem like it makes a ton of sense. This is handled in the map view by explicitly putting nodes into layers by node type, potentially the "parallel" idea would use similar logic.
Makes sense, yeah I agree that these are important and the cards at the side seem like a good way of getting to these.
I see
Completely agree
I see this currently as one design flaw that exists. The current layout puts problems on top and solution on bottom, so that details of solutions can explicitly tie to specific details of problems, and these ties are visually in between the problems and solutions. If all solution details were placed below solutions, then they wouldn't be able to nicely tie to the problem details, which lie above the solutions. If only negative solution details (ideally to be addressed) were placed below solutions, well initially that sounds good because they don't often make sense to tie to problem details. But the issue here is that sometimes positive or neutral effects can create Detriments, and showing that relation is very awkward if positive/neutral effects are above the solution and negative are below. Perhaps there could be a toggle to easily switch between viewing details above vs below solutions. It requires some thought. It does seem like UX should be able to allow both of these goals (viewing how solution details tie to problem details, and viewing how solution downsides can be addressed) to be achieved. |
Beta Was this translation helpful? Give feedback.
-
Maybe consistently for all nodes without child nodes. Solution nodes can also have child nodes like Detriments/Subproblem and other types of nodes can also have no child nodes.
Also a good solution. If there's many child nodes one would have to scroll down to see these.
I think a small element (for medium-sized maps not even a large one) is too small for a visualization of the full map, a nearby region could work and one could view the full map or a visualization, like the sunburst diagram, thereof, when tapping on it. I think here even if one could make a sunburst visualization for the map, it would be way too large to show. As for feeling lost without a visualization like that: one could simply navigate backward (upward); more experienced users could also switch to the map view to locate their current node (position).
More or less what I meant with "excerpt of the map that shows its location" too. There would however be the problem that it's a very long chain of nodes: this could be solved by showing just the nearby region but when dragging within the minimap circle, one could navigate upward (it would be reset when navigating to any other node so it looks like image1 again except that the node now open is highlighted somehow like here filled with color green): this could be in a corner if screen is large enough [before and after scrolling upward]
Interesting. Despite of this variability it can still be inferred in another way: if a benefit is connected to a detriment and also via these two nodes' text the user can basically fill in the gap, it may take a bit but generally it's inferrable how nodes relate which doesn't mean those labels aren't needed for ease & learning etc.
Yes, for example it's more understandable for new users and one doesn't lose orientation and things don't change a lot etc. I guess there's advantages to both. But probably better discussed at another time, I think for new users even dimming / using a dimmed view (one could maybe back to normal by clicking on dimmed area) is too confusing and complex.
I think direct interaction / writing to the map is important and that most people interested in this app would like to add things directly to existing maps, not just view or comment maps or create entirely new maps.
I think it may be better to map widely known / present problems for that. Climate change is a great example. When it comes to Kialo, consider that their content is not released under CCBY (at least so far) so it would be good to no copy things 1:1. Rather than constructing maps, I think it needs to make things so accessible that people just create them anew or contribute to wellfindable existing ones.
Oh, right, that's a complication there.
…also later there could be a search where on enters part of the text of the node and it can make one jump to that node. If things are connected across the map maybe one could for a 3 sec or so show the map with an animation of the newly added edge. I think it would probably turn to or would be good to make it the way people learn to use and navigate the map. At start they only use it occasionally to make links between nodes and become increasingly familiar with the full map view this way.
Okay makes sense. I think it's a source for new users to get lost or confused so it could be good to design things so they don't accidentally land on such views and/or to include some hints about the hidden map contents. Outside the scope of this issue though. One way to simplify things there would be to rename "All Breakdown" to just "All" or "All (default)" and to move it to always be displayed at the top of the quickviews.
When a card on the left of the top card is swiped into the view it's loaded into the top card at the same size of the previous top card (top card always has the same size); when a top card only has one parallel item then the partly-visible card on the side of it would be the same size (only not if there's multiple).
By the way maybe it would improve that part a lot if these quickviews were linked on their relevant nodes – for example in the open source vs closed source those quick views could be linked somehow on the respective Benefit node (the criterion node doesn't seem to be visible on the full map?). And/or maybe one could also allow seeing quickviews dynamically, e.g. pressing ctrl+clicking a node = quick view where just nodes connected to that node are on the map (with a button at the bottom of the map to escape the limited quick view).
Ah okay. Maybe one could still create subproblems like "Costs are too high" even when a node is connected to Criterion "Low enough costs" so the cost problem can be addressed (this is just one example). I thought criteria would be exclude nodes even when they are relevant to the problem map but if not that's not a problem.
No, only parallel nodes of the same type would show there. At least that's how I meant it I think as the use of this would be to see alternatives to the current node (other solutions) or further problems/…. However, now I wonder whether maybe parallel node of all types should be viewable somehow (maybe after swiping until the last parallel node of the same type there could be something else on the side by which one could also swipe to other parallel nodes if that has any use / if there's a need for that).
I think those Detriments would be above the solution if tied to positive effects (ie Benefits(?)) – wouldn't it just mean that their benefit is not as large.
Could you give an example of that (with a map link)? I thought solution details like Detriments and subproblems of solutions would be further down. In any case it seems like that should go into a separate issue. I think it's the same issue as the complication of "+ button […] Solution has components/effects as "parents" above it, whereas Problem has cause/effects as "children" below it" – could you make a separate issue or discussion about that so this issue stays focused? |
Beta Was this translation helpful? Give feedback.
-
I suppose it's slightly better that technically all nodes without children could have that UI, but I think Solutions would be the most common, since they're usually placed at the bottom of the diagram.
Yeah if that's the case maybe there could be some UX that let's you jump to them
That's a good point, rather than always showing a full-sized minimap, it may be better to have an easy-to-find button (or smaller-region-view) that shows more when clicked on.
This is always possible but it could be annoying if you have to navigate up a couple times just to get context before navigating back to where you were - as opposed to just tapping a minimap then closing it. (and I suppose an expanded minimap could have benefit over a full map particularly for cases where including text in all the nodes makes it too large for a small screen)
Yeah I like this concept
That's true, I hadn't thought of inferring based on node text. That's probably good enough but maybe not ideal in some cases.
Maintaining orientation and ease-of-returning to the whole-map view sound really nice. I could envision a one-click setting where Quick Views either filter nodes out or just dim them. One uncertainty here is that - you can currently modify filters to reveal research & justification nodes in the diagram, and maybe there are desirable Quick Views with these in them (e.g. I want to see all the facts related to any nodes that are related to the cost criterion)... but how would those work with such a dimming mode? Since those nodes wouldn't be in the default "whole map" view. That might require some thinking.
Except that there needs to be an initial set of people that actually create maps so that there are existing ones for others to add to 😅. I suppose in theory I could make a bunch of existing maps that others are interested in contributing to, and that could be one main avenue for inspiring people to eventually create their own maps.
I enjoy doing these and find them easier (particularly easier to find the problems, and to find information about them) than smaller-scope/narrower problems, but the smaller-scope/narrower problems are often the ones that people have within their power to take action on, so I want to be able to have examples for these too. I think I've seen both of these kinds of maps on Kialo (e.g. for smaller-scope ones, I've seen specific legislative bills laid out in argument form there), though the more broad topics seem generally more popular.
Hmm I didn't think of that. That is slightly annoying, because converting (then potentially adding-to/refactoring) existing content is much easier than creating new content. I read the Kialo terms relating to contributions, and it seems pretty lax: "By posting content to Kialo, you agree to give us a perpetual and irrevocable license to use, copy, display, distribute, and store your content. You also agree to freely license your published content to all Kialo users on the same terms."
One idea could be to alter the view to place the selected node in the center of the screen, in which case there could be a + button above and below the selected node.
Yeah definitely this sounds useful, should be able to share logic with #376
Good idea
That could be good
Will keep this in mind, though I'm hoping that UX can be improved to make them more intuitive to navigate.
I think sometimes though that starting with "All" is too much info for a first entry-point into a Topic. Maybe a high level view (e.g. problem/solutions + 1 or 2 layers) with some better indication of hidden nodes would be sufficient.
Makes sense
Oooohhhh that's brilliant. I'd have to do some investigation to see if this would be performant (I'm imagining that this could show in the Details pane perhaps, but then it'd have to recalculate all Quick Views' filters to see if this selected node is in that view), though I think some refactoring could make it work if it's not good enough currently.
There is already a "show only this node and neighbors" button when you right-click on a node, and technically you can click the "go back" button to return to your last view. Though this functionality could exist in a more intuitive way like you describe.
Yeah if the criterion represents something that someone thinks is important to address, it can be a criterion for comparison purposes and separately a problem for the purpose of addressing.
Gotcha, yeah I think there could be some cases where parallel nodes of different types could be useful to see, but that having the UX show same-types first seems good.
Hmm but I think that, even if Detriments just reduce the value of a Benefit, there could still be value in addressing the Detriment e.g. so that the Benefit is even better.
Yeah the cars-going-too-fast example is like that (at least, now it is, after edits in the last few weeks I think) - where Stop Sign has Component "everyone must stop at intersection", which has Benefit "legally requires people to stop at bottom of hill", which addresses Problem's Cause "bottom of hill has intersection but no legal need to stop". You can also see some Detriments as created by the Solutions' Components I think in the past I've used Criteria more, rather than directly tieing Solution pieces to Problem pieces, but I think there's a lot of value (for precision of communication/argument) in making direct ties like this.
Yeah good call, will do that (will post back with that when I make it) |
Beta Was this translation helpful? Give feedback.
-
Diagrams are pretty hard to read if you're unfamiliar with Ameliorate, especially if they're larger diagrams.
It'd be useful if
This ticket's purpose is to organize all ideas that can make it easier for Ameliorate to be understood by new users, and provide a place to discuss these ideas. Concrete ideas that should be implemented should have their own tickets and be linked to this one.
Specific concerns:
Existing related tickets:
Beta Was this translation helpful? Give feedback.
All reactions