On 13-11-06 10:01 PM, Stephan Sokolow wrote:
> I see one thing which should be changed and two which should be discussed:
>
> First, since they're all titles, they should all be capitalized like
> "Home Directory". ("Trash Can" rather than "Trash can", "Network Places"
> rather than "Network places", etc.)
>
> Second, "Desktop" may be better than "Desktop Folder". Explicitly using
> the word "folder" could cause conceptual confusion if the user thinks
> there's special significance to how you've drawn attention to that
> implementation detail.
>
> (If it's just called Desktop, they can click it, recognize that it's
> another way to work with things on the desktop, and recognize that it's
> just another folder by seeing the path in the location bar.)

Oops. I forgot to mention the second one that needs discussion. (Which 
is really two things.)

It'd probably be best to consider alternate phrasing for `File system 
root` and `"Computer" special folder`.

First, `"Computer" special folder` is awkward at best. Given the 
context, "Computer" should be good enough and feels more natural. 
("Computer" is what shows up in Places, so "Computer" is what should 
appear in "Show in Places".)

Second, discussion is needed on whether "File system root" should be 
written with or without a space between "file" and "system".

Both "file system" and "filesystem" are valid and both have between 10 
and 20 million results on Google but, to my intuition, "filesystem root" 
feels more natural while "file system root" feels like it introduces an 
archaic and now unnatural semantic subdivision of the "filesystem" 
concept similar to calling e-mail "electronic mail".

We've grown accustomed to thinking of it as a "filesystem" rather than 
"system of files" because anyone familiar with the term interacts with 
the concept so much that, intuitively, it's become its own first-order 
concept rather than just a special case of the "system" concept.

(Plus, in the grammatical sense, "file system root" has a faint feeling 
of awkward complexity to it, like a less serious version of how "lait de 
noix de coco" would be awkward so the French refer to "coconut milk" as 
"lait de coco" instead.)

>
>>
>>       It is not correct to use term "address" for that. Even web browsers
>> use term "location" (the L in URL stands for that). And since we can form
>> that location bar in two ways:
>>    - text entry to type the path
>>    - bar of buttons representing the path
>> we used the term "entry" in the first place.
>>
>
> Good point on the use of "location" rather than "address" (it also has
> the added advantage that "location" is more intuitive than "address" and
> even more so when working with paths rather than URLs) but I have to
> disagree on the use of "entry" rather than "bar".
>
> Your use of "entry field" uses the adjective form of entry which relates
> to the present-tense form of "to enter" ("Field to be used for the
> process of entering things").
>
> However, GUI toolkits already make heavy use of "entry" as the noun
> corresponding to the past-tense of "to enter". ("things that have been
> entered")
>
> When you say "location bar", users recognize it as a single term
> containing two words.
>
> When you say "location entry field", even skilled users are likely to
> look to the Places sidebar. (In the eyes of the user, "field" is a
> vaguely-defined concept that roughly means "interactive widget that
> isn't a button or checkbox" and the Places sidebar is a listbox that's
> full of "location entries")
>
>
> ------------------------------------------------------------------------------
> November Webinars for C, C++, Fortran Developers
> Accelerate application performance with scalable programming models. Explore
> techniques for threading, error checking, porting, and tuning. Get the most
> from the latest Intel processors and coprocessors. See abstracts and register
> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
>


------------------------------------------------------------------------------
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most 
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
_______________________________________________
Lxde-list mailing list
Lxde-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxde-list

Reply via email to