[Patternfly] Truncation guidance for long names

Andres Galante agalante at redhat.com
Tue Oct 25 12:03:10 UTC 2016


I agree with Thomas, truncation should be a last resource and abbreviation
is preferable.

My comment on javascript vs CSS is about performance. I am not a js expert
but I expect that truncating a word in the middle would requiere measuring
spaces and adapting the string length to them.

It's absolutely doable but it should be avoided, a hit in performance, as
small as it can be results in worst user experience that means for example
less conversion.

If we have use cases that must use truncation in the middle and there is no
other solution for it, then we should move forward with this idea. But if
we should think of other options to accomodate long names in our UI without
doing middle of the string truncation.


On Tue, Oct 25, 2016 at 12:26 AM, Serena Doyle <sdoyle at redhat.com> wrote:

> Matt, I also agree that we need both methods.  It would be great if we
> could provide guidance on when to use which method.
>
> I wonder if the method would also depend on naming conventions used by the
> customers.
>
> On Mon, Oct 24, 2016 at 11:59 AM, Catherine Robson <crobson at redhat.com>
> wrote:
>
>> +1 to needing both end and middle based on the use case.
>>
>> On Mon, Oct 24, 2016 at 10:53 AM, Matt Carrano <mcarrano at redhat.com>
>> wrote:
>>
>>>
>>>
>>> The middle truncation is really useful for long path names that will all
>>> share the same prefix.  Think about things like files names or disk names
>>> that are required to display the full path name.  If out truncate the end,
>>> all of the name strings will be identical at a glance.  Middle truncation
>>> allows you to see what's different, which is usually at the end of the long
>>> string.
>>>
>>> I would expect that there are some standard algorithms out there for
>>> doing this.  End truncation is likely to be the default choice, but I think
>>> we need both.
>>>
>>> Matt
>>>
>>> On Mon, Oct 24, 2016 at 10:39 AM, Andres Galante <agalante at redhat.com>
>>> wrote:
>>>
>>>> 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
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> 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
>>>
>>>
>>
>> _______________________________________________
>> Patternfly mailing list
>> Patternfly at redhat.com
>> https://www.redhat.com/mailman/listinfo/patternfly
>>
>>
>
>
> --
> - Serena Chechile Doyle
> *UXD | Unified Management Experience*
> *Red Hat*
> *Cell* 508-769-7715 | *IRC* - serena | *Skype* - serenamarie125 |
> *Twitter* - @serenamarie125
>
> _______________________________________________
> 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/20161025/e3368965/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/20161025/e3368965/attachment.png>


More information about the PatternFly mailing list