Select a Formula, Chart, or other OLE object Right-click, choose Properties. Actual: Title of dialog box is "Object" Suggested: Title should be "OLE Object" Reasons: "Object" is also used generically for Images, Textboxes, Shapes, and OLE Objects (e.g., "Align Objects") By adding OLE Object to the dialog, ambiguity is reduced. Also consistent with the categorization in Navigator.
(In reply to sdc.blanco from comment #0) > Select a Formula, Chart, or other OLE object OLE is a technology by MS, which we don't use for embedding objects. Our embedding isn't OLE. > Suggested: Title should be "OLE Object" > > Reasons: > By adding OLE Object to the dialog, ambiguity is reduced. Which specific ambiguity is meant? I mean, there should be *a problem* that this is supposed to resolve. A problem is something that makes some task more difficult than it could be. So please describe, what is more difficult for any user with "Object" title than it would be with "OLE Object"?
(In reply to Mike Kaganski from comment #1) > Which specific ambiguity is meant? The meaning of "Object" 1. If I insert a Formula or a Chart. They appear in Navigator as "OLE objects" 2. If I select a Textbox, right click, I see "Align Objects" 3. If I edit Properties of Formula or Chart is says "Object" As a start, the OP arises from the ambiguity among these three cases. With implications like: i. How should one refer generically to objects (as in case 2)? ii. How should Navigator align with the title of the Properties dialog for "Object"? (interaction between case 1 and 3)? iii. How should help pages refer to "object" so that the meaning is clear (e.g., see "Content vertical alignment" in [1] where object also seems to mean shape, textbox) [1] https://help.libreoffice.org/7.4/en-US/text/swriter/01/05060900.html
(In reply to sdc.blanco from comment #2) > (In reply to Mike Kaganski from comment #1) > > Which specific ambiguity is meant? > The meaning of "Object" If we want to disambiguate, look at Navigator, where textbox is under "Drawing objects". But there is a generic term for any "thing" that may be anchored to the text flow; and that generic term is "object". It allows to use sentences like "select objects and drag using mouse to position ...", or the like, without monsters like "select OLE objects, or images, or drawing objects, or frames, and drag ...". The disambiguation is only needed when there is some confusion that disallows user to see some important distinction. In the case of the dialog, I do not see such a problem. The dialog is shown for the selected objects. The user knows and even *sees* what is selected. > i. How should one refer generically to objects (as in case 2)? When one really needs to *disambiguate* drawing objects from other kinds of objects, one needs to use "drawing objects" term, aligned with Navigator. > ii. How should Navigator align with the title of the Properties dialog for > "Object"? (interaction between case 1 and 3)? There is no such requirement. > iii. How should help pages refer to "object" so that the meaning is clear > (e.g., see "Content vertical alignment" in [1] where object also seems to > mean shape, textbox) See i). Note that the change is in fact trivial; and changing "Object" to "OLE Object" is not a problem (and I don't actually oppose that change). What I ask for is that the issues describe the problems, which hasn't happened here. The real problem may be inconsistent use of some term throughout the program and help, with specific case that *creates confusion*. When there's such a description, it's OK to *also* change some less problematic cases (or completely innocent, like this) *along with problematic cases* for consistency.
I suppose that a reason to rename would be consistency with the other titles of the same dialog: it doesn't use the generic term "Object" when you open it for images, or frames - so use of generic term in case of embedded objects is inconsistent.
(In reply to Mike Kaganski from comment #4) > use of generic term in case of embedded objects is inconsistent. For Insert menu: Object -> Embedded Object For Properties dialog title (for embedded objects, e.g, Formula, chart, OLE Object) Object -> Embedded Object In Navigator OLE objects -> Embedded Objects For Title of "OLE-Object" toolbar "OLE-Object" --> Embedded Object Would make it easier in online help to use "object" as generic term and "embedded object" for QR code, formula, chart, OLE object, etc. Better consistency across UI elements. Reduce ambiguity about scope of "Align Objects" (for users who do not read documentation or understand technical differences between Images, Shapes, Formula...) Remove ambiguity that OLE-Object (in Navigator and Toolbar) is not just for OLE Objects.
(In reply to sdc.blanco from comment #5) I like the direction very much! However, the OLE wrong term has one advantage. The "embedded objects" (using the proposal terminology) may be both linked or embedded. So while distinguishing the embedded objects from MS OLE technology, it introduces another confusion: is it consistent to call a linked object "embedded"? I realize that I myself raised the topic of "OLE is not OLE", but I must confess that I myself don't have a specific proposal how to solve that. Likely the OLE term was chosen by ex-SUN back then because of the same terminology difficulties ...
(In reply to Mike Kaganski from comment #6) > is it consistent to call a linked object "embedded"? Naive user POV. Sure! As a naive user, I would just accept that some objects (including "external links") are called "embedded" in LO, and not think further about it. (And from an everyday pov, "external links" sound "embedded") To some extent these distinctions are arbitrary* from UI pov (even if not arbitrary from technical implementation pov). Given that "frame" and "image" get their own labels in the Properties dialog, then it appears that the word "Object" was used as the leftover "Other" category for other objects that have a properties dialog. => any chosen adjective before "object" (even if not a perfect fit) would at least limit the scope of that group of "objects" and allow differentiation from Shape and Textbox, which are also called "objects" (in the generic meaning). * To elaborate this point about a certain amount of arbitrariness, from a user/UI POV -- as noted "frame" and "image" get their own labels in the properties dialog, but in principle, they could be considered as "embedded objects" as well, no? Understandably, "frame" and "image" are used more frequently (and in different ways), so they get their own individual labels, which makes it easier to refer to them in help, etc. No problem (imo). But why (as a rhetorical question) are QR code and media files treated as "Drawing objects" (in Navigator, and do not have an Object Properties dialog), even though, in everyday meaning, they are embedded? And why shouldn't textboxes and shapes also (from user pov) be considered "embedded objects"? As user, it is easy to accept that QR code is listed under Insert > Object (even if technically in LO, it is not), and I accept that QR codes and media files are treated as "drawing objects" -- which primes expectations about which dialogs to use for positioning, formatting these objects.
(In reply to sdc.blanco from comment #7) > (In reply to Mike Kaganski from comment #6) > > is it consistent to call a linked object "embedded"? > Naive user POV. Sure! > > As a naive user, I would just accept that some objects (including "external > links") are called "embedded" in LO, and not think further about it. ... > > To some extent these distinctions are arbitrary* from UI pov (even if not > arbitrary from technical implementation pov). Oh, I would love to quote you to Eyal in tdf#141452, who insists that "What we should do is *simultaneously* become consistent with "dictionary meaning" _and_ self-consistent", and "dictionary meaning is not a "personal preference", it is the preference of essentially everyone". They insist that the terms used in the program have no right to mean something specific, defined in the program: they require that every word used in the term be exact to the *dictionary* meaning. === rant end === I would say, I agree with you; but in this specific case, the distinction between linking and embedding will be really crucial to the usage for some people; and when they will be confused, unsure if the term means that what they thing "linked" is termed "embedded", they would be really lost, and will have all the reasons to complain (unlike Eyal's case mentioned above).
(In reply to Mike Kaganski from comment #8) > distinction between linking and embedding will be really crucial Skipping over the general point of linking v. embedding -- -- the focus here is on "objects" (in whatever sense) that use sw/uiconfig/swriter/ui/objectdialog.ui Could not find examples of "links" in Writer that use this Properties dialog. Is this in Calc? Are you referring to sections with links to external files?
Insert->Object->OLE Object; use (*) Create from file, check [x] Link to file, and select e.g. an ODS or an ODT or an ODG (or whatever).
(In reply to Mike Kaganski from comment #10) Thanks. Got it. if "Embedded" label with OLE Objects is expected to be problematic... then -- first speculation about possible response: Make a "Linked Object" label dialog (just as Frame and Image have their own), modify toolbar to show Ole Object or Embedded Object as title, and reconfigure Insert Menu as follows: Image Chart Embedded Object Formula Object QR and Barcode Scan > Audio or Video Gallery Shape OLE Object Main changes: (a) Rename "Object" to "Embedded Object" (b) move entries in "Media" to "Embedded Object" submenu, (c) Ole Object at top level. Additional Comments 1. Have (almost) followed existing menu ordering -- other orderings are fine with me. 2. Initial ordering/organization is a modifiable default, because users can reconfigure in Customize. 3. Embedded objects submenu now includes commands that can be understood from user POV as "embedded" (even though QR and Audio do not get Properties dialog, and Gallery is actually Image). Another possible response: decide that Eve users who link files are familiar with the chaotic labelling in LO and will just ignore the fact that it is now called embedded. (-:
(In reply to Mike Kaganski from comment #8) > the distinction between linking and embedding will be really crucial to the > usage for some people; and when they will be confused, unsure if the term > means that what they thing "linked" is termed "embedded", they would be > really lost Ok -- will assume that this hypothesis is valid for now.... ---but a few questions and comments to clarify the situation. 1. Afaict, only one small corner of Insert -> OLE Object involves an external link, where all other uses of Insert > OLE Object result in what we are presently calling an "embedded object". Right? Even when an external file is chosen ("Create from file"), it is only "linked" if "Link to file" is chosen. The proposal in comment 11 to make a "Linked Object" dialog was motivated by my misunderstanding that all OLE objects were a "Linked Object". It seems inappropriate to make a special dialog for OLE Objects, when most of the uses are embedding. 2. This (potential) confusion or uncertainty about linked/embedded is already addressed in the documentation. See "Link to file" https://help.libreoffice.org/7.4/en-US/text/shared/01/04150100.html If there are other places where it would be appropriate to mention, then I can add them. 3. Meanwhile, as a different issue, there is no way afaict (e.g, in Properties dialog or Navigator) to see if an OLE object is linked or not. (and Edit > External Links does not identify the object name). (not a complaint, just an observation, and a thought that this might be a bigger problem for users than the "embedded" label in the Properties dialog.) 4. The proposal in comment 11 might still be usable (if it seems an improvement), but now with "OLE Object" included in the Embedded Objects submenu, otherwise, comment 5 still seems valid.
(In reply to sdc.blanco from comment #12) > no way to see if an OLE object is linked or not. At least for linked images, it is possible to see in Navigator. But presumably there has not been any confusion (bug reports) about the Image Properties dialog being the same for both embedded and linked images (i.e., no need to change Image title, e.g., to "Linked or Embedded Image").
(In reply to Mike Kaganski from comment #8) > ...but in this specific case, the distinction > between linking and embedding will be really crucial to the usage for some > people You can insert an image as link only. Meaning the distinction whether an "embedded object" occupies space in the document or is a link to some other place is taken later and not when you start to embed. I like the proposed term and doubt many users including me know what OLE means (beyond embedding objects somehow).
(In reply to Heiko Tietze from comment #14) > You can insert an image as link only. Meaning the distinction whether an > "embedded object" occupies space in the document or is a link to some other > place is taken later and not when you start to embed. I fail to see how that is true or is relevant to the discussion. > I like the proposed term and doubt many users including me know what OLE > means (beyond embedding objects somehow). I fail to see how "doubt many users including me know what OLE means" contradicts the "some" I used in comment 8, or change the fact that for those who *care* if that is linked or embedded (which is crucial e.g. when you decide if you may delete the file which you used as the source for insertion of the object) or which files you need to transfer to another place (move to a different directory or email to someone), seeing "embedded" would mean "embedded", so they would indeed expect that removal of the source is OK.
To clarify a bit: Say, you are a user who (a) does not know what OLE means, and (b) needs to know if the files used to insert something into a main document may be safely deleted. In the current state, when the OLE term is used, *both* knowing what it means, and *not* knowing what it means forces you to do some additional steps to check if the files are safe to delete (when you know, you realize that OLE may be both linked and embedded, so you need to check *somehow* which one is this; and when you don't know, you simply have no information). In the proposed change, the user sees the recognized "embedded" term, which tells exactly what they need to know (and which lies, but the user would learn that after the fact).
(In reply to Mike Kaganski from comment #16) > Say, you are a user who (a) does not know what OLE means, and (b) needs to > know if the files used to insert something into a main document may be > safely deleted. RTFM. (-: (or make a test using documents that can be lost without distress) Mike, please help us to find a way forward. As I understand, the ”E” in OLE stands for ”Embedded” – so contradictions abound before we even get started. You write as though you have some insight into this small (?) group of users who link OLE objects, as opposed to simply embedding OLE objects, which seems to be the "default" (most common case?) in the Insert > Ole Object dialog Do you really think such users would be ”tricked” by the word ”Embedded”, when they had to explicitly click ”link to file” to get this kind of embedding, and where there is documentation about this option (which I am happy to improve if you think it is inadequate). Would it be better to leave OLE-Object as a ”separate” (special) case, just as Image and Frame, where each gets their own dialog and toolbar title, and appears at the top level of the menu (i.e., not in a category, such as "Object" or Embedded Object")? (either way is fine with me)
(In reply to sdc.blanco from comment #17) > As I understand, the ”E” in OLE stands for ”Embedded” – so contradictions > abound before we even get started. I do not understand the "so contradictions abound before we even get started" - please describe what you mean. OLE means exactly Object Linking and Embedding; regardless of the copyright on the term, it says explicitly that the object that would use that name may be *either* linked *or* embedded, so both cases are possible. It does not contradict anything, it just does not prescribe which option is used in a specific case. > You write as though you have some insight into this small (?) group of users > who link OLE objects, as opposed to simply embedding OLE objects, which > seems to be the "default" (most common case?) in the Insert > Ole Object > dialog I used that much when I worked in a previous job. I have no numbers, so I am in no position to discuss how small the group is (my gut feeling is that it's quite large, but I will not insist - but note that data loss potential - even if it's just because of a term that is misleading - is not something that we may deem OK just because the number of affected is small); the search for "embed link" on Ask [1] suggest that there are real uses of that. > Do you really think such users would be ”tricked” by the word ”Embedded”, > when they had to explicitly click ”link to file” to get this kind of > embedding, and where there is documentation about this option (which I am > happy to improve if you think it is inadequate). The feature is rather advanced. And you need to consider different scenarios. You may forget how you created the file a year ago, when you need more space today; you may use a file created by your colleague in a shared environment... > Would it be better to leave OLE-Object as a ”separate” (special) case, just > as Image and Frame, where each gets their own dialog and toolbar title, and > appears at the top level of the menu (i.e., not in a category, such as > "Object" or Embedded Object")? (either way is fine with me) No. And as said, I can't suggest the better name. My current proposal is to follow your *original* idea, and use OLE everywhere where we need to disambiguate such objects from images or the like, and keep the "MS OLE vs our wrongly-named OLE" for a future. [1] https://ask.libreoffice.org/search?q=embed%20link
(In reply to Mike Kaganski from comment #18) > My current proposal is to follow your *original* idea, and use OLE everywhere > where we need to disambiguate such objects from images or the like. Got it. Thanks. So, starting small... For Insert menu: Object -> OLE Object For Properties dialog title (for embedded objects, e.g, Formula, chart, OLE Object) Object -> OLE Object No other immediate changes afaict -- but I think there may be some additional small adjustments buried in some small/rare dialog boxes -- Any opinions about following side effect from such a change? Insert menu OLE Object Formula Object QR and Barcode OLE Object a little inelegant with Insert > OLE Object > OLE Object -- but that is counterbalanced with better consistency across whole UI (e.g., between Navigator, toolbar and Property dialog titles). Will wait for further comment/opinions....
(In reply to sdc.blanco from comment #19) LGTM :)
One additional consideration... Add "Properties" to the Dialog title so that it would be: "OLE Object Properties" (and if that is ok, then would do the same for Image and Frame to keep it parallel).
Created attachment 180098 [details] OLE and Object in General Glossary Attached is the entries for OLE and Object in the General Glossary [1]. (imo) They do not really seem to "fit" fully with the discussion here. Regardless of the final renaming decision, maybe it is a good time to consider whether these descriptions need improvement. [1] https://help.libreoffice.org/7.4/en-US/text/shared/00/00000005.html
(In reply to sdc.blanco from comment #21) > One additional consideration... > Add "Properties" to the Dialog title so that it would be: No input, so have not done anything there. Otherwise, this might be ready to go: https://gerrit.libreoffice.org/c/core/+/134186 plus -- to remain parallel with the Properties dialog for image (see bug 138844), I have changed the "Type" tab to "Position and Size". (still wondering why it has been called..."Type")
The topic was on the agenda of the design meeting. No further comment was given, no objection to the proposal. The issue might have been solved with bug 149047
Seth Chaiklin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/70b00434bad4216aeaed360808e19344de794c9c tdf#149047,tdf#149018 improve label and tooltip of .uno:ObjectMenue It will be available in 7.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Seth Chaiklin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/4602a27bc9d6304f1ac7c56fde31c138fe7ad626 tdf#149018 "Object" -> "OLE Object" in Menu and Dialog labels It will be available in 7.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
From General Glossary: @Mike, are you happy with this description. (Maybe "Object" should be added after OLE.) In help pages where "OLE Object" is mentioned, I will add a link to this description -- so it is a good place to add any relevant information that would not normally appear in a help page. --------------------------------------------------- OLE Object Linking and Embedding (OLE) objects can be linked to a target document or may also be embedded. Embedding inserts a copy of the object and details of the source program in the target document. If you want to edit the object, simply activate the source program by double-clicking on the object. ------------------------------------------------------ And then there is "Object" -- which I have trouble understanding. Is this description referring to what the Insert menu (with Image, Frame, OLE Object, etc.) is inserting? ------------------------------------------------------ Object An object is a screen element containing data. It can refer to application data, such as text or graphics. Objects are independent and do not influence each other. Any object containing data can be assigned certain commands. For example, a graphic object has commands for image editing and a spreadsheet contains calculation commands. ------------------------------------------------------------- Otherwise, I think the main UI changes are made now. (In reply to Heiko Tietze from comment #24) > The issue might have been solved with bug 149047 Nope. FTR, that bug was a spinoff from this one. There were some "strange" (unclear) .unos that could be seen in the Customize dialog. Bug 149047 tried to improve the labelling and tooltips for some .unos -- to reduce ambiguity and give a better indication of their function.
(In reply to sdc.blanco from comment #27) > Maybe "Object" should be added after OLE I don't see it necessary: the "object" is present in the description; and the title looks like it describes a "technology", which is OK (making the title "OLE object" would still leave room for "but what that OLE stands for in the combination" type of question :-)) > And then there is "Object" -- which I have trouble understanding. Is this > description referring to what the Insert menu (with Image, Frame, OLE > Object, etc.) is inserting? > ... The description below is highly abstract; it's unclear how this description fits the "object" term (as defined here) usage in the documentation (and only that fit matters). If we use (or want to use) "object" only to point to some specific kind of things in the program, we better re-word this. In the current form, I'm afraid it helps no one. (But that would be for a follow-up?)
(In reply to Mike Kaganski from comment #28) In light of the concerns expressed in comment 15 and comment 16, maybe something like the following should be added to the OLE description (which only elaborates on embedding at present). If an OLE object is linked to a target document, then the target document must be available in the location specified in the link. Deleting or moving the target document will make it impossible to open the linked OLE object. About "Object" > The description is highly abstract ... In the current form, I'm afraid it > helps no one. (But that would be for a follow-up?) Thanks for confirmation. Bug 149211.
Seth Chaiklin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/969603ffa48c6566b602a2a9174fc0acea307428 tdf#149018 a few more "Objects" -> "OLE Objects" It will be available in 7.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Seth Chaiklin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/help/commit/bdaeee88ae63c1107b6c7db0dbcabb5347554397 (related) tdf#149018 add to OLE explanation in Glossary
Seth Chaiklin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/help/commit/4252eedb1e8e11aaae5e4d5e1b1f6f1c24067afe (related) tdf#149018: "Object"-> "OLE Object" for Insert and Edit menus
Seth Chaiklin committed a patch related to this issue. It has been pushed to "libreoffice-7-4": https://git.libreoffice.org/help/commit/c06db8913c665d5647889f8f78d4bb7666956f3f (related) tdf#149018: "Object"-> "OLE Object" for Insert and Edit menus
To the extent of my arguably limited knowledge, the QR codes / barcodes that LO generates are not OLE objects, but regular bitmap images. So, that particular entry should be moved to the main Insert menu
Seth Chaiklin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/help/commit/9f035d777141d5f039a85d6f64b627eaf73b8079 (related)tdf#138844, (related)tdf#149018 "Type" -> "Position and Size"
Seth Chaiklin committed a patch related to this issue. It has been pushed to "libreoffice-7-4": https://git.libreoffice.org/help/commit/2823fbf593dc4f9d87f3d14731bf997cc7de7deb (related)tdf#138844, (related)tdf#149018 "Type" -> "Position and Size"
(In reply to Adolfo Jayme Barrientos from comment #34) > To the extent of my arguably limited knowledge, the QR codes / barcodes that > LO generates are not OLE objects, but regular bitmap images. So, that > particular entry should be moved to the main Insert menu. Your knowledge is correct. That issue was noted, but not addressed here. I was about to close this ticket, so I would propose that you open a new ticket for this issue -- so that UXEval can agree to add QR code to the toplevel of the Insert menu, or make another kind of categorization/structuring of that menu.
At this point, "Object" has been replaced in menus (for all modules), afacit. And the relevant help pages have been updated. The aim was to bring consistency between Navigator and menus, and to avoid using "object" in a generic way in the interface. These goals have been addressed, so closing this ticket as FIXED. (will leave it to others to open a new ticket in relation to QR code, as noted in comment 34)