Re: Nautilus search, memory usage, hidden files, webinterface


On Nov 16, 2007 8:28 AM, Nirbheek Chauhan <nirbheek chauhan gmail com> wrote:
> On Nov 16, 2007 2:53 AM, Bjørn Haagensen <bhaagensen gmail com> wrote:
> > 4. Could there be an option for collapsing all hits in the webinterface ?
> Why exactly do you need an option for collapsing all the hits in the
> webinterface? I'm not asking this because I think there shouldn't be
> one, but to see the deeper need for such a feature, and whether that
> need can be used to fix other features of the webinterface :)
> Is it because you feel there are too many hits to browse through? Or
> that you feel that you can find the result you're looking for simply
> from the title of the result? Or is it something else?


I'll try. I realise it's work in progress, so I'll be a bit verbose.
Generally the sheer amount of information makes it difficult to parse
for me. Lots of scrolling and no usable visual formatting clues to
guide my eyes. All the extra info distracts and is difficult to use.
E.g. it is difficult to choose
a property, say date, and skim the results for hits close to the
desired date. Since usually the title, path, and perhaps type are
required (must) to find what I'm looking for, I would prioritise being able
to quickly identify those. It depends on the backend though. For mail
messages the type and sender/reciever is nice.

I think it would be cool to extend the paradigm with graphical
widgets, currently used for results types. A cool thing could be
sliders for setting date interval,
pagenumbers, filesize etc.

Perhaps a "design guideline" could be something like using graphical
widgets such as sliders, check-boxes etc. for properties which are
common and have a common format, or just for which it can be done in a
meaningful way. E.g. date,
size, etc. Then this info would not need to be displayed along with
the results.

Properties which are not common should be hidden/collapsed by default.
When uncollapsed they should be formatted in such as way that one can
from the shape/color/etc identify the desired one(s). An example of
such a property could be sender/reciever/subject in mail messages, or
author etc. in documents.

Anyway, I'll stop here since this might not make sense at all. I'll be
happy to answer questions of course.

Thanks, Bjørn

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]