Community
Participate
Working Groups
Linda suggests we use "Clone repository" "New folder" not "Clone Repository" "New Folder" She says there's a general shift away from heavy capitalization. I checked gmail and while they don't have many multi word commands, when they do, it is mixed case. Note bugzilla uses caps.
I can make a pass for this after M2.
generalizing title because there are more style guide items to think about than just capitalization. I'm not saying we do all these, but should consider: - mixed case capitalization - ellipsis on text commands that open a slideout or dialog vs. having immediate effect (this is an emerging IBM web UI guideline) there are other stylistic things with links that involve "real links" vs. "command links" but the command framework can enforce those.
there are also some command names that could be shortened. Need to make sure we understand the context. "See Full Log" on a git page could just be "Log" "Show in Navigator" could just be "Navigator" etc.
marking RC2 but this could slip to RC3 if we had to
The longer names might make good tool tips.
Also ensuring that the tooltip generally starts with the command name (for the icon case).
John suggested that the github/eclipse org related pages commands be: "Show in Github" "Show in Eclipse.org" rather than go to. I also noticed that we need consistency for "go to the place in the navigator" we use "Show in Navigator" "Navigate"
Just to record my reasoning.. a link like "Go to navigator", "Go to eclipse.org", etc, doesn't imply to me that it will take me to a page related to the current page's resource. I would expect a link called "Go to eclipse.org" to take me literally to "http://eclipse.org" and nothing more. On the other hand "Show in git.eclipse.org" implies to me that it will show a page corresponding to the *current* resource on eclipse.org. When referring to another web site I'm not sure what preposition is most appropriate... "Show in", "Show on", or even "Show at" could make sense. Maybe it will depend on the target... "Show in Navigator", and "Show on git.eclipse.org". Whatever we end up deciding we definitely have inconsistencies right now.
Note that we also have "View all" actions for showing all tags or branches. Should it be "Show all" then?
Moreover on git commit page there is "Compare" action to show the side-by-side compare (similarly to git status page) and "Working Directory Version" to show the editor with the current file state. Should they be "Show Compare" and "Show Working Tree Version"?
I don't have a strong opinion on "View" vs "Show".. they are roughly the same. I guess in Eclipse world we avoided "View" because UI parts were called Views so that's confusing ("View in Console View" doesn't sound right).
There was a lot of change involved in doing this pass, and Simon is starting to be afraid of me. I did change "Go to eclipse.org" to "Show in eclipse.org" so that it would be the same as John's previous change for "Show in GitHub". That was a free change I did while changing git commands in bug 371121. Otherwise let's do a calm, editing pass on command names, tooltips, punctuation, capitaliation, etc. in 0.5. One of the outcomes should be a styleguide (and maybe even a pointer to the styleguide in the code) so that folks writing new commands know the rules.
moving out of 0.5M2 to 0.5 milestone until we have more specific buckets for future
Moving to 1.0. Also in the realm of editing/style guide stuff: Task names: verb, noun (Navigator), gerund (Coding) Link names: nouns that name pages (Xternalizer, Git Log, etc.) vs. verbs (View, Show, etc.)
Closing as part of a mass clean up of inactive bugs. Please reopen if this problem still occurs or is relevant to you. For more details see: https://dev.eclipse.org/mhonarc/lists/orion-dev/msg03444.html
