Replies: 10 comments 16 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.
-
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. (created #582 for this)
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.
-
|
Created separate discussion here for placing Detriments above vs below Solutions #579 |
Beta Was this translation helpful? Give feedback.
-
|
Made an initial attempt at a prototype inspired by this, starting a new comment #541 (comment) for that |
Beta Was this translation helpful? Give feedback.
-
|
Doing some more prototyping for this. Here's an idea inspired by #541 (comment) as a way to navigate the diagram, without the diagram (still requires more fleshing out):
Figma prototype using the free school lunch topic To update:
Good:
Bad:
|
Beta Was this translation helpful? Give feedback.
-
|
Here's another idea, more focused on giving an overview of what's good vs bad about a solution. I think maybe it could be ideal to offer a couple goal-specific views like this (this one doesn't work well from the perspective of seeing all of a problem's details).
Figma prototype using the free school lunch topic Need to update prototype:
Good:
Bad:
|
Beta Was this translation helpful? Give feedback.
-
|
And the last new idea for now, for viewing all the main node types in a diagram. Maybe it could be nice to allow picking which tiles to display.
Figma prototype using the free school lunch topic Need to update in prototype:
Need to figure out:
Good:
Bad:
|
Beta Was this translation helpful? Give feedback.
-
|
I'll have to read up. Briefly, my take on these designs is that they could be useful but aren't the kind of simplified view that most nonpoweruser and new users would like to use; they are still very complex and filled with lots of different things, colors, icons etc. It's cognitively straining to try to make sense of what all of it means. Imagine you were some random Internet user who knows nothing about the site, how cognitively demanding would it be to understand things and know how & want to engage compared to Twitter? There it's pretty self-explanatory, just a list of posts and when clicking it one sees the comments in one column underneath them. I think the main view can't be much more complex than that; all the extra stuff would be accessible via swipes and so on but not be directly on the screen which may be best to think of a small mobile screen where barely three or so nodes fit on. Coming back to this discussion, I couldn't make sense of the design above, like what is the subject – there is no heading and in the upper tile there are different problems; then it's lots of different colors/types instead of just one of these which would be intricate on itself already etc. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah I agree, it's still not super straightforward. I've been thinking the Topic diagrams need some way to draw the eye better as well. I just posted my latest design below #541 (comment) which I think does a little better with drawing the eye/being intuitive. I'm going to be focusing on this til completion now - hoping to refine the design over the next few weeks and get the implementation done in slightly fewer weeks after that. |
Beta Was this translation helpful? Give feedback.
-
|
Here's the latest I've been working on: creating summary views for each node type. The idea is that generally people would have a few different main questions they'd want to answer when looking at a node, e.g. "what is solution X?" "why do we want solution X?" "why wouldn't we want solution X?". So we can make summaries for these main questions, then we can be one click away from going to the diagram, which would be better at viewing the info more precisely i.e. with relations.
Figma prototype using the free school lunch topic There are several questions that still need to be answered for this design:
|
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Diagrams are pretty hard to read if you're unfamiliar with Ameliorate, especially if they're larger diagrams and/or you're on mobile.
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:
Quick Views aren't easily noticedmaybe reducing clutter generally will helpmaybe panes need to generally be sleeker, slightly redesignedExisting related tickets:
Beta Was this translation helpful? Give feedback.
All reactions