Enable suggesting nodes for maps

[prototyperspective]

Describe your issue

When people find this software or its website, I think the first thing interested ones will do is trying to find an example map and opening it and then checking out the features. However, in these maps most features are not enabled because presumably "Allow anyone to edit this topic" is not checked in the debate settings. Moreover, just enabling that could also be a problem due to spam and vandalism. Currently, one can only add comments which makes it seem like that is all the features implemented as of now.

Solution you'd like

Please enable all features for registered users but when they add anything to maps which do not have this "Allow anyone to edit this topic" setting checked add isSuggestion=true to the the nodes and connections they create. Then, moderators could accept them in. If they are not yet accepted only the person who submitted them can see them as well as admins/mods if a setting to show suggestions is checked (these tiles could have another color).

Alternatives you've considered

No response

Additional context

One could also make it so that e.g. only people who successfully submitted e.g. >50 items can add items directly and have all public maps have the editable setting enabled (otherwise it can only be unlisted or private). Things like that could be thought about later. I think it's important to enable people learning about this software to be able to explore its features and not think that they can only add comments. Facilitating that new users rather add comments than new tiles may be a good thing to do but that can also be worked on later such as prompting them to add comments if they have any questions or issues with any of the items already on the map.

On Kialo, every debate has admins (at first only the debate creator) who must check and accept every claim. However, I think that design is not ideal. It has some advantages such as enabling setting a quality standard by requiring people submitting Pros & Cons to e.g. add sources or at least coherent explanations before things are accepted and weeding out entirely unrelated things but in practice many debates turned stale once the admins became inactive or don't accept valid claims in somewhat biased ways. There are further downsides. So this issue is not about making ameliorate implement a very similar design where all contributions have to be accepted.

Technical ideas and questions

If the suggestion has a wrong format, e.g. it's a "Problem" when it should be a "Detriment" and all the differences between the different types isn't yet that clear to me and probably most (especially new users), the mods could change the tile type. There could be a changelog for every tile where one can see who created and changed it and what the changes are (e.g. changed text with diff or changed format from "problem" to "detriment" etc). This is really important for several reasons but maybe it should go into a separate issue and I suggest Wiki tech is used so this could look like the History page of Wikipedia articles just much simpler.

[keyserj]

I think #11 covers most of the ideas in this issue - going to add the new ideas to that one and close this ticket as duplicate. Let me know if you think there's reason to reopen/keep this separate.

---

Currently, one can only add comments which makes it seem like that is all the features implemented as of now.

Please enable all features for registered users but when they add anything to maps which do not have this "Allow anyone to edit this topic" setting checked add isSuggestion=true to the the nodes and connections they create.

I think that edit features, while their UX could probably be improved, would add more complexity to the UX for new users. But this and your concerns here might all be addressed by adding something like Google Docs's mode component, where it's explicit which mode you're in (editing/suggesting/viewing) and you can easily switch between the ones you have access to:

One could also make it so that e.g. only people who successfully submitted e.g. >50 items can add items directly and have all public maps have the editable setting enabled

That's a good idea, I hadn't considered that. Maybe couple that with the creator's ability to remove edit access from people (in case someone contributed a lot but then started abusing) and history/loading a snapshot of history (#371) (to save the day if there's abuse). Maybe forking would also be a separate way of addressing the issue.

I think it's important to enable people learning about this software to be able to explore its features and not think that they can only add comments.

Yeah that's a good point

So this issue is not about making ameliorate implement a very similar design where all contributions have to be accepted.

Is the main desired difference in design to have is the automatic edit access after X contributions? It seems like the other aspects of Kialo's design seem reasonable, like requiring contributions to be accepted seems always preferrable when trust is not built, unless users are explicitly given access.

If the suggestion has a wrong format [...] the mods could change the tile type.

This would always be possible after accepting the change, though maybe for history's cleanliness, changing before accepting might be slightly preferred? In any case, that's probably lower priority.

There could be a changelog for every tile

Yes definitely agree. Have #371 for that

I suggest Wiki tech is used so this could look like the History page of Wikipedia articles just much simpler.

By "Wiki tech" do you mean that there's some tooling from them that can be used to add history? Or just that it'd be a good design to take inspiration from

I think it's a good start, and that Ameliorate should be able to have a simpler version. I also appreciate GitHub's commit history design, though it's not as trivial to compare the diff between two commits.

[prototyperspective]

I think https://github.com/amelioro/ameliorate/issues/11 covers most of the ideas in this issue - going to add the new ideas to that one and close this ticket as duplicate.

Thanks! Seems good.

I think that edit features, while their UX could probably be improved, would add more complexity to the UX for new users.

I think there is far too much complexity but it can and would need to be reduced in ways other than making the key core features of the software not available to new users and only allowing them to make notes. The complexity can also be lower than full-permissions editing in various ways such as only allowing them to make connections or new nodes without being able to specify which kind of node (like problem) or relation these are. They could then be introduced to these different types of nodes and that may be good anyway since I also don't yet understand the difference all between the different types of nodes for example.

So I don't think it would be a good idea to have a Viewing only mode enabled by default – that mode could however still be useful for the view shown to signed out readers and maybe the reduced-complexity view (such as for getting familiar with a problem-tree or just exploring it or exporting it).

Maybe couple that with the creator's ability to remove edit access from people (in case someone contributed a lot but then started abusing) and history/loading a snapshot of history (https://github.com/amelioro/ameliorate/issues/371) (to save the day if there's abuse). Maybe forking would also be a separate way of addressing the issue.

All good ideas. One could also get some ideas or inspiration how things are done on Wikipedia/Wikimedia sites. People can edit most pages except for a few that got vandalized often where they need some small minimum number of edits and days since account creation coupled with features like Watchlist where people can notice problematic changes and revert them or block/warn the user. I don't know if problems trees have a history yet but I'd suggest something like the MediaWiki page history where one can revert any changes. FYI one can also fork argument maps on Kialo "clone" them and link or copy a branch of one map somewhere in another debate (both features are rarely used but they're underused and require special permissions that usually only a few debate mods have).

Is the main desired difference in design to have is the automatic edit access after X contributions?

Yes more or less. There is another site that is not offline for argument maps Wikidebate and there people can make contributions right away. Problematic changes are reverted after the fact and it's the same on Wikipedia albeit there are now bots that quickly detect maybe 50-75% of vandalism/problematic changes. Partly because the site is smaller and less frequented by potential watchers or similar, I think having initial contributions be only 'suggestions' that have to be approved is preferable.

Once they have contributed enough items that have been accepted and reached a certain time since registration, they are probably also more familiar with the site and potential policies and norms and due to the many contributions can be better checked in regards to whether they contribute constructively (they have an contributions history) so after that point any potential issues could also be solved like on Wikimedia sites where things are fixed afterwards instead of having everything be slow and require approval.

[mods could change the tile type] This would always be possible after accepting the change

Sure, wasn't suggesting it's approved before or after accepting the change. I think it would probably be best if it was edited before accepting but both could be made possible anyway since items probably often need to be edited at a later point. If the item was edited (e.g. the type changed) by a mod before getting added in by a mod, the History log of them would show for example:

• new-user [datetime] added new node as suggestion
• mod-name [datetime] set node type to problem
• mod-name [datetime] edited description [click here to see diff]
• mod-name [datetime] approved suggestion

By "Wiki tech" do you mean that there's some tooling from them that can be used to add history?

I mean wiki technology and ideally something like that could be used and not just for inspiration. Every node would be a wiki page with its own History page that can be edited like wiki-pages. However, I don't know if there's small module one could use. Btw reddit also has Wiki pages in subreddits. For example, see Wiki.js https://github.com/Requarks/wiki Adding the entire thing as a dependency and enabling all its markdown in every node (and maybe some meta pages) would be too much – I may check later if there's some lightweight package one could use. It may even be possible to have the Watchlist feature for example through that where you track all changes of problem trees you have on the Watchlist including diffs of edited items.

[keyserj]

I think there is far too much complexity but it can and would need to be reduced in ways other than making the key core features of the software not available to new users

Yeah that's a good point.

The complexity can also be lower than full-permissions editing

Also a good point

make connections or new nodes without being able to specify which kind of node (like problem) or relation

I currently have the perspective that the node types are valuable enough for newbies to learn about. One of the main purposes of the tool is to help people get on the same page about problems/solutions, and I feel that being explicit about the kind of thing being discussed is a huge help towards that end. Additionally, as someone who knows all the node types, I've actually appreciated the "framework" as a means of thinking about the topic. E.g. oh there aren't any detriments in this map - are we actually in agreement already about why this topic's problem is a problem? Also, since certain node types generally are associated with certain other node types, they help give structure to the topic as a whole, and build expectation for what related nodes to expect.

Given this perspective, my initial reaction to your comment is - can anything be done to make it trivial to understand the node types? You should check out ontology if you haven't yet. I recognize though that expecting users to go to that topic is not something that's ideal as a prerequisite to interacting with a map (e.g. if someone shares a map with you and you've never used Ameliorate, it'd be nice if you could tell what you're looking at without spending several minutes or more just learning about the tool).

One thing I could envision actually, is expecting maps to be trivial enough for a first-timer to view and understand, but expecting a first-timer to go through a short effort (~1 minute) to be able to effectively make suggestions. If you haven't checked out the tutorials, they're here:

and my intent was that "2. Breaking down a problem" covers the node types pretty quickly.

I don't think it would be a good idea to have a Viewing only mode enabled by default

I do see your point about suggestion mode being a good way to encourage new users to start contributing and get more involved with the platform.

how things are done on Wikipedia/Wikimedia sites

Yeah these ideas seem good. I think generally an Ameliorate topic could have different levels of restriction - basing off of credibility/vandalizing seems good, but also I think based on the author's intention. I could see someone wanting to be more restrictive/opinionated about what they want in their topic, but perhaps that would just have less respect in a way, as a more-biased topic.

On a related note - I think Ameliorate is good for Wikipedia-like topics, where the topic is intended to be thorough, maybe be "official"/not duplicate with any other Ameliorate topics, and consistently be updated for the long-term. But a core purpose for Ameliorate is also for shorter-term topics - where you might have a problem you're trying to figure out what to do, you want to align with someone or a group, so you make a topic and use it over the course of like a few weeks, then a decision is made and the topic doesn't need to be revisited (unless something major changes and decision needs to be re-made). I think shorter-term/smaller-group topics might have different preferences for suggestion behavior than longer-term/Wiki-like topics.

require special permissions that usually only a few debate mods have

Oh I actually didn't know that. Good to know

Wikidebate

Had not heard of this, also good to know. Interesting strategy.

I mean wiki technology and ideally something like that could be used and not just for inspiration

Added to #371 to look into the possibility of Wiki tech. It would certainly be cool if that were possible to reuse.

[prototyperspective]

Thanks for explaining! Yes, maybe it's good if new users need to learn and specify the node type. The problem is not with understanding node types but there's so many of them and some of them are quite similar (+ people may forget the nuanced distinctions; e.g. when to use Detriment and when Problem). The ontology example map I think helps best. I think the best solution would be to ask for the node type to be specified but also accept node-suggestions where the type is unspecified but allowing mods to simply change the node type before adding a newcomer's node in would essentially solve this anyway as well.

As for the number of node types: I doubt that having a node "Effect" is helpful, things should probably only be added if they specify/explain why something would be positive or negative. It only makes things harder to understand and fills the map with more items that make it harder to oversee. E.g. Air pollution can have Effect particles in atmosphere which has Benefit short-term cooling and Detriment health issues etc – just adding the latter two or so would usually be better. An optimal approach would be to allow advanced users to link things to effects but to not show the effect nodes on the map by default, maybe sometimes having things categorized like that can indeed be useful. I think elsewhere I already argued that having a separate Criterion node may not be good as it just blocks potential solution and makes the map some opinionated one-of-many narrow essay instead of something like a one-comprehensive-only Wikipedia article about a subject – problems of solutions could be specified via problems to these and via the ratings so I don't see much use in the criterion nodes but several large problems. Here again the solution may be to allow users to configure criterions somehow but to not show them on the map by default. Also I don't see why Detriment is used below a problem instead of a problem that is about why a problem is a problem. Maybe Detriments would be better just Problem nodes, in this case: Detriments of the top-level problem I think it would be better if the "Problem" type was used since if you can solve all individual subproblems of a problem you either solved the main problem or you don't need to solve the top-level problem. However, this may best go into a separate issue or discussion about node types.

I think based on the author's intention. I could see someone wanting to be more restrictive/opinionated about what they want in their topic

Yes, I think it would become biased, restrictive, misleading etc – e.g. if I go to a problem map about the demographic transition problem according to the title, I wouldn't expect that certain kinds of subproblems or reasonable solutions (like labor demand reduction methods) are excluded for ideological reasons or because the mod happens to not like some nodes. There may also be value in having quite restrictive maps or narrow maps...I would suggest something like different namespaces is implemented where one namespace is the public sphere where the problem is discussed in the sense of 'one problem - one comprehensive map' and one namespace where people can e.g. set criterions or make the map more narrow etc. E.g. "Problem:Demographic transition" and for the latter "Collab:Demographic transition" or "Collab:How to actually solve demographic transition problems". People could for example find these collab maps via the problem map or invite people from there, there could even be different collab maps for different factions who come up with different ways to address a problem and the collab maps would somewhat also shape the main map and vice versa by kind of 'merging' in their solutions and nodes into this broader more comprehensive map.

But a core purpose for Ameliorate is also for shorter-term topics - where you might have a problem you're trying to figure out what to do,[…]

Makes sense. I think this Collab namespace or a third namespace could also be used for these. One could then also browse them separately. (Most people would mainly just browse and contribute to the main mainspace.)

[keyserj]

ask for the node type to be specified but also accept node-suggestions where the type is unspecified but allowing mods to simply change the node type

That might be good enough.

I doubt that having a node "Effect" is helpful, things should probably only be added if they specify/explain why something would be positive or negative

I think that even if an effect isn't directly positive/negative, it can still be good to call out. For one, understanding a full causal chain seems important, rather than just understanding the good/bad effects. If there's an Effect in between a Component and a Benefit/Detriment, people might not understand how the component creates the Benefit/Detriment without the intermediate Effect. This is similar to why you'd want to look at root causes. Root causes might not be inherently good or bad but can be a target of change in order to remove the negative (and positive) effects downstream. Secondly, it may not be clear if an effect is good or bad yet, but someone can still suspect that the effect is significant, in which case it seems good to model via node (and worth potentially being shown in a default view).

It only makes things harder to understand and fills the map with more items that make it harder to oversee

I feel that this concern is better addressed by either manual filtering via Quick Views (I hadn't thought of this before but I think Quick Views could be community-built too, for wiki-style maps), or by filtering out nodes by importance score.

having a separate Criterion node may not be good

For context, I responded to this within this comment (near the bottom) https://github.com/amelioro/ameliorate/discussions/541#discussioncomment-11082569

Maybe Detriments would be better just Problem nodes [...] since if you can solve all individual subproblems of a problem you either solved the main problem or you don't need to solve the top-level problem

Similar to what I said here https://ameliorate.app/examples/climate-change?comment=moDkjpJKysC4JqAPD6uZpb, Problem is used to highlight core problems for the Topic. A Detriment justifies why a Problem is concerning, but in itself is not a core Problem (within the context of the Topic). If we want to convey that the Detriment is a concern independent of the Problem i.e. even if the Problem is solved, and we want to highlight that within the context of the Topic, then we could use a Problem instead of a Detriment. But if the main purpose of modeling the Detriment is to convey why a Problem is concerning, then use the Detriment node type.

If you're interested in discussing this in more detail, yeah I think a separate GitHub Discussion would be good for that.

something like different namespaces

Something like this might work, I hadn't considered that. It also might be possible to break up the "Public" type of Topic into two, where both are intended to be open to the public but one is intended to be Wiki-like and the other would welcome contributions but is more opinionated/restrictive. I'd have to think about it more to understand tradeoffs between using namespaces and the Topic type for this.

find these collab maps via the problem map

I think being able to specify related maps would be good.

different factions who come up with different ways to address a problem and the collab maps would somewhat also shape the main map and vice versa by kind of 'merging' in their solutions and nodes into this broader more comprehensive map

This sounds similar to #13, which I'm a big fan of, though it seems pretty far in the future, so I haven't fleshed it out much.

[prototyperspective]

I think that even if an effect isn't directly positive/negative, it can still be good to call out […]

Totally see that, it's just that I think the burden should be higher to put things on the map when it comes to effects so people need to make the effort to identify potential negative and/or positive aspects from that effect instead of only adding the effect. It requires more thought but it makes the map more useful and the same things can ultimately be on the map, people just need to work out the negative and positive aspects. When an effect is beneficial the info about the effect is put into the node about the Benefit. In the example, 'Air pollution has Benefit of short-term cooling' is a claim directly instead of being put after some intermediary node, having intermediary node that is linked to multiple nodes is not a good thing in itself. Actually I think it would be best to try to / aim for reducing the number of nodes so things are as condensed and overseeable as possible. One could say there should links between two nodes that are related via sharing some effect but I think they are already quite close if they're simply linked to Air pollution. However, it could well be that you're right on this but I think it's worth keeping in mind that the Effect node type may be somewhat redundant and problematic – I need more experience with the actual maps to say more about that. It could be that the best solution would be to allow people to add Effects and to link nodes to effects but to have these not be displayed by default, it's like a Detail view so to say.

manual filtering via Quick Views

The filter showing least items on the maps would be most useful for people new to the platform who are most likely least aware and capable to use any filtering options. I think the default view would best filter away a lot and there is a well-visible button directly on the map (not any sidebar) to hide all branches below a certain score (based on at least 2 ratings).

A Detriment justifies why a Problem is concerning, but in itself is not a core Problem (within the context of the Topic)

Still it seems like quite difficult if not often impossible to clearly distinguish between Detriment and Subproblems. It's a subproblem of air pollution that it causes health problems, if somebody invents some magical fluid of nanobots that fully cleanse your body that everybody can afford and take daily, then Air pollution wouldn't be a problem assuming it doesn't cause other problems. That it causes health problems is the problem caused by air pollution. The sum of problems caused by a node is why it's a problem at all. What would be the use of setting things to the Detriment node type? What is a core problem and what's just a problem? Even if it makes semantic sense somehow that doesn't mean it's useful to make this very nuanced distinction in the map. That topic could also be revisited at a later point but I suspect making things simpler is more useful than trying to capture every nuanced distinction even if these are reasonable.

where both are intended to be open to the public but one is intended to be Wiki-like and the other would welcome contributions but is more opinionated/restrictive

Something like that would be great.

[keyserj]

'Air pollution has Benefit of short-term cooling'

As a note, I would put this into two nodes. One for air pollution (maybe a component, effect, or detriment, depending on the context of the Topic), then that "creates" the benefit: "short-term cooling". Yes "pollution create short-term cooling" is one claim, but breaking it down further allows independent discussion about importance of "short-term cooling"/"air pollution"; and the initial claim would be implied by the "creates" edge.

instead of being put after some intermediary node, having intermediary node that is linked to multiple nodes is not a good thing in itself

Intermediary nodes enable a more precise/clarified discussion, because if there indeed is an intermediate cause/effect, then it will be ambiguous whether we're considering that the root cause causes the intermediary vs whether the intermediary causes the final effect. If the root cause causes the final effect separately from the intermediary cause, then there can also be a direct edge from root cause -> final effect to specifically discuss that relation without the intermediary.

it would be best to try to / aim for reducing the number of nodes so things are as condensed and overseeable as possible

UX should be able to do this without forfeiting the ability to have more precise discussion, e.g. via hiding low-score nodes/relations.

I think it's worth keeping in mind that the Effect node type may be somewhat redundant and problematic

allow people to add Effects and to link nodes to effects but to have these not be displayed by default, it's like a Detail view so to say

I do think the diagram is particularly good at showing cause/effect relations vs relying on a detail view, but I'll keep these ideas in mind and think about it as I continue using the tool more myself.

default view would best filter away a lot and there is a well-visible button directly on the map (not any sidebar) to hide all branches below a certain scorej

I agree that more could be filtered out, and that the UX needs to be able to make it more intuitive to do simple-but-common filtering.

Still it seems like quite difficult if not often impossible to clearly distinguish between Detriment and Subproblems

What would be the use of setting things to the Detriment node type? What is a core problem and what's just a problem?

Perhaps the better explanation is: if the Detriment's Problem node is solved and you still care about the Detriment (within the context of the Topic), then it should be a Problem, not a Detriment. If solving the Problem means you don't care about the Detriment (within the context of the Topic), it should be a Detriment. And if the Detriment is still important after the Problem is solved, but it's no longer relevant for the Topic, then the Detriment should probably just have its own separate Topic made (and be a Problem in that).

Within the context of a Topic, it's satisfactory to solve all Problems, but it's not necessarily satisfactory to solve all Detriments (unless there's confidence that all possible Detriments are explicitly specified in the Topic).

Under this definition, typically there are one/few Problems, and more Detriments. This makes it easier for a reader to know where to look/focus when navigating through a Topic: start from Problems, only need to look at Detriments to better understand "why should I care about these Problems".

[prototyperspective]

As a note, I would put this into two nodes.

Then that would kind of support the case for doing something about the Effects node type: these two nodes could be linked to a third effects node type and it seems arbitrary / inconsistent when to link them to such an effect node and when not. Of course air pollution would be a node – I argued the effect node underneath an air pollution node wouldn't be helpful/good.

Intermediary nodes enable a more precise/clarified discussion

Consider that 1. precision could be improved much more if there were e.g. 100 nuanced types and connections but higher precision is not necessarily needed or beneficial overall 2. the same level of precision can still be there via the comments, justifications, critiques, etc of the nodes – just not directly on the map 3. it also reduces precision by changing what nodes are connect to – eg it could make more sense if they are connected to the air pollution node rather than intermediary nodes like "Novel [reflective] particles in atmosphere".

UX should be able to do this without forfeiting the ability to have more precise discussion

Yes but I think this ability is still there if the nodes are more directly connected. Making it possible to show the map with either with or without certain intermediary nodes could be best. Also I need to use the site more before I could say more about whether I think Effect nodes are generally either redundant or convertible to another node type. Just wanted to note that this ability would not be forfeited by not having this node type – one would simply discuss matters on the other items and possibly add nodes based on that.

showing cause/effect relations

Yes but they don't necessarily need the Effect node type, e.g. only effects that are relevant to the Problem subject are relevant so it would be kind of out of scope to include random other effects; same for Effects that are not related or kinds/parts of solutions or subproblems.

I agree that more could be filtered out, and that the UX needs to be able to make it more intuitive to do simple-but-common filtering.

Great.

it's satisfactory to solve all Problems, but it's not necessarily satisfactory to solve all Detriments

Don't yet really understand it but I think I simply need examples for that and more experienced editors could change the node type of others to get back to the issue's topic: they could suggest it in one way and then reviewers could change the type if inaccurate; if a node has a flawed type after approving it can also be edited by more experienced contributors. I do have doubts whether this would make it easier rather than more difficult/complex to understand maps though and for examples where I've seen the Detriments node type used think subproblem would be a better fit as it's the problem that causes the problem above to be a problem where if some were solved the problem above would be reduced in severity and if they all were then the problem itself would be solved (assuming no notable subproblems are missing). If a certain level of climate change like 2.5°C had no notable effects on human migrations, conflicts, economics, and health then it wouldn't be a problem so if you solve these subproblems in ways that have not large subproblems (or detriments?) like extremely high costs then it would itself be solved in terms of the problem it poses.

[keyserj]

it seems arbitrary / inconsistent when to link them to such an effect node

It's a similar arbitrariness to when you should create a Component for a Solution, or a Cause between two existing Causes. I suppose it's more arbitrary than creating a Benefit between two Benefits, because Benefits have value merely by conveying an additional distinct good thing, whereas the extra Effect/Component/Cause nodes have value by their additional accuracy/precision of modeling reality, and therefore enabling more accurate/precise discussion of it.

Of course air pollution would be a node – I argued the effect node underneath an air pollution node wouldn't be helpful/good.

My bad, I had forgotten some of the context of our discussion.

precision could be improved much more if there were e.g. 100 nuanced types

I agree that there's a limit to the value of precision, but right now we have 9 breakdown node types (cause, problem, criterion, solutionComponent, effect, benefit, detriment, solution, obstacle - maybe remove criterion and consider subproblem an additional one) which doesn't seem like too much (by quantity of types at least).

the same level of precision can still be there via the comments, justifications, critiques, etc

I think the first comment/justification/etc can match precision with some cost of brevity (because the causal nature would have to be noted explicitly in words rather than via node type/relation), but responses to that lose precision because there's no longer the ability to score/justify/comment-on specifically the causal aspect (via the two additional edges) separately from the concepts/nodes involved.

I suppose in theory you can always be precise by adding more words, but it gets harder and harder, and I feel there's an argument to be made that some precision is inherently lost whenever you have to use more words to convey the same thing.

it could make more sense if they are connected to the air pollution node rather than intermediary nodes

In this case it seems like the Effect of "particles in atmosphere" is more of an additional description of pollution, rather than an effect, because pollution is particles more than creates them. I think a better example might be something like this:

where the Effect answers the question of "how?". Without "particles reflect sun", I could see there being confusion about how air pollution creates cooling. Even if we didn't know a specific Benefit/Detriment yet, this Effect seems like it could have other effects (that could be positive/negative) if we look into it more.

Actually, this example illustrates to me another advantage of the explicit causal relation. You could replace the Effect "particles reflect sun" with a Support on the "short-term cooling - created by - air pollution" edge, but then if you wanted to be accurate, you'd also have to put that Support on the "less sunlight - created by - air pollution" edge. And it wouldn't be as easy to separately discuss "do particles actually reflect the sun?" vs "does reflecting sun create cooling?" vs "does reflecting sun reduce plant growth?"

Making it possible to show the map with either with or without certain intermediary nodes could be best

Yeah there's always the ability to hide nodes

I need to use the site more before I could say more about whether I think Effect nodes are generally either redundant or convertible to another node type. Just wanted to note that this ability would not be forfeited by not having this node type

The discussion is always open if you think of more later. I think it's good to note that technically the point of Effects can still be communicated without them, but I currently think that discussion can be easier with them.

reviewers could change the type if inaccurate

True

(assuming no notable subproblems are missing)

If a certain level of climate change like 2.5°C had no notable effects on human migrations, conflicts, economics, and health then it wouldn't be a problem

I think the assumption is an important point here. If a Problem is missing Detriments, and there's disagreement about whether or not it's a concern, it's a much bigger deal. The author needs to think about it until they can justify it, otherwise maybe the Topic isn't even worth discussing at all. But if a Detriment is missing Detriments, and there's disagreement about whether or not it's a concern, perhaps the author can't think of anything and they just delete it or change it to an Effect. That Detriment was not the core concern for the Topic, so it's not a big deal. Maybe there are other Detriments to justify the Problem.

[prototyperspective]

It's a similar arbitrariness to when you should create a Component for a Solution, or a Cause between two existing Causes. […] whereas the extra Effect/Component/Cause nodes have value by their additional accuracy/precision of modeling reality

Not sure about it yet but I think I disagree: the latter are added when they're relevant to the problem map. The relevance of an Effect-type node to the map/context is inherently unclear. I think the burden to find out how and specify how something relates to the map context should be on the person adding the node. That's why I think the Effect node type is redundant to the others as no other Effects than those known or argued to actually be relevant are good to include in the map (they can be added as soon as somebody figures out how it relates to the map and prior to this can of course still be discussed via comments etc). Even more, if people put nodes underneath the Effect node then that just creates large segments of offtopic branches.

which doesn't seem like too much (by quantity of types at least).

I think it would be best to have just the problem-type not an additional subproblem one (and if there's one then it could be set automatically in some way eg when a problem node is directly underneath another problem node). I think 9 types is many for most users. Kialo has 3 types: Pro, Con and Hypothesis (the latter only included once in most maps and a just a few times at the top-level at multi-thesis argument maps). Argüman also had 3 node types: because, but, however. The issues can be solved to a large degree if node types can be and regularly are changed or specified by experienced users.

no longer the ability to score/justify/comment-on specifically the causal aspect (via the two additional edges)

That's more a feature than a problem: it's unclear what ratings mean if it's a neutral/unclear effect node and it would be best to not enable ratings when it's not clear how the node relates to the subject (in terms of problem/solution/detriment of x severity/impact/importance).

because pollution is particles more than creates them

Makes sense but I meant reflective particulate particles, should have made it clearer. Chemical molecules like CO2 are also particles but that's not what I was referring to. Your example is helpful. I tend to still think connecting them directly would be better. That is having a Benefit node linked to a probably useful component node "particulate air pollution" like "Reflective particulate pollution reflects sunlight causing short-term cooling" and a Detriment node "Reflective particulate pollution reflects sunlight which may cause agricultural problems in some regions".

Without "particles reflect sun", I could see there being confusion about how air pollution creates cooling

Indeed but it would be in the node as described above.

this Effect seems like it could have other effects (that could be positive/negative) if we look into it more

I think the optimal thing to do for such cases is to put the burden on the people seeking to add it to research this and find out and/or specify relevance. This is to facilitate this work to be done and for the map to stay ontopic, condensed, and relevant etc. Otherwise maps will just be overcrowded but of low-quality and of little use.

but then if you wanted to be accurate, you'd also have to put that Support on the "less sunlight - created by - air pollution" edge.

Another problem with having the intermediary Effect node that I just noticed is that it has a combined rating on the edge above the "particles reflect sun" Effect above the Benefit and Detriment – this means people need to consider the two in combination instead of rate them separately how it relates to the problem node and I think this is a redundant rating that will be very difficult to rate or interpret and it makes little sense to combine the ratings that way.

And it wouldn't be as easy to separately discuss "do particles actually reflect the sun?" vs "does reflecting sun create cooling?" vs "does reflecting sun reduce plant growth?"

The only change is that "do particles actually reflect the sun?" would have two nodes where it can be discussed instead of one. I don't think that's a problem, especially as people don't watchlist/track individual nodes but changes to the entire map. If they do not reflect the sun then both nodes would be removed (or flagged or rated low). How much of an effect it has varies per the two nodes so subnodes would have to go beneath each/either anyway rather than beneath the Effect node.

Maybe it would be good to put this into a separate discussion about the Effect node type.

Yeah there's always the ability to hide nodes

Does it cause the nodes then to be connected directly? In your example the Detriment and Benefit directly to Problem. That's what I mean – not that it would hide the entire branch underneath the Effect node.

but I currently think that discussion can be easier with them.

Assuming the discussion becomes easier with them that doesn't mean the overall problem map becomes easier. Maybe the discussion of some things becomes a bit easier (let's say +3) but the overall subject map becomes harder to understand/navigate/explore/interact with (eg -5) which would still mean the map would be better without these nodes.

I think the assumption is an important point here

Yes of course, I meant this on a conceptual level: hypothetically if the problem has all the subproblems/detriments included and all of them are solved then it's not a problem. Usually either or both of these are not the case.

But if a Detriment is missing Detriments, and there's disagreement about whether or not it's a concern, perhaps the author can't think of anything and they just delete it or change it to an Effect. That Detriment was not the core concern for the Topic, so it's not a big deal. Maybe there are other Detriments to justify the Problem.

I think you meant "Problem is missing Detriments". (If so:) if a problem has no subproblems or no (largely) unsolved subproblems then that doesn't mean it's invalid and/or should be deleted but that there's a greater likelihood something is missing or that the problem is solved/nonexistent. I think having a separate "Detriment" node type doesn't improve that part and having it be subproblems would standardize and simplify things more, e.g. in terms of Problem-solving mindset/structuring/thinking/activity, not sometimes-Problem-solving-sometimes-Detriment-addressing.