[Patternfly] Truncation guidance for long names

Mon Oct 24 14:39:09 UTC 2016

Hi Liz,

That's great information, this is the first time I heard about truncation
in the middle of the word.

I am sure that middle of the string truncation can be done with javascript,
but CSS only allows to do it at the end of it. I'd say that unless there is
a really good reason to do it in the middle lets try to avoid JS.

Thanks!

Andrés

On Mon, Oct 24, 2016 at 11:24 AM, Matt Carrano <mcarrano at redhat.com> wrote:

> This is great, Liz.  I think that your proposed text will add a lot of
> clarity to the choice between these two methods.  Will look forward to
> seeing some examples of truncated names and we can evaluate further.
>
> Matt
>
> On Mon, Oct 24, 2016 at 10:11 AM, Liz Blanchard <lsurette at redhat.com>
> wrote:
>
>> Hi All,
>>
>> I've been thinking about truncation a bit and was looking into some UX
>> standards on the topic. It's all very much in line with the examples that
>> Greg and Ju have given. What do you all think about extending the
>> PatternFly "Truncation" section on the Terminology and Wording page [1] to
>> include something like the following...
>>
>>
>>>
>>>
>>> *"Using an ellipsis to truncate a long string is recommended. There are
>>> two different methods that could be applied. One is to truncate at the end
>>> of the string "abcdef..." and the other would be to truncate in the middle
>>> of the string "abc...ghi".Choose the method on the basis of whether text at
>>> the end or in the middle of the string is more likely to differentiate the
>>> item. This would be dependent on the domain.On a property website, for
>>> instance, an address string will usually end 'Road' or 'Street'. So the
>>> form 'abc...def' won't be much use as the final characters will almost
>>> always be 'oad' or 'eet', neither of which help the user.If the answer is
>>> not clear, default to the 'abcdef...' form over 'abc...ghi'. Partial words
>>> will most likely be easier to guess from the initial characters than the
>>> end ones. 'Openi...' is much more recognizable than '...ening', for
>>> example."*
>>
>>
>> I'd also like to add in a statement where we suggest the use of the tool
>> tip on hover to view the entire string.
>>
>> I'm working on some specific use cases with the Storage product and we
>> definitely are seeing the need for both methods. More commonly, we will be
>> using method 1 for things like Cluster Name and Pool Name, but we are
>> considering method two for things like Hostname where the end characters
>> are important in differentiating the items in the list.
>>
>> Any further thoughts on this?
>>
>> Thanks!
>> Liz
>>
>> [1] http://www.patternfly.org/styles/terminology-and-wording/#_
>>
>> On Thu, Oct 20, 2016 at 8:12 PM, Andres Galante <agalante at redhat.com>
>> wrote:
>>
>>> Hi Matt, we definitely need guides around truncation, not only on server
>>> names but in general.
>>>
>>> It's always a grey area how and when to truncate.
>>>
>>> If working on Tendrl you can come up with some refomendations we can
>>> apply them to our patterns.
>>>
>>> Let me know if I can help in any way, we can test things up in different
>>> use cases to see if it works
>>>
>>> Thanks!
>>>
>>> On Monday, 10 October 2016, Ju Lim <julim at redhat.com> wrote:
>>>
>>>> This generally works for most names except I've found in certain
>>>> contexts from previous experience that truncating in the front made more
>>>> sense, e.g. "...xyz" for MAC Addresses and SAN nicknames as it was less
>>>> useful doing it as "xyz..." since the beginning portion was repeated a lot
>>>> and didn't help so much with uniquely identifying the object.
>>>>
>>>> An interesting consideration is if there is a need for truncation of an
>>>> IPv6 addresses, how do we tackle this.  I know IPv6 already includes
>>>> truncation in the spec, but there are going to be circumstances where we
>>>> may need to go beyond this.  Thoughts?
>>>>
>>>> Regards,
>>>> Ju
>>>>
>>>> On Sat, Oct 8, 2016 at 11:59 AM, Greg Sheremeta <gshereme at redhat.com>
>>>> wrote:
>>>>
>>>>> Hi Matt / all,
>>>>>
>>>>> This gets tricky when you have machine names in your listings!
>>>>> my_super_important_vm_1
>>>>> my_super_important_vm_2
>>>>> his_super_important_vm_1
>>>>>
>>>>> ^ Either way you truncate that "column", someone's going to lose some
>>>>> important info, and looking through the column will be frustrating for the
>>>>> users.
>>>>>
>>>>> In oVirt, we take the simple approach and truncate at the end. And, in
>>>>> most places where there is truncation, hovering over the truncated string
>>>>> shows you (via tooltip) the entire string:
>>>>>
>>>>> [image: Inline image 1]
>>>>>
>>>>> My recommendation for PatternFly: recommend / default to end
>>>>> truncation with "...". I like the hover-show-full-name feature -- that's
>>>>> something UX people should discuss re: if it should exist and what it would
>>>>> look like. (We use PF tooltips, but I could see other widgets being useful.)
>>>>>
>>>>> Best wishes,
>>>>> Greg
>>>>>
>>>>> On Fri, Oct 7, 2016 at 2:08 PM, Matt Carrano <mcarrano at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> Hey Patternflyers,
>>>>>>
>>>>>> I am currently working on the Tendrl storage console project and need
>>>>>> to come up with some guidance on how to truncate long names that may appear
>>>>>> in our UI.  I'm thinking of things like hostnames, disk names, and other
>>>>>> types of objects that may take on a potentially long path name based on
>>>>>> user naming.  PatternFly currently provides some general guidance, but no
>>>>>> specific rules.
>>>>>>
>>>>>> I'm curious how you are handling this on other projects as I know
>>>>>> it's a common problem.  Do you truncate in the middle of the string, the
>>>>>> end of the string, or have another method?
>>>>>>
>>>>>> Any advice or examples will be welcome.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Matt
>>>>>>
>>>>>> --
>>>>>> Matt Carrano
>>>>>> Sr. Interaction Designer
>>>>>> Red Hat, Inc.
>>>>>> mcarrano at redhat.com
>>>>>>
>>>>>> _______________________________________________
>>>>>> Patternfly mailing list
>>>>>> Patternfly at redhat.com
>>>>>> https://www.redhat.com/mailman/listinfo/patternfly
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Greg Sheremeta, MBA
>>>>> Red Hat, Inc.
>>>>> Sr. Software Engineer
>>>>> gshereme at redhat.com
>>>>>
>>>>> _______________________________________________
>>>>> Patternfly mailing list
>>>>> Patternfly at redhat.com
>>>>> https://www.redhat.com/mailman/listinfo/patternfly
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Ju Lim
>>>> Red Hat
>>>> Office: 978-399-0422
>>>> Mobile: 781-507-1323
>>>> Email: julim at redhat.com
>>>> IRC: julim
>>>>
>>>>
>>> _______________________________________________
>>> 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
>>
>>
>
>
> --
> Matt Carrano
> Sr. Interaction Designer
> Red Hat, Inc.
> mcarrano at redhat.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/patternfly/attachments/20161024/834ed50e/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Selection_115.png
Type: image/png
Size: 22666 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/patternfly/attachments/20161024/834ed50e/attachment.png>