Thank you all for continuing to suggest directions and adding more examples of what's used out there for truncation.
I think we all agree that truncation should be used only if needed, so I will be sure to add in a statement to encourage folks to try and show the full text when possible. It does sound like we have use cases for both truncation methods, but I will suggest that the first method should always be considered first. @Andres - maybe we can continue discussions around implementation details of method 2 in a PR? I hope to submit something to the design repo today. Thanks again, everyone! Liz On Tue, Oct 25, 2016 at 9:40 AM, Gabriel Cardoso <[email protected]> wrote: > Andres, MacOS truncates in the middle ;) > > > On 24 Oct 2016, at 13:59, Catherine Robson <[email protected]> wrote: > > +1 to needing both end and middle based on the use case. > > On Mon, Oct 24, 2016 at 10:53 AM, Matt Carrano <[email protected]> > 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 <[email protected]> >> 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 <[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: >>>>>>>> >>>>>>>> <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 <[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] >>>> >>> >>> >> >> >> -- >> Matt Carrano >> Sr. Interaction Designer >> Red Hat, Inc. >> [email protected] >> >> _______________________________________________ >> Patternfly mailing list >> [email protected] >> https://www.redhat.com/mailman/listinfo/patternfly >> >> > _______________________________________________ > Patternfly mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/patternfly > > > Gabriel Cardoso > UX designer @ Red Hat > > > > > _______________________________________________ > Patternfly mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/patternfly > >
_______________________________________________ Patternfly mailing list [email protected] https://www.redhat.com/mailman/listinfo/patternfly
