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.

Sign up for GitHub

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

Jump to bottom

Sidepanes have no horizontal scroll bar (0.73.x) #1171

Closed
fdt-dev opened this issue Jul 10, 2020 · 21 comments
Closed

Sidepanes have no horizontal scroll bar (0.73.x) #1171

fdt-dev opened this issue Jul 10, 2020 · 21 comments

Comments

@fdt-dev
Copy link

fdt-dev commented Jul 10, 2020

The side panes have no horizontal scroll bars. For example if there are many levels of documents within a Wiki the Index sidepane can not be scrolled sideways to show the lower levels. Instead the names of the lower levels are truncated with three dots at the end.

I think for large wikis (and I have quite a large one with more than 3000 partly nested pages) there should be the possibility to scroll the sidepanes not just vertically but also horizontally.

The only current option is to pull out the sidepanes and make them larger, which takes away from the usable space in the middle.

The attachment demonstrates that. The vertical scrollbar is visible. There is no horizontal scrollbar.

Bildschirmfoto von 2020-07-10 18-32-59

It affects Linux and Windows versions.
@fdt-dev
Copy link
Author

fdt-dev commented Nov 2, 2020

Just a small reminder: Is this a feature that could be useful? Is it possible to implement? I'm not sure that it is. I tried to mess around in the source code; couldn't get it to work.
I think it'd be very nice to have a horizontal scrollbar in the sidepanes. Just now I have the issue with long page names that if I have several of those which are prefixed identically, it is rather hard to find the correct one. If I could scroll over to the right, it'd be very helpful.
Thank you.

@jaap-karssenberg
Copy link
Member

jaap-karssenberg commented Nov 3, 2020 via email

@fdt-dev
Copy link
Author

fdt-dev commented Nov 3, 2020 via email •
edited

@jaap-karssenberg
Copy link
Member

jaap-karssenberg commented Nov 3, 2020 via email

@fdt-dev
Copy link
Author

fdt-dev commented Nov 3, 2020

Thank you for the explanation. Sorry for being so insistent on this topic. It's just that I really miss the scrollbar. The horizontal scrollbar would make the side panel even more useful. What am I supposed to do with entries which are beyond the right border of the panel?

Why do you need the truncation? For cosmetic purposes, probably. But the right most border of the panel would automatically truncate text anyway. So, again: why the explicit truncation when an implicit truncation would happen by the border of the column?

I maintain that the horizontal scrollbar is essential if the text grows beyond the right border of the panel. I just don't understand what a truncation does in terms of usability vs. a horizontal toolbar.

I'd rather forgo the cosmetics of the three-dot-truncation and be able to scroll to the right to actually be able to read the entries there. The three dots do nothing in terms of usability, and frankly the truncation annoys me to no end. I can't imagine that I am the only one with this problem. I really don't want to make the panel wider than in the screenshot above. Not by much anyway. The main part is the center panel with the actual text, but the side panel is needed for navigation. I am running older netbooks and they have displays at 1280x768 pixel resolution. But even at 1920x1080 it's not much better. If I had a 4K display, I'd make the side panel larger, but as it is a scrollbar is the only real option.

Truncation in conjunction with a scrollbar would probably cost a lot of performance because every pixel column scrolled would require a redraw of everything in the panel. That's probably why the framework doesn't support it in the first place. What's the appeal of this truncation anyway? :D Sorry, I don't get it.

I'm really sorry if I don't understand your reasons. I'll leave it at that. Thank you for your time!

@fdt-dev
Copy link
Author

fdt-dev commented Nov 4, 2020 •
edited

I'm really sorry, but I can't let it stand as it is. I'm just again working in my notebook and this truncation is driving me up the wall. I believe that a horizontal scrollbar is necessary. You said:

Usability wise I'm undecided. Agree that at some point you'll need the
scrollbar to show content to far out to the right. However for notebooks
with limited nesting levels, the ellipsize works better.

I disagree. Maybe I can't see it. My questions would therefore be:

  • Why would ellipsize work better for notebooks with limited nesting levels? Better than a horizontal scrollbar? And why would that be the case? That makes no sense to me, because for notebooks with limited nesting levels the truncation isn't needed anyway. Or the other way around: as soon as the text goes beyond the width of the widget the truncation makes everything worse. I mean, it really hasn't anything to do with the number of nesting levels, but only with the length of the page titles. :)

  • Why is the truncation for notebooks with limited nesting levels good in regards to usability? That would needlessly limit the usability without giving any advantage.

I understand that this is your project and you can do whatever you want with it. So, I don't want to impose but since apparently it's such a minor change in the code I think it would be beneficial. Am I really the only one who thinks this is an issue?

Please consider changing the behaviour of the side panes.

If not I will have to manually change the code myself every time there's a new release. That's fine, I can do that, too. I am assuming that I have to remove line 391 in the file __init__.py in the folder plugins/pageindex Is that correct? Seems so, because it worked. Thank you for the suggestion! I'm learning every day. It looks and works much better with the horizontal scrollbar than with the truncation. Please try it yourself and compare. I think the horizontal scollbar is the better option.

Thank you.

@fdt-dev fdt-dev mentioned this issue Dec 20, 2020
Closed
@oscarbidabehere
Copy link

+1 I agree the horizontal scrollbar is needed

@jaap-karssenberg
Copy link
Member

Still feel we need a complete different widget for deep nested trees. With horizontal scrolling you miss the context where you are in the tree. But added a patch with the option so you can at least try it. It's a bit flacky though, rendering does not refresh immediately, might require a re-start of the application before it works correctly.

@fdt-dev
Copy link
Author

fdt-dev commented Jun 18, 2021

Still feel we need a complete different widget for deep nested trees. With horizontal scrolling you miss the context where you are in the tree. But added a patch with the option so you can at least try it. It's a bit flacky though, rendering does not refresh immediately, might require a re-start of the application before it works correctly.

Jaap, thank you for that.

But still for the rest of the text: What are you talking about? Without the scrollbar you miss the context to the other side, too. That's the whole point. The scrollbar is a non-issue. It is not possible to make the widget wide enough (because when push comes to shove it's never going to be wide enough).
Prioritizing: The center widget containing the text is the most important thing. The left and right panels have simply a supporting role. The scrollbar is not a problem, because the whole point of a scrollbar is to be able to scroll. So in order to get the context, why not scroll back the other way. I like scrollbars.

Conversely: What would this "completely different" widget look like? It's a tree that needs visualizing. What would you possibly use other than a tree?

Until now I kept removing the ellipsize line. Rendering has been immediate and flawless. It seems like a perfectly easy fix to a problem that is bothersome. Seems like the new option is doing exactly that. Thank you very much. I hope this will come up in the PPA?

Look, sorry if I am enthusiastic about that point. I respect your decisions. Thank you again for this great application that has been very helpful to me over the last eight years and hopefully in years to come. But that's exactly why I am enthusiastic about these things, because this in particular has been a usability issue so far.

@sojusnik
Copy link
Contributor

Can we have the same setting for the tag sidebar? ATM, the horizontal scrollbar is activated there by default, which I would prefer to deactivate.

@jaap-karssenberg
Copy link
Member

jaap-karssenberg commented Jun 26, 2021 via email

@sojusnik
Copy link
Contributor

@jaap-karssenberg Many thanks!

If it is not too laborious, can you please add the remaining two settings from the index side pane to the tags side pane, namely:

The option Automatically expand sections on open page determines whether the section for the current page is automatically expanded.

The option Automatically collapse sections on close page determines whether sections that are automatically expanded are also collapsed again on moving away from the page. It does not affect sections that were expanded manually by clicking on the expand arrow.

@sojusnik
Copy link
Contributor

sojusnik commented Jul 7, 2021

@jaap-karssenberg Many thanks!

If it is not too laborious, can you please add the remaining two settings from the index side pane to the tags side pane, namely:

The option Automatically expand sections on open page determines whether the section for the current page is automatically expanded.

The option Automatically collapse sections on close page determines whether sections that are automatically expanded are also collapsed again on moving away from the page. It does not affect sections that were expanded manually by clicking on the expand arrow.

@jaap-karssenberg Thanks for adding those settings too!

oscarbidabehere pushed a commit to oscarbidabehere/zim-desktop-wiki that referenced this issue Jul 9, 2021
@jaap-karssenberg
Add option for horizontal scrollbar in pageindex
ecc35bc 
Fixes zim-desktop-wiki#1171
@introt
Copy link
Collaborator

introt commented Aug 10, 2021

With horizontal scrolling you miss the context where you are in the tree

Without the scrollbar you miss the context to the other side, too

What are your opinions on word wrap? That'd keep the context on both sides for arbitrarily long page names[0] with the downside of making the list much longer. Coupled with bullets for pages without subpages this makes for a (in my opinion) very fashionable alternative[1].

  1. Unless, of course, the nesting goes so deep you can't fit multiple characters, but at that point it sounds like the information contained in the page names should be stored in pages instead
  2. https://i.stack.imgur.com/vQwmi.png shows one implementation of such a TreeView; I'd add bullets to differentiate between multiple leaf nodes so they don't end up like this: https://i.stack.imgur.com/5dr6N.png

@fdt-dev
Copy link
Author

fdt-dev commented Aug 10, 2021 •
edited

I'm not a fan of word wrapping, mostly because it wouldn't actually solve the issue. I'd rather have the option for the panels to turn on scrolling (I think that has been implemented). If someone feels like they lose the context by scrolling horizontally, then they can turn off scrolling. And by the way: What kind of an argument is that anyway? You do know that you can scroll both ways with a horizontal scrollbar? So, if you scrolled to the right and "lost the context" then you can scroll back to the left. That's the beauty of it.

As for deep nesting and why you have to mock it: It makes sense to do it, trust me. I'm using nesting as a form of classification of the things that I do. I go from the general to the specific. It helps to use that in order to structure information when working at the office. I really don't get why you mock that. Please don't. How deep the nesting has to go until it becomes unfeasible to use word wrap depends mostly on how wide you can make the left panel. So ... what was your point again? I don't have any 4K displays available (and even if, that'd only delay the problem). I don't use Zim in full-screen if possible (and even if, that'd only delay the problem). The left panel will always have a limited width. For everyone. I already mentioned that: No matter how wide the left panel is, there will always come a point where either the nesting level becomes invisible (for lack of a much needed horizontal scrollbar) or the word wrapping becomes unfeasible. The latter will become a problem sooner. So, we're back at horizontal scrollbars again. Why are they such a big problem? I don't get it.

For example: I am maintaining project documentation for my work in the excess of 4000 articles in Zim. As part of this documentation I have meeting minutes that go back seven years on 20+ projects. So, in order to structure those I for example had to split project category, project name, topic "meeting minutes", year, month, day (and sometimes time of day) as separate nesting levels. (It actually goes one nesting level below that, because I have "attendees" and "notes" on the same level but one below that previously noted level.) Does it make sense? It does to me, yes, because it is logically structured and it is helpful. Would it make sense to store this information as page contents? No, because then the structure would be lost. Would word wrapping help? Well, have you ever word wrapped "2018"? I hope that I got my point across. Thank you. I know that maybe I am misusing Zim. Sorry. It's the way I am using it. And it works. It just would work better with a horizontal scrollbar.
Of course that way I'm using it the nesting goes deep and beyond the limited size of the left panel. Please seriously consider the possibility that somebody makes a deep nesting structure that actually makes sense. I know very well that a horizontal scrollbar is really the only option to deal with that. Losing the context is a strange and moot argument (sorry Jaap). Just try it, thank you.

I have argued very clearly why horizontal scrollbars are a necessity. See my comment from June 18th. Word wrapping is worse because it makes the panel even less usable, less well arranged. To me anyway. I don't understand why it is such a terrible thing to have a horizontal scrollbar. I really don't get why everyone seems to see it as a downside. I see it as a plus. But if it can't be done because it isn't liked, then fine ... Zim is modular enough that I may make my own panel for that. It's just a terrible hassle to keep it up to date whenever a new version of Zim is being released. Mostly because it doesn't work properly to keep plugins in the user's folder. But that'd be another issue to post.

This is my last comment on this topic. I have made my case clear enough. I have to accept that nobody else sees the benefit of horizontal scrolling. A simple option in the preferences dialogue window of the panel would have sufficed. It's not much code. Why not give users the option to turn on the horizontal scrollbar as needed? I thought that Jaap has an implementation for exactly that in the development branch. I'd consider that the solution, so please Jaap merge it into the master branch. This is a good solution.

@introt
Copy link
Collaborator

introt commented Aug 11, 2021

Greetings, @fdt-dev!

I'd like to start by the way of apology. I came across this issue while filing other ones and didn't read all the prior discussion, just skimmed the beginning and Ctrl+F:d for wrap after coming up with the idea. This was foolish of me and I regret the fact I hurt your feelings and made you feel mocked.

I am not a representative of the project; my collaborator status is due to just a few contributions, but I'd like to point out that Jaap has already implemented the horizontal scroll bars for you and they will be included in all the future releases starting with 0.74.

I imagine Jaap hasn't merged this with the master branch as between 0.73.5 and the develop branch there has been a major rewrite for moving to GTK3 – as well as the fact that you've stated you've been able to make the current version accommodate your needs.

You may not agree with the way releases handled, and I know how that feels: a workflow-breaking regression that I personally took the time to fix, #1452, hasn't landed either- though I'm at fault there for preferring to patch the develop branch.

With your need for horizontal scrollbar being taken care of, I'd like to address your questions about the explicit truncation before proposing (to Jaap) another solution for the more general problem.

I've gotten the impression that Jaap deeply cares about the quality of the Zim user experience and would rather provide complete solutions later than partial solutions right now. If I've understood the design philosophy regarding context correctly, it basically boils down to these two rules:

  1. Don't hide things from the user.
  2. If you must hide things, indicate that they are hidden.

This is oversimplified and doesn't cover eg. the right-click menu or keybindings; though everything in those is usually available elsewhere. However, it does cover for example why tabs stay behind when closing the panels and the reason for ellipsis: they tell the user that something is hidden. You'll also see them used for menu items that open dialog windows and other things; compare "Find..." with "Find Next", for example.

Why the explicit truncation? To show the user that the title doesn't fit- just cutting it off at the edge bodes badly for page titles with spaces as there's nothing to indicate whether the title continues beyond the edge, and that disqualifies it from being good UX. The presence of the horizontal scroll bar at the bottom doesn't fix it either, as it doesn't indicate which title gets cut short.

So, the downside of having a horizontal scroll bar without ellipsis, the missing context, is that there's no indication whether a specific page name continues off-screen. You may be okay with that, and Jaap has conceded to give the users the option, but there's no argument whether it breaks the UX. Without a way to give the users the aforementioned context, it does. With the ellipses, it would not.

@fdt-dev
Copy link
Author

fdt-dev commented Aug 11, 2021 •
edited

Thank you, that's alright. No worries. But now I have to respond again even though I was resolved that I wouldn't.

I understand and appreciate that Jaap is aiming at a highly polished user experience. That's part of the reason why I love Zim so much. It is wonderful.
I also appreciate that Zim should not hide information from the user: I feel like we're going in circles.

The thing is: a truncation is hiding information. We're already at the point of hiding information. That was my whole reason why I started this thread because I don't want hidden information either. A horizontal scrollbar fixes that. And if your UI isn't entirely broken you can also see that there is a horizontal scrollbar, therefore you immediately know that there is potentially hidden information.
If horizontal scrollbars were a fundamental UI problem then I'd assume that those would be gone by now. But in fact it's the other way arond: Imagine a UI without horizontal scrollbars. Wouldn't you say that this is broken? I'd certainly say so.

The fact remains that any pane will always have a limited size (esp. width). So either we live with the fact that things have to be truncated (which I really dislike) or we introduce a horizontal scrollbar. I just don't get why it is such a big deal. It wouldn't even be possible to avoid either truncation or a scrollbar if Zim were limited to only one nesting level. Not even then it would be possible to avoid that issue.
And also: What about vertical scrollbars? The panel has a limited height, so to stay with your argument you'd need to truncate at the bottom and indicate that but without a way to scroll. If you forgo the horizontal scrollbar using this kind of arguments, vertical scrollbars are equally out. But that would really break the usability, I hope we can agree on that. See: I don't get why the horizontal scrollbar would make anything worse.

An explicit truncation via ellipsize isn't necessary. If the panel ends in the middle of a word what is your first thought: "Oh, that word is just like that: half." or "Oh, that word surely continues, maybe I have to scroll to the right." I admit, though, that if there is a space character right at the border of the pane then the context is lost. But I don't think that this would be a long-term issue.

So, the downside of having a horizontal scroll bar without ellipsis, the missing context

No. For the last time: No. The ellipsize function causes loss of context and it does not provide the user with any way to get the missing information back. That's definitely terrible. That's what I try to get across here.

but there's no argument whether it breaks the UX. Without a way to give the users the aforementioned context, it does.

Why does a horizontal scrollbar break the UX? If that were the case there were no horizontal scrollbars anywhere. Is that the case? No. Conversely: Why does ellipsize not break the UX? That makes no sense.
Also: You want context? I understand, I want that, too. The scrollbar itself is giving the context. It clearly shows that there is more. Ellipsize breaks the UX for me, because despite making it blatantly obvious that there is information missing, it still does not provide the user with any way to get this information back. No matter how you try to talk around that point: That's worse!

In menu items the three dots usually indicate that the function calls up another dialogue window. I am working with computers since the mid-1980's, that's not news to me. That's really not comparable here. It's not the same thing.

@introt

This comment has been minimized.

Sign in to view
@introt

This comment has been minimized.

Sign in to view
@introt
Copy link
Collaborator

introt commented Aug 11, 2021 •
edited

A "completely new" widget for displaying the index

Zim stores notes and their structure with text files and folders, respectively. Thus, we can look at other file system browsing tools for inspiration for a widget that supports arbitrary nesting depths.

Most solve the problem of context with a path bar. This scales well from the prompt of UNIX shells to fully-featured file managers. But how to we handle moving between nested pages? Does one need to list the sub-pages of the current page's sub-pages one by one?

My suggestion is combining a path bar with a partial tree view, as can be seen in this Finder screenshot[0]. Eg. having the current page as the root node of the tree view, with a path bar for context. Such a view brings the added benefit of searches limited to the current page and it's sub-pages without bringing up the search dialog + toggling the option.

[0] https://i1.wp.com/ravingroo.com/wp-content/uploads/2015/12/mac-os-x-finder-show-hidden-files.png

@introt
Copy link
Collaborator

introt commented Aug 13, 2021 •
edited

The "Moodle sidebar" way

Usability wise I'm undecided. Agree that at some point you'll need the
scrollbar to show content to far out to the right. However for notebooks
with limited nesting levels, the ellipsize works better.

Not sure what a good rule would be to make the behavior OK in all cases.
Could make it optional, but that just puts the burden to the user.

The "Moodle sidebar" way is to wrap the titles to the max width of the sidebar and provide horizontal scrolling (only) if something doesn't fit. Using wrapping like this solves two problems at once:

  1. A single long title doesn't make the scroll bar appear (unless unwrappable)
  2. The user knows whether a title has more words after the cut-off (though it isn't immediately obvious whether there are more letters to a given wrapped word)

That leaves us with "just" one problem: what to do with deep nesting?

I propose having a minimum wrapped width per level, as pseudocoded below. This way the horizontal scroll bar only/always appears when an unwrappable string in a page name doesn't fit in the view, and the wrapping doesn't become obnoxious in the deeper levels.

visible_width = panel_width - (depth * indent)
wrapping_width = visible_width if visible_width > min_width else min_width

Edit: Would also fix #1418

@introt introt mentioned this issue Sep 28, 2021
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@sojusnik @jaap-karssenberg @oscarbidabehere @introt @fdt-dev