+1 go for the PR! also to be clear I am not saying we should not truncating in the middle, I just want to make us aware of the cost of it.
On Tue, Oct 25, 2016 at 2:28 PM, Liz Blanchard <[email protected]> wrote: > 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 > >
_______________________________________________ Patternfly mailing list [email protected] https://www.redhat.com/mailman/listinfo/patternfly
