Re: [Usability]File renaming/extensions

[David Lazaro <david lazaro eresmas net>]

On Tue, 2002-08-20 at 16:05, Daniel Borgmann wrote:
> 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).

I develop software for windows and had never seen the need to "show all
extensions". Development apps register the file types and handle all of
them nicely. Although, now that I think of it... Buggers! :P In Windows
you get extensions always shown for DLLs, C files, C headers, C++
headers and so on...

Maybe the equilibrium is in showing extensions only for system and
development files?

> > 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.

The user should only need to remember what he is actually using. We also
have icons for all those kind of files now. (Nice work Tigert et al., by
the way)

> > 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. 

True. My opinion is that the file should be called "Read me
(Italiano).txt" where "Read me" with its Italian translation.

Not everybody needs to know about ISO country codes. With that name the
contents of the file would be readable by its intended Italian audience,
whether they know English or not.

My point is that with so much space for file names (255 chars) it is a
shame that we keep using those cryptic names taken from tradition. They
are good for the CLI but not for the GUI.

> > > 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.

I like the magic number approach too. But without showing what I
consider a confusing file extension.

> > 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)?

If it was a .txt file the user would never be able mangle its type
indicator (the extension).

> > I disagree, but keep the bug report, please
> 
> Do you mean "file the bugreport" or "keep it for yourself"? :)

You Choose! :)

But I will require a higher up opinion from Seth, Calum, Havoc or Louie
before sending it. Leaders should... well... lead. :)

So I would say that given the options I like "yourself" more :D

Cheers,

David