file dialog: horizontal file list vs. vertical

Hello everyone!

Aaron's post reminded me of an usability issue. In the file dialogue you get a
file-list to pick from. Yet while file-lists in dolphin, folder-view, digikam
etc. are all vertical, the file-dialogue is the only one that has a horizontal
list.

Why does the user have to behave differently in the file-dialogue than in any
other file-list? Or to put it differently, why not make the file dialogue list
scroll vertically?

As a side-effect: If the filenames and the dialogue size fit perfectly, the
user does not see the next column of the list and because we are used to
vertical scrollbars, a lack of it mediates that there are no more files in
that list. The horizontal scroll-bar, is common in browsers, but only if the
content does not fit the width, so it is not associated with "more files to
the right" but "filenames too long for the width". This issue would be gone as
well.

Sven
_______________________________________________
kde-usability mailing list
kde-usability@...
https://mail.kde.org/mailman/listinfo/kde-usability

[Benno Dielmann]

| Aaron's post reminded me of an usability issue. In the file dialogue you
| get a file-list to pick from. Yet while file-lists in dolphin, folder-view,
| digikam etc. are all vertical, the file-dialogue is the only one that has a
| horizontal list.
|
| Why does the user have to behave differently in the file-dialogue than in
| any other file-list? Or to put it differently, why not make the file
| dialogue list scroll vertically?

You can, it's optional - just choose Detailed View in settings or press F7...

| As a side-effect: If the filenames and the dialogue size fit perfectly, the
| user does not see the next column of the list and because we are used to
| vertical scrollbars, a lack of it mediates that there are no more files in
| that list. The horizontal scroll-bar, is common in browsers, but only if
| the content does not fit the width, so it is not associated with "more
| files to the right" but "filenames too long for the width". This issue
| would be gone as well.
|
| Sven
| _______________________________________________
| kde-usability mailing list
| kde-usability@...
| https://mail.kde.org/mailman/listinfo/kde-usability

_______________________________________________
kde-usability mailing list
kde-usability@...
https://mail.kde.org/mailman/listinfo/kde-usability

Am Dienstag 26 August 2008 09:04:32 schrieb Benno Dielmann:

> | Aaron's post reminded me of an usability issue. In the file dialogue you
> | get a file-list to pick from. Yet while file-lists in dolphin,
> | folder-view, digikam etc. are all vertical, the file-dialogue is the only
> | one that has a horizontal list.
> |
> | Why does the user have to behave differently in the file-dialogue than in
> | any other file-list? Or to put it differently, why not make the file
> | dialogue list scroll vertically?
>
> You can, it's optional - just choose Detailed View in settings or press
> F7...

I can do a lot of things, yet by default it is different than the other lists.
What's the reason for that?

Sven
_______________________________________________
kde-usability mailing list
kde-usability@...
https://mail.kde.org/mailman/listinfo/kde-usability

Hi Sven,

> Hello everyone!
>
> Aaron's post reminded me of an usability issue. In the file dialogue you
> get a file-list to pick from. Yet while file-lists in dolphin, folder-view,
> digikam  etc. are all vertical, the file-dialogue is the only one that has a
> horizontal list.
>
> Why does the user have to behave differently in the file-dialogue than in
> any other file-list? Or to put it differently, why not make the file dialogue
> list scroll vertically?

I think the reason is that the file dialog usually has a smaller available item-area than an application; the current layout of a "list-view" (= ordering items in columns from left to right) offers a maximum number of visible items.

But I agree that the "list-view" in it's current form has some drawbacks:

- If the width is too small, you cannot differ between a filename
  like dolphindetailsview.h and dolphindetailsview.cpp as both items
  are shown as "dolphindetailsv...". Providing a tooltip might help, but this
  might only bypass the problem and does not solve the root of the issue.

- I guess that users are more familiar with the vertical scrolling than with
  the horizontal scrolling. Especially when using the mouse-wheel, at least
  for me it does not feel natural to scroll the wheel down to move to the
  right...

Just to have a common understanding: The current default view (let's call it "list-view") does a horizontal scrolling, the icon is aligned on the left, the text is right beside the icon. The ordering of the items is done per column from top to bottom, the columns are aligned from left to right.

When talking about having a "vertical scrolling", we must precisely talk which kind of view type we want to have.

1. Icon on top, text below (= Icons view in Dolphin). Drawback: requires quite a lot of space even if the icons are small.

2. Details view (= Icon on the left, followed by the file name, date and size). Offers already a vertical scrolling. Drawback: Not as much items are visible like in the "list-view", additional clutter by the columns date and size (this information might not always be needed for some users).

In bug-reports for Dolphin some people suggested just using the "list-view" and doing a vertical scrolling, but this does not work. The eye reads column by column from top to the bottom like in newspapers. Assuming we have the items A to Z. If we would introduce a "list-view" with vertical scrolling, the following would happen:

--- start visible area ---
A        L        W
B        M        X
C        N        Y
D        O        Z
E        P
F        Q
--- end visible area ---
G        R
H        S
I        T
J        U
K        V

So the eye would scan A to F, L to Q and W to Z. Problem: try to find "I" and quickly tell me whether you do it by using column 1 and 2. You see: you really have to think about this... So for the user this approach means that he needs to scroll like hell and this is the reason why no file manager uses the "list-view" with vertical scrollbars. Using the following approach also does not work (just try to find "K" in a quick way):

--- start visible area ---
A        B        C
D        E        F
G        H        I
J        K        L
M        N        O
P        Q        R
--- end visible area ---
S        T        U
V        W        X
Y        Z


So if we really don't want the list-view in the file-dialog, we must  try to find a solution like 1. and 2. (or someone has a completely new idea ;-)).

Best regards,
Peter

> As a side-effect: If the filenames and the dialogue size fit perfectly,
> the user does not see the next column of the list and because we are used to
> vertical scrollbars, a lack of it mediates that there are no more files in
> that list. The horizontal scroll-bar, is common in browsers, but only if
> the  content does not fit the width, so it is not associated with "more files
> to  the right" but "filenames too long for the width". This issue would be
> gone as well.
>
> Sven
> _______________________________________________
> kde-usability mailing list
> kde-usability@...
> https://mail.kde.org/mailman/listinfo/kde-usability

_______________________________________________
kde-usability mailing list
kde-usability@...
https://mail.kde.org/mailman/listinfo/kde-usability

Am Dienstag 26 August 2008 09:00:46 schrieb Peter Penz:
> When talking about having a "vertical scrolling", we must precisely talk
> which kind of view type we want to have.

Maybe we should ask, whether we do want to make a difference between browsing
files in a file-dialogue and browsing them in dolphin? Why is there a
different view, if the task is the same?

Obviously there are some differences, i.e. it might make sense to only display
certain types of files (filters) or add functionality like "add file-
extension", but those are just tools that are added because of the context and
do not necessarily mean that the view has to be different or smaller.

> 1. Icon on top, text below (= Icons view in Dolphin). Drawback: requires
> quite a lot of space even if the icons are small.

Why does the file-dialgue have to be smaller than the window it is opened
from? Would it not make things a lot more comfortable, if it was bigger than
the current size? More space for the list, more space for the preview, less
scrolling. What are the drawbacks of using available space?

What's the difference between the user browsing files in dolphin and the file-
dialogue?

> 2. Details view (= Icon on the left, followed by the file name, date and
> size). Offers already a vertical scrolling. Drawback: Not as much items are
> visible like in the "list-view", additional clutter by the columns date and
> size (this information might not always be needed for some users).

If the size of the file-dialogue was not restricted to being small, why not
use whatever dolphin uses for that folder, i.e. whatever the user has set as
his preference?

> In bug-reports for Dolphin some people suggested just using the "list-view"
> and doing a vertical scrolling, but this does not work.

Indeed this would not work.

Sven
_______________________________________________
kde-usability mailing list
kde-usability@...
https://mail.kde.org/mailman/listinfo/kde-usability

Sven Burmeister wrote:

> Hello everyone!
>
> Aaron's post reminded me of an usability issue. In the file dialogue you get a
> file-list to pick from. Yet while file-lists in dolphin, folder-view, digikam
> etc. are all vertical, the file-dialogue is the only one that has a horizontal
> list.
>
> Why does the user have to behave differently in the file-dialogue than in any
> other file-list? Or to put it differently, why not make the file dialogue list
> scroll vertically?

I believe this comes from the fact that the current dialog is not tall
enough by default. Make it more or less square by default and I think
you can set the file-list to be vertical.

I don't see any reason for this dialog to be as thin as it is. It
appears as a request of the user, so I believe he won't mind if it takes
the necessary space to make it confortable to choose files.

Aurélien
_______________________________________________
kde-usability mailing list
kde-usability@...
https://mail.kde.org/mailman/listinfo/kde-usability