One often needs to write some background info to code but one needs to keep the overview. Therefore comments cannot be as large as their content. Currently XOD truncates the comment content if the comment size is not large enough without any hint for the reader about the truncation. This is a problem.
Solution
Add a scrollbar to comment nodes. This way users see that there is more in the comment than currently shown and they can either scroll through
Thanks for the feedback. I’ve never had a desire to have comment content bigger that it can contain. I believe it can be handy in some cases though.
The problem is in the solution proposed. It has a serious flaw. The regular scroll bar will make mouse wheel rotation (or two-finger touchpad swipe) ambiguous and modal. Should it pan the patch board or scroll the comment now? Depending on the cursor position we get wildly different effects. Effectively, we create a scrolling container inside a scrolling container. This is a bad UX.
I’ve never had a desire to have comment content bigger that it can contain.
I am coming from the world of LabView. There you usually have more comment content than actual code. This is normal and my former bosses even pushed us to document each and every bit and now, with some years experience I see how valuable proper documentation is in real life applications.
So if XOD should be an application for real life projects filling comments with lot of info is definitely necessary.
The regular scroll bar will make mouse wheel rotation (or two-finger touchpad swipe) ambiguous and modal. Should it pan the patch board or scroll the comment now?
It should scroll in the comment when the cursor is inside the comment. If the cursor it outside the comment, the scroll wheel acts like it currently does.
Effectively, we create a scrolling container inside a scrolling container. This is a bad UX.
I don’t agree, see e.g. this Github report window:
I write in a field container inside a scrollable website. So that is exactly the same as I proposed for XOD.
<…> I really insist that this is an important feature for larger projects.
Well, XOD uses this UX already too: The search node widget has a scrollbar. So please add a scrollbar to comments exactly the same way you did it for the search widget.
I see the point. Can we think about a better mechanism in XOD for a moment?
Well, XOD uses this UX already too: The search node widget has a scrollbar
This is not the same thing. The search bar and patch board are sibling containers. That is, the search does not belong to the patch board. So there’s no conflict here.
I write in a field container inside a scrollable website.
The scrollbar is shown only when the content is being edited. The same is done in XOD right now when you edit a comment.
Maybe, if the content overflows we can show it as some ellipsis or arrow label at the bottom. Something like “↓ Read on ↓”. Clicking on it could temporarily bring everything in the comment to the front and expand the comment completely. What do you think?
The scrollbar is shown only when the content is being edited. The same is done in XOD right now when you edit a comment.
No, this is not the case and that is why I reported the bug. It is OK if a scrollbar only appears when editing a comment but that does not happen yet. For readers I think it is no problem to double-click into a comment to be able to read and scroll through everything in a comment.
Probably adding some sort of indicator that comments are truncated should be a high priority. Selecting the comment for edit at least provides a work-around to read the missing text. I see donovaly’s point, though; in edit mode, you can use arrow keys to scroll, but there is no scrollbar (at least not in 0.26.1–maybe there used to be?).
It might be nice to be able to just select the comment (without going into edit mode) and be able to scroll through the text. I’m not so sure scrolling through the text when comment is not selected is a good idea; what happens if you are using the scroll-wheel to pan your workspace & a comment happens to move under the cursor?
One more suggestion, when passing the cursor could open a pop-up with the content of the commentary, there would have to be a small delay from being positioned until it opens.
Oops, gentlemen, you’re right. I was sure there is a scrollbar in edit mode. But it is not. Not sure whether it is a regression or we have never attached it there. This behavior indeed looks like a flaw in XOD.
OK, we can add the V-scrollbar when editing.
What about the regular/view mode? Ideas so far:
Scroll on wheel (bad because conflicts with panning)
Scroll on wheel only when selected (Is it a good UX? What about multiple selection? What if I left a comment scrolled to the middle?)
Have a kind of “expand” button at the bottom (Will be hard to collapse back because the button will jump. The actual comment height can be confusing for a user)
Always attach a scrollbar and allow scrolling only with it (Can cause a question “Why the wheel doesn’t scroll?”)
Should we choose among the existing variants or are there other ideas?
An “expand” option to view all the comments will be troublesome. Very large comment may not fit on the screen. A comment near the bottom won’t be visible while looking at nodes above the comment reference. A comment in the middle of nodes will cover referenced nodes while expanded.
Always having a scrollbar would indicate there is more text and provide a way to access it.
Allowing scroll wheel all the time is going to cause issues (conflicts with pan, do you scroll all comment nodes?). Allowing scroll wheel when node is selected will seem kind of arbitrary, but allows the functionality without causing conflicts. Only allowing scroll wheel when there is a single item selected makes it even more arbitrary, but alternative is to scroll all selected comment windows at the same time and you can’t pan if you happen to have a comment selected with a group of nodes.
While jumping back to the top of comment on de-select makes sense, there will probably be times someone wants to see the middle/bottom of comment while making changes to code, so leaving at current location is probably better. People can manually scroll back to the top using scrollbar if that is what they want.
Another question: does using the scrollbar select the node? Probably? I can see times I might have some nodes selected and need to scroll down to read more comments before doing anything with the selection, but it probably makes more sense to select the comment when scrollbar is used so scroll-wheel is activated for the comment.