On 13-11-07 12:39 PM, Andrej N. Gritsenko wrote:
> 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.
It varies widely. British publishers and U.S. newspaper publishers
capitalize titles as ordinary sentences.
U.S. book publishers either capitalize every word in a title or
capitalize every word except certain types of short words (articles,
prepositions, conjunctions, and forms of "to be").
Anyway, I think the more important thing is to ask what is most
consistent and aesthetically pleasing within the environment in which
PCManFM exists.
The names in the Places sidebar are, intuitively, similar in nature to
menu items. (They're short noun phrases which can be clicked to alter
the state of the file manager.)
While, some GTK+ applications like Geeqie and Comix consistently
capitalize only the first letter in menu items, the overwhelming
majority of applications found on my LXDE desktop use "title case" for
menu items.
Applications which, as far as I can determine, capitalize every word in
a menu item:
- Audacious Media Player
- Deluge
- Dropbox
- Firefox
- Galculator
- Leafpad
- LibreOffice
- LyX
- LXTerminal
- Parcellite
- Thunderbird
- Xpad
Applications which capitalize every word in a menu item except articles
(a/the) and prepositions (to/in/as):
- Evince
- GNOME MPlayer
- Pidgin
- PCManFM
- Anything in KDE or the Trinity Desktop Environment (Dolphin, K3b,
Konqueror, Filelight, BasKet, etc.)
Applications which have no consistent approach:
- AbiWord (eg. "Save As...", "Report a Bug", and "In web browser")
- File Roller
- GNOME Character Map (See the "View" menu)
- gVim (eg. "Split Diff with" immediately before "Split Patched By")
File Roller is actually an interesting case because it gives me the
impression that its inconsistency is specifically being caused by the
maintainers of the GTK+ stock actions choosing "capitalize everything"
for phrases like "Save As..." while the maintainers of File Roller chose
"capitalize everything except articles and prepositions".
PCManFM 1.1.1 appears to be trying to follow the KDE approach with the
"Open Folder in/as..." entries in the Tools menu showing an intent to
capitalize everything except prepositions (as KDE and Pidgin do) but has
a single mistake with the "Help > Keyboard navigation" failing to
capitalize the non-article, non-preposition word "navigation".
Furthermore, the Places sidebar actually has MORE reason to use "title
case" capitalization than menus do because menus may contain verbs but
Places is, by nature, limited to nouns which the user intuitively
recognizes to be proper nouns... and English grammar rules say to fully
capitalize multi-word proper nouns like "South Pole" and "White House".
(Even in the potentially ambiguous cases. There may be multiple
"applications" but there is only one *list* of applications and that's
what "Applications" refers to.)
Also, given the consistent styling I've observed, I have a strong
suspicion that, had I time to check things like the GNOME and KDE HIGs,
I'd find that the same title-case conventions are actually generally
applicable to "action text", regardless of whether it takes the form of
a menu or toolbar item. (eg. Same rules for command buttons, specifying
that they should use brief, title-case phrases.)
Under that interpretation, it would also apply to Places with
non-user-specified names since, in practice, they're actions.
Finally, you're displaying all of these things from Places in the Go
menu, which means they should probably follow the same capitalization
convention as "Previous Folder", "Next Folder", and "Parent Folder".
>
> 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?
Agreed. As a starting point for discussion, here's how I'd do it were I
in charge:
Shown in Both
---------------
Home Folder
Desktop
Trash Can
Filesystem Root
---
Applications
Computer/Drives/Devices (I'm not yet certain which is best)
Network
Here's my rationale:
- Home Folder (Yes, I know it may require a GTK+ patch):
1. I've found that unskilled users are confused by the display of
the username in the Places list.
2. It's a lot easier to instruct a user to look for "Home Folder"
than it is for "I don't know what it'll be called, but it should
be at the top of the list and have a 'home' icon." (Many users
never type their username and pick their full name from a list in
the login manager.)
3. Even for skilled users, using the explicit folder name just slows
down recognition. The concept at the top of my mind is $HOME, not
"ssokolow".
4. "Home Folder" rather than "Home" because, in my experience, a
user's conception of "Home" is some kind of launcher, not a
folder on the hard drive. Using "Home Folder" allows them to more
readily grasp that it's a technical term which, obviously, has
something to do with "the place where all my stuff goes".
5. "Folder" is more intuitive than "Directory" because it matches the
iconographic metaphors used in the GUI.
- Filesystem Root:
1. I've already explained my reasoning behind making "filesystem"
one word.
2. Include the word "Root" because, on its own, the concept of
"Filesystem" doesn't carry a strong enough sense of location.
(Everything the file manager browses is within some kind of
filesystem concept. Despite its archaic, utilitarian ugliness,
"Root" would be better than "Filesystem" if one-word names were
mandatory.)
- Computer/Drives/Devices:
1. I've already explained my reasoning for not explicitly saying
"special folder".
2. My main point of confusion when choosing a name has to do with
what actually appears in it. "Devices" or "Drives" would be most
intuitive and consistent with the "category for" pattern
established by "Applications" and "Network" but "File System" is
neither a drive nor a device.
3. I tossed in "Devices" as an alternative to "Drives" because, if
something like an MTP-attached camera or MP3 player's internal
flash storage appears in the list, the fact that it's a "drive"
is purely an implementation detail and wouldn't feel natural to
the user.
- Network:
1. "Network Places" is redundant and reminds me of "My Documents". If
it's in the file manager, it's a conceptual "place". (Even if it's
a virtual one like "Applications")
2. "Network Drives" carries the impression that you're getting a list
rather than a navigable tree. Entries like "Windows Network",
"WORKGROUP", and "MY_PC" are not "Drives".
3. "Network" works nicely as a conceptual contrast to "Local
Filesystem"
4. If we decide to stick with "Computer", Network works nicely as an
explicit contrast to that.
- Ordering (Yeah, may require GTK+ patching. Included for completeness):
1. There are two distinct kinds of preset places in the sidebar:
- Specific places like the home folder, the desktop, the trash
can, and the filesystem root. (specific places)
- Things the user recognizes as disjoint hierarchies like
Applications, Computer, and Network. (location domains)
2. Ideally, the separator would be included since it drives home the
conceptual separation.
3. I've ordered the location domains list alphabetically since it
feels more natural than any other order I considered.
4. I've ordered the specific places presets based on the following
considerations:
- Keep "Home" at the top for the following reasons:
- Consistency with previous versions
- Keep it in a familiar place if the rename to
"Home Folder" goes through.
- It's probably the most used Places preset among
non-technical users.
- Keep "Desktop" as the second item because:
- Consistency with previous versions
- It's probably the second most used Places preset among
non-technical users.
- Trash Can is infrequently visited and the most common action
is clearing it, so it should appear below "Home Folder" and
Desktop.
- Filesystem Root is more "strange and esoteric" than Trash Can
for non-technical users, so it should appear further down the
list.
>
>>> 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. :)
>
My reason for suggesting "location bar" is that its location and
appearance are similar to the ones in browsers, so using the same
terminology will aid recognition.
(Especially given how copying things from the location bar and pasting
things into it are operations that often need to be described in the
context of web browsers, so unskilled users are much more likely to be
familiar with the term.)
------------------------------------------------------------------------------
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
