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

Andres Galante agalante at redhat.com
Fri Mar 20 19:38:29 UTC 2015


On Unified push console a user can "Create an app" and then "Add a variant"
inside the app that has been created.

On Fri, Mar 20, 2015 at 4: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.
>
> 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/799ec9ad/attachment.htm>


More information about the PatternFly mailing list