Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
Summary: | Q-PCD The AutoText dialog is only usable for OOo experts | ||
---|---|---|---|
Product: | General | Reporter: | christian.jansen |
Component: | code | Assignee: | AOO issues mailing list <issues> |
Status: | ACCEPTED --- | QA Contact: | |
Severity: | Trivial | ||
Priority: | P4 | CC: | gleppert, issues |
Version: | OOo 1.0.0 | ||
Target Milestone: | AOO Later | ||
Hardware: | Other | ||
OS: | Other OS | ||
Issue Type: | FEATURE | Latest Confirmation in: | --- |
Developer Difficulty: | --- |
Description
christian.jansen
2003-09-25 15:23:18 UTC
Accepted. Additional Info: Source User Experience Category Usability Customer Need/Problem The AutoText dialog is only usable for SOOo experts. Eng Owner Christian Jansen added keyword Q-PCD according to the announcement on releases (http://www.openoffice.org/servlets/ReadMsg?list=releases&msgNo=7503) this issue will be re-targeted to OOo Later. SBA->CJ: I would like to point out that this summary"...DIALOG only usable for experts" is not targetting the problem as I would describe it: "A new user has a problem to understand the use of AutoText". A tiny bit of "Competitive analysis": In MS Word, AutoText can also be inserted via menu. This is very intuitive. The menu has a clear and intuitive structure ("Travel-Select-Use") while a dialog is always at least "a little" confusing when the user sees it for the first time. Dialogs have different controls (buttons, checkboxes, listboxes, radio buttons, preview windows,...) that leave new users uncertain about "what will happen if I try", especially if they already experienced that a dialogs layout can change massively after using one of them! (Try Insert-Index-Index, use of the listbox "Type" - This discourages the use of unknown dialogs. In contrary, a new user always can feel "safe" while travelling through unknown menus in order to "just look" for something. Finding the AutoText entries themselves in the (sub-sub menu of the) "insert" menu can raise interest in the this feature much better than the "most inviting layout" of any "Edit-AutoText" dialog. Just my 2 cts. I would say I am well-versed in using different software packages, and I found the AutoText dialog extremely confusing. I thought it was broken at first! I would like to help with redesigning it, but I have no C++ coding experience. What can I do to help? I completely agree with the comments above and would like to give some specific feedback about the current implementation in the hope that any re-design will include improvements in these areas: 1) The user is invited to lose work. 2) The edit feature is very confusing. 3) It is possible to override standard entries unintentionally. Concerning item 1: Select some text. (That you have to know ahead of time to do this is another problem.) Activate the AutoText dialog, type in a name and shortcut. Now what to do? There is no obvious way to "save" anything. If the user clicks "Close" (an obvious button and not normally a destructive action), then the entire effort is silently canceled and lost. Worse, if the user happened to try and define something like "DT" that's already defined, the lost definition will now appear to work, but will give an entirely different and unexpected result (see http://www.oooforum.org/forum/viewtopic.phtml?t=43164). Concerning item 2: Clicking on AutoText > Edit cause the dialog to disappear and the user is thrown into a completely new document window with no explanation or guidance. This is a very unusual pattern of interaction and very disorienting. I realize that, by nature, editing an autotext entry may require the complete Writer application, but at least some explanation is required. Some kind of window embedded in the dialog would be nice, with an option to expand it to the full window. At the very least, you could insert some boilerplate instructions in the new document along with the autotext, then ignore that when the edited entry is stored. Concerning item 3: An organization may have set up standard autotext entries that are needed. If a user defines an autotext that happens to use the same shortcut, the standard entry will no longer work. There should at least be some indication that a shortcut is in use or not, so that an override is a conscious, intentional decision. Although this issue is quite old, I second the motion that the usability of Autotext needs to be improved. Creating an autotext is difficult and the autotext window is not self-explaining (and there is no help-button either). Inserting an autotext in the document is difficult, too. What is the meaning of the abbreviation that can be assigned to an autotext? This is not self-explaining. Is there something like an autotext manager for text fragments? No, but it would make sense. Thanks |