The AutoText dialog has quite some usability problems. Creating an autotext is particularly difficult and the AutoText dialog is absolutely not self-explaining in this regard. How to reproduce: * Write any text in a Writer document and mark some part of the text. * Open the AutoText dialog. * Where is it possible to add the marked part of the text as AutoText? Behind the button "AutoText" there is only the option "Import", but no option to add AutoText. * The user then needs to figure out that after he/she adds something in the field "name", then there is suddendly a new option available behind the "AutoText" button which allows to "Add" the new AutoText. Solution: The usability of the AutoText dialog can be quite easily improved. It would be good, if there is simply always a button "add new AutoText". The name and shortcut could be added or changed by the user afterwards. By the way, also renaming of existing AutoTexts is also implemented counter-intuitive. If the user changes the name of an existing AutoText, this simply does not have any effect. The user rather needs to click on the "AutoText" button, because now behind it there is the new entry to rename AutoTexts, for which a separate window pops up. Sorry that my bug description sounds difficult, but that's actually the situation how the AutoText feature currently is implemented. LibreOffice 3.5.4 PPA, Ubuntu 11.10.
Sending a gentle ping with regards to this enhancement request. Please have a look at it and confirm it. It has been sitting around for already half a year (or 2003 if I take the OpenOffice.org bug entry) :-)
@Gerry: sorry you had to wait this long. Especially for your activity in LibreOffice. But, after this time I can confirm this is a horrible implementation. Still can confirm using W8 with LibreOffice 4.1.0.1 RC. I totally agree there is a (big) usability issue here. NEW, but as enhancement (high). Kind regards and thanks for reporting, Joren
Thanks a lot Joren for looking into this bug. Caolan mentioned once that the AutoText dialogue is already ported to the .ui format. However, without any usability changes yet (screenshots here: https://wiki.documentfoundation.org/Development/WidgetLayout#Screenshots). This porting of the .ui makes it much easier to make future changes in this dialog, though. Caolan described it like this: git clone git://anongit.freedesktop.org/libreoffice/core and play around with glade and sw/swriter/ui/autotext.ui I tried a bit myself, but I did not get very far, unfortunately.
Actually setting to NEW (joren already confirmed this in comment 2).
Still unusable in 5.3beta2. I'm glad you had the instructions written clearly or I wouldn't have been able to figure out how to add it, and a disabled "insert" button doesn't help... Wouldn't insert mean add the autotext I just created into the existing list?
Changing priority back to 'medium' since the number of duplicates is lower than 5
Confirming this "bug" I'm using autotextes, but when I have to add one, I often need to search on the web to refresh my mind how to do it
I felt free to add Andreas Kainz to this bug, since he works on dialog layouts. The AutoText dialog (as described in this bug) has a terrible usability. Maybe Andreas has an idea for its improvement.
*** Bug 141430 has been marked as a duplicate of this bug. ***
*** Bug 152574 has been marked as a duplicate of this bug. ***
Created attachment 195577 [details] Mockup I believe we have to separate the overview and insert actions from creating a new entry. The mockup shows the idea; I moved a couple of less important functions into a context menu to have only the most relevant actions on buttons. Some remarks: Display remainder of name... * does not work (DUM => no DUMMY) and should be on by default AutoText menu > Edit (Opens the selected AutoText...) * no additional value Save links relative to * no clear need for two options here Categories * functions are available only for content in the user space; should be made more clear eg. by showing the items as disabled * path modification could go into this dialog, if needed her at all * Rename applies to the selection and what is entered under the (new) category name; could be done inline * Delete works only if the matching path is selected (and fails silently otherwise); better autoselect the path https://help.libreoffice.org/24.2/en-US/text/swriter/01/02120000.html
(In reply to Heiko Tietze from comment #11) > Created attachment 195577 [details] > Mockup Thanks for the Mockup. I really like the separation of overview and creation of new AutoTexts and the Mockup. Here some comments from me. General comments: * Concerning the preview window: Is it possible to add a zoom slider for the preview window? In the current (old) dialog, it is necessary to perform a right mouse click in order to change the zoom level. A zoom slider would be much better. * The AutoText dialog should not be a modal dialog. Currently, the (old) dialog is modal and it is not possible e.g. to select any text in the document after the user has opened the dialog. Comments on the Mockup for the creation of new AutoTexts dialog: * I think there should be a drop-down dialog to choose the category where the new AutoText should be placed in. Comments on the Mockup for the overview dialog: * I think there should be five buttons: "Help", "New AutoText" (out of selection), "New Category", "Insert", and "Close". (I don't know where else the "New Category" best fits; it could be also placed in the context menu when performing a right mouse click on a category) * In the context menu, ** I think it is sufficient, if there is only "insert", "copy", "modify" and "delete". ** The "categories" entry is not necessary, if there is an option to change the category after the user clicks on "Modify". Alternatively, the dialog could allow drag and drop from of an autotext entry from one category to the other. ** If one performs a right mouse click on a category in the list, it would be good to get a context menu showing "Modify" and "Delete", and "Import?" (is it currently possible to import a category of AutoTexts? I am not sure) Additionally to that: * Since the create new AutoText dialog would be now a separate dialog, the following would be possible now: If the user selects text/tables/images in a document and then performs a right mouse click, there could be the new entry "Create AutoText out of selection".
We discussed the topic in the design meeting. The idea to create a new AT from clipboard was rejected as the content should be verified in the context. And if the dialog is amodal it wont be necessary anymore. Having a slider for the preview is over-engineering. The actual issue should be fixed, and the AT not drawn on some A4 page. Plus, bug 162101 might be a solution here. We pondered over the question whether it make sense to modify the category while creating a new AT. The mockup carefully avoided to mix individual attributes from one AT with information on the list of ATs such as categories and path. In this regards the idea of a "New from Selection" function would require some default/favorite category where all new AT go first. The category and its path must not be r/o. It might be possible if we drop the category/path overkill and have just one flat list of items somewhere in the user space. And to structure the list of ATs I could imagine to have a category name directly on each item - in this case the above changes respectively. This makes the whole functionality way easier to understand and to handle.
(In reply to Heiko Tietze from comment #13) > We discussed the topic in the design meeting. Thank you very much for discussing the topic in the design meeting. How do you imagine the workflow for "Add new"/"New from selection" if the user cannot choose a category in the "creation of new AutoTexts" dialog? Where does the new AutoText go? I just imagine the following scenario: 1. the user opens the AutoText overview dialog 2. the user selects some text in the document 3. the user clicks on "Add new"/"New from selection" and then the "creation of new AutoTexts" dialog opens up. 4. How does the user choose the category? Or will the new AutoText just appear in the list of AutoTexts without a category and the user needs to drag&drop it later in a category? I agree to everything else. Also, the idea of a magnifier tool sounds good (just some good way to properly preview the existing AutoTexts). Thank you so much for looking into it.
(In reply to Gerry from comment #14) > How do you imagine the workflow for "Add new"/"New from selection" if the > user cannot choose a category in the "creation of new AutoTexts" dialog? There would be only one place and one file for AT. And the Category information is part of the AT attributes' list. If we have to keep various files in various places for some reason, one alternative could be to store new AT in one standard category with the follow-up workflow to sort. > I just imagine the following scenario... You describe the "New AT" workflow, which is not "New From Selection". On the other hand, the amodal dialog allows to change the selection and it is always 'new from selection'. > 4. How does the user choose the category? In order to stick to the current workflow / background processing as close as possible, the idea was to run "New AT" from a certain category. Sorting afterwards is possible per drag 'n drop.