[Patternfly] Truncation guidance for long names

Thomas Maas tmaas at redhat.com
Mon Oct 24 14:52:20 UTC 2016 

+1

Maybe consider adding something about truncation being a last resort: not just to make things look prettier or to support an inflexible template. I.e. wrapping to the next line or data abbreviations might be preferable solutions.

-Thomas

> On 24 Oct 2016, at 16:39, 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:
> 
> <Selection_115.png>
> 
> 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
> 
> _______________________________________________
> Patternfly mailing list
> Patternfly at redhat.com
> https://www.redhat.com/mailman/listinfo/patternfly

More information about the PatternFly mailing list