[RFC] "Documents Folder" icon in "system:/"

[James Richard Tyrer]

Kévin Ottens wrote:
> Le Mardi 2 Août 2005 02:53, James Richard Tyrer a écrit :
> 
>> Why would they think that?  Wouldn't they see a HOME folder and a 
>> User folder?
> 
> 
> Hum... yes of course, and the home folder IS the user folder hence
> why I think this icon is misleading.
> 
We do need to separate these two classes of files.  Nothing is gained by 
mixing the user's files and the computer's files.  This has been an 
issue since DOS 2.x
> 
>> What!!  If we call them all personal files we are just begging the 
>> question.  The question then becomes which personal files.
>> Personal data files or personal configuration and administration
>> files.
> 
> Personal data files since personal configuration and administration
> files are all hidden on a properly setup system.
> 
Yes, personal (or usr) configuration, executable, and administration 
files as opposed to personal data files which the user will load into 
application and save from applications.

Well, most systems are not "properly setup" then.  Actually, in addition 
to those configuration files that are supposed to be hidden (some are 
NOT), there is also a "bin" directory.  I also have an Install directory 
with some misc. stuff in it, but on a real multi-user system (where you 
don't have root privilege), if you install software for a single user, 
you are going to have a lot of stuff that isn't hidden.  You are going 
to have source files in "src" and when you install with a prefix of 
$HOME, you are going to have a lot of stuff that isn't hidden.
> 
>> Actually, you are creating confusion by calling it "Documents
>> Folder".
> 
> Maybe because it's described by the "documents path"?
> 
Other people told me that this confused users.  The example was that the 
user that saved their video files in HOME rather than Documents because 
they didn't think that they were documents.  Not good from a usability 
standpoint.  If Documents isn't HOME, when they open their video viewer, 
the default directory isn't the correct place.
> 
>> Then to base the choice of icon on this poor choice of a name only 
>> compounds the problem.
> 
> Well, you reduce the problem here. This icon proposal is bad IMHO
> because it could be confused with the home folder, I don't care if
> it's used for the documents folder or another one.
> 
I simply took what it said: "Your personal files" and used the 
"personal" icon.  Try to see this from the engineering perspective. 
Don't say that the icon is good or bad, but if you think that you have a 
better idea, by all means come up with one.  I thought that it was 
better than "folder_important", but perhaps that was only temporary.
> 
>> And, it is going to come down to what you mean by "_documents_".
>> Are documents all a user's application data files or are they just 
>> wordprocessor files?
> 
> Well, "document" is an ambiguous term, it's often used with different
>  meanings. My purpose is to avoid enforcing one particular definition
> to the user since in the end, "document" is just a status we give to
> a particular object (in our case files), it's really user's choice.

Yes, but perhaps a better term would be better for the "Joe User" types.

> To be more precise, most users I know have some of their "application
> data files" in the "document folder" because they consider they
> provide a particular information _to them_ and other "application
> data files" are at other places in their home folder.
> 
Yes, that is the problem that I think that we need to avoid.  My, 
"Documents" directory is currently called "Files" and I have it divided 
up into various kinds of user files.
> 
>> I proceed from the idea that "Documents" was a poor choice of words
>> but we are now stuck with it.
> 
> I agree here because of the use of "document".
> 
Stuck with it in the code, but we can use something else for the user. 
Some have suggested that we need to have the actual folder name language 
specific.  Not a bad idea.
> 
>> It would be much clearer to call it "User Files".
> 
> I don't think it's really better...
> 
It would probably avoid the person putting the video files somewhere 
else.  If we call it "<something> Data" they will say that it is too 
technical.  "Personal Files" is OK with me -- I chose "User Files only 
because it was shorter.
> 
>> Perhaps it would be informative to search the icons in a
>> "mimetypes" folder for: *_doc.*:
>> 
>> [root at localhost mimetypes]# ls -1 *_doc.* kig_doc.png 
>> kpovmodeler_doc.png kwordquiz_doc.png netscape_doc.png 
>> widget_doc.png
>> 
>> I proceed on the theory that these are "documents".  Equivocation
>> on what is meant by "Documents" isn't going to answer the question.
>> 
> I love this kind of argument... "Ok we regularly misuse a term, let's
> make the situation even worse".
> 
I'm not sure that we are misusing the term since in the broad sense,
anything that conveys information is a document

http://www.m-w.com/cgi-bin/dictionary?book=Dictionary&va=Document&x=0&y=0

>> Basically, if you don't understand this, please turn it over to the
>>  usability people.
> 
> I'd be pleased if you could avoid being arrogant,

Remember, I am good at splitting hairs on the definition of arrogant. 
:-) It wasn't my intention to make a presumptuous claim, but your point 
is taken what I said can easily be taken the wrong way.

> it won't motivate me to cooperate on this at all (I interpret your
> sentence this way, if it wasn't intentional please accept my excuses
> in advance).

Really, I was just being blunt (probably too blunt).  But, I wasn't 
being disingenuous.  Some developers say that they aren't good at 
usability so we have usability experts at Open Usability to ask for 
advice.  I am suggesting that this might be a good idea.  I'm sort of 
out of ideas.  I like my ideas -- they look nice on my system, but I 
can't say what Joe User would like.
> 
> Moreover, it's not simply an usability issue since it's related to 
> terminology.

Yes, and terminology is clearly the problem, a major issue in usability. 
  And we need to have terminology in how many languages.  Not at all 
pleasant is it.

-- 
JRT