Re: compact view removed from Nautilus

[Mikkel Kamstrup Erlandsen <mikkel kamstrup gmail com>]

On 2 July 2012 22:18, Allan Day <allanpday gmail com> wrote:
> Hey Adam,
>
> Thanks for your responses. Comments inline...
>
> Adam Dingle <adam yorba org> wrote:
>>>* Horizontal scrolling is unergonomic with mouse and touchpad input
>>
>> It's true that the mouse scroll wheel moves vertically and compact view
>> scrolls horizontally, but that takes only a moment to get used to.  I see no
>> reason why scrolling on a touchpad would be any more natural vertically than
>> horizontally.
>
> The problem is the way fingers and wrists work. :) The human hand is
> not well suited to horizontal movement with a mouse/touchpad (unless
> you're using a scroll wheel).

I think you got this backwards.

When you rest a human hand on a desk it is expressly suited for
horizontal left/right movements, and *not* very well suited to move
vertically up/down. For horizontal movement you use your wrist as a
pivot point giving you very precise and flexible movements.

SNIP
>> To me, the compact view is essential because it's our only view which
>> displays files in a layout where filenames have significantly greater
>> density than icons.  This is important in the (extremely common) case where
>> you're looking at a large number of files in a directory and care more about
>> the names than about the icons.  List view is inappropriate for this use
>> case because it shows too much detail about each file.  To put it simply,
>> compact view is like 'ls' and list view is like 'ls -l'.
>
> I think there are a lot of ways that list view can be improved to fit
> these requirements. Jon has already gone some way towards making the
> noise level lower by sanitising the date formats. Another thing we can
> do is (which I think he's going to look at) is improve zooming so that
> you can have the icons become less significant in comparison to the
> text.
>
> In general, I much prefer this approach of concentrating on one or two
> views and putting effort into making them work really well. And if
> we're improving the defaults, then the maximum number of users benefit
> from that work.

Tighter focus in the user experience is a commendable goal. I can only
support that.

However, as software development usually goes, important features are
not removed before you have something to fill the void. If there is a
suitable replacement for a feature it makes good sense to remove it.
In this case I don't see a suitable replacement. Yet.

So my plea is to remove it when you have an actual codified solution.
Not at this point where the solution is still just talkware.

Cheers,
Mikkel