Icon-mime type associations
frans.englich at telia.com
Fri Sep 17 02:31:23 EEST 2004
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
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
> 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.
> 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.
More information about the xdg