Icon-mime type associations

[Frans Englich]

On Thursday 16 September 2004 22:54, you wrote:
> Frans Englich wrote:
> >On Thursday 16 September 2004 01:48, Ryan Gammon wrote:
> >
> >A common use of mimetype icons is to follow up the document/context
> > centric model; an icon tries to resemble what it represents as close as
> > possible in order to make the user's association steps as short as
> > possible. Functional names is another example. If cases like this(3rd
> > party branding, I guess) is the major reason for the usage of such an
> > mechanism, it would be a step backwards in terms of usability, AFAICT.
>
> I think it's a step forwards.
>
> Let's say the desktop alone controls document icons. I'd argue that
> there's no way the desktop can both know about all media types, and have
> icons representing all of them. New types get introduced all the time,
> not all icon theme maintainers have the time to write icons for all
> document types, etc.
>
> If the icon theme does not have a suitable icon, there are two things
> the desktop could do:
> - Show a generic file icon
> - Let the app provide an icon

There's a difference between adding mimetypes, and changing icons for existing 
mimetypes. The former is necessary for expandability and flexibility, while 
the latter is needed if the already selected icon(the theme) is wrong or in 
some way unsuitable. And that's the question; whether there exists valid 
cases for changing the icon.

>
> If we show the user a generic icon, it provides no information to the user.

I assume you mean "generic" as in the one the icon theme provides. I think 
that's slightly wrong. When the icon have a metaphoric image of its 
content( a speaker, notes, waves etc.), or a preview thumb nail shows the 
content, it is a direct mapping to the actual content. When its an 
application icon, the association is like this:

Application(for example Real Player) == sound == what I want

instead of 

sound == what I want

Of course, that assumes the user focuses on his/her documents, data, and task, 
instead of the tools(programs) which helps achieving the goals and accessing 
the documents.

>
> If we show a vendor-provided document, that at least tells the user
> "this is content I can play with the Helix Player." They can recognise

> that this file is a media file,

This is already communicated.

> and that it will open in Helix Player. I 
> think this is a step forward.

All modern usability is user, task, and data oriented, instead of whatever 
tools which are used to achieve that. Instead of looking upon the computer as 
the purpose in itself, it is just one of possible solutions; the user doesn't 
care about programs, but to get his/her work done. In open source this is 
usually missed by the attitude of that a pet-project is the middle of the 
world, and in the belief users are just as interested in the software as the 
hackers who wrote it. Among companies, they don't really care what is right, 
because they want the consumers to associate their product with what they do, 
for the sole reason they exist. In other words, I still don't see how 
associating a certain program with a certain task, gains the user or the 
system at large.

I think this is one area where open source, practically Free Desktop, have the 
opportunity to guard and value the consumer's rights, which is what differs 
it from other well known instances.


Cheers,

		Frans

>
> Now, the vendor icon is a neutral hicolor icon, so it might not match
> the surrounding icons, but that's more of a "should hicolor exist" kind
> of argument. It seems to have been decided that hicolor is a good idea,
> much to our satisfaction, or we'd be stuck trying to provide individual
> icons for every icon theme -- not practical.