Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Text is cut off in nodes #557

Open
prototyperspective opened this issue Nov 4, 2024 · 3 comments
Open

Text is cut off in nodes #557

prototyperspective opened this issue Nov 4, 2024 · 3 comments
Labels
enhancement New feature or request learn app helps people learn how to use Ameliorate needs ux design User experience should be solidified before implementing QoL small change the improves the feel of using the tool

Comments

@prototyperspective
Copy link

Describe your issue

text

Solution you'd like

There are multiple possible solutions and these could be discussed here.

  • The nodes could be a little bit larger if there is more text in them and how large could be configurable (I'd suggest that the default would be quite a bit larger than now; this may either itself not fully solve this or one sets a max-length for these texts so that the text always fits into the node with any additional details going into the Notes of the item)
  • The node could expand when hovering over it
  • The nodes could become bigger and the font-size be decreased up to the max-length of the node text

However, I think for exporting a map, the full text of all items definitely needs to be visible. If you want to export an image version one can't hover over nodes. Nodes with long texts would need to be edited to improve how the problem tree map looks like when shared with others / exported but having a few somewhat larger nodes is much better than just making parts of the text not readable. So just showing the full text when hovering would not be sufficient for that...e.g. an export to image view would adjust the nodes sizes and then one could also have an option whether the full text should always be shown (I would enable that).

Maybe there are more ways this could be addressed.

Alternatives you've considered

No response

Additional context

Mentioned in #535 where @keyserj wrote

My intention was to keep node text small and concise so they can be quickly glanced at to understand high-level concepts. To this end, nodes are fixed size, and extra explanatory text can be included in the node's notes. This is open to discussion. It probably requires some practice for wording/sentence-fragmenting, but I've always been able to word nodes such that their concept fits in the current node's size.

Facilitating users keep texts in nodes short and succinct is good but there still needs to be a way to see the full text.

If text is entered longer than the max-length it should display an error and save the text up to the max length and ask the user to shorten/summarize it and to put any additional info into the notes (Maybe that field was better be called "More information" or "More information and notes" or similar.)

Technical ideas and questions

No response

@prototyperspective prototyperspective added enhancement New feature or request needs review Hasn't been reviewed by a maintainer yet labels Nov 4, 2024
@keyserj
Copy link
Collaborator

keyserj commented Nov 4, 2024

Text is cut off in nodes

As I was quoted, I prefer keeping the nodes small to encourage sticking to "node = concept" not "node = sentence/explanation". But I think UX could be a little more forgiving than the current cut-off + have-to-scroll (scrolling such a small text box sucks).

font-size be decreased

Shrinking font-size to fit the text sounds more appealing to me than increasing node size. This way, if the text barely overflows, the UX is very forgiving, but becomes more discouraging the more text overflows. This aligns with the idea that more overflow = worse for understandability. Doesn't seem like this is a super-standard strategy, but there are a few libraries for this that seem decent here.

However, I think for exporting a map, the full text of all items definitely needs to be visible

This is a good point.

If text is entered longer than the max-length it should display an error and save the text up to the max length and ask the user to shorten/summarize it and to put any additional info into the notes

Would have to design UX for this, though it seems very useful for conveying the intent. Might do this separately from the functional change.

(Maybe that field was better be called "More information" or "More information and notes" or similar.)

Yeah "more information" might be clearer than "notes"

@keyserj keyserj added this to the update #5 milestone Nov 4, 2024
@keyserj keyserj added needs ux design User experience should be solidified before implementing QoL small change the improves the feel of using the tool learn app helps people learn how to use Ameliorate and removed needs review Hasn't been reviewed by a maintainer yet labels Nov 4, 2024
@prototyperspective
Copy link
Author

could be a little more forgiving than the current cut-off + have-to-scroll

Yes, that but also it needs a better way to see the full text than scrolling in a tiny node. This is the main problem: the way to see the full text whenever the text is longer than whatever is the max is not sleek but pretty inconvenient.

but becomes more discouraging the more text overflows

I think if the text gets too small and probably also in general a way to just at least temporarily increase the node size is needed – this is not so much about people reading the problem maps they created themselves but people reading other people's problem maps. It's already a problem if the full text can't be seen by default so it already well signifies there's a problem and facilitates people to shorten the text.

@keyserj
Copy link
Collaborator

keyserj commented Nov 5, 2024

if the text gets too small and probably also in general a way to just at least temporarily increase the node size is needed

Fair point. An easy interactive solution could be to allow hovering to show all the text in a tooltip.

I also see that increasing node size may be the only way to address this problem for a not-interactive screenshot. This just seems like a bit of an annoying thing to support. In theory, maybe you could also increase the screenshot resolution and just zoom in with whatever screenshot-viewing software you're using.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request learn app helps people learn how to use Ameliorate needs ux design User experience should be solidified before implementing QoL small change the improves the feel of using the tool
Projects
Status: No status
Development

No branches or pull requests

2 participants