Re: [Usability]File renaming/extensions

[Daniel Borgmann <daniel liebesgedichte net>]

On Tue, 2002-08-20 at 16:42, David Lazaro wrote:
> > One of them was, that I remembered that I always disabled it in Windows
> > so if I would disable it, it would not solve the problem for me. :) Of
> > course it could be combined with another solution, but so much trouble
> > and coding and crack for what?
> 
> I am afraid that you are not a typical user, and that is a compliment.
> ;)

Well, as you can gather from this list, many people would disable it and
if the option is there to disable it, then it has to be taken care of
anyway and all this rats tail. :/ Finding a consistent solution for
everybody should be prefered (if possible, which I think it is).


> Extensions were not necessary in the past. They served the function of
> customizable icons. C files have always been .c and .h files since the
> first incarnations of Unix. Then you do an ls and you can grasp what
> kind of files they were. Makefiles also depend on extensions for they
> most complicated tricks. So I am afraid that we must live with them for
> a long, long time.
> 
> For us, developers, they are natural. But for users that have only used
> Mac OS, they aren't. They have always seen the extension in a nice panel
> as a four letter code, for example.

Developers are also users, just more advanced users. Usability is not
just for the casual user. That is IMO even one the biggest problem of
the current Unix desktops. It's very easy to use for the complete
beginner but those people who want to do something more are screwed and
that's not good. So if file extensions are neccessary to make files like
C source and header files even usable, it shouldn't even be a thought to
disable them. Or do you have a better idea how to make clear what kind
of file it is? I mean it's easy to tell the applications but how do you
tell the user? Creating different icons for every kind of sourcecode,
image, archive, etc? How should a user remember them all? That just
doesn't seem to be a good idea to me.


> Nautilus also depends on extensions. For a strange reason the file
> README.it on every Red Hat 7.x x86 disc 1 is recognized as a impulse
> tracker file with a nice score pictured on the icon. Not that I think
> that the Italian accent isn't musical and very nice... but Nautilus
> botches it because it depends on extensions.

Indeed, that is bad. But this is a problem of Nautilus file handling. If
it would hide the extension, it would be even worse! Neither would you
know that this README is written in italic, nor would you have any idea
that it isn't actually musicfile. 


> > Oh and about the "extensions are a thing of the past" thing, I would
> > agree with that but that's exactly why we don't need to hide them. :) If
> > they aren't neccessarily used to determine the filetype anymore, there
> > is no reason to hide them as they are simply part of the name now. 
> 
> Well they are a thing of the past but will have to stay for a good deal
> of time due to all the programs that depend on it.

That's not what I meant. I like the thought that applications shouldn't
rely on file extensions but I see that as a reason not to hide them as
they are part of the name, not filetype indicators. The README.it is a
prime example. Removing the fileextension would make it useless. While
the actual problem (showing the song icon) would go away if Nautilus
wouldn't rely on the file extension but not at all by hiding it.


> Uhm... Let a user create a README.it file... ;) From past experience
> some people will first think that they have created a new song. Truly!
>
> You are preventing possible errors. This is a basic usability principle.

How exactly does hiding the extension prevent this possible error (which
isn't an error anyway, as naming a file "README.it" should be very well
possible)?

 
> I disagree, but keep the bug report, please

Do you mean "file the bugreport" or "keep it for yourself"? :)

- Daniel