[Patternfly] *Action Required - Terminology and Wording Sprint 2

Liz Blanchard lsurette at redhat.com
Fri Mar 20 19:45:44 UTC 2015


On Mar 20, 2015, at 3:29 PM, Matt Carrano <mcarrano at redhat.com> wrote:

> 
> 
> ----- Original Message -----
> From: "Leslie Hinson" <lhinson at redhat.com>
> To: "Matt Carrano" <mcarrano at redhat.com>
> Cc: patternfly at redhat.com, "uxd-team" <uxd-team at redhat.com>
> Sent: Friday, March 20, 2015 3:22:10 PM
> Subject: Re: [Patternfly] *Action Required - Terminology and Wording Sprint 2
> 
> Hey Matt, 
> 
> Thanks for looking over these. The recommendation is not to use Create instead of Add. The intent of the guidelines is to distinguish the difference between Add/Create and Remove/Delete so that the correct label is applied appropriately. You have brought up a good use case where the user is initiating two actions (both create and add) with the click of one button. To me, this sounds like an additional requirement that could be added to the list to look at. If you are in agreement, I will add it to the list of to-dos to investigate for future sprints. 
> 
> Yes, this makes sense.  I think there will be many cases where Create and Add will occur together in what appears like one atomic operation to the user.
> 
> I second your call for any other known cases of this as it will be helpful for any future work. 


FWIW…

RHEV uses the term “New” a lot. So they have just avoided the action verb. I’ve been introducing both Create and Add where applicable in the 4.0 designs. RHEV also has the concept of “Clone” for copy so +1 to Josephine’s request on standardizing something here…

OpenStack Horizon uses Create and Add where applicable. 

Hope this helps!

Liz

> 
> Regards, 
> Leslie
> 
> 
> 
> 
>> On Mar 20, 2015, at 1:42 PM, Matt Carrano <mcarrano at redhat.com> wrote:
>> 
>> I think this looks good.  I have only one question/comment about the usage of Add vs. Create (and consequently Remove vs. Delete).
>> 
>> I personally like the distinction between Add and Create and agree that Create is a more descriptive term when naming the action of instantiating a new object.  However, in the Middleware products I've worked on I have generally seen the term Add used to create a new object and add it to a list or table.  Curious how these terms are being used elsewhere (are the products I've worked on the exception?).  If we start promoting the use of the term Create instead of Add, will this cause an inconsistency with existing releases?
>> 
>> -Matt
>> 
>> ----- Original Message -----
>> From: "Leslie Hinson" <lhinson at redhat.com>
>> To: patternfly at redhat.com, "uxd-team" <uxd-team at redhat.com>
>> Sent: Thursday, March 19, 2015 7:58:42 PM
>> Subject: [Patternfly] *Action Required - Terminology and Wording Sprint 2
>> 
>> Hi all, 
>> The Terminology and Wording Group's second sprint includes general rules and standards for the following: 
>> 
>> 
>>   * Started to define Terminology and Wording for Action Labels. This list will continue to grow and we are taking requests. 
>>   * Some more abbreviations were added for Days, Months and Units of Time 
>>   * General rules and guidelines for Truncation 
>> 
>> As part of our review process, we would like to gather feedback from you to ensure there are no major issues or concerns with the definitions below. Please provide your input by end of day on Friday, March 27. In addition, let us know of any new requests for us to address in future sprints. 
>> 
>> Thanks, Leslie 
>> Terminology and Wording for Action Labels 
>> 
>> Label 
>> 	
>> Action 
>> 	
>> Complement 
>> 	
>> Notes 
>> 
>> Add xxx 
>> Add 
>> 	
>> Add an existing item to an existing list, group, view, or other container element 
>> 	
>> Remove 
>> 	
>> If what you are adding is not readily apparent from the context, 
>> consider adding a noun to the button label (for example, Add 
>> File, Add User). 
>> Do not use Add to mean create a new item. See Create 
>> 
>> Change 
>> 	
>> Not recommended. See Edit 
>> 
>> Create xxx 
>> Create 
>> 	
>> Create something new 
>> 	
>> Delete 
>> 	
>> If what you are creating is not readily apparent from the context, 
>> consider adding a noun to the button label (for example, Create User, Create File, Create Device). 
>> Not recommended: 
>> 
>> 
>>   * 
>> New 
>> 
>>   * 
>> Add (see Add for usage guidelines) 
>> 
>> 
>> Delete 
>> 	
>> Removes the selected items. 
>> Also see Undo. 
>> 
>> 	
>> Create 
>> 	
>> Provide a mechanism to reverse (undo) Delete. 
>> Not recommended: 
>> 
>> 
>>   * 
>> Erase 
>> 
>>   * 
>> Remove (see Remove for usage guidelines). 
>> 
>> 
>> Edit 
>> 	
>> Open a dialog box to make changes (to a file, configuration, policy, and so on). 
>> Also see Rename. 
>> 
>> 	
>> 	
>> Use Edit to provide a facility for making changes to an object the 
>> user selects. 
>> Not recommended: 
>> 
>> 
>>   * 
>> Modify 
>> 
>>   * 
>> Change 
>> 
>> 
>> Modify 
>> 	
>> Not recommended. See Edit 
>> 
>> New 
>> 	
>> Not recommended. See either Add or Create 
>> 
>> Remove 
>> 	
>> Remove an item from a list, group, view, or other container element without deleting the item 
>> Also see Add and Delete. 
>> 
>> 	
>> 	
>> Complement of Add. 
>> If what you are removing is not readily apparent from the 
>> context, consider adding a noun to the button label (for 
>> example, Remove File, Remove User). 
>> 
>> Abbreviations for Days 
>> In sentences, do not abbreviate days. Abbreviate them only when space is limited, as in tables or graphics. When you must abbreviate them, use the following abbreviations: 
>> 
>> Sun 
>> 	
>> Sunday 
>> 
>> Mon 
>> 	
>> Monday 
>> 
>> Tue 
>> 	
>> Tuesday 
>> 
>> Wed 
>> 	
>> Wednesday 
>> 
>> Thu 
>> 	
>> Thursday 
>> 
>> Fri 
>> 	
>> Friday 
>> 
>> Sat 
>> 	
>> Saturday 
>> 
>> Abbreviations for Months 
>> In sentences, do not abbreviate months. Abbreviate them only when space is limited, as in tables or graphics. When you must abbreviate them, use the following abbreviations: 
>> 
>> Jan 
>> 	
>> January 
>> 
>> Feb 
>> 	
>> February 
>> 
>> Mar 
>> 	
>> March 
>> 
>> Apr 
>> 	
>> April 
>> 
>> May 
>> 	
>> May 
>> 
>> Jun 
>> 	
>> June 
>> 
>> Jul 
>> 	
>> July 
>> 
>> Aug 
>> 	
>> August 
>> 
>> Sep 
>> 	
>> September 
>> 
>> Oct 
>> 	
>> October 
>> 
>> Nov 
>> 	
>> November 
>> 
>> Dec 
>> 	
>> December 
>> 
>> Abbreviations for Units of Time 
>> In sentences, do not abbreviate these units of time: seconds, minutes, hours, days, months, and years. Abbreviate them only when space is limited, as in tables or graphics. When you must abbreviate them, use the following abbreviations for both the singular and plural forms: 
>> 
>> sec 
>> 	
>> Seconds 
>> 
>> min 
>> 	
>> Minutes 
>> 
>> hr 
>> 	
>> Hours 
>> 
>> d 
>> 	
>> Days 
>> 
>> mo 
>> 	
>> Months 
>> 
>> yr 
>> 	
>> Years 
>> 
>> qtr 
>> 	
>> Quarter 
>> 
>> Q1 
>> 	
>> First Quarter 
>> 
>> Q2 
>> 	
>> Second Quarter 
>> 
>> Q3 
>> 	
>> Third Quarter 
>> 
>> Q4 
>> 	
>> Fourth Quarter 
>> 
>> Truncation 
>> Instances where text might need to be truncated: 
>> 
>> 
>>   * 
>> Page titles that show object/host names 
>> 
>>   * 
>> Table cells that contain long strings or lots of data and that have some method to view the full text 
>> 
>>   * 
>> Others? 
>> 
>> 
>> Avoid abbreviations or truncated text in navigation items (first, second, and third levels of navigation in the masthead; left navigation). 
>> 
>> In column headings, if there is not sufficient room for the full spelling or hyphenation of a word, abbreviate the text according to the English abbreviation rules [actually, should be according to our rules too]. Do not truncate text in column headings. 
>> 
>> Whether to design for truncating strings at the beginning, end, or in the middle requires a bit of research. 
>> 
>> 
>>   1. 
>> Does the product have a default truncation scheme? (For example, CloudForms, which has a default setting for how to truncate host names but also a user preference if users want to change it to suit their naming scheme.) If yes, follow that scheme along with the guidelines here. 
>> 
>>   2. 
>> If the product doesn't have a default truncation choice, think about how the product's users are apt to name objects -- is it more likely that the unique part of the name will be at the beginning or end of the string? 
>> 
>> 
>> Guidelines: 
>> 
>> 
>>   * 
>> Indicate truncated text with an ellipsis (…). If the text is part of a link, the ellipsis should be part of the link as well. 
>> 
>>   * 
>> Leave no fewer than 4 characters when truncating text, and preferably leave enough characters to give a fair idea of what the string says. For example, don't truncate demo1.internal-el6.satellite to de... 
>> 
>>   * 
>> Ensure that there is at least one method for the user to view the entire string. Options include: tooltips (useful for less than 150 characters or so), expanding rows, overlays, others? 
>> 
>>   * 
>> For UI text (as opposed to user-generated text), ensure that the truncation does not make an awkward word (i.e. "associate" truncating to "ass...") 
>> 
>>   * 
>> If possible, ensure that truncation does not happen after punctuation, because then it is difficult to differentiate which is the ellipsis and which is part of the name. For example, don't truncate demo1.internal-el6.satellite to demo1…. 
>> 
>>   * 
>> If a table column is resizable, the truncated text should adjust accordingly, and continue to follow the preceding guidelines. 
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Patternfly mailing list
>> Patternfly at redhat.com
>> https://www.redhat.com/mailman/listinfo/patternfly
> 
> 
> _______________________________________________
> Patternfly mailing list
> Patternfly at redhat.com
> https://www.redhat.com/mailman/listinfo/patternfly

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/patternfly/attachments/20150320/ec8726d5/attachment.htm>


More information about the PatternFly mailing list