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 <[EMAIL PROTECTED]> _______________________________________________ Usability mailing list [email protected] http://mail.gnome.org/mailman/listinfo/usability
