Feedback to new Files startup screen - and a case for showing all file types

[Thomas Pfeiffer]

On 12.11.2012 11:41, Aaron J. Seigo wrote:
> On Monday, November 12, 2012 10:03:42 Thomas Pfeiffer wrote:
>> What users expect is to first see _all_ files and then be able to narrow
>> them down until they see the one(s) they are looking for. This is how
>> filtering works. First show everything, then reduce the results. If this
>
> i agree that being able to start with any set of filtering criterion (filteype,
> tag, time) would be nice and should make it on to the functionality
> improvement list.

Absolutely. And in that case, we wouldn't even need the UI to be different 
before something is selected (which makes the UI more calm): Just show the whole 
UI right from the start so users can choose any filter/search to begin with. Two 
birds with one stone.
For me this is more than just "nice": It is to be expected. When I already know 
the name of the file I am looking for or when I'm looking for a certain tag, why 
would I need to select the file type first? This would be just an unnecessary 
additional step.

> showing everything immediately not only slows down initial presenation
> (nothing to do with Nepomuk; this would be equally true if we just listed
> every file in the user's home directory with normal filesystem reads), what is
> the benefit of that? or put differently: how often do you want to see "all of my
> files alphabetically"? if that is rarely / never the case then why use that as
> the default presentation?

Counter question: How often do you want to see "All of my 
documents/pictures/music files/etc." alphabetically? Not much more often, I 
suppose ;)
I agree that showing all files in an unfiltered way isn't of much use, but file 
type isn't a better starting criterion either, because it doesn't reduce the 
amount of files shown to a useful number (1/4 or 1/5 of "too many" is usually 
still "too many").
The idea to make users select the file type first seems inspired by the current 
situation on Unix systems with the typical filetype-related folders in /home or 
in Windows with the filetype-related subfolders in the "My Files" folder. That 
makes some sense in folder hierarchies as it reduces the number of folders in 
the home directory by adding another hierarchy level (and can be used by 
applications as default saving folders).
There you have to choose filetype first because you have to drill down through 
the hierarchy, but this structure is optional, every user is free to just put 
their own hierarchy in place, ignoring the default top-level folders (and I know 
many people who do just that).
But that's where we're better: You don't have to drill down but instead you can 
look for any criterion you like immediately (which can be file type but is just 
as likely to be a different criterion).

Still I think a UI consisting of mostly empty space until you select something 
is rather confusing, so I think what we should show is something that tells the 
user "Choose a criterion by which to search and I'll show you the results". Even 
just putting a message "Select a filter criterion on the right or enter a search 
term above" in the main area which disappears as soon as something is 
tapped/entered would be better than nothing. Or just putting big arrows in there 
that point to where you can select a filter or enter a search term. Anything 
that makes clear
a) why currently no files are shown
b) what you can do to make it show files
Currently it just looks weird because usually file browsers show you _something_ 
in the main area when you open them.

> i'd also suggest that showing all the files immediately will encourage people
> to simply page through the long list. having them first make a selection
> (either by searching or by selecting some filters to start applying) encourages
> "correct" (or at least more efficient) usage.

Agreed. But we have to make clear to them what we want them to do (see above).

> perhaps where this gets confusing is that since Files starts with the null
> set, initial interaction results in additive filtering. further interaction can
> result in subtractive filtering. this is a common interaction pattern in daily
> (non-computer) life for people, so i'm not convinced it's bad.
>
> consider deciding on a hot drink on a cold day .. tea or coffee? only once i
> pick "tea" am i actually presented with concrete items and choices, perhaps in
> the form of a box of tea bags .. (additive) and now i get to pick: which kind
> of tea? (subtractive) cream / sugar? (additive again). moving between additive
> and subtractive modes is quite easy for us ...

Yes, but you can also go to the cafe and say "Earl grey tea please, with milk 
and sugar".

> perhaps a useful question is whether we are trying to create a set that
> matches an internal set of criterion ("i like black tea, but it needs to be
> sweetened to not be bitter") or are we combing through a general set for a
> pre-selected item ("i'm looking through a jigsaw puzzle box for pieces with
> straight edges with blue sky on them")
>
> the mental processes are not the same. i wonder which Files is currently
> better suited to, and which it ought to be made for.

Currently the startup experience is definitely better suited to indistinct 
browsing (if nothing else, you always know the type of the file you're looking 
for, so in that case it's a useful first step). If you are looking for something 
more specific, selecting a filetype first is unnecessary.
I think both modes (browsing and searching) are equally important and should - 
and can - both be accommodated.

> i'm going to do some digging over the next couple to see what i can find about
> this in academia.

Ok.