Re: [Usability] An extended default applications dialog

[Kai Willadsen <kaiw itee uq edu au>]

On Thu, 2007-01-18 at 19:47 +0000, Matt Medland wrote:
> > (Not currently subscribed to the list.)
> > 
> > Yep: it's probably not likely to work that well. You're going to end up
> > with an arbitrarily long list of different "types", most of which aren't
> > going to be interesting to people. Even assuming that you make it less
> > scary with categories, and replace "x-ico" with "ICO image", "x-bmp"
> > with "BMP image", etc., you're looking at a huge list in which it's
> > impossible to find what you're looking for. 
> 
> This could be solved (almost) by only having the long list's in the
> Exceptions bit in Christian's mock-up. Then the user would rarely have
> to see a huge list.

This certainly moves the problem to a less obvious location.

> >Last I looked, the
> > equivalent KDE dialogue 'solved' this with a search box at the top.
> > Maybe I'm alone in this, but I think that once you start adding search
> > boxes to dialogues, you know you've gone wrong somewhere.
> 
> unless it's done well. The filter in the Gnome Control Centre in Ubuntu
> feisty is an excellent use of search in my opinion, it uses it
> tastefully and it is near real-time.

True, but that's not what I was saying. The fact that the control centre
*needs* a search box is in and of itself a bad sign. It would be nice to
try and design an interface that works without a search box before
resorting to search.

> > Categorisation is also a dubious way of making the dialogue more usable;
> > you end up with an arbitrary set of categories that may or may not make
> > sense to an individual, and you inevitably show people types that they
> > know *nothing* about. As a Latex user, I'm going to expect Latex
> > documents to be in the same category as Openoffice files, but I'm not
> > sure that my parents would see the association between rubber products
> > and their word processor.
> 
> Again, if the categorisation is done well, and thought out there is no
> reason that it can't work (in my opinion). Christian's mock-up is a good
> solution, someone may be able to do better. As I said above, in his
> mock-up the individual file-types would be tucked away in the exceptions
> bit, so most users wouldn't need to see them.
> 
> If you haven't seen Christian's mock-up there is a link somewhere in
> here: https://wiki.ubuntu.com/Usability/SpecEnhancedPreferredApps

It's an interesting approach, and it addresses a use case that isn't
addressed by the current system. I personally feel that corner-cases are
likely to interfere with it working properly, but that's a pure hunch.

IMO, enumerating all of the specific file types that people are likely
to care about is going to get ugly. The expectations about what file
types are easily configurable (i.e., without getting into exceptions)
may well be long and somewhat confusing. For example:
* PDF files are probably a top-level item, PS files are not. They
clearly come under the same category; what would it be called?
* Photos != jpg/gif files downloaded from the web. These are actually
probably the same file type, which is fun.
* Vector graphics != raster graphics (but try explaining that to a
random user). I don't want to view svg files in the GIMP, I want to view
*all* vector graphics in Inkscape. Would vector graphics be exposed as a
top level type? it's clearly a sensible group of file types.
* All office types are sensible top-level types, but I suspect that
users (particularly people running MS Office under wine) are more likely
to think in terms of OpenOffice files vs. MS Office files than in terms
of Spreadsheet, Word Processor, etc.

I realise I'm being pretty negative here, and I feel bad because the
interface looks so nice and elegant, but the corner cases seems to be so
incredibly messy. I could attach a screenshot of file-roller telling me
it can be my default word processor if that helps. (I assume it's trying
to claim that it can open the gzipped xml files used by various office
components.)

> > At least back then, the feeling seemed to be that the Preferred
> > Applications capplet should be killed altogether. Even today, it's only
> > useful because there is no other means of configuring protocol (i.e.,
> > http:, mailto:, etc.) handlers.
> 
> I feel something like this would be very useful, the easier it is for a
> user to control what happens when (s)he opens a file the better in my
> opinion. The more control a user has, while keeping it simple, the better.

As far as I can tell, the proposed system doesn't actually add any
control that the user didn't already have; it just makes one aspect of
it (changing a lot of similar file types quickly) easier. It also means
that the same configuration is present in more than one place,
potentially confusing the user.

One of the nice things about the current MIME system is the association
between action and situation: the time at which I'm most likely to want
to change the association of a file is when I've got the file in front
of me.

You could make a similar argument for the additional use case solved by
this approach: the time at which I'm most likely to want to reassign
lots of file types is when I've just installed a new application (or
installed a new system), and I want to open all files of a given type in
it. By that reasoning, batch-changing of file-type associations should
be associated with an application.

-- 
Kai Willadsen <kaiw itee uq edu au>