Created attachment 183197 [details] Presentation with confusing animations list In the Impress animations list, on the animations sidebar, the first line of every item has the shape name and the shape's text. Ignoring whether this is a good idea or not, I claim that these two pieces of text need to be better differentiated than with a mere colon. See the attachment for a particularly nasty example. I leave it up to the UI experts to propose how to achieve this differentiation: Different color, different font, different size, something in the background, a more "forceful" symbol of separation etc.
*** Bug 151690 has been marked as a duplicate of this bug. ***
I see no problem. Your shapes have no name at all, so a default enumeration is used to distinguish them. If that are meaningful shapes, you should name them. And I see no problem with the entries in the Animation list. Left of the colon is always the identifier for the shape and right of the colon the contained text as it is, if any. Currently the contained text is needed to help the user to identify the shape. For any other character as delimiter it can happen as well, that it is part of the text. So changing the colon to something different will not work. Distinction by color is questionable in regard to accessibility. Interesting is the approach of PowerPoint. It does not use the text content to help the user to find the associated shape, but it enumerates the entries in the list and shows this number in a small box left to the shape in the slide. That way the text content is not needed at all in the list items.
(In reply to Regina Henschel from comment #2) > I see no problem. Your shapes have no name at all, so a default enumeration > is used to distinguish them. If that are meaningful shapes, you should name them. I wasn't complaining about how shapes are named. Let's assume I chose those shape names myself even. > And I see no problem with the entries in the Animation list. Left of the > colon is always the identifier for the shape and right of the colon the > contained text as it is, if any. A colon is not enough of a differentiation. Colons occur naturally in runs of text. > For any other character as delimiter it can happen as well, ... which is why a delimiting character is not good enough, hence this bug. (Caveat: Some extremely-rare character combination could theoretically work, but probably not a good idea.) > Interesting is the approach of PowerPoint. It does not use the text content > to help the user to find the associated shape, but it enumerates the entries > in the list and shows this number in a small box left to the shape in the > slide. That way the text content is not needed at all in the list items. That would be a separate bug... but see also my bug 151692.
What Regina didn't note is that when the object receiving the animation is named, its entry on the animation list will receive single quotation tics. So already provides more than the ":" separator. If you want more differentiation just name the object, as opposed to accepting the object type defaults. I imagine the name gets quoted to allow emended white space, but it works none the less. To name the sd objects, we can select from canvas or Navigator but we can't directly name an object from Navigator, open as bug 139633. But with object selection made the Format -> Name... dialog works fine.
(In reply to V Stuart Foote from comment #4) > If you want more differentiation just name the object, 1. But I don't want to have to name the object. Certainly not for this purpose. 2. Even if it's named, that's still no help: I will still only have a bunch of text. Colons, quotation marks, whatever - it's a single run of text. Not enough differentiation.
I'm also in the pro-colon camp. Your only point, at least what I can see, is that colons may appear in regular text as well, which is a quite academic argument. The alternative, to move the object text into a second line, is not really helpful. Neither go with brackets or quotes. See also bug 145031.
Created attachment 183393 [details] Example file I agree with Eyal, in the sense that is hard to distill something meaningful from the automatic generated labels at the Animation List. I get confused - lost - within 5 minutes :-) Distinguish shape text from shape name is - for me - only an illustration of the issue. The animations in the example file are attached to the text within a 'shape' (text frame), not to the text frame itself. However, I can't distill this from the label in the animation list. ---- Also the default Text Frame (empty slide) are called identified as shape (like shape1) while inserted smiley also being called 'shape'. ---- Something else: Insert a shape -> Right Click it -> Name. The field being empty, while the navigator naming it 'Shape3 (Shape)' I prefer to simply name the insert shape. So the name field showing 'Shape3'. Instead of empty name. Observe that '(Shape)' disappears inside the navigator after naming it. I think this might be still relevant information... --- I don't have an answer a simple answer to solve this puzzle straight away. I personally like some indication of the locations of the animation within the name. I mean the type of object (text frame/ drawing object name). Drawing objects have names on insertion (smiley/8 point star, circle). Yes, you can change a circle into an ellipse. But most other drawing object have unique properties. If you insert multiple smileys, those will be called smiley1 smiley2 ... It's surely better compared to calling everything 'shape1' 'shape2' The ability to manually rename Animations would be something to consider, IMHO
(In reply to Heiko Tietze from comment #6) > I'm also in the pro-colon camp. Your only point, at least what I can see, is > that colons may appear in regular text as well, which is a quite academic > argument. No, the colon was not the point, it was just an _illustration_ on how the shape name is not distinguished from the shape text. Heiko, where else in the LO UI are we presenting multiple pieces of information as a concatenated string of text characters? What are we, xfontsel of 30 years ago? :-( > The alternative, to move the object text into a second line, is not really > helpful. Neither go with brackets or quotes. That's still just text. It won't do...
The topic was on the agenda of the design meeting but didn't receive further input. Besides most comments express the opinion that this is not an issue we should think about alternatives (since discussing the colon is not what you want). Replacing the type name with an icon or a thumbnail clutters the dialog too much. And showing the information in multiple lines or in a tabular view might solve _this_ problem but introduces other issues such as taking too much space. You can click on the animation and get the respective object highlighted, and vice versa. And you can name objects properly. => NAB
(In reply to Heiko Tietze from comment #9) > The topic was on the agenda of the design meeting but didn't receive further > input. I'm sorry I couldn't make it. I wish you could try to allow bug reporters, who also occasionally attend the sessions, the prerogative of tabling bugs for a later date... > Besides most comments express the opinion that this is not an issue we > should think about alternatives (since discussing the colon is not what you > want). Replacing the type name with an icon or a thumbnail clutters the > dialog too much. Ok. > And showing the information in multiple lines or in a > tabular view might solve _this_ problem but introduces other issues such as > taking too much space. But those are not even my first suggestions! What's wrong with a different shade of color, emboldening, underlining, boxing adding a shadow effect or something like that?
(In reply to Eyal Rozenberg from comment #10) > But those are not even my first suggestions! What's wrong with a different > shade of color, emboldening, underlining, boxing adding a shadow effect or > something like that? I don't see how you would color-code these information. Proper naming works much better.
(In reply to Heiko Tietze from comment #11) > I don't see how you would color-code these information. Proper naming works > much better. What's so difficult about, say setting the shape name in boldface and the text in regular weight? Or the shape name in black and the shape text in gray?
(In reply to Eyal Rozenberg from comment #12) > What's so difficult about, say setting the shape name in boldface and the > text in regular weight? Or the shape name in black and the shape text in > gray? You wont see the difference unless both are visible at the same time. And in this case we do have an easy to understand layout.
(In reply to Heiko Tietze from comment #13) > You wont see the difference unless both are visible at the same time. This bug is only about when they are visible at the same time. When they aren't, there's nothing to distinguish. > And in this case we do have an easy to understand layout. No, we don't: We have a sequence of characters with no break in the layout of the shape and the name. Not to mention how the effect lines also have a nearly-identical layout, other than the indent. It's as though we have a misunderstanding about what this bug is complaining about.
Created attachment 183589 [details] Screenshot of the animations list "Shape 1: Shape 2: Shape 3: Shape 4: Shape 5" <- this is the "clear to understand layout" we get right now.
(In reply to Eyal Rozenberg from comment #15) > "Shape 1: Shape 2: Shape 3: Shape 4: Shape 5" <- this is the "clear to > understand layout" we get right now. As commented before, proper naming is the key to success. You wont have this trouble with real life examples.
(In reply to Heiko Tietze from comment #16) > As commented before, proper naming is the key to success. You wont have this > trouble with real life examples. If it said "Shape 1: Foo: Bar" and "Shape 2: Baz: Quux" it would not be much better.