Talk:Specification search toolbar

The short cut Ctrl-F1 is bound to the extended help in dialogs (at least on WinXP). Currently this short cut cannot be customized by the user.

The specification should say whether wildcards are possible or not.Regina 21:11, 28 April 2009 (UTC)

Spec Review, 2009-10-11

First: I still love the idea and I am absolutely happy that it is worked on :-) Nevertheless, I'm part of the UX team and consequently I sometimes have a different view on some things which I would like to discuss. Since the specification is very well structured, I will refer to each of the sections. First, I will consider all questions related to User Experience, then I'll add some more general comments with regard to the specification itself. If you have any questions, then please contact me or the User Experience team mailing list ux-discuss. Okay, let's go :-)

Detailed Specification:

• Position and visibility:
  • Docked/Undocked: Inconsistent description: The upper text states "status bar and will be immovable", the General section below sais "A rip-out handle when docked". The section Position and Visibility sais "by default" and "docked/undocked", which is a clue for making it movable. However it is meant, I suggest to keep it docked without the possibility to move it by the user.
  • The proposed position "above the status bar" is sub-optimal, if other windows (Stylist, Navigator, other Task Panes) are docked. Then, the search field is far away from the document content. I suggest a behavior very similar to the "Color bar" in Draw/Impress. It is fixed and considers the position of the document viewport.
• Search bar settings:
  • What does "individually for each application module" mean? Does it e.g. consider several instances of Writer? Currently, Writer seems to only share the very last Search Text across multiple Writer documents, the other search items are somehow handled individual with regard to the document. Calc handles it completely different. I didn't check further...
  • Concerning "privacy/security", what does "office restart" mean? Closing the last document, or closing the quickstarter (if used). I propose to consider the former one to clear the contents.
  • Does "stored individually for each application" module mean, that the settings are even safed after an office restart? This should behave similar to the "string combo box" (see above); reset after last document has been closed. (Please note: We may change that behavior with the help of Usage Data. It should be possible to track the initial action of the user after e.g. opening the Search Toolbar.)
• Shortcut behavior:
  • We had the same problems for "Notes2", so we decided to go for "Ctrl+Alt+N" (the 'N' may be changed, soon). So I propose to use "Ctrl+Alt+F". But, please check this with localisation.
• Toolbar items:
  • Toolbar: The "rip-out handle" is described before, but missing in the figure. It is still hard for me to know whether the toolbar can be undocked...
  • Toolbar: Name is a bit weird - especially in the context of the view menu (View -- Toolbars -- Search Toolbar). Please consider to mimic the name of the "Hyperlink Bar", thus "Search Bar". Additionally, the search bar does not contain different tools, it provides interaction elements which strongly correlate with each other.
  • "Find" label:
    • The label "Find" is much more positive than "Search", but inconsistent to the current search dialog (and all other places mentioning search). I propose to harmonize it and just call it "Search:" or "Search for".
    • Usually, the colon isn't used in OOo for text boxes / combo boxes, but since the toolbars no never (?) contain descriptive text, it makes clear that this is a descriptive (non-active) element. (The colon may be replaced by "for" to match the search dialog, see before).
  • Search Text Field:
    • Usability Issue: Usually the OOo window border is close to the screen border. So what happens when the "drop-down button" is used. How likely is it to open above the text field. This is a real issue for the order of the elements (top to buttom, bottom to top), since the user do remember the last Search Texts (to be found at the top, at the bottom, ???)
  • "Next" button, "Previous" button:
    • The order [Next] [Previous] of the buttons is questionable. It seems that the "default" button is located next to the Search Text Filed. But, Firefox (Ubuntu 9.04, Western Text) handles this different and OOo also (Navigator, see Interaction and User Experience Related Questions" below. So I strongly recommend to use [Previous] [Next] to be consistent within our product and other software.
    • The Navigator uses different naming: Backwards/Forward, also the search dialog ("Search backwards"). To be consistent, it would be nice if you consider [Backward] [Forward].
  • "Search All" button.
    • Basically, the name visible in the figure "Tool bar items" is "Find All". This is better, since it is consistent to the current search dialog behavior.
    • The icon which is shown in the figure "Tool bar items" is (sorry) totally wrong. Firefox presents read-only web pages and does not alter the text itself. The given icon represents a formatting change (yellow background) which can also found in the formatting toolbar. And, we do not markup the text, we select it. So I propose to use the icon for "Selection" (see Navigator, presents some text lines with two text selections).
  • "Match Case" CheckBox: Default value is missing (Proposal: off).
  • "Whole Word" Checkbox:
    • It is a bit inconsistent to the search dialog which states "Whole words only". The consistency would ease the translation and provide the clue that more than one word can be entered in the Search Text Field. At least, I assume this behavior, since the Search Toolbar doesn't seem to be used for single words only (the other text states "any text" for the Search Text field).
    • Default value is missing (Proposal: off).
  • Dynamic Text Info:
    • The text "phrase not found" is inconsistent to the current implementation. The separate dialog (run a search without occurrences from the search dialog) states "Search key not found." Although the wording can be improved, it should be consistent. Thus, either re-use the existing formulation or update the dialog, too.
    • Additional use case: The user did not enter any search text and searched (e.g. by pressing <RETURN>). The current specification states to do "nothing" (refer to the "Search Text Field" section). Sometimes people accidentally delete their search text and don't notice it.
    • It seems that the space for the Dynamic Text Info is "reserved" in advanced. This may cause problems for a) the user (toolbars do never have empty space, so it is hard to know that the option menu button at the right belongs to it) and translation (more or less space required according to the language). This issue could be solved with a "undockable" bar like mentioned above (fixed size below the whole document viewport).

Search behavior:

• Search in Notes: The notes are represented by individual text elements (EditEngine?). Due to technical limitations they cannot be active at the same time and consequently it is impossible to select text in different notes at the same time. "Replace All" is a bit different, but the Notes2 team decided to disable it to be consistent with "Find All" (either it works for both, or not).
• Remaining text has been skipped, since it should be better to discuss it together.

Accessibility: Skipped, since there are people who know much more about that than I do.

Future Tasks: Skipped, since this should be (later) discussed together.

Interaction and User Experience Related Questions Here are some more questions which relate to how the user will perceive the interaction and how beneficial the new functionality appears to be. I try to provide a priority which "simulates" the user's point-of-view :-)

• Priority High: I strongly recommend to "highlight" the buttons when accessed via keyboard bindings. Example: If the user enters Search Text and presses <RETURN>, then the "Next"-button should be highlighed. This is pretty similar to the current behavior of the search dialog. Same is valid for next/previous or close (if used).
• Priority High: Currently it seems unclear how to easily and efficiently leave and/or close the Search Toolbar. My proposals:
  • The current approach of "keybinding" and "close" in the option menu can only be hardly discovered. There should be a highly visible element to "get rid of it", otherwise it will stay open and reduce the the size of the document workspace (which is somehow different to the goals mentioned in the spec).
    • Proposal 1 (recommended): Please add an additional button [Close] at the end of the toolbar. A similar design pattern can be found in Impress in the "Master View Toolbar" which states a "Close Master View", which changes the context and therefore also closes this context dependent toolbar.
    • Proposal 2: Add a small 'x' (the same like in the current Task Panes in e.g. Impress) at the most right toolbar position. (Specification at task_panel_spec.sxw, but seems to miss the 'x' available in OOo.)
  • If the focus is in the "Search Text Field" and (some) Search Text is selected in the field, then <ESC> should remove the text selection. Cursor is kept in the Search Text Field.
  • If the focus is in the "Search Text Field" and Search Text is not selected, then the focus is set back to the document.
    • The position of the cursor is dependent of previous actions: a) If the user exectuded search and the some document text has been selected, then the cursor is set to the end of the selection (like in the current Search Dialog). b) If the user did not execute a search, then the previous document cursor position is used. (I should remember the the current behavior of Notes is wrong... *g*).
    • At the moment I'm a bit unsure whether the Search Toolbar should be closed, too. Usually I would say yes, since the user is able to easily re-enable it via the keybinding (in the future). But, with regard to the currently proposed behavior "Toolbar", we shouldn't introduce another new behavior.
• Priority Middle: It would be extremely desirable to let the user know whether the Search Text can be found at all. Firefox for example, changes the background color of the Search Text Field to red, if it is clear that nothing can be found. (And, it immediately starts to search for the first occurrence right after the user starts to type - great!)
• Priority Middle: How do the search entries of both search bar and search dialog relate to each other? Two examples: What happens if the search bar is closed and the find dialog is opened (same Search Text?). What happens if the search bar and search dialog are open same time (harmonized Search Text?). (...) This also relates to the search history (drop-down) in both the dialog and the toolbar. And the special options like e.g. "regular expressions" (Usability Issue).
• Priority Middle: Are there any plans to switch from the current search dialog to the search bar? Since it is planned (in the first step) to keep the keybinding "Ctrl+F" for the search dialog, this feature might be hard to discover. If the current development step is really intended to gather feedback without making the feature "more visible", this is okay for me.
• Priority Low: What happens if the search bar is closed via e.g. "close". Will the currently searched text selection in the document be kept?
• Priority Low: At the moment it is a bit hard to discover how to delete the content of the Search Text Field (this also relates to many other occurences in OOo). Many (!) people still click into the field, move the cursor to the first/last position and delete the text manually (they don't know that a selected text can be simply deleted, trust me). Due to the use of the combo box, it will be an open issue (for me).
• Priority Low: It is recommended to consider the "object" search buttons in both the navigator and below the vertical scrollbar. After entering the search text, and selecting the "Navigation" object "Repeat Search", the use of "Continue search forward" and "continue search backward" should be usable, too. Behavior like continuing the search with the search dialog.

Specification Related (Rather Formal Requests):

• References: The section "References" is missing and would be well suited to refer to the original "OpenOffice.org Toolbar Specification" (refer to openoffice_org_toolbar_spec.odt). Currently references to documents or other information are placed at the end of the wiki page.
• User Scenarios: I don't know if "obscures" is well suited, here. Proposal: "hides some document content". Additionally, the user scenario is the "bad one" without mentioning what is to be improved :-)
• Competitive Analysis: For "Safari (Mac)" and "MS Office" the text says "missing". Is the competitive analysis missing or is the functionality missing?
• Detailed Specification:
  • Referring to "Figure3" may cause problems in wiki texts if more pictures are added. I propose to refer to the section or to the picture file itself.
  • General: The "OpenOffice.org Toolbar Specification" (Section 6.2) refers to "option menu" instead of "context menu".
• 6. "Match Case" CheckBox: I don't understand the descriptive text for "Checked".
• 9. "Dynamic Text Info": Small typo "stirng" --> "s.

--ChristophNoack 23:02, 10 October 2009 (UTC)