-
Notifications
You must be signed in to change notification settings - Fork 10
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
Comments
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).
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.
This is a good point.
Would have to design UX for this, though it seems very useful for conveying the intent. Might do this separately from the functional change.
Yeah "more information" might be clearer than "notes" |
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.
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. |
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. |
Describe your issue
Solution you'd like
There are multiple possible solutions and these could be discussed here.
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
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
The text was updated successfully, but these errors were encountered: