Icons of program

[tom mystery antar com (tom)]

i have given this several days of thought, so please flame me *after* reading
all of it. thanks.


this is a proposal on how to handle the icon problem. it is not perfect nor do
i claim it to be, but i'd like to lay this out as the general concept or
guideline. even if you don't agree, i think it's a good point to start from
something structured and improve from there.


overview - main points
======================
unix has a different filesystem, file-structure and fs-philosophy than windoze,
 mac or amiga. this structure has been field-tested for over 20 years now and i
think it would be arrogant to say "it's not good for us, let's do away with
it."
the second main point is that i object to the idea that the system needs to be
hidden away from the user. this is the windoze philosophy and when i look at
what its results were, i look at millions of people who *think* they should be
able to handle their computer, because marketing tells them how "easy" and
"intuitive" everything is, but who in reality can't. the net result is that
they feel even dumber than before. as a second note, it has been said that the
user should not see the system itself, only the sysadmin should. but the huge
majority of the people we are talking about will (have to) be their own
sysadmins - people running gnome on their home-pc. these are the people who run
everything as root because they don't grasp the user concept. i don't think we
should make their life even more difficult.


conclusion - general thoughts
=============================
the job of a gui is to make the user's work easier, and the learning curve less
steep. a gui should employ real-world concepts to make using a computer more
intuitive. a good example is drag-and-drop: people use it all day, grabbing
something, moving it to where it belongs and dropping it. all you have to do is
teach them that on the gui they do it with the left mousebutton (or whatever) -
you don't have to explain the concept to them.

icons are a subset of a gui and serve the very same purpose. people are used to
having a small picture of whatever is in the box on the outside of it, they are
used to taking a scetch or graphic of something as a representation of the real
thing. and icons job is to make an application easily identifiable in the same
way as the pizza box at your supermarket has a picture of the pizza on it, 
instead of just the word "salami pizza" - people grasp pictures faster than
text, and a salami-pizza-picture is faster found amoung the various kinds of
pizza than a box with "salami pizza" written on it.

an icon should identify the *type* of file one has, not the exact contents. so
there should be an icon symbolizing "graphics file", maybe even (slightly!)
different ones for different kinds of graphics, but not a thumbnail. the
reasoning is that if there are too many different icons, the advantage is lost
as the user has yet again to start looking at every single one instead of
getting with a single look that, e.g. he has a directory full of html-pages in
front of him with three graphic files inbetween.



implementation
==============
unix has a different philosophy than windoze. while in windoze every
application has its own directory, in unix files are sorted according to
function, not application. files in /usr/bin don't have to have an .exe
extension to make clear that they are executables.

furthermore, unix usually has lots of small executables, whereas the usual
philosophy on windoze is to put everything into one file.

both points give enough reason to go for a different concept.

i suggest to have icons in a different file (one for each icon) and to put all
these icons into two places on the system, one system-specific, one user-
specific. the first could be /usr/X11/include/X11/icons, the second could be
~/.gnome/icons - these are examples, i don't want to discuss the exact
directories at this stage.

having icons in their own file has several advantages:

        - you can use any existing format, like xpm for example,
          for them and you instantly have all tools needed to view
          and edit them, while the windoze way requires specialized tools.

        - it doesn't blow up executables and makes reuse of icons
          far easier (almost automatic, actually).

        - it is more portable across different platforms.

        - it is more consistant

        - it is easy to define icons based on extensions as a fallback
          by defining a simple standard, one obvious example (with the
          disadvantage of colliding with the hidden file standard, but
          for examples sake:) would be to define ".html.xpm" to be the
          standard item for html files.

        - it is possible, as a second fallback mechanism, to define
          standard icons based on filetype (i.e. result of the file cmd).


having all icons in only one or two places has several advantages:

        - it is far easier to check, modify or delete icons.

        - there are no problems with access rights.

        - the link from file to icon does not break if the file
          is moved or copied around the system.

        - directories are not unnecessarily cluttered. the typical
          users' /usr/bin directory has more than 500 files - it would
          be a terrible mess to put a further 500 icon files into it,
          *especially* as this violates the unix concept of having only
          executable files in /usr/bin.
          nb: putting filename.icon files into the same dir also has the
          very unfortunate side-effect of ruining the shell-completion
          functions.

        - as the icon directory is most probably often consulted, the
          kernel will keep it cached with no extra work on our part
          required, which will speed up the process of looking up icons.

        - because of the unix filestructure, there is little danger of
          collisions, i.e. files with the same name serving different
          purposes. those files which *do* have the same name also nearly
          always serve the same purpose (makefiles, configure, readme, ...)
          and thus can just as well have the same icon

        - there can be icons for directories based on their name. s.b.




additions - some ideas
======================
i suggest to extend the icon concept from files to everything else that the
unix filesystems offer. especially there should be icons for directories. with
a suitable icon, no user will be confused about what /usr/local/bin contains. i
consider this a very important point, as different from the windoze world, the
directory structure on a unix system was built to make sense. icons are the
perfect opportunity to visually display this meaning.
other items of the filesystem can easily get icons as well, just think of all
the entries in /proc and /dev.

it should be made sure that there is always a visual difference between an icon
as we discuss it currently and an iconified application. this is a major hassle
with cde - the difference is not as clear as it should be.

if there are icons, users _will_ drag&drop them. as i said in the beginning,
icons are representations of the real objects. if an html-file is displayed as
an html-icon, the user _will_ drag it into netscape and expect netscape to open
this file.



enough for today. i'm awaiting your flames. :)