Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Scrollbars are becoming a problem

artemis.sh

Post reply on HN
Print view View original

781–790 of 944 posts

Re: Scrollbars are becoming a problem

#781

Post by accoil »

tomjakubowski wrote: post #773
expazl wrote: post #765

> Ok so a lot of folks have fine motor control problems. The scrollbar is not there so you can use it to change your scroll position. It's there solely for the purpose of visualizing what your current scroll position is. Every device and every application should have a way to scroll that does not rely on the assumption that people will hunt out some narrow area of their screen and hold it while dragging to scroll. Th…

You're right that clicking and dragging the indicator part of the scroll bar to scroll around is silly and nobody really ever did it. But the scroll bar isn't just for visualization and it was commonly used to jump around the page - you'd click in the "negative space" on the scroll bar, which would then scroll the page to that position.

I drag the indicator when scanning a document. It's only a single click, and then I move the mouse to part of the document I'm interested in (and then can keep moving it if I want to look at another part). If I was to do this with negative space it would be multiple clicks (and even then negative space clicks tend to jump to the position, whereas a drag will show everything in between).

Though I find it's more common for a negative space click to just move a page and not jump to the location, so maybe that's influenced me.

Re: Scrollbars are becoming a problem

#782

Post by pseudalopex »

bluGill wrote: post #556
jwrallie wrote: post #229

Earlier quoted context omitted.

I believe the biggest obstacle is dealing with different toolkits, since gtk3 and later are constantly breaking theme compatibility with new versions, and nobody have the time to maintain good alternative themes in these conditions. XFCE with Chicago95 already exists (and so does Q4OS with XPQ4) as proof of concept that the window manager and toolbar side can be replicated. The problem is that important pieces of sof…

You can find well maintained applications for almost everything in either qt or gtk3. So you can select one toolkit to support. KDE might even accept your theme if you did enough work on it to make it work - and this is something that is feasible for one person. The hard part is those few exceptions, if you need one GTK3 app because KDE doesn't have a good alternative (or one qt app because GTK3 doesn't) then you hav…

Most maintained GTK 3 apps replaced menu bars with hamburger menus.

Re: Scrollbars are becoming a problem

#783

Post by [deleted] »

tomjakubowski wrote: post #773
expazl wrote: post #765

> Ok so a lot of folks have fine motor control problems. The scrollbar is not there so you can use it to change your scroll position. It's there solely for the purpose of visualizing what your current scroll position is. Every device and every application should have a way to scroll that does not rely on the assumption that people will hunt out some narrow area of their screen and hold it while dragging to scroll. Th…

You're right that clicking and dragging the indicator part of the scroll bar to scroll around is silly and nobody really ever did it. But the scroll bar isn't just for visualization and it was commonly used to jump around the page - you'd click in the "negative space" on the scroll bar, which would then scroll the page to that position.

[deleted]

Re: Scrollbars are becoming a problem

#784

Post by pseudalopex »

joseda-hg wrote: post #777
deepspace wrote: post #767

Earlier quoted context omitted.

I am going to disagree strongly there. The alternative way to scroll is, in most cases, the mouse scroll wheel. And that gets tedious (and strenuous for some people) really fast when the document gets large. I absolutely need the ability to use the scroll bar to change my position in a document.

I can't remember the last time I had to resort to manually scrolling by clicking the scrollbar In order of use, I scroll one click, middle-click and drag (Best for constant movement), use the dedicated keys, use arrows, or use vimium bindings (Which I try to avoid, because I'd prefer to not get used to non-CUA keybindings on programs I might have to use in other computers)

Dragging the scroll indicator is much faster than some of these. And more reliable. And easier to control than middle click and drag.

Re: Scrollbars are becoming a problem

#785

Post by pseudalopex »

pohuing wrote: post #776
deepspace wrote: post #767

Earlier quoted context omitted.

I am going to disagree strongly there. The alternative way to scroll is, in most cases, the mouse scroll wheel. And that gets tedious (and strenuous for some people) really fast when the document gets large. I absolutely need the ability to use the scroll bar to change my position in a document.

One Alternative would be autoscroll. Ie clicking with the middle mouse button and then moving the mouse up or down. The distance and direction between the click position and the cursor controls the scroll speed. But it feels like this is primarily a windows thing for some reason. Firefox supports it cross platform but that's about it

Many people have trouble controlling the speed. And most Apple mice didn't have a middle button.

Re: Scrollbars are becoming a problem

#786

Post by masswerk »

IIsi50MHz wrote: post #779
masswerk wrote: post #743

Earlier quoted context omitted.

I guess, it's a question of perspective. For me, maybe due to habit, these are two distinct actions: moving the origin and resizing the viewport. And I'm actually not comfortable with having to combine them in a single interaction. More often, I do not want to combine both, especially on a larger screen. Moving the viewport or its origin is a matter of the desktop metaphor, as well as altering stacking in the Z-order…

Possible meant: "Window's resize widget is outside the viewport, so have to first move the window by dragging the titlebar until the resize widget is accessible, then resize, then drag the titlebar again to approximately restore the window position".

Still, this seems to be more logical to me than moving the window borders, since moving something in a suitable place first, in order to maybe manipulate it there, is much more like we would proceed with real-life objects.

(However, the window being rendered for an initial view in a way where not all the crucial controls are accessible is the real problem and arguable shouldn't happen at all. At this point, every action to fix this will probably be flawed. E.g., if we resize the window by dragging any of its visible borders, any action and/or cancel buttons will be still tied to the bottom part of the window, which is still off-screen, meaning, we're still stuck. On the other hand, dragging the window by its title bar, while maybe a more promising approach, may be impossible, as there is probably not sufficient screen estate left for this, to begin with.)

Re: Scrollbars are becoming a problem

#787

Post by Dylan16807 »

NoGravitas wrote: post #740
hulitu wrote: post #719

Earlier quoted context omitted.

Well, MS Excel , Word etc. put a search widget and a user widget in the.title bar which occupy the whole thing. Moving Office windows is a pain.

Visual Studio actually puts the menubar in the titlebar; I never have any place to click left unless the window is maximized (or, at least, full width).

Oh yeah, that's a little bit annoying. It looks like I can drag on the second toolbar on the very left but it would be much better to force some dragging space both left and right on the title bar. Otherwise I think menus there is okay, I don't need the entire title bar as a dragging area.

Re: Scrollbars are becoming a problem

#788

Post by BLKNSLVR »

Dylan16807 wrote: post #657
JohnFen wrote: post #641

Earlier quoted context omitted.

> By moving things to the title bar, you gain back some real estate that you can dedicate to this ever expanding set of other tools and content. But the loss of the title bar causes actual pain and interferes with practical use. It's hard to imagine any tools/content that would be worth that loss.

The only programs I have that are putting things in the titlebar are putting tabs there, and those programs do not cause me notable problems. For me the positives are much stronger than the negatives.

Browser tabs I actually find OK, I didn't even really consider them as "using" title bar space, since each tab is a title bar and contains no "active" areas that prevent the simple 'click and drag' action.

This does become more problematic when there are so many tabs they become tiny and the whole title bar of the browser is taken up by tabs so that there's no dead-space to drag the entire browser window to another screen. I try to keep minimal contexts (due to personal brain capacity issues), so I don't run up against this very often - I manage links that I want to keep and go back to using other means, or if I forget them then they weren't very important in the first place.

Re: Scrollbars are becoming a problem

#789

Post by Fatnino »

Narishma wrote: post #492
Fatnino wrote: post #302

Earlier quoted context omitted.

If you double click in the top left corner of most windows they will close. Leftover behavior from 3.1

No, it worked like that since the very first Windows version.

Fair, but after win3.1 there wasn't a menu up in that corner anymore.

Re: Scrollbars are becoming a problem

#790

Post by pseudalopex »

IIsi50MHz wrote: post #739
hulitu wrote: post #719

Earlier quoted context omitted.

Well, MS Excel , Word etc. put a search widget and a user widget in the.title bar which occupy the whole thing. Moving Office windows is a pain.

Some occupied parts of the titlebar accept mouse-down-drag to move the window in MS Office apps, including: document-name-dropdown, search-box, username, user-icon. Elements that do not allow dragging the window, because they react to mouse-down, include: application-icon, quick-access-toolbar, notifications-bell-icon, and the standard titlebar icons.

This requires experimentation, memory, and conscious thought moving a window did not require previously.
Post reply on HN