Hello!
Stephan Sokolow has written on Wednesday, 6 November, at 23:49:
>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.)
Good point. Is it a rule in Englist that all words in title should be
capitalized? Beside I'm not sure it those can be named titles - they are
items in Places list in fact.
>> 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".)
Well, if you think items in Places should be absolutely equal to
items in the checklist, then below is a comparizon:
shown in Places checklist item in Preferences
----------------------------------------------------
<username> Home Directory
Desktop Desktop Folder
Applications Applications
Trash Can Trash can
File system File system root
Computer "Computer" special folder
Network Drives Network places
Some items require sync then. Probably some should be changed in both
places, yes?
>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.)
That sounds fair enough. It's worth to eliminate space in there then.
>>> 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")
Well, I'm agree already that string is vulnerable and should be
replaced. The question is what the replacement should be. :)
With best regards.
Andriy.
------------------------------------------------------------------------------
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
