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
Please sign in to leave a comment.
+ 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!
Completely agree on all points!
Please vote at http://www.intellij.net/tracker/idea/viewSCR?publicId=24903 .
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 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.
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
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
+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:
--
Vilya Harvey
vilya.harvey@digitalsteps.com / digital steps /
(W) +44 (0)1483 469 480
(M) +44 (0)7816 678 457 http://www.digitalsteps.com/
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 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
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
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
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 , ]]><END>, and moving the scrollbar thumb to the bottom have to go to the exactly same position. Currently if you press <CTRL> 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.
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
So there are two requests:
1) make , , ]]> end at the same positiono
2) make the free space at the end configurable
IntelliJ, do you hear us?
Tom
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
Much more consistent.
+10
Everybody will be happy
+100
Guillaume Laforge
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
For me it's absolutely inacceptable and against all GUI design principles I know of that ]]><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> and ]]> is definitively wrong.
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! :)
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
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
No, despite the fact that it would solve my problem it still wasn't meant that seriously! :)
Correct. Often they just say, the application behaves "odd".
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".
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).
This is only successful, if the testing users are capable of finding bloopers.
Friendly,
Tom
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
+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
I just noticed that the annoying new behavior has been made configurable in build 1101.
Thank you, Jetbrainers!!
Best Regards,
Jens