Folders with too many entries in the Bookmarks Toolbar have inconsistent height/position

BoneTone

@RiceKirby said in Folders with too many entries in the Bookmarks Toolbar have inconsistent height/position:

Personally, I think a simpler approach would be better. Just having it behave like any other dropdown would make things more consistent and easier to understand.
I feel like imposing too many conditions to determine if it will show on the right or left will be fairly clunky and not even consistent (for example, it will always display to the right if it's too close to the screen's left boundary, so those solutions wouldn't help much).
I know that would mean sacrificing a bit of display, but that's already how those menus usually work in most applications (including in parts of Vivaldi itself), so I think going for consistency and respecting the menus' hiearchy would bring more benefits.

The thing is, this isn't technically a dropdown menu. It's a listing of a folder's contents. But have you noticed how the Bookmarks Menu in the top bar also covers up other folders, making them inaccessible? What you need is a moderately deep folder structure, not nearly 20, it happens after opening the third folder down for me. Opening the third folder displays the 4th "menu" (as clicking Bookmarks to show the root folder creates the first). The 4th menu covers the 2nd, the 5th menu covers the 3rd, the 6th menu covers the 4th, the 7th menu covers the 5th, the 8th menu covers the 6th, and so on. Now, you can reveal the hidden content by sliding the mouse "backwards" (from the 8th menu to the 7th, 8 disappears, 7th to 6th, 7 disappears, and so on). But you can do the same thing with the Bookmarks Bar, just slide the mouse in either direction and hover another folder. Or you can just hit the arrow key if the keyboard is acceptable.

The issue with truncating the list is that you can end up dramatically decreasing the amount of bookmarks and subfolders displayed. In my current restored (not maximized) window, less than 1/3rd the entries would be displayed as currently are. Since this only applies when there is a folder whose contents are larger than the screen can fit when displaying as it usually would, we know that is going to create a lot additional of scrolling to get at the bookmark if it doesn't happen to be in the limited listing. Compared to maybe 4 or 5 maximum being blocked on the bar itself, the result would probably end up being lot more time & effort on average to get to your bookmark.

For what it's worth, there aren't too many conditions, there is only 1 condition when something is a toggle, all it does is change the state. But...

Currently Working 'Fix' that Requires No Additional Mouse Movement

So this is a quick and easy way to display what is hidden below the list... just right click the folder, that kills the content list and brings up the context menu, and you can now see all of the toolbar's items.

@Pesala said in Folders with too many entries in the Bookmarks Toolbar have inconsistent height/position:

@RiceKirby Please vote for the existing feature request:

Multiple Columns for Bookmark Bar Folder Dropdown Menu

While you're waiting, just add some subfolders. This is a better policy for accessibility reasons anyway. Any menu with more than 20 items becomes inefficient to navigate, so split it into subfolders.

What about when it's 20 folders deep? Is it better to have maybe 7 levels with 50 items instead of 20 levels with 20 items? As mentioned above though, it's not really a menu, it just kind of looks like one. I mean, nothing is going to be evenly split like that, but, just illustrating a point.

This is why I do not put my entire bookmarks library inside the Bookmarks Bar folder. I have only a select set of bookmarks in the bar that I use frequently and want to be able to click quickly. For easy access to my bookmarks while in the same view as my webpage I use the Bookmarks Panel. I find it much faster and more forgiving than trying to any menu-style view into the library. My bookmarks library isn't a menu and shouldn't be restricted by any UI design philosophies for menus. Some folders definitely make sense to have more than 20 items, some have more than 20 subfolders.

Pesala

@bonetone

But have you noticed how the Bookmarks Menu in the top bar also covers up other folders, making them inaccessible?

I never encounter that problem as my primary monitor is 1200x1600 portrait and I subdivide long folders into subfolders.

I had to add some bookmarks to my longest folder to test the problem on my secondary 1920x1080 secondary monitor. There, 48 items is too many, so I split it with a submenu.

400 bookmarks would not need 20 levels. Twenty subfolders with twenty bookmarks in each supports 400 bookmarks. That is surely more efficient than cascading one folder to 10 levels with 40 bookmarks in each!?

RiceKirby

@bonetone
What I think it's important here is that a menu is never covered by any of its direct children submenu. This is a very important UI matter for any application, since having anything appear over the menu you are currently on ends hindering the navigation.
Here's a generic example to illustrate this point:

alt text

On this image, it would be fine if the Main Folder menu were overlapped by the Subfolder 2, as the user is currently navigating through the Subfolder 1. But having the Subfolder 1 be covered by the Subfolder 2 (its direct child) would be a bad UI practice since you are still browsing Subfolder 1.

In other words, an user interface should never put anything over the menu you are currently navigating. Having workarounds like clicking or right clicking or moving the mouse back and forth doesn't change the fact that there's something obstructing the area that you are currently on.
This is how those menus work in every other browser, so I don't see why Vivaldi needs to rely on workarounds to achieve the same thing.

BoneTone

@Pesala Sorry, I should have been more clear, the 400 bookmarks don't represent the entire library, just one traversal down a path; I also had a typo with a 7 instead of an 8. 400 wouldn't require 8 deep with 50 either, you could make the library just as flat. It is implied (now explicitly stated) that there are already the relevant number of siblings at each level, but for this path of 400 bookmarks they could be organized into 8 nodes containing 50, or 20 nodes containing 20, or 5 nodes, some containing a dozen and some containing 60. Something like that last example being the most likely. In reality, I would be shocked if any member of the forum had a perfectly balanced tree structure in their bookmarks library.

The truth is, any such rule will always lead to inefficiency. Imposing artificial limits will eventually breakdown in the face of real world data. Let the bookmarks you create dictate their structure. In some places it makes sense to break them up into more subfolders, sometimes many nested folders deep. In other cases it makes sense to have many items within one folder rather than breaking them up. Both cases probably occur in most reasonably organized bookmarks collections, they do in mine. I can see ≈60 items without having to scroll on my workstation, so limiting myself to only 20 items wouldn't even take up half the display. Clearly that's not efficient use of my screen real estate. If I have 50 bookmarks that are all closely related, forcing them into subfolders would just slow me down and create unnecessary work when I could just let my eyes scan the entire list at once.

Do you only have 20 folders or less in the root of your bookmarks? And if a folder contains 10 bookmarks, you only create 10 folders? Do you similarly never allow more than 20 items in any folder on the hard drive? That seems a better metaphor for what bookmarks are than a menu system. Like the files in your file manager, bookmarks are basically just pointers to data. However you manage your files would probably be the best way for you to manage your bookmarks. I don't think any one method could be called best in the universal sense, though I do think that a method could be called best for a specific person. That person likely knows which method that is if they have spent enough time working with data like this and thinking about how they remember where things are for easy retrieval in the future. That's not to say for every person there is a singular best method. And what is best for a person can change over time, as their perspective changes, as their library changes, etc.

I just don't see the need to invent arbitrary limits on bookmark library structures. At some point, reality is going to prove itself to be broader, deeper and more complex than we could have anticipated.

I subdivide long folders into subfolders.

About that… having more subfolders would actually make what I was describing there more likely to happen. It's not the vertical length that cause the overlap. The width of the list is determined by the length of the titles of the bookmarks (with some upper bound), I've actually got a 2160 pixels horizontally, so you should hit this faster than me if you have similar data in your bookmarks library. Just start traversing down some path that you know has a bunch of subfolders. Eventually, instead of displaying to the right, the next one displays to the left, covering up its grandparent.

BoneTone

@RiceKirby said in Folders with too many entries in the Bookmarks Toolbar have inconsistent height/position:

What I think it's important here is that a menu is never covered by any of its direct children submenu.

In your example that is true, however there is a big problem with the test set. You won't see it happen if you use very limited data like that, in both total quantity and string length. You've got one equivalence class there and no more than 3 of each item, so you're unlikely to see any behavior except for what you expect. This thread is about what happens when a folder's contents are so great it causes Vivaldi to exhibit different behavior. Rather than a generic set, that is a negligible set... It wouldn't cover anything if you used the bookmarks toolbar as the entry point either.

To make my life easier I just used my actual bookmark library. It may or may not count as generic, but it is a specific set that exhibits the behavior we're interested in. Rather than deal with identifying all the equivalence classes that we can find in a real world data set. Then generating a test set that covers them all and is large enough to hit the conditions and corner cases that would hopefully cause unexpected behaviors. And to avoid the advantages I gain from the high end specs on my workstation, I tested on our laptop.

The bottom of the root folder:

The contents of the Technology folder:

As you can see, direct children can and do cover up their parent & its siblings. There are many folders in my library that do this; so it does happen and isn't unique to the toolbar entry point.

BTW, I'm not certain what design is best, nor am I privileged to Vivaldi's internal design conventions. They'll be the ones that eventually solve any problems we give to them. I just think these are questions worth considering & cases in which the interesting things occur. The problem gets a lot more complex when we're not just solving it for our workflows and environments, but have to generalize it enough to account for as many of the workflows, data sets and environments as we can that are compatible with/supported by Vivaldi.

With the proposal that the folder contents be displayed inside the browser window without overlapping the bookmarks toolbar, we've marked where to truncate on one side of the list, but what about the other? That would have to be considered before implementing the new tree view. When the toolbar is on the bottom do we let it run all the way to the top of the screen, even when that's outside of the browser window? That seems to conflict with the design philosophy of not covering up what the user is currently working on as the controls at the top can be covered, including navigation buttons, search field, address field, possibly the active tab but certainly some tabs if the tabs bar is positioned at the top. If we also truncate the tree view lists at the edge of the first toolbar on the opposite side of the bookmarks toolbar, we can end up with a dramatically shortened list if the user is in windowed mode.

One way or another, compromises must be made, and workarounds will have to be employed in the cases like we face now. Call out the bookmarks uncertainty principle. We cannot both guarantee that a reasonably large portion of the folder's contents will be displayed and also avoid covering up important UI elements in every case.

Pesala

@bonetone Twenty is an ideal to aim at due to Fitts’ Law; one can add more but it becomes less inefficient. I have some folders with nearly 30 bookmarks, and a couple of rarely used folders with 40, which I subdivide with separators. I have only 7 root folders including Speed Dial. I currently have 76 YouTube bookmarks, which I have split into four folders according to topic.

There should be an option to Limit the Width of Bookmark Menu Folders. That will prevent the problem that you highlighted with overlapping menus.

It is not suggested that Vivaldi should set limits to the number of bookmarks in a folder — I suggest that users should organise their bookmarks themselves to avoid problems caused by overflow and long titles.

The linked feature request to cascade long folders is much better than scrolling them.

BoneTone

@Pesala Where do you get this 20 number? I've never seen 20 mentioned in anything I've read on Fitts', Hicks' or the Steering laws.

BoneTone

Also, I'd argue that solely relying on Fitts' Law to come up with said number is a very limited understanding of what is occurring here. Fitts' Law simply speaks about human movement, and human movement is a very small part of navigating my bookmark library. Much of the time I don't even use a mouse, in which case Fitts' Law is completely irrelevant.

We're not discussing UI design here, we're discussing data organization. I never access my bookmarks through the menu bar except for when dealing with questions on the forum. I've said it before and I'll say it again, my bookmarks library is not a menu system.

BoneTone

@Pesala said in Folders with too many entries in the Bookmarks Toolbar have inconsistent height/position:

I have some folders with nearly 30 bookmarks, and a couple of rarely used folders with 40, which I subdivide with separators. I have only 7 root folders including Speed Dial. I currently have 76 YouTube bookmarks, which I have split into four folders according to topic.

Yeah, I guess with a small bookmarks library it might seem logical to limit the number of items per folder to another a small number, and 150 pixels might seem like the optimal amount of view into the title of the bookmarks. That just isn't true for everyone.

There should be an option to Limit the Width of Bookmark Menu Folders. That will prevent the problem that you highlighted with overlapping menus.

No, it wouldn't. Especially if I were to impose such tight limits on the number of bookmarks I would allow per folder, but even with my current structure 768/150 = 5.12. There are more than 18 pixels to get to the Bookmarks item in the menu bar, probably more than 150, perhaps even 300, but let's still assume that we are able to get the the full 5 in before being forced to reverse course. I already have paths that are 8 or 9 folders deep. That issue will still happen even in this idealized theoretical case, it's probably more like 4 or 3 levels before having to reverse course. Regardless, I would never cut my view of my bookmarks down to 150 pixels. Even the current limits are too small for my liking, which is why I don't use them.

Pesala

@bonetone said in Folders with too many entries in the Bookmarks Toolbar have inconsistent height/position:

We're not discussing UI design here, we're discussing data organization.

You may be talking about data organization, but the thread is about the Bookmarks Bar Folders, and that's what I am discussing. I rarely use the keyboard to access the bookmarks bar folders. Most uses will use the mouse.

I don't know where you get 768 from? Your available width is 2,160 pixels. Most users will have 1920 pixels or more, so 12 columns @ 150 pixels.

BoneTone

@Pesala said in Folders with too many entries in the Bookmarks Toolbar have inconsistent height/position:

@bonetone said in Folders with too many entries in the Bookmarks Toolbar have inconsistent height/position:

We're not discussing UI design here, we're discussing data organization.

You may be talking about data organization, but the thread is about the Bookmarks Bar Folders

You're absolutely right, this whole "20 items in a folder" thing is completely off-topic. It is not related to the thread, and I shouldn't have responded to it. Fitt's law and ideas about how people could optimally organize their collections are for another thread. What matters here is the behavior of Vivaldi as it applies to any and all organizational methods that are possible.

Edit: Just to answer the direct questions, but I won't reply about it again in this thread, to discuss it further, start a different thread so we don't keep driving this one off-topic.

768 = laptop - where the test was done, as stated right before the first screenshot.
2160 = workstation

23.5% of desktop users on the internet have 1920 or greater. Personally, I would call that a minority rather than most.

https://gs.statcounter.com/screen-resolution-stats/desktop/worldwide

Anyways, let's take this elsewhere... if you find some resource on Fitts' Law that shows the 20 items in a folder limit, tag me when you start that thread, I'm genuinely interested, but I won't respond again in this thread about how one should be organizing their bookmarks to avoid driving it further off the rails.

Regardless of any laws, Vivaldi needs to support people who will have lots bookmarks, lots of items in folders, and lots of folders with fewer items. That's the whole point of Vivaldi, adapting to the user, even if they are working in ways we might consider inefficient.