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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> >> 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 <[email protected]> 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 <[email protected]> >>>> 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 <[email protected]> >>>>> 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. >>>>>> [email protected] >>>>>> >>>>>> _______________________________________________ >>>>>> Patternfly mailing list >>>>>> [email protected] >>>>>> https://www.redhat.com/mailman/listinfo/patternfly >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Greg Sheremeta, MBA >>>>> Red Hat, Inc. >>>>> Sr. Software Engineer >>>>> [email protected] >>>>> >>>>> _______________________________________________ >>>>> Patternfly mailing list >>>>> [email protected] >>>>> https://www.redhat.com/mailman/listinfo/patternfly >>>>> >>>>> >>>> >>>> >>>> -- >>>> Ju Lim >>>> Red Hat >>>> Office: 978-399-0422 >>>> Mobile: 781-507-1323 >>>> Email: [email protected] >>>> IRC: julim >>>> >>>> >>> _______________________________________________ >>> Patternfly mailing list >>> [email protected] >>> https://www.redhat.com/mailman/listinfo/patternfly >>> >>> >> >> _______________________________________________ >> Patternfly mailing list >> [email protected] >> https://www.redhat.com/mailman/listinfo/patternfly >> >> > > > -- > Matt Carrano > Sr. Interaction Designer > Red Hat, Inc. > [email protected] >
_______________________________________________ Patternfly mailing list [email protected] https://www.redhat.com/mailman/listinfo/patternfly
