You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Implementing this might be a workable compromise between two concerns: Enable argument<>premise visual node-merging for visitors when a certain flag is included in the url (to maximize simplicity/new-user-friendliness), but disable it for editors (to reduce the chance of structural misunderstandings and thus mistakes, as has been seen in the past with merging).
General notes:
If an "end-user" who followed the link "upgrades" into an editor (eg. signing-in -- perhaps also requiring that they have editing rights), then debate-map can remove that url-flag, and revert to the regular/"structurally accurate" display mode.
If a node is somehow "too complicated" for the simple-tree display-mode (eg. if it has showable relevance arguments), that individual argument-node can revert itself to regular display-mode.
For the url flag
Will probably extend the "?extra=X" url-flag system to allow multiple flags in the same url-param, eg. "?extra=sl,st" (with "st" standing for "simple tree").
For tree-rendering implementation
We could re-use the "child upshifting/extracting" rendering-logic that was used previously (the key step in its removal can be seen here), however it has a couple drawbacks:
Makes the logic relating to the rendering-tree more complicated in some places. (eg. assumptions about ancestors/descendants)
Makes it unclear how the user would be able to quickly view information about the argument-node specifically, right-click it, etc. (which is important in some cases, eg. you've shared a link with a friend, then realize you need to show them some info about the argument node specifically and don't want the only option to involve instructing them on how to change to a different display structure just to see that one little thing)
Since the SL maps do not use relevance arguments (virtually never anyway), another option (which I'm leaning toward) is:
Tweak the styling of NodeBox for the to-be-merged argument nodes. (to match with the "prefix" toolbar-item)
As part of the above, hide the "expand children" arrow at right of argument-node. (not a problem since this mode's only used when there are no relevance-arguments to show there anyway)
Remove the line and gap to left/top of the single-premise. (so that argument-node's box and premise-node's box are directly touching, making the argument node look just like the "prefix text" box at left of a standalone node's toolbar)
Add+use a way to instruct tree-grapher to adjust the line that ends at the argument node to instead end at the premise node's location.
The main reason I prefer this route is that it leaves all of the same UI elements in place (so no actual reduced functionality, other than just lack of structural clarity, which is okay for true first-time visitors) -- it just "makes things fit together more seamlessly" (ie. fewer separated boxes and lines), so that the end-user doesn't have to think about the difference/separation between argument and premise (which is important in some cases, eg. for editors, but not in the typical SL first-time-visitor scenario).
The text was updated successfully, but these errors were encountered:
Venryx
changed the title
Possibly add an "SL end-user display mode" eventually (open for details)
Possibly add a "simple tree" display mode (eg. for SL end-users) eventually (open for details)
Dec 7, 2023
Summary
Implementing this might be a workable compromise between two concerns: Enable argument<>premise visual node-merging for visitors when a certain flag is included in the url (to maximize simplicity/new-user-friendliness), but disable it for editors (to reduce the chance of structural misunderstandings and thus mistakes, as has been seen in the past with merging).
General notes:
For the url flag
Will probably extend the "?extra=X" url-flag system to allow multiple flags in the same url-param, eg. "?extra=sl,st" (with "st" standing for "simple tree").
For tree-rendering implementation
We could re-use the "child upshifting/extracting" rendering-logic that was used previously (the key step in its removal can be seen here), however it has a couple drawbacks:
Since the SL maps do not use relevance arguments (virtually never anyway), another option (which I'm leaning toward) is:
The main reason I prefer this route is that it leaves all of the same UI elements in place (so no actual reduced functionality, other than just lack of structural clarity, which is okay for true first-time visitors) -- it just "makes things fit together more seamlessly" (ie. fewer separated boxes and lines), so that the end-user doesn't have to think about the difference/separation between argument and premise (which is important in some cases, eg. for editors, but not in the typical SL first-time-visitor scenario).
The text was updated successfully, but these errors were encountered: