New KListView - Grouping items

[Robert Knight]

> The goal of all this kind of improvements is to let them be configurable

I would prefer to see more emphasis on "doing the right thing out of
the box", and leave out extensive customizability in the first
iteration of a feature, it can always be added later.

My observations are that a common dialogue between KDE developers goes
like this:

first developer:  When the user does X , Y should happen.
second developer:  When the user does X, Z should happen.
first developer:  Lets make it configurable!
second developer:  OK

And a setting gets added to let the users choose, even though one of
options Y or Z is there for the wrong reasons, or perhaps the choice
of Y or Z can be done by the program itself depending on the context.
Once a setting has been added, it is difficult to remove again.  This
later leads to important settings, those for which large numbers of
users have different preferences on, getting lost in a huge
configuration dialog.  It might also be the case that neither Y nor Z
is ideal, and that there is a slightly better solution W.  If you
really force yourself to try and choose between Y and Z, then option W
is more likely to come up in the discussion.  That solution is less
likely to be imagined if you just add a setting to pick between Y or Z
as a compromise.

In your example you talked about "plugins" for selection drawing.  I
view that as a bad example of excessive configurability, because your
original email speculates about what preferences our users may or may
not have - it isn't based on actual research or feedback from users.

I expect that people with enough experience develop certain heuristics
that they can apply to determine what users are likely to change, but
how many of us ( apart from those who are usability professionals )
have that experience?

Regards,
Robert.

On 11/02/07, Rafael Fernández López <ereslibre at gmail.com> wrote:
> 2007/2/11, Robert Knight <robertknight at gmail.com>:
>
> > Hello,
> >
> > I had an unoriginal idea about a useful new feature, which could be
> > implemented as part of the new KListView class.
> >
> > Something Windows Explorer has had for a long time is the ability to
> > group sets of items into various catagories, with a divider drawn
> > between each group.
> >
> > For example, if you sort by size and enable grouping, the items are
> > divided into "Large", "Small", "Medium" etc.
> > If you sort by type and enable grouping, the items are divided into
> > "Image", "Music", "Text" etc.
> >
> > This particular feature I like very much, although I can think of a
> > few improvements to it, such as being able to collapse/expand groups
> > and displaying a small amount of summary information - such as file
> > count etc. next to the group caption.  As a power user, the ability to
> > control the granularity of grouping would be useful - although that is
> > very much an "advanced, useful if you have spare time" feature, and
> > not perhaps not appropriate for say, Dolphin.
>
> The goal of all this kind of improvements is to let them be configurable. So
> we can write it, and then most of users (if it is nice) will have it
> enabled, and others that are more nearly to X and terminal will disable it
> :P.
>
> Apart from the joke, I find it a very useful way to show information. I
> would really like to know if I will be able to commit when I have it
> prepared the KListView class, or as I heard somewhere Trolltech wouldn't
> like whole class rewritings. I just want to recall KListView inherits
> QListView, not QAbstractItemView, so any changes done to QListView will be
> visible from KListView, so it is not "another list view class apart from
> QListView", it is written on top of QListView, but just gives some more
> functionality.
>
> I would like to know what other thinks about your proposal Robert.
>
> Bye and thanks,
> Rafael Fernández López.