Scrollbar problem

Hi all,

I don't know, what other users think about it, but for me the scrollbar also showed how large a file is or what part of the file I am viewing at the moment. If the scrollbar's thumb was at the bottom, nothing was below the visible window ("viewport").

Currently this is broken and IntelliJ calls it a feature. I call it a bug or GUI blooper. I know, that some people have asked for an option to let the user edit a file in the upper third of the editor window - even on the end of the file. But why bother all the other users, that liked the existing behaviour?

Please make it possible to get back the old behaviour, e.g. by adding an option.

Tom

25 comments
Comment actions Permalink

+ 10^100

I consider this a GUI mistake too. I can't think of any application who's scrollbars behave like the current EAP scrollbars.

Besides, the horizontal scrollbar just behave like one expected, so why implement two different kind of behaviours for both horizontal and vertical scrollbers??

Please, remove this feature, or at least make it a user-cobfigurable option!

0
Comment actions Permalink

Completely agree on all points!

0
Comment actions Permalink

You've got my remaining 30 votes. Together with this comment, which I double here by hoping it is read by one of JetBrains GUI designers:

The current behaviour is absolute garbage! And I have the impression that Lars' original request was completely misunderstood.

In IDEA 3.0.x the scrollbar represents exactly the file size. Nevertheless there is some free space at end of file. Lars' request was for a configuration to increase the amount of free space, period.

Now in Aurora the scrollbar doesn't represent the file size anymore. And there are four (!!!!!) different file end positions:

- If I move the caret to end of file with <![CDATA[ then I have no empty lines at the bottom of the screen. - If I move the caret to end of file with then I have about 5 empty lines at the bottom. - If I move the caret to end of file with +]]> then I have about 30 empty lines at the bottom.

- If I move the file view to end of file by dragging the scrollbar then I have the whole screen filled with empty lines.

And worst of all: Lars' request is not implemented, since there's no configuration for the amount of empty space.

0
Comment actions Permalink

Hey, get your hands off my new and improved scroll-behavior - I'm one of those who requested this feature :)

I just tried build 1094, and as far as I can see the thumb in the scrollbar is still sized to indicate how much of the total file is visible in the viewport. And it is also still positioned to indicate where you are in the file.

The thumb shows which part of the entire viewable area is currently show. If you take into account that the viewable area extends farther below the last line in the file because the empty space after the last line should also be visible if the user scrolls that far down, then the thumb in the scrollbar is totally accurate.

Its not supposed to graphically represent the file contents, it is supposed to graphically represent the viewable contents of the scroll pane, which happens to include extra space below the last line.

By all means add yet another option to tweak the GUI to please as many users as possible, but I do want to defend the latest solution against claims that it's 'wrong'!

Best regards,
Lars Ugleberg

0
Comment actions Permalink

Actually, I suggested the feature as an additional option BECAUSE I expected it to meet a lot of resistance. And an additional option should hopefully irritate less users.

But the changed behavior is (almost) exactly as I requested and hoped for. The only 'deviation' is that I would also expect to get farther down when pressing Ctrl-End.

And I would NOT want to have to configure the amount of extra empty space, at least not as a number of lines, since the desired number would change if a changed window size, font size, or if the layout changed in later releases.

I am very pleased with the new behavior even though I would have taken it a small step further to achieve complete consistency.

Best regards,
Lars Ugleberg

0
Comment actions Permalink

+1

I quite like this feature. I much prefer working on text in the top half of
the screen and this lets me do so, even when I'm adding a method at the end
of a class. It's also in line with what most of the better text editors out
there do (TextPad, UltraEdit, even Vim IIRC!).

Vil.

Lars Ugleberg wrote:

Hey, get your hands off my new and improved scroll-behavior - I'm one of those who requested this feature :)

I just tried build 1094, and as far as I can see the thumb in the scrollbar is still sized to indicate how much of the total file is visible in the viewport. And it is also still positioned to indicate where you are in the file.

The thumb shows which part of the entire viewable area is currently show. If you take into account that the viewable area extends farther below the last line in the file because the empty space after the last line should also be visible if the user scrolls that far down, then the thumb in the scrollbar is totally accurate.

Its not supposed to graphically represent the file contents, it is supposed to graphically represent the viewable contents of the scroll pane, which happens to include extra space below the last line.

By all means add yet another option to tweak the GUI to please as many users as possible, but I do want to defend the latest solution against claims that it's 'wrong'!

Best regards,
Lars Ugleberg


--
Vilya Harvey
vilya.harvey@digitalsteps.com / digital steps /
(W) +44 (0)1483 469 480
(M) +44 (0)7816 678 457 http://www.digitalsteps.com/

0
Comment actions Permalink

Lars, I know and respect your wish. But if it makes my life harder, this features should be an option.

The current behaviour is counter-productive (for me). Take these issues:
1) in the attached screenshot, the scrollbar suggests, that there is more content below the visible area - there ain't
2) scroll down using the <![CDATA[ key. You will not be able to get fully down, because it stops at the last line (why the scrollbar still suggests there is more?). 3) press - strange, more (free area) becomes visible 4) press - more free space is shown 5) even after pressing the scrollbar is not at the bottom 6) use the mouse and move the scrollbar to the bottom, then press ]]> - the content scrolls up???
7) take the situation from 2), make an error and press F2 - the content scrolls down - strange, wasn't I at the end of the file

You see, there are more usability bloopers than advantages. The current solution looks completely unprofessional to me like half-done. Nothing seems intuitive.

Please FIX ASAP!

Tom



Attachment(s):
incorrect-scrollbar.png
0
Comment actions Permalink

I am very pleased with the new behavior even though I
would have taken it a small step further to achieve
complete consistency.


Cool, but what's with the other users? IIRC, IDEA worked perfectly with the old scrolling behaviour for over 3 years - nobody complaint about it. Why there was no option, so the feature does not effect people who think it is an anti-feature? There are so many options, one more does not hurt.

Tom

0
Comment actions Permalink

Well, my preferred editor (ConText) works like old IDEA and I like it.

I want to see the end of my text file when pressing Ctrl-End (or Page Down/Cursor down until the eof). I quite never want to write code at the end of the file, because we have different locations, where methods are inserted.

Tom

0
Comment actions Permalink

I agree that the scrollbar thumb may represent the viewport size (including any extra blank lines) instead of only the file content.

What I claim is that <![CDATA[, ]]><END>, and moving the scrollbar thumb to the bottom have to go to the exactly same position. Currently if you press <CTRL><![CDATA[ and then , ]]> moves the view up for about 20 lines! That's absolutely ridiculous.

And I don't see why all of us many who liked the 'correct' behaviour have to suffer from this strange and 'wrong' behaviour, only because a handful of people would like to have more than 5 extra lines. That's an excellent case for a simple configuration where most of us leave the standard 5 lines and you and some others can change it to whatever they want.

0
Comment actions Permalink

And I would NOT want to have to configure the amount
of extra empty space, at least not as a number of
lines, since the desired number would change if a
changed window size, font size, or if the layout
changed in later releases.


I did not talked about a line count. What about an percentage of screen-height? I would like to set it to 0.0, you may want to set it to 0.7 or 1.0 and everybody would be happy.

Tom

0
Comment actions Permalink

So there are two requests:

1) make <![CDATA[, , ]]> end at the same positiono

2) make the free space at the end configurable

IntelliJ, do you hear us?

Tom

0
Comment actions Permalink

Let me first say that I hope this will become an option so that as many users as possible can achieve a pleasing experience.

That said, I do want to object to your first point about the attached screen shot. The scrollbar does not promise you that there is more code to be found below, it says correctly that there is more viewable area to view should you wish to do so.

However, I absolutely agree that some of the various key presses you mention do act inconsistently. This is because the action handlers behind them still base their navigation on the number of lines in the file rather than on the total viewable area.

What would you say if Ctrl-End placed the last line of the file as the last line in the editor window? I certainly wouldn't mind, actually, I agree that sometimes we want to see the last lines of a file (and not an almost blank viewport). However I would expect to be able to immediately press PageDown and have the last line of the file move from the bottom of the viewport to the top of the viewport, enabling me to begin entering new code in the top of the viewport.

Couldn't this accommodate most wishes?

By the way, I also try to organize methods according to some reasonable and recognizable pattern, and I often add methods in the middle of the file.

However, when doing that I want to be able to position the viewport so the cursor is in the .... I'm babbling, you know what I mean :)

Best regards,
Lars Ugleberg

0
Comment actions Permalink

1) make <page down>, <ctrl end>, <cursor down> end at the same positiono


Much more consistent.
+10

2) make the free space at the end configurable


Everybody will be happy
+100

Guillaume Laforge


0
Comment actions Permalink

There is also an alternative implementation possible. Currently, when
pressing enter, IDEA scrolls the lower part of the screen down. What
about scrolling the upper part up?

--
Lars Köhler

0
Comment actions Permalink

What would you say if Ctrl-End placed the last line
of the file as the last line in the editor window? I
certainly wouldn't mind, actually, I agree that
sometimes we want to see the last lines of a file
(and not an almost blank viewport). However I would
expect to be able to immediately press PageDown and
have the last line of the file move from the bottom
of the viewport to the top of the viewport, enabling
me to begin entering new code in the top of the
viewport.


For me it's absolutely inacceptable and against all GUI design principles I know of that <![CDATA[]]><END> and <PAGE DOWN> move the view to different positions. I don't care if there were some (few!) empty lines at the end, but having jumping the view around when pressing <CTRL><![CDATA[ and ]]> is definitively wrong.

0
Comment actions Permalink

You gave the key word: The scrolling behaviour will be reverted to as it was in 3.0.x, and Lars can add some extra blank lines to his source files. Then everybody is happy! :)

0
Comment actions Permalink

Any solution for configuring this would certainly be fine with me.

Stop reading right now because the rest of this may very well bore you to sleep! I am still not particularly experienced in the field of usability design but I am learning through literature and experimenting with my own Swing applications.

Studies show that users usually don't complain about usability defects for several reasons:

- There are usually more significant issues that they feel even stronger about.

- They usually have difficult to identify exactly what part of the interaction that displeases them.

- They often find it hard to suggest changes because they don't know the limitations and possibilities of the platform/environment.

- They are inclined to suggest new solutions that also don't build on proven usability principles, since these are not common knowledge and not (always at least) as initial logical as one might expect.

This leads me to conclude that the following observations are true:

- Developers and designers need to study usability design rules and use this knowledge to make their own qualified decisions on how to implement various features. Otherwise, less sound solutions grow attached to the seat of the chair and become hard to get rid of in future. Persistent users learn to use even less usable products and of course they are annoyed when new knowledge suddenly leads to behavioral changes in the product.

- Good usability should not be achieved by offering numerous configurable options. All studies show that only a very few users spend time figuring out how to best configure their tools. Most users go with the defaults and judge the product from the default behavior. The default behavior should be based on sound usability rules, which are in turn based on years of studies of human behavior. Any deviation from these rules should require the user's intentional tweaking of the product.

- Experimenting with different approaches to achieve high level of usability should be done in-house and tested on a few target users. The wide user population should not be exposed to experimentation because each variation is likely to attract some users and displease others. Just look at the latest design changes of the Settings dialog. Experimenting publicly leads to a product that can be tweaked in so many ways that users soon may loose their way and can't make it work in a reasonable manner any longer.

Hey, stop snoring and get back to work!

Best regards,
Lars Ugleberg

0
Comment actions Permalink

Except Lars :)

Seriously, you're not suggesting that I add blank lines to my source files?

Don't think I didn't try early on even though the idea offended me from the start. But there are many obvious drawback to that idea, see if you can figure out the top 10 list yourself!

Best regards,
Lars Ugleberg

0
Comment actions Permalink

Seriously, you're not suggesting that I add blank
lines to my source files?


No, despite the fact that it would solve my problem it still wasn't meant that seriously! :)

0
Comment actions Permalink

Studies show that users usually don't complain about
usability defects for several reasons:
...
- They usually have difficult to identify exactly
what part of the interaction that displeases them.


Correct. Often they just say, the application behaves "odd".

This leads me to conclude that the following
observations are true:

- Developers and designers need to study usability
design rules and use this knowledge to make their own
qualified decisions on how to implement various
features. ...


Completely agree. Unfortunately my experience tells me, that some developers have a good feeling and some don't. The latter ones even do not learn it no matter how much good books they read (no pun intented!). Do you think a good master craftman can become a good architect by reading a lot of books (or visa versa)? No, he also need the "right feeling".

- Good usability should not be achieved by offering
numerous configurable options. ...


Absolutely agree. An application should have as least options as possible. The best is to find a "smart" way of implementing some features. But sometimes, see our discussion, different expectations completely contradict - then one cannot avoid an option (at least not a hidden one).

- Experimenting with different approaches to achieve
high level of usability should be done in-house and
tested on a few target users.


This is only successful, if the testing users are capable of finding bloopers.

Friendly,
Tom

0
Comment actions Permalink

That said, I do want to object to your first point about the attached screen shot. The scrollbar does not promise you that there is more code to be found below, it says correctly that there is more viewable area to view should you wish to do so.


I think this is more confusing than need be. I can't recall a time I have see the scrollbar behaviour you describe as "correct".

The scrollbar should convey information about the placement of the fragment viewed in the total file, and it's size should convey the real proportions between the fragment and the total file size.

- Jake

0
Comment actions Permalink

+100

I see your point Lars, and I agree. Having the posibility to edit the end of the file while looking at it on top of the viewport is a very comfortable feature, since I always (intuitively) try to adjust the viewport to accomodate this situation. (Try video filming your own behaviour during a session, it is very interesting)..

All the best
Chris

0
Comment actions Permalink

I just noticed that the annoying new behavior has been made configurable in build 1101.

Thank you, Jetbrainers!!

Best Regards,
Jens

0

Please sign in to leave a comment.